સ્થાપન-સંબંધિત નોંધો

લક્ષણ સુધારાઓ

કર્નલ-સંબંધિત સુધારાઓ

ડ્રાઈવર સુધારાઓ

ટેક્નોલોજી પૂર્વદર્શનો

ઉકેલાયેલ મુદ્દાઓ

જાણીતા મુદ્દાઓ

જો તમે Red Hat Enterprise Linux 4.8 CD-ROMs (નેટવર્ક-આધારિત સ્થાપન માટેની તૈયારીમાં, ઉદાહરણ તરીકે) ના સમાવિષ્ટોની નકલ કરી રહ્યા હોય તો માત્ર ઓપરેટિંગ સિસ્ટમ માટે તમે CD-ROMs ની નકલ કરો તેની ખાતરી કરો. પુરવઠીય CD-ROM ની, અથવા સ્તરવાળી ઉત્પાદન CD-ROMs માંની કોઈની પણ નકલ કરશો નહિં, કારણ કે આ Anaconda ની યોગ્ય પ્રક્રિયા માટે જરૂરી ફાઈલો પર ફરીથી લખી નાંખશે.

Red Hat Enterprise Linux સ્થાપિત થઈ જાય પછી જ આ બધી CD-ROM સ્થાપિત થવી જોઈએ.

Red Hat Enterprise Linux 4 સાથે આપવામાં આવતી GRUBની આવૃત્તિ (અને બઘા બદલાવો) સોફ્ટવેર મીરરીંગ(RAID1) ને આઘાર આપતી નથી. આથી કરીને જો તમે RAID1 ના પાર્ટીશન પર Red Hat Enterprise Linux 4 સ્થાપન કરો તો બુટલોડર માસ્ટર બૂટ રેકોર્ડ (MBR) ના બદલે પ્રથમ હાર્ડ ડ્રાઈવ પર સ્થાપીત થશે. આ સીસ્ટમને બૂટ થવા નહી દે.

જો તમારે RAID1 પાર્ટીશન પર Red Hat Enterprise Linux 4 ના સ્થાપન કરવાની ઇરછા હોય તો, પહેલા MBR માંથી કાઇપણ પુન:અસ્તિત્વ બુટલોડરને સાફ રાખવુ જોઇએ.

જ્યારે સિસ્ટમો પર લખાણ સ્થિતિમાં Red Hat Enterprise Linux 4 નું સ્થાપન કરી રહ્યા હોય, ત્યારે જે ફ્લેટ-પેનલ મોનિટરો અને કેટલાક ATI કાર્ડો વાપરો, સ્ક્રિન વિસ્તાર ખસેડાયેલો દેખાઇ શકે છે. જ્યારે આવુ થાય, સ્ક્રિન નાં કેટલાક વિસ્તારો ઢંકાઇ જશે.

જો આવુ થાય તો, પરિમાણ linux nofb સાથે સ્થાપન કરો.

જ્યારે આ પ્રકાશનને Red Hat Enterprise Linux 4.6 માંથી સુધારો કરી રહ્યા હોય, ત્યારે minilogd ઘણાબધા SELinux denials લોગ રાખી શકે છે.આ ભૂલ લોગો હાનિકારક નથી, અને સુમેળ રીતે અવગણી શકાય છે.

પહેલાં, Anaconda કિકસ્ટાર્ટ દસ્તાવેજીકરણમાં (પર સ્થિત થયેલ છે: /usr/share/doc/anaconda-<anaconda-version>/kickstart-docs.txt), કિકસ્ટાર્ટ ફાઇલ સ્થિતિ થયેલમાં વિભાગ એ --driveorder વિકલ્પની વિગત આપી રહ્યુ છે:

BIOS બુટ ક્રમમાં કઇ ડ્રાઇવ પહેલી છે તે સ્પષ્ટ કરો.
                                        

છતાંપણ, --driveorder વિકલ્પ એ સિસ્ટમ પર બધી ડ્રાઇવોની યાદીની જરૂર છે, યાદીમાં પહેલાં દેખાતી પહેલાં બુટ ઉપકરણ સાથે. આ સુધારા સાથે, દસ્તાવેજીકરણને સ્પષ્ટ કરી દેવામાં આવ્યુ છે અને હવે વંચાય છે:

BIOS બુટ ક્રમમાં કઇ ડ્રાઇવ પહેલી છે તે સ્પષ્ટ કરો.
ક્રમ થયેલ યાદીને સિસ્ટમમાં બધી ડ્રાઇવોનો સમાવેશ કરવો જ જોઇએ.
                                        

જ્યારે ક્રમ થયેલ યાદીને સિસ્ટમમાં બધી ડ્રાઇવોનો સમાવેશ કરવો જ જોઇએ તે કિકસ્ટાર્ટ ફાઇલમાં --driveorder વિકલ્પને વાપરી રહ્યા હોય.

Systemtap Red Hat Enterprise Linux 4 માં સંપૂર્ણ આધારભૂત લક્ષણ હવે છે. systemtap એ ચાલી રહેલ Linux સિસ્ટમ વિશે જાણકારી ભેગી કરીને સરળ બનાવવા માટે મુક્ત સોફ્ટવેર (GPL) ઈન્ફ્રાસ્ટ્રક્ચર પૂરું પાડે છે. આ પ્રભાવ અથવા વિધેયાત્મક સમસ્યાની તપાસમાં સહાય કરે છે. systemtap ની મદદથી, વિકાસકર્તાઓને લાંબા સમય સુધી જટિલ અને ભંગાણજનક વાજિંત્ર, પુનઃકમ્પાઈલ, સ્થાપન, અને રીબુટ ક્રમ સુધી જવાની જરૂર નથી કે જે ક્યાં તો માહિતી ભેગી કરવા માટે જરૂરી હોય.

નોંધો કે જે નવાં Red Hat Enterprise Linux અથવા Linux સિસ્ટમો માટે systemtap નાં અમુક લક્ષણો એ કર્નલ લક્ષણોને ગુમ થવા દરમ્યાન Red Hat Enterprise Linux 4 પર કામ કરશે નહિં. કર્નલ utrace ની ગેરહાજરી કોઇપણ વપરાશકર્તા -જગ્યા પ્રોબીંગ માટે આધારને પહેલેથી જ સમાવે છે.

dmidecode એ BIOSes અને motherboard પૂનરાવર્તનો વિશે જાણકારી આપે છે. kernel-utils ની આવૃત્તિ એ આવૃત્તિ 2.2 થી આવૃત્તિ 2.9 સુધીનાં આ સલાહકાર સુધારાઓ સાથે પૂરુ પાડેલ છે. આ આવૃત્તિ એ નવી પ્રક્રિયીઓને ઓળખે છે, PCI-express slots અને devices, અને blade chassis. તે પણ SMBIOS v2.6 સ્પષ્ટીકરણ માટે આધારને વધારવા પ્રસ્તાવ કરે છે.

kernel-utils ની નવી આવૃત્તિ એ આ પ્રકાશનમાં સમાવેલ છે, આવૃત્તિ 20080910 માં Intel માઇક્રોકોડ ફાઇલને સુધારી રહ્યા છે, નવા Intel પ્રોસેસરોને આધાર આપવા માટે.

smartmontools ને નવી HP ProLiant હાર્ડવેરમાં શોધાયેલ CCISS નિયંત્રકોને આધાર આપવા માટે વિસ્તારી દેવામાં આવ્યુ છે.

Samba પેકેજ એ અપસ્ટ્રીમ આવૃત્તિ 3.0.33 માં પુન:આધારિત કરી દેવામાં આવી છે. 3.0.x આવૃત્તિ શ્રેણીઓ એ Samba કોડ આધારની બ્રાન્ચનો ભૂલ સુધારો છે. 3.0.33 માં પુન:આધાર કરવા દ્દારા આપણે ભૂલ સુધારાઓ અને સુરક્ષા સુધારાઓની મહત્વની સંખ્યાને સમાવેશ કરશે. આ પુન:આધાર દ્દારા નવા લક્ષણો ઉમેરાશે નહિં.

આ પુન:આધાર દ્દારા પૂરા પાડેલ અપસ્ટ્રીમ સુધારાઓ પર વધારે જાણકારી માટે, Samba પ્રકાશન નોંધોનો સંદર્ભ લો: http://samba.org/samba/history/samba-3.0.33.html

ipmitool એ અપસ્ટ્રીમ આવૃત્તિ 1.8.11 માં સુધારી દેવામાં આવી છે, કે જે પહેલાંની પ્રકાશન પર ઘણાબધા ભૂલ સુધારાઓ અને ઉન્નત્તિકરણોને પૂરા પાડે છે, નીચેનાંનો સમાવેશ કરી રહ્યા છે:

મહેરબાની કરીને નોંધો કે જે -K આદેશ વાક્ય સ્વીચની વર્તણૂક એ prompt for Kg key થી read Kg key from environment variable માં બદલેલ છે. -Y ફ્લેગ હવે આ સુધારો કરતા પહેલાં -K તરીકે વર્તણૂક કરે છે.

ibmphp મોડ્યુલ એ અપલોડ કરવા માટે સલામત નથી. પહેલાં, મિકેનીઝમ કે જે લોડ ન કરવાનું અપૂરતુ હતુ તેમાંથી ibmphp મોડ્યુલને અટકાવે છે, અને છેવટે અટકેલ ભૂલ અટકેલ છે. આ સુધારા સાથે, લોડ ન કરવાનું સુધારી દેવામાં આવ્યુ છે તેમાંથી આ મોડ્યુલને અટકાવવા માટે પદ્દતિ છે, ભૂલ ને અટકવવાનું અટકાવી રહ્યા છે. છતાંપણ, મોડ્યુલને અનલોડ કરવાનો પ્રયત્ન કરવા દરમ્યાન સંદેશ લોગમાં ચેતવણી ઉદ્ભવી શકે છે, સૂચન કરે છે કે જે મોડ્યુલ એ અનલોડ કરવા માટે સુરક્ષિત નથી. આ ચેતવણીને સલામત રીતે અવગણી શકાય છે.

આ સુધારા સાથે, ભૌતિક મેમરી એ 64GB કરતા વધારે સિસ્ટમો પર 32-bit x86 કર્નલો ચલાવવા માટે 64GB એ મર્યાદિત હશે. કર્નલ એ ૨ અલગ વિસ્તારો: Lowmem અને Highmem માં મેમરી ને અલગ કરે છે. Lowmem એ બધા સમયે કર્નલ સરનામાંની જગ્યામાં માપ થયેલ છે. Highmem, છતાંપણ, જરૂરી હોય તે સમય પ્રમાણે કર્નલ વિન્ડો પાનાંમાં માપ થયેલ છે. જો મેમરી I/Os 64GB કરતા વધારે પરવાનગી આપેલ હોય તો, mem_map (પાનાં એરે તરીકે પણ જાણીતુ છે) માપનો પ્રસ્તાવ કરી શકે છે અથવા Lowmem નાં માપને વધારી શકે છે. જો આ બને તો, બુટ દરમ્યાન કર્નલ ભયભીત થાય છે અથવા નિયત સમય પહેલા શરૂ થાય છે. પછીની સ્થિતીમાં, કર્નલ એ બુટીંગ અને ક્યાંતો ગભરાટ અથવા અટકવા પછી કર્નલ મેમરીને ફાળવવા માટે નિષ્ફળ જાય છે.

પહેલાં, જો વપરાશકર્તા એ હાર્ડવેર અવરોધ અને ટાઇમર એવરોધ શોધેલ હતુ તેની વચ્ચે અવરોધ રેશ શરતને Hardware Virtual Machine (HVM) પર સતત એરો કીઓ ને દબાવેલ હોય તો. પરિણામ પ્રમાણે, કિબોર્ડ ડ્રાઇવર અજ્ઞાત કિકોડ ઘટનાઓનો અહેવાલ કરેછે. આ સુધારા સાથે, i8042 પોલીંગ ટાઇમર એ દૂર કરી દેવામાં આવ્યુ છે, કે જે આ મુદ્દાને સુધારે છે.

આ સુધારા સાથે, diskdump ઉપયોગિતા (કે જે vmcore કર્નલ ડમ્પોને ભેગુ કરવા અને બનાવવા માટે સક્ષમતા પૂરી પાડે છે) એ હવે sata_svw ડ્રાઇવર સાથે વાપરવા માટે આધારભૂત છે.

આ સુધારા સાથે, "swap_token_timeout" પરિમાણ ને /proc/sys/vm માં ઉમેરી દેવામાં આવ્યુ છે.

આ ફાઇલ એ સુરક્ષિત ટોકનને સ્વેપ કરવાનાં યોગ્ય સમયને સમાવે છે. Linux Virtual Memory (VM) ઉપસિસ્ટમ ની પાસે ટોકન આધારિત થયેલ થ્રેશીંગ નિયંત્રણ મીકેનીઝમ છે અને થ્રેશીંગ પરિસ્થિતિમાં બિનજરૂરી પાનાંની ભૂલોને અટકાવવા માટે ટોકન. કિંમતનો એકમ `સેકંડ` માં છે. કિંમત એ થ્રેશીંગ વર્ણતૂકને ટ્યુન કરવા માટે ઉપયોગી છે. 0 થી તેને સુયોજિત કરવા દરમ્યાન તે સ્વેપ ટોકન મીકેનીઝમને નિષ્ક્રિય કરશે.

પહેલાં, જ્યારે NFSv4 (Network File System Version 4) ક્લાઇન્ટ મુદ્દાઓને શોધેલ હતુ ત્યારે readdir() મદદથી ડિરેક્ટરી પ્રક્રિયા કરી રહ્યુ છે, આખા readdir() કોલ માટે ભૂલ પાછી મળેલ હતી. આ સુધારા સાથે, fattr4_rdattr_error ફ્લેગ હવે સુયોજિત છે જ્યારે readdir() એ કોલ થયેલ હોય, તેની પર સતત સર્વરને સૂચના આપી રહ્યા છે અને ચોક્કસ ડિરેક્ટરી પ્રવેશ પર ભૂલનો અહેવાલ લો કે જે મુદ્દાનું કારણ હતુ.

પહેલાં, NFS (Network File System) ક્લાઇન્ટ એ readdir() વિધેય માંથી મેલફોર્મ થયેલ જવાબો સંભાળાતા ન હતા. પરિણામે, સર્વરમાંથી જવાબ એ સૂચવે છે કે જે readdir() વિધેયનો કેલ એ સફળતાપૂર્વક હતો, પરંતુ જવાબ એ નોંધણીઓને સમાવે છે. આ સુધારા સાથે, readdir() જવાબ પદચ્છેદન લોજીક ને બદલી દેવામાં આવ્યુ છે, જેવુ કે જે મેલફોર્મ થયેલ જવાબ મળેલ છે, ક્લાઇન્ટ એ EIO ભૂલને પાછી લાવે છે.

RPC ક્લાઇન્ટ એ મેમરીમાં સ્થાન પર portmap કોલનાં પરિણામનો સંગ્રહ કરે છે કે જે મુક્ત થઇ શકે છે અને સાચી પરિસ્થિતિઓની હેઠળ ફરીથી ફાળવેલ છે. છતાંપણ, અમુક પરિસ્થિતિઓ હેઠળ, portmap નું પરિણામ ઘણુ વહેલુ મેમરીમાંથી મુક્ત થયેલ હતુ, કે જે મેમરી ભ્રષ્ટાચારમાં પરિણમી શકે છે. આ સુધારી સાછે, ગણતરીનો સંદર્ભ એ મેમરી સ્થાનમાં ઉમેરી દેવામાં આવ્યુ છે જ્યાં portmap પરિણામનો સંગ્રહ થયેલ છે, અને તે વાપરી દેવામાં આવ્યુ છે તે પછી ફક્ત તેને મુક્ત કરાશે.

અમુક પરિસ્થિતિઓ હેઠળ, RPC માટે અમુક માહિતી બંધારણોની માહિતીની ફાળવણીને બ્લોક કરી દેવામાં આવી છે જ્યારે સિસ્ટમ મેમરી નીચી હોય. પરિણામે, ડેડલોક એ વધારે મેમરી દબાણ હેઠળ કદાચ શોધાઇ દેવામાં આવી છે જ્યારે ત્યાં writeback રાહ જોતી NFS પાનાંઓની વિશાળ સંખ્યા હતી. આ સુધારા સાથે, આ માહિતી બંધારણોની ફાળવણી હવે બ્લોક કરવામાં આવી નથી, કે જે આ મુદ્દાને સુધારે છે.

પહેલાં, હલકો પાડેલ પ્રભાવ એને કદાચ શોધી દેવામાં આવ્યો છે જ્યારે સમકાલીક રીતે LVM મીરર થયેલ વોલ્યુમ ને લખી રહ્યા હોય ત્યારે (O_SYNC ફ્લેગની મદદથી). પરિણામે, મીરર થયેલ વોલ્યમુમાં પ્રત્યેક લખાણ I/O એ 3ms દ્દારા વિલંબ થયેલ હતુ, મીરર થયેલ વોલ્યુમમાં પરિણામ લિનીઅર વોલ્યુમ કરતા આશરે 5-10 સમયો ધીમુ છે. આ સુધારા સાથે, I/O કતાર અનપ્લગીંગ એ dm-raid1 ડ્રાઇવર માં ઉમેરી દેવામાં આવ્યુ છે, અને મીરર થયેલ વોલ્યુમોનો પ્રભાવ લિનીઅર વોલ્યુમો સાથે સરખાવા માટે સુધારી દેવામાં આવ્યુ છે.

નવું ટ્યુનીંગ પરિમાણ એ તે ચાલે છે તેનાં દરેક સમયે પુનરાવૃત્તિ પ્રતિ બદલેલ પાનાંઓ ડિસ્ક પર લખે છે તેનાં મહત્તમ નંબરને બદલવા માટે સિસ્ટમ વહીવટકર્તાઓને પરવાનગી આપવા માટે ઉમેરી દેવામાં આવી છે. આ નવુ ટ્યુનેબલ (/proc/sys/vm/max_writeback_pages) 1024 (4MB) ની કિંમતને મૂળભૂત છે તેથી કે જે 1024 પાનાંઓનુ મહત્તમ kupdate માં દરેક ઇટરેશન પર લખાયેલ છે. આ કિંમતને વધારવાનું કેટલું આક્રમક રીતે kupdate એ બદલેલ પાનાંઓને ફ્લશ કરે છે તે બદલે થે અને માહિતીને ગુમાવવાનું શક્તિશાળી સંખ્યાને ઘટાડે છે જો સિસ્ટમ એ kupdate ચલાવવા વચ્ચે ભાંગે છે. છતાંપણ, max_writeback_pages કિંમતને વધારવા દરમ્યાન સિસ્ટમો પર નકારાત્મક પ્રભાવ પડી શકે છે કે જે I/O લોડોમાં સંવેદનશીલ છે.

નવી પરવાનગી મળેલ કિંમત એ /proc/sys/kernel/wake_balance ટ્યુન થાય તેવા પરિમાણમાં ઉમેરી દેવામાં આવ્યુ છે. 2 ની કિંમતમાં wake_balance ને સુયોજિત કરવા દરમ્યાન શ્રેષ્ટ CPU પર તેને ગોઠવવા કરવા કરતાં કોઇપણ ઉપલ્બધ CPU પર થ્રેડને ચલાવવા માટે ગોઠવાનાર ને સૂચન કરશે. 2 નાં આ કર્નલ પરિમાણને સુયોજિત કરવા દરમ્યાન કુલ સિસ્ટમ આઉટપુટ મારફતે કિંમત પર આખી ગુપ્તતા ને ઘટાડવા માટે ગોઠવનારને દબાણ કરશે.

જ્યારે ડિરેક્ટરી ટ્રીને ચકાસી રહ્યા હોય ત્યારે, કર્નલ મોડ્યુલ એ અમુત પરિસ્થિતિઓમાં કરી શકે છે, નક્કી કરેલ અયોગ્ય ટ્રી એ વ્યસ્ત ન હતી. વ્યસ્તતા ચકાસણી તરફ ગણતરી ન કરવા માટે ફાઇલ સંભાળવાને કારણે નિવૃતિ માટે ખુલ્લી ફાઇલ સાથે સક્રિય ઓફસેટ માઉન્ટ એ વાપરેલ હતુ. માઉન્ટ સૂચનોમાં આ પરિણામ થયેલ એ પહેલેથી જ માઉન્ટ થયેલ ઓફસેટો માટે બનાવેલ હતુ. આ સુધારા સાથે, કર્નલ મોડ્યુલ ચકાસવાનું યોગ્ય બનાવી દેવામાં આવ્યુ છે અને અયોગ્ય માઉન્ટ સૂચનો એ લાંબા સમય સુધી ઉત્પન્ન નહિં થાય.

સિસ્ટમનાં પ્રારંભ દરમ્યાન, CPU વિક્રેતા એ Advanced Programmable Interrupt Controllers (APICs) નાં પ્રારંભ પછી શોધાયેલ હતુ. પરિણામે, 8 કોરો કરતા વધારે x86_64 AMD સિસ્ટમો પર છે, APIC કલસ્ટર થયેલ મોડ વપરાયેલ હતુ, ઉપશ્રેષ્ટ સિસ્ટમ પ્રભાવમાં પરિણામ આપી રહ્યા છે. આ સુધારા સાથે, CPU વિક્રેતા એ APICs નો પ્રારંભ કરતા પહેલાં હવે પ્રશ્ર્ન થયેલ છે, APIC ભૌતિક ફ્લેટ સ્થિતિમાં પરિણામ મૂળભૂત રીકે વાપરેલ હતુ, કે જે આ મુદ્દાને સુધારે છે.

Common Internet File System (CIFS) કોડ એ Red Hat Enterprise Linux 4.8 માં સુધારી દેવામાં આવ્યો છે, ભૂલોનાં નંબરને સુધારો કરી રહ્યા છે કે જે અપસ્ટ્રીમમાં સુધારી દેવામાં આવી છે, નીચેનાં બદલાવનો સમાવેશ કરી રહ્યા છે:

પહેલાં, જ્યારે Unix એક્સટેન્શનો વગર સર્વરને માઉન્ટ કરી રહ્યા હોય ત્યારે, તે ફાઇલની સ્થિતિને બદલવાની શક્યતા હતી. છતાંપણ, આ સ્થિતિ બદલાવને કાયમ માટે સંગ્રહ કરી શકાયુ નહિં, અને કોઇપણ સમયે મૂળભૂત સ્થિતિમાં પાછુ બદલી શકાય છે. આ સુધારા સાથે, ફાઇલની સ્થિતિ એ મૂળભૂત દ્દારા કામચલાઉ રીતે બદલી શકાતી નથી; chmod() કોલો એ સફળતાને પાછી લાવશે, પરંતુ અસર થશે નહિં. નવું માઉન્ટ વિકલ્પ, dynperm ને વાપરવા માટે જરૂર છે જો જૂની વર્ણતૂકની જરૂરિયાત હોય તો.

પહેલાં, કર્નલમાં, dio_bio_end_aio() અને dio_await_one() વચ્ચે race condition ને શોધી દેવામાં આવી હતી. આ સ્થિતિને વધારે છે જ્યાં સીધુ I/O એ I/O પ્રક્રિયા પર અસ્પષ્ટ રીતે રીહ જોવાનું છોડી દીધુ છે કે જે પહેલેથી સમાપ્ત થયેલ છે. આ સુધારા સાથે, આ સંદર્ભ ગણતરી ક્રિયાઓ હવે તાળુ મારેલ છે કે જે સોંપવાનું અને સમાપ્ત પાથો એ એકીકૃત સ્થિતિમાં જોવાય છે, કે જે આ મુદ્દાને સુધારે છે.

પહેલાં, Red Hat Enterprise Linux 4 ની નવી આવૃત્તિઓમાં Red Hat Enterprise Linux 4.6 (kmod-xenpv પેકેજ સાથે સ્થાપિત થયેલ છે) માંથી સંપૂર્ણ વર્ચ્યુઅલાઇઝ થયેલ સિસ્ટમને સુધારો કરવા દરમ્યાન બિલ્ટઇન કર્નલ મોડ્યુલો: xen-vbd.ko & xen-vnif.ko અને જૂનું xen-platform-pci.ko મોડ્યુલ વચ્ચે અયોગ્ય મોડ્યુલ આધારમાં પરિણમેલ છે. પરિણામે, xen-vbd.ko બ્લોક ડ્રાઇવર મારફતે માઉન્ટ થયેલ ફાઇલ સિસ્ટમો, અને xen-vnif.ko નેટવર્ક ડ્રાઇવરની મદદથી મહેમાન નેટવર્કીંગ નિષ્ફળ થશે.

Red Hat Enterprise Linux 4.7 માં, xen-platform-pci.ko માં કાર્યત્મકતા કર્નલમાં બિસ્ટ-ઇન હતી. છતાંપણ, જ્યારે ઔપચારિક રીતે લોડ થઇ શકે તેવુ કર્નલ મોડ્યુલ એ કર્નલનો ભાગ બને છે ત્યારે, હાલનાં લોડ કરી શકાય તેવા મોડ્યુલો માટે સંકેત આધારિત ચકાસણી યોગ્ય રીતે module-init-tools માં માટે ગણતરી થયેલ નથી. આ સુધારા સાથે, xen-platform-pci.ko કાર્યત્મકતા એ બિલ્ટ-ઇન કર્નલમાંથી દૂર કરી દેવામાં આવી છે અને લોડ કરી શકાય તેવા મોડ્યુલમાં પાછી સ્થિત થયેલ છે, ચકાસણી માટે module-init-tools ને પરવાનગી આપી રહ્યા છે અને કર્નલ સુધારા દરમ્યાન યોગ્ય આધારો બનાવો.

પહેલાં, 64-બીટ યજમાન પર પેરાવર્ચ્યુઅલાઇઝ થયેલ બ્લોક ડ્રાઇવર(xen-vbd.ko) ની મદદથી 32-બીટ Red Hat Enterprise Linux 4.6 સંપૂર્ણ વર્ચ્યુઅલાઇઝ થયેલ મહેમાનમાં ડિસ્કો અથવા પાર્ટીશનોને માઉન્ટ કરવા માટે પ્રયત્ન કરવા દરમ્યાન નિષ્ફળ જઇ શકે છે. આ સુધારા સાથે, બ્લોક આગળનું ડ્રાઇવર (block.c) બ્લોક પાછળનાં ડ્રાઇવરને જણાવવા માટે સુધારી દેવામાં આવ્યુ છે કે જે મહેમાન એ 32-બીટ પ્રોટોકોલ વાપરી રહ્યુ છે, કે જે આ સુધારાને સુધારે છે.

પહેલાં, આપમેળે બેર મેટલ કર્નલ એ આપમેળે /proc/xen ડિરેક્ટરીને બનાવેલ છે તેની પર pv-on-hvm ડ્રાઇવરોને સ્થાપિત કરી રહ્યા છે. પરિણામે, કાર્યક્રમો કે જે ચકાસો જો સિસ્ટમ એ હાલની /proc/xen ડિરેક્ટરીને ચકાસવા દ્દારા વર્ચ્યુઅલાઇઝ થયેલ કર્નલને ચલાવવી રહ્યા હોય તો તે અયોગ્ય રીતે ધારેલ હોઇ શકે છે કે જે વર્ચ્યુઅલાઇઝ થયેલ કર્નલને વાપરેલ છે. આ સુધારા સાથે, pv-on-hvm ડ્રાઇવરો ને ડિરેક્ટરીને બનાવવા માટે લાંબો સમય નહિં લાગે, કે જે આ મુદ્દાને સુધારે છે.

પહેલાં, પેરાવર્ચ્યુઅલાઇઝ થયેલ મહેમાનો પાસે ફક્ત મહત્તમ 16 ડિસ્ક ઉપકરણો છે. આ સુધારા સાથે, આ મર્યાદાને મહત્તમ 256 ડિસ્ક ઉપકરણોને વધારી દેવામાં આવ્યુ છે.

ALSA માં Intel® High Definition Audio (HDA) ડ્રાઇવરને સુધારી દેવામાં આવ્યુ છે. આ સુધારો HDA એકત્રિત કરેલ ઓડિયો સાથે નવાં હાર્ડવેર માટે ઓડિયો આધારને પૂરુ પાડે છે.

પહેલાં, forcedeth ડ્રાઇવરની મદદથી નેટવર્ક ઉપકરણો એ જવાબ આપવાનું અટકાવી શકે છે જ્યારે ઘણાબધા ક્લાઇન્ટોમાંથી rcp આદેશને કરી રહ્યા હોય. આ સુધારા સાથે, forcedeth ડ્રાઇવરને સુધારી દેવામાં આવ્યુ છે, કે જે આ મુદ્દાને સુધારે છે.

પહેલાં, Automatic Direct Memory Access (ADMA) સ્થિતિ એ sata_nv ડ્રાઇવરમાં મૂળભૂત રીતે સક્રિય થયેલ હતી, પરિણામે, ઉપકરણ ભૂલો અને સમયસમાપ્તિઓ એ અમુક ઉપકરણો સાથે કદાચ શોધી દેવામાં આવી છે કે જે sata_nv ડ્રાઇવરનો ઉપયોગ કરો. આ સુધારા સાથે, ADMA સ્થિતિ એ હવે મૂળભૂત દ્દારા નિષ્ક્રિય થયેલ છે, કે જે આ મુદ્દાને સુધારે છે.

virtio માટે ડ્રાઇવરો, KVM માં I/O વર્ચ્યુઅલાઇઝેશન માટે પ્લેટફોર્મ એ Linux Kernel 2.6.27 માંથી Red Hat Enterprise Linux 4.8 માં બેકપોર્ટ કરી દેવામાં આવ્યુ છે. આ ડ્રાઇવરો I/O પ્રભાવનાં ઉચ્ચ સ્તરને પ્રપ્ત કરવા માટે KVM મહેમાનોને સક્રિય કરશે. વિવિધ વપરાશકર્તા જગ્યા ઘટકો: anaconda, kudzu, lvm, selinux અને mkinitrd એ virtio ઉપકરણોમાં આધાર આપવા માટે પણ સુધારી દેવામાં આવ્યો છે.

r8169 ડ્રાઇવર ને નવી નેટવર્ક ચીપસેટો માટે આધાર પૂરો પાડવા માટે સુધારી દેવામાં આવ્યુ છે. આ સુધારા સાથે, RTL810x/RTL8168(9) નાં બધા બદલાવો એ હવે Red Hat Enterprise Linux 4.8 માં આધારભૂત છે.

mptsas ડ્રાઇવર એ આવૃત્તિ 3.12.29.00 માં સુધારી દેવામાં આવ્યુ છે. આ સુધારો ભૂલ સુધારાઓને સમાવે છે અને નીચેનાં નવા લક્ષણોને સક્રિય કરે છે:

lpfc ડ્રાઇવર એ 8.0.16.46 ની આવૃત્તિ નંબરમાં સુધારી દેવામાં આવ્યુ છે. આ સુધારો ઘણબધા ભૂલ સુધારાઓ અને ઉન્નત્તીકરણોને લાગુ કરે છે, સમાવેશ કરી રહ્યા છે:

SAS આધારિત RAID નિયંત્રકો માટે megaraid_sas ડ્રાઇવર એ આવૃત્તિ 4.01-RH1 માં સુધારી દેવામાં આવ્યુ છે. ઘણાબધા ભૂલ સ્થિરતા અને સુધારાઓ એ આ સુધારા દ્દારા લાગુ પડેલ છે, સમાવેશ કરી રહ્યા છે:

IBM eServer System P માટે eHEA ઇથરનેટ ઉપકરણ ડ્રાઇવર એ આવૃત્તિ 0078-08 માં સુધારી દેવામાં આવી છે.

EHCA infinband ઉપકરણ ડ્રાઇવર એ Red Hat Enterprise Linux 4.8 અને બધા ભવિષ્યનાં Red Hat Enterprise Linux 4 પ્રકાશનો માટે આધારભૂત હશે નહિં.

પહેલેથી,જો Red Hat Network applet એ વિવિધ Red Hat Satellite Server માં ક્લાઇન્ટને પુન:રજીસ્ટર કરવા માટે વાપરેલ હોય તો, એપલેટ સુધારો બતાવવા માટે ચાલુ રહેશે કે જે પહેલાંના સર્વર પર ઉપલ્બધ હતુ, જો તેઓ હાલનાં સર્વર પર ઉપલ્બધ ન હોય તો. /etc/sysconfig/rhn/rhn-applet નવાં સર્વરની વિગતોની અસરોને બદલવામાં આવતી નથી. એપલેટની આવૃત્તિ સર્વર url સાથએ સુધારાઓની કેશને અનૂકુળ આ સુધારા સાથે પૂરુ પાડેલ છે, અને તે માટે ખાતરી કરો કે જે સુધારો વપરાશકર્તા ખરેખર ઉપલ્બધ છે તે દર્શાવેલ છે. આ આવૃત્તિ પણ શોધી શકે છે જ્યારે તેની રૂપરેખાંકન ફાઇલ બદલેલ હોય ત્યારે. જો થોડા બદલાવ શોધેલ હોય તો, એપલેટ એ આપમેળે રૂપરેખાંકન ચલોને પુન:લોડ કરશે અને નવા સર્વર જોડાણોને બનાવશે.

sysreport.legacy એ તેની રુટ ડિરેક્ટરી તરીકે $HOME ને વાપરેલ છે. જો આવુ થાય તો આ પર્યાવરણ ચલ અસ્તિત્વ ધરાવતુ નથી અથવા તે સંદર્ભ થયેલ ડિરેક્ટરી એ લખી શકાય તેવુ ન હતુ, sysreport.legacy એ તેનાં અહેવાલને ઉત્પન્ન કરી શક્યા નહિં અને સંદેશ Cannot make temp dir સાથે બહાર નીકળે છે. Sysreport.legacy હવે તેની રુટ ડિરેક્ટરી તરીકે ગમેતેમ બનાવેલ ડિરેક્ટરીને વાપરે છે અને માટે $HOME વાપર્યા વરગ સિસ્ટમ પર અહેવાલને ઉત્પન્ન કરી શકાય છે.

automount ડિમન એ સ્થાનિક ઇન્ટરફેસો વિશે SIOCGIFCONF ioctl માંથી જાણકારી મેળવવા માટે લાંબુ 128 બાઇટોની સ્થિર બફર માપ વપરાયેલ છે જ્યારે આપેલ માઉન્ટમાં અનૂકુળ યજમાનની નિકટતા માટે ચકાસી રહ્યા હોય ત્યારે. દરેક ઇન્ટરફેસની વિગતો 40 બાઇટો લાંબી છે, ડિમન સ્થાનિક ઇન્ટરફેસો કરતા નહિં પર જાણકારીને મેળવી શકે છે. જો માઉન્ટ કરવા માટે અનૂકુળ યજમાન પાસે સરનામું હોત તો કે જે સ્થાનિક હતુ પરંતુ નિકટતા માટે ત્રણ ઇન્ટરફેસોનાં એકને અનૂકુળ ન હતુ જે અયોગ્ય રીતે વર્ગીકૃત કરેલ છે.

automount ડિમન એ હવે ગતિશીલ રીતે બફરને ફાળવે છે, ખાતરી કરો કે જે NFS mount માટે આપેલ યજમાનની નિકટતા યોગ્ય રીતે શોધવા માટે ક્ષમતા પૂરી પાડેલ સિસ્ટમ પર બધા ઇન્ટરફેસો પર જાણકારી સમાવવા માટે પૂરતી છે.

Automount નક્ષાની નોંધણીઓ કે જે માઉન્ટ સ્થાન (નકલી થયેલ માઉન્ટ) માં ઘણાબધા મહેમાનોનો સંદર્ભ લો, automount ડિમન એ તેની નિકટતા અને NFS આવૃત્તિ માટે દૂરસ્થ યજમાનોની યાદીને પ્રોબ કરે છે. જો યજમાનો જવાબ આપવા માટે નિષ્ફળ જાય તો, તેઓ યાદીમાંથી દૂર થયેલ છે. જો દૂરસ્થ યજમાનો કોઇપણ રીતે જવાબ ન આપતા હોય તો, યાદી ખાલી થઇ શકે છે. પહેલાં, ડિમન એ ચકાસતુ ન હતુ જો યાદી એ નીચેનાં પ્રોબ ખાલી હોય તો કે જે સેગમેન્ટેશન ખરાબીને આગળ કરશે (NULL પોઇંટરને સંદર્ભ કર્યા વગર). આ ચકાસવાનું ઉમેરી દેવામાં આવ્યુ છે.

ttfonts-zh_CN પેકેજ એ Zhong Yi Song TrueType ફોન્ટ એ અગાઉ સમાવેલ છે. Beijing Zhong Yi Electronics Co ને જોડાયેલ આ ફોન્ટમાં copyright, કે જે Red Hat નામની હેઠળ પ્રોડક્ટો અને સોફ્ટવેરમાં ફક્ત ફોન્ટને વહેંચણી કરવા માટે Red Hat Inc. તરીકે લાઇસન્સ થયેલ છે. ttfonts-zh_CN માં આ ફોન્ટનો આ સમાવેશ મુક્ત રીતે વહેંચણી કરતા આ પેકેજમાંથી Red Hat નો પહેલેથી સમાવેશ કરેલ હશે. Zhong Yi Song TrueType ફોન્ટ એ હજુ fonts-chinese-zysong પેકેજમાં Red Hat Network અને વધારાનાં CD મારફતે Red Hat ગ્રાહકોને ઉપલ્બધ છે.

multipathd dead but pid file exists સાથેની સ્થિતિ સાથે ભંગાણ થયેલ છે જ્યારે મલ્ટીપાથ એ 1024 અથવા વધારે પાથો માટે રૂપરેખાંકિત થયેલ હતુ, કારણ કે દરેક પાથ માટે ફાઇલ વર્ણનકર્તા ખોલવા માટે અસમર્થ હતુ. આ error calling out /sbin/mpath_prio_ontap /dev/[device] ભૂલોનાં કારણે થયેલ હોઇ શકે છે. હવે, નવું multipath.conf પરિમાણ, max_fds, ફાઇલ વર્ણનકર્તાઓની મહત્તમ સંખ્યાને સુયોજિત કરવા માટે વપરાશકર્તાને પરવાનગી આપે છે કે જે multipathd પ્રક્રિયા એ ખુલ્લી થઇ શકે છે, અથવા સિસ્ટમ મહત્તમની સંખ્યાને સુયોજિત કરવા માટે max ને વાપરવા માટે પરવાનગી આપે છે. max_fds એ ક્યાંતો પૂરતી ઊંચી સંખ્યા અથવા multipathd માં આ ભંગાણને અવગણવા માટે સુયોજિત કરી રહ્યા છે.

પહેલાં, જ્યારે Adaptec 2120S અથવા Adaptec 2200S નિયત્રકો સાથે accraid ડ્રાઇવરને વાપરી રહ્યા હોય ત્યારે, સિસ્ટમ એ બુટઅપ દરમ્યાન નિષ્ફળ થઇ શકે છે, ભૂલને પાછુ મેળવી રહ્યા છે: aac_srb:aac_fib_send failed with status 8195. આ સુધારા સાથે, accraid ડ્રાઇવરને સુધારી દેવામાં આવ્યુ છે, કે જે આ મુદ્દાને સુધારે છે.

SOS એ સાધનોનાં સમૂહ છે કે જે સિસ્ટમનાં હાર્ડવેર અને હાલનાં રૂપરેખાંકન વિશે જાણકારીને ભેગી કરે છે. જાણકારી એ હેતુઓ અને ડિબગીંગ ને નિદાન કરવા માટે વાપરી શકાય છે.

આ સુધારા સાથે, sosreport દ્દારા ઉત્પન્ન થયેલ અહેવાલો એ હવે જાણકારીનાં પાંચ પ્રકારોને સમાવે છે કે જે પહેલેથી સંગ્રહ થયેલ ન હતુ:

automount એ umount(8) ને વાપરે છે જ્યારે નિવૃત્ત માઉન્ટો અને umount(8) એ જવાબ આપવા માટે અસ્પષ્ટ રીતે રીહ જોઇ શકે છે. સરખી પ્રક્રિયા (એ છે, માઉન્ટ કે જે આપેલ ઓટોમાઉન્ટ પ્રક્રિયાને વ્યવસ્થિત કરવામાં છે) માં સમયનાં લાંબા ગાળા માટે નિવૃત્ત ન કરવા માટે માઉન્ટો ને કારણે બ્લોક થયેલ ને નિવૃત્ત કરવા માટે આગળ થઇ શકે છે. પરિણામે, જો સર્વર પહોંચેલ ન હોય તો, પછી ઓટોમાઉન્ટ એ કોઇપણ નિવૃત્ત થયેલ માઉન્ટો ને અનમાઉન્ટ કરશે નહિં. સર્વરો પર તે જવાબ આપી રહ્યુ છે. સિસ્ટમોને પછી માઉન્ટોની વિશાળ સંખ્યા સાથે છોડી શકાય છે કે જેને નિવૃત્ત થઇ શકે છે પરંતુ નથી. ઓટોમાઉન્ટ હવે રહેલાં માઉન્ટો માટે છોડી દેવા અને ખસેડતા પહેલા રાહ જોવાનું ઓટોમાઉન્ટ માટે સમયને સ્પષ્ટ કરવા માટે આદેશ વાક્ય વિક્લપને હવે સમાવે છે. નિવૃત્ત થયેલ માઉન્ટોને અટલે અનમાઉન્ટ કરી શકાય છે જો અમુક સર્વરો જવાબ આપે નહિં તો.

ICQ ઇન્ટરનેટ સંદેશ પ્રોટોકોલ સર્વરો તાજેતરમાં બદલાયેલ છે અને ICQ પ્રોટોકોલની નવી આવૃત્તિને વાપરવા માટે હવે ક્લાઇન્ટોની જરૂર છે. Pidgin 2.5.2 સાથે ICQ માં પ્રવેશવા દરમ્યાન (Red Hat Enterprise Linux 4 સાથે ખસેડેલ પહેલાંની આવૃત્તિ) એ પરિણામ તરીકે ભૂલ સંદેશ સાથે નિષ્ફળ થયેલ છે. આ સુધારા સાથે, Pidgin આવૃત્તિ 2.5.5 માં સુધારી દેવામાં આવ્યુ છે, કે જે આ મુદ્દાને સુધારે છે.

પહેલાં, Red Hat Knowledgebase લેખ દસ્તાવેજીકરણ ફાઇબર ચેનલ એ Red Hat Enterprise Linux 4 માં પુન:સ્કેન કરવાનું ચોક્કસ ન હતુ. આ પ્રક્રિયા એ હવે સુધારી દેવામાં આવી છ, અને આની પર દેખી શકો છો: http://kbase.redhat.com/faq/docs/DOC-3942

SSH સર્વરને સફળતાપૂર્વક જોડવા પછી, સર્વર એ SSH ક્લાઇન્ટમાં પાછુ લખાણ આધારિત બેનર પાછુ મેળવા શકે છે. પરિણામે, જો gftp (ગ્રાફીકલ ftp ક્લાઇન્ટ) SSH સર્વરને જોડાવા માટે પ્રયત્ન કરેલ છે કે જે બેનરને પાછુ મેળવે છે, gftp ભૂલ તરીકે બેનરને ઇન્ટપ્રિટ કરે છે, અને જોડાણને બંધ કરો, આ સુધારા સાથે, gftp એ આવૃત્તિ 2.0.18 માં સુધારી દેવામાં આવ્યુ છે, બેનરો સાથે સર્વરોને જોડાવા માટે પરવાનગી આપી રહ્યા છે.

જ્યારે NFS ડિરેક્ટરીમાં એક ફાઇલને અપલોડ કરી રહ્યા હોય ત્યારે, ટાઇમસ્ટેમ્પ એ બદલવા માટે સૂચિત કરી રહ્યુ છે અને ફાઇનો પ્રવેશ સમયો એ યોગ્ય રીતે કદાચ રેકોર્ડ કરી દેવામાં આવતા નથી. આ સુધારા સાથે, ટાઇમસ્ટેમ્પ એ હવે હંમેશા સુધારેલ છે, કે જે આ મુદ્દાને સુધારે છે.

PCI ઉપકરણો માટે kudzu માં પ્રોબીંગ કોડ એ યોગ્ય રીતે અમુક મોડ્યુલોને શોધી શકાયા નહિં કે જે ચોક્કસ PCI વર્ગોને બાંધવા દ્દારા કામ કરે છે, નોંધનીય રીતે, SGI Altix સિસ્ટમો પર sgiioc4 ડ્રાઇવર. આ મોડ્યુલો લોડ થયા વગર, સિસ્ટમ એ ઉપકરણોને શોધશે નહિં કે જે ડ્રાઇવર પર આધારિત છે. પ્રોબીંગ કોડની નવી આવૃત્તિ એ આ સુધારેલ પેકેજમાં સમાયેલ છે, કે જે અસર થયેલ મોડ્યુલોને સફળતાપૂર્વર શોધવા માટે સક્ષમ છે.

Red Hat Enterprise Linux 4.8 માં Logical Volume Manager એ ફાઇલ વર્ણનકર્તા લીકોનો અહેવાલ કરે છે, સ્થાપન આઉટપુટમાં નીચેની પાછી મળેલ નીચેની ભૂલમાં પરિણમે છે:

File descriptor NUM (socket:XXXX) leaked on lvm invocation.
                                        

. આ સંદેશને સલામત રીતે અવગણી શકે છે.

જ્યારે Network File System (NFS) સર્વર મારફતે Red Hat Enterprise Linux 4 ને સ્થાપિત કરી રહ્યા હોય ત્યારે, સ્થાપનાર NFS માઉન્ટ પોઇંટોને યોગ્ય રીતે બંધ કરવા માટે અસમર્થ છે. આ NFS સર્વરનાં ખરાબ વર્તનનું કારણ હોઇ શકે છે. આની સ્થિતિઓમાં Red Hat એ સ્થાપનો માટે HTTP સર્વરને વાપરવાની સલાહ આપે છે.

સિસ્ટમો પર જ્યાં BIOS બંને લેગસિ (acpiphp) and native (pciehp) PCI hotplugging ને કરવા માટે સક્ષમ છે, તે પસંદ થયેલ પદ્દતિને પસંદ કરવા માટે વહીવટકર્તા માટે જરૂરી છે અને સ્પષ્ટ રીતે અનિચ્છનિય પદ્દતિ માટે મોડ્યુલને લોડ કરવાથી Red Hat Enterprise Linux 4 ને અટકાવે છે. આ /etc/modprobe.conf માં અનિચ્છનિય મોડ્યુલને બ્લેક યાદી કરવા દ્દારા પૂરુ થયેલ છે.

Mellanox MT25204 માટેની હાર્ડવેર ચકાસણી ખૂલી ગયેલ છે કે જ્યારે ચોક્કસ ઊંચા-ભારવાળી શરતોમાં આંતરિક ભૂલ ઉદ્દભવે. જ્યારે ib_mthca ડ્રાઈવર આ હાર્ડવેર પર કેટાસ્ટ્રોફીક ભૂલનો અહેવાલ આપે, ત્યારે તે સામાન્ય રીતે વપરાશકર્તા કાર્યક્રમ દ્વારા પેદા કરેલ અખૂટ ક્રિયા અરજીઓની સંખ્યાને સંબંધિત કતાર ઊંડાઈની અપૂરતી સમાપ્તિ સમાપ્તિને સંબંધિત હોય છે.

ડ્રાઈવર હાર્ડવેર પુનઃસુયોજીત કરશે અને આવી ઘટનામાંથી પુનઃપ્રાપ્ત કરશે છતાંય, બધા હાલના જોડાણો ભૂલના સમયે ખોવાઈ જાય છે. આ સામાન્ય રીતે વપરાશકર્તા કાર્યક્રમમાં સેગ્મેન્ટેશન ક્ષતિમાં પરિણમે છે. આગળ, જો ભૂલના સમયે opensm ચાલી રહ્યું હોય, તો પછી તેને યોગ્ય પ્રક્રિયા ફરી શરૂ કરવા માટે જાતે પુનઃશરૂ કરવું પડશે.

openmpi અને lam ની પહેલાની આવૃત્તિમાં ભૂલ એ તમને આ પેકેજોનો સુધારો કરી રહ્યા છે એમાંથી અટકાવી શકે છે. આ એજ ભૂલ up2date ને નિષ્ફળ થવાનુ કારણ બની શકે છે જ્યારે બધા પેકેજોને સુધારી રહ્યા છે.

આ ભૂલ નીચેની ભૂલોમાં મેનીફેસ્ટ કરે છે જ્યારે openmpi અથવા lam સુધારો કરવા માટે પ્રયત્ન કરી રહ્યા હોય છે:

error: %preun(openmpi-[version]) scriptlet failed, exit status 2
                                

આ બગ નીચેની ભૂલમાં મેનીફેસ્ટ કરેલ છે (/var/log/up2date માં પ્રવેશ થયેલ છે) જ્યારે up2date મારફતે બધા પેકેજોનો સુધારો કરવા માટે પ્રયત્ન કરી રહ્યા છીએ:

rpm પરિવહન ચલાવવામા up2date નિષ્ફળ થયેલ છે - %pre %pro નિષ્ફળતા ? .
                                

આથી કે, તમે આ ભૂલો અવગણવા માટે ઓર્ડરમાં પહેલા openmpi અને lam ની જૂની આવૃત્તિઓને જાતે જ દૂર કરવાની જરૂર પડી શકે છે. આવુ કરવા માટે, નીચેનો rpm આદેશ વાપરો:

rpm -qa | grep '^openmpi-\|^lam-' | xargs rpm -e --noscripts --allmatches

જ્યારે LUN રૂપરેખાંકિત ભરનાર પરથી કાઢી નાંખવામાં આવેલ હોય, ત્યારે ફેરફાર યજમાન પર અસરમાં આવતો નથી. આવા કિસ્સાઓમાં, lvm આદેશો ચોક્કસપણ અટકી જશે જ્યારે dm-multipath વપરાય, કારણ કે LUN એ હવે stale બની ગયેલ છે.

આનો ઉકેલ લાવવા માટે, stale LUN ની ચોક્કસ /etc/lvm/.cache માં બધા ઉપકરણન અને mpath કડી પ્રવેશોને દૂર કરો. ક્યા આ પ્રવેશો છે એને શોધી કાઢો, નીચેના સંદેશને ચલાવો:

ls -l /dev/mpath | grep <stale LUN>

ઉદાહરણ માટે, જો <stale LUN> એ 3600d0230003414f30000203a7bc41a00 હોય, તો નીચેના પરિણામો દેખાશે:

lrwxrwxrwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwx--rwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
                                

આનો અર્થ એ થાય કે 3600d0230003414f30000203a7bc41a00 એ બે mpath કડીઓ સાથે જોડાયેલ છે: dm-4 અને dm-5.

આથી, નીચેની લીટીઓ /etc/lvm/.cache માંથી કાઢી નાંખવામાં આવવી જોઈએ:

/dev/dm-4 
/dev/dm-5 
/dev/mapper/3600d0230003414f30000203a7bc41a00
/dev/mapper/3600d0230003414f30000203a7bc41a00p1
/dev/mpath/3600d0230003414f30000203a7bc41a00
/dev/mpath/3600d0230003414f30000203a7bc41a00p1
                                

HA-RAID બે-સિસ્ટમ રૂપરેખાંકન માં, બે SAS એડેપ્ટરો બે સિસ્ટમો માં પ્લગ થયેલ છે અને વહેંચાયેલ SAS ડિસ્ક ડ્રોવરને જોડાયેલ છે. બંને SAS એડેપ્ટરો પર Primary ના Preferred Dual Adapter State લક્ષણોની સુયોજના race શરત અને બે SAS એડેપ્ટરો વચ્ચે અનંત ફેઇલઓવરનુ કારણ ટ્રીગર હોઇ શકે છે. આ એટલા માટે કે એક SAS એડેપ્ટર Primary માં સુયોજિત થઇ શકે છે.

આ ભૂલને અટકાવવા માટે, ખાતરી કરો કે જે એક SAS એડેપ્ટરનો Preferred Dual Adapter State એ None માં સુયોજિત છે જો બીજુ SAS એડેપ્ટર Primary માં સુયોજિત થવુ જોઇએ.

જો તમે hp_sw કર્નલ માડ્યુલને વાપરવુ જરૂરી હોય તો, સુધારાયેલ device-mapper-multipath પેકેજ સ્થાપિત કરો.

સક્રિય/નિષ્ક્રિય સ્થિતી યોગ્ય રીતે વાપરવા અને Linux મશીન માંથી જોડાણો ઓળખવા માટે HP એરેને યોગ્ય રીતે રૂપરેખાંકન કરવુ પડશે. આવુ કરવા માટે નીચેના પગલાઓ કરો:

Red Hat એ EXT3 ફાઇલ સિસ્ટમો પર quota ને વાપરવા માટે અપ્રોત્સાહિત કરે છે. આ એટલા માટે કે અમુક સંજોગોમાં આવુ કરવાથી ડેડલોક નું કારણ થઇ શકે છે.

ચકાસણી દ્દારા એ સામને આવ્યુ છે કે kjournald અમુક વખત અમુક EXT3 ને લગતા કોલઆઉટને બ્લોક કરે છે કે જે quota ચાલતુ હોય એ વખતે વપરાય છે. આથી કરીને, Red Hat આ સમસ્યાને Red Hat Enterprise Linux 4 માં સરખુ કરવાની યોજના નથી કરતી કારણ કે આ બદલાવો ખૂબ ઊંડા હોઇ શકે છે.

નોંધો કે જે આ મુદ્દો Red Hat Enterprise Linux 5 માં હાલ નથી.

Mellanox MT25204 માટેની હાર્ડવેર ચકાસણી ખૂલી ગયેલ છે કે જ્યારે ચોક્કસ ઊંચા-ભારવાળી શરતોમાં આંતરિક ભૂલ ઉદ્દભવે. જ્યારે ib_mthca ડ્રાઈવર આ હાર્ડવેર પર કેટાસ્ટ્રોફીક ભૂલનો અહેવાલ આપે, ત્યારે તે સામાન્ય રીતે વપરાશકર્તા કાર્યક્રમ દ્વારા પેદા કરેલ અખૂટ ક્રિયા અરજીઓની સંખ્યાને સંબંધિત કતાર ઊંડાઈની અપૂરતી સમાપ્તિ સમાપ્તિને સંબંધિત હોય છે.

ડ્રાઈવર હાર્ડવેર પુનઃસુયોજીત કરશે અને આવી ઘટનામાંથી પુનઃપ્રાપ્ત કરશે છતાંય, બધા હાલના જોડાણો ભૂલના સમયે ખોવાઈ જાય છે. આ સામાન્ય રીતે વપરાશકર્તા કાર્યક્રમમાં સેગ્મેન્ટેશન ક્ષતિમાં પરિણમે છે. આગળ, જો ભૂલના સમયે opensm ચાલી રહ્યું હોય, તો પછી તેને યોગ્ય પ્રક્રિયા ફરી શરૂ કરવા માટે જાતે પુનઃશરૂ કરવું પડશે.

જ્યારે તમે ડેસ્કટોપ વહેંચણી જોડાણ આઇકોન પર ડબલ-ક્લિક કરો ત્યારે તેનુ સંદર્ભ મેનુ દર્શાવે છે, નહિં કે જ્યારે ડેસ્કટોપ વહેંચણી જોડાણ આઇકોન પર રાઇટ-ક્લિક કરો. બીજા બધા તેના સંદર્ભ મેનુ દર્શાવે છે જ્યારે તમે તેઓની પર રાઇટ ક્લિક કરો.

જો ib_ehca InfiniBand ડ્રાઇવર એ પોર્ટ auto-detection સ્થિતિમાં લોડ થયેલ છે (મોડયુલ પરિમાણ nr_ports=-1 ની મદદથી), P-over-InfiniBand network interfaces (ibX) એ ઘણું મોડુ ઉપલ્બધ થઇ શકે છે. જ્યારે આ ઉત્પન્ન થાય ત્યારે, ifup ibX આદેશ એ openibd શરૂઆતી સ્ક્રિપ્ટ એ નિષ્ફળ જશે તેમાંથી અદા કરેલ છે; પરિણામે, ibX ઇન્ટરફેસ એ ઉપલ્બધ થશે નહિં.

જ્યારે આ ઉત્પન્ન થાય ત્યારે, સમસ્યાને સુધારવા માટે આદેશ rcnetwork restart ને વાપરો.

IBM Redbook "Implementing InfiniBand in IBM System p (SG247351) પુસ્તિકામાં, Table 6-3 (PDF આવૃત્તિનાં પાનાં 220 પર) ડિબગ કોડ બીટ વ્યાખ્યાઓને વર્ણવે છે, જ્યાં ઘણાબધા HCA ભૂલ નિર્દેશક બીટો એ વર્ણવેલ છે.

નોંધો કે જે eHCA2 એડપ્ટરો સાથે, આ ભૂલ નિર્દેશક બીટોની બીટો 46 અને 47 એ ખોટા વાસ્તવિકતાઓને પાછુ લાવી શકે છે.

HP ICH10 વર્કસ્ટેશનો પર, ઓડિયો એ ફક્ત ફ્રન્ટ 3.5mm જેકો મારફતે સક્રિય થયેલ છે. આથી કે, કોઇપણ ઓડિયો આઉટપુટને મેળવવા માટે અથવા રેકોર્ડીંગ ને વાપરો, તમારે ફ્રન્ટ જેકોમાં હેડફોનો, સ્પીકરો, અથવા માઇક્રોફોનોમાં પ્લગ કરવો જોઇએ. હાલમાં, રેર જેકો, આંતરિક સ્પીકરો, અને મુખ્ય વોલ્યુમ આ વર્કસ્ટેશન માટે કામ કરતુ નથી.

આ સુધારા સાથે, મૂળભૂત PCI એ નીચેનાં મોડલો બદલાયેલ છે તે માટે શોધી રહ્યા અને ક્રમમાં કરી રહ્યા છે:

આ મોડલો એ ઉપકરણ સ્કેનીંગ અને ગણતરી સ્થિતિને વાપરે છે કે જે Red Hat Enterprise Linux 4 અથવા 5 માટે મૂળભૂત નથી. આ HP Proliant મોડલો દ્દારા વપરાયેલ સ્થિતિ એ શોધેલ add-on કાર્ડોમાં પરિણમી શકે છે અને onboard/internal ઉપકરણો કરતા પહેલાં ઉમેરાયેલ છે. આ અનિચ્છનીય ક્રમ એ સમસ્યાનું કારણ થઇ શકે છે જ્યારે Red Hat Enterprise Linux નાં નવા ઉદાહરણોને સ્થાપિત કરી રહ્યા હોય, હાર્ડવેર, અને ભરણપોષણને ઉમેરી રહ્યા છે.

પહેલેથી સંદર્ભ થયેલ HP Proliant મોડલો માટે network interface cards (NIC) નું નંબરીંગ એ બદલાઇ શકે છે જ્યારે તેઓ Red Hat Enterprise Linux 4.7 કર્નલ સાથે સુધારેલ છે. સ્થાપનાર એ NIC નંબરીંગને બદલે છે જો HWADDR=MAC ADDRESS પરિમાણ એ દરેક સ્થાપિત થયેલ NICs માટે /etc/sysconfig/network-scripts/ifcfg-eth[X] માં વ્યાખ્યાયિત થયેલ નથી. આથી કે, Red Hat એ અગ્રહણીય છે કે તમે ખાતરી કરો કે આ પરિમાણ અનિચ્છનિય NIC ગણવામાંથી કોઇપણ સમસ્યાઓને ઉત્પન્ન કરવાનું અવગણવા માટે ક્રમમાં વ્યાખ્યાયિત થયેલ છે.

વધુમાં, Red Hat Enterprise Linux 4.7 માં આ HP Proliant મોડલોને સુધારવા પછી કોઇપણ NIC બદલાવોને ગણવાનું અવગણવા માટે, /boot/grub/grub.conf માં કર્નલ બુટ પરિમાણને ઉમેરો.

જ્યારે વોલ્યુમ જૂથ એ મીરર અથવા સ્નેપશોટને સમાવે છે ત્યારે, વોલ્યુમ જૂથ પરિમાણ સાથે lvchange આદેશ ને અદા કરવા દ્દારા નીચેનાં ભૂલ સંદેશાઓમાં પરિણામ મળી શકે છે:

સીધુ મિરર લોગ LV fail_secondary_mlog ને બદલવામાં નિષ્ફળ
સીધુ મિરર ઇમેજ LV fail_secondary_mimage_0 ને બદલવામાં નિષ્ફળ
સીધુ મિરર ઇમેજ LV fail_secondary_mimage_1 ને બદલવામાં નિષ્ફળ
        

આ સંદેશાઓ એ સલામત રીતે અવગણી શકાય છે.

Dell PowerEdge SC1435s સિસ્ટમો એ બુટઅપ દરમ્યાન અટકી જઇ શકે છે. આ અવગણવા માટે, grub.conf માં terminal લીટીમાં ફેરફાર કરો અને console serial સાથે શબ્દમાળા serial console ને બદલો.

સુધારેલ ixgbe ડ્રાઇવર એ Intel 82598AT (Copper Pond 10GbE) ને આધાર આપતુ નથી.

Red Hat Enterprise Linux 5.3 એ બ્લોક ઉપકરણની નીચે લીટીને વિકસાવવા અથવા સંકોચવાનું ઓનલાઇન શોધી શકાય છે. છતાંપણ, ત્યાં આપોઆપ શોધી શકાય તેવી પદ્દતિ નથી કે જે ઉપકરણ પાસે બદલાયેલ માપ છે, તેથી મેન્યુઅલ પગલાઓ આને ઓળખવા માટે જરૂરી છે અને કોઇપણ ફાઇલ સિસ્ટમોનુ માપ બદલો કે જે આપેલ ઉપકરણો પર રહેલ છે. જ્યારે પુન:માપ થયેલ બ્લોક ઉપકરણ શોધાયેલ હોય ત્યારે, સંદેશ જેવુ કે નીચેનાં સિસ્ટમ લોગોમાં દેખાશે:

VFS: બદલેલ મીડિયા અથવા બદલેલ માપ ડિસ્ક sdi પર આઇનોડો વ્યસ્ત છે
                                

જો બ્લોક ઉપકરણ વિકસેલ હતા, પછી આ સંદેશને સલામત રીતે અવગણી શકાય છે. છતાંપણ, જો બ્લોક ઉપકરણ પહેલા બ્લોક ઉપકરણ પર કોઇપણ માહિતી સુયોજનને સંકોચવા વગર સંકોચાયેલ હતુ, ઉપકરણ પર રહેતી માહિતીએ ખરાબ હોઇ શકે છે.

ફાઇલસિસ્ટમને ઓનલાઇન પુન:માપ કરવા માટે તે ફક્ત શક્યતા છે કે જે આખા LUN (અથવા બ્લોક ઉપકરણ) પર બનાવેલ હતુ. જો ત્યાં બ્લોક ઉપકરણ પર પાર્ટીશન કોષ્ટક હોય તો, પછી ફાઇલ સિસ્ટમ એ પાર્ટીશન કોષ્ટકને સુધારવા માટે અનમાઉન્ટ કરવાની જરૂર પડશે જ.

સુધારનાર રુટીનો (એટલે કે. res_nquery, res_nsearch અને res_nmkquery) સાથે જાણીતી મેમરી લીક છે. પ્રક્રિયાઓ કે જે આ વિધેયને વાપરવાથી સમયથી વધારે મેમરી લીક થશે. glibc ની નવી આવૃત્તિમાં તેને સુધારી દેવામાં આવ્યુ છે, છતાંપણ, સુધારો એ Red Hat Enterprise Linux 4 માં લાગુ કરવા માટે ઘણો આક્રમક છે. પ્રક્રિયાઓ કે જે આ વિધેયોને વાપરવાનું મુક્ત મેમરી માટે અવારનવાર પુન:શરૂ કરવાની જરૂર પડી શકે છે.

ઉપકરણોની સંખ્યા કે જે સ્થાપન initrd ઇમેજનાં માપ પર Red Hat Enterprise Linux 4 આધાર રાખે છે તેનાં સ્થાપન દરમ્યાન સંભાળી શકાય છે. માટે, આવી પરિસ્થિતિઓમાં જ્યાં મશીન (જેવુ કે ભારે જાણીતુ ફાઇબર ચેનલ સુયોજનો) સ્થાપન શક્ય હશે નહિં તેમાં જોડાયેલ ઘણાબધા ઉપકરણો છે નહિં તો દેખાતા ઉપકરણોની સંખ્યા એ ઘટાડેલ છે.

aacraid ડ્રાઇવરને સુધારો કે જે Red Hat Enterprise Linux 4.7 ને એકદમ બરાબર Adaptec PERC3/Di ફર્મવેર ની જરૂર છે તેમાં પહેલા પરિચય આપેલ હતુ. Red Hat Enterprise Linux 4 નાં પછીનાં સુધારાઓ (આ 4.8 સુધારાનો સમાવેશ કરી રહ્યા છે) ની જરૂર છે, કે જે PERC3/Di એ ફર્મવેર એ આવૃત્તિ 2.8.1.7692, A13 અથવા નવા પર છે. ફર્મવેર એ નીચેનાં સ્થાન પર મેળવી શકાય છે:

http://support.dell.com/support/downloads/download.aspx?c=us&cs=555&l=en&s=biz&releaseid=R168387&SystemID=PWE_PNT_PIII_1650&servicetag=&os=WNET&osl=en&deviceid=1375&devlib=0&typecnt=0&vercnt=9&catid=-1&impid=-1&formatcnt=4&libid=35&fileid=228550

anaconda સ્થાપન દરમ્યાન બધા Logical Volume Manager (LVM) મેટાડેટા ને દૂર કરી શકાતુ નથી કે જે સ્થાપન પહેલાં સિસ્ટમ પર અસ્તિત્વ ધરાવે છે. આ વધારાનાં મેટાડેટા એ સ્થાપન પછી ગેરહાજર વોલ્યુમ જૂથ અથવા લોજીકલ વોલ્યુમોનો અહેવાલ કરવા માટે LVM સાધનોનું કારણ બની શકે છે. આ મુદ્દાની આજુબાજુ કામ કરવા માટે, સ્થાપન સમાપ્ત કર્યા પછી વાપરેલ LVM ને દૂર કરો.

multipath એ તેનાં કોલઆઉટ પ્રક્રિયાઓનાં કોઇપણ દ્દારા છપાયેલ ભૂલ સંદેશાઓને શાંત રાખતુ નથી. માટે, જો multipath એ ચાલે છે જ્યારે પાથો નીચે છે, વિવિધ ભૂલ સંદેશાઓને દર્શાવી શકાય છે. સંદેશાઓ કે જે ચોક્કસ કોલઆઉટ પ્રક્રિયાઓ પર આધારને દર્શાવેલ છે કે જે multipath ને વાપરી રહ્યા છે. ઉદાહરણ માટે, જો multipath ચાલે છે જ્યારે scsi ઉપકરણો નિષ્ફળ થાય છે, scsi_id એ છાપશે

<H>:<B>:<T>:<L>:INQUIRY vpd 1 પાનાં 0x0 ને મેળવવામાં અસમર્થ.
<H>:<B>:<T>:<L>:sg_io એ સ્થિતિ 0x0 0x1 0x0 0x0 નિષ્ફળ કરેલ છે
                                        

અથવા, જો multipath -ll એ ચાલે છે જ્યારે EMC CLARiiON એ નીચે છે, mpath_prio_emc priority કોલઆઉટ એ query command indicates error ને છાપશે