પ્રકાશન નોંધો સુધારાઓ

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

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

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

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

અન્ય સુધારાઓ

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

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

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

જ્યારે Red Hat Enterprise Linux 5 ને સંપૂર્ણપણે વર્ચ્યુઅલાઈઝ થયેલ SMP મહેમાન પર સ્થાપિત કરી રહ્યા હોય, તો સ્થાપન અટકી જશે. આ ત્યારે જ થાય જ્યારે યજમાન (dom0) એ Red Hat Enterprise Linux 5.1 ચલાવી રહ્યું હોય.

આને અટકાવવા માટે, મહેમાનને સ્થાપનની મદદથી એક પ્રોસેસર વાપરવા માટે સુયોજીત કરો. તમે આવું virt-install માંના --vcpus=1 વિકલ્પની મદદથી કરી શકો છો. એકવાર સ્થાપન સમાપ્ત થઈ જાય, પછી તમે મહેમાનને SMP માં ફાળવેલ vcpus ને virt-manager માં બદલીને સુયોજીત કરી શકો છો.

આ પ્રકાશન WBEMSMT નો સમાવેશ કરે છે, વેબ-આધારિત કાર્યક્રમોનો સમૂહ કે જે Samba અને DNS માટે વપરાશકર્તા-મૈત્રી વ્યવસ્થાપન ઈન્ટરફેસ પૂરું પાડે છે. WBEMSMT વિશે વધુ જાણકારી માટે, http://sblim.wiki.sourceforge.net/ નો સંદર્ભ લો.

pm-utils ને pm-utils ની Red Hat Enterprise Linux 5.1 બીટા આવૃત્તિમાંથી સુધારવાનું નિષ્ફળ જશે, જે નીચેની ભૂલમાં પરિણમે છે:

ભૂલ: પેટીને /etc/pm/sleep.d ફાઈલ પર ખોલવામાં નિષ્ફળ: cpio: rename

આને થવાથી અટકાવવા માટે, /etc/pm/sleep.d/ ડિરેક્ટરીને સુધારો કરવા પહેલાં કાઢી નાંખો. જો /etc/pm/sleep.d કોઈપણ ફાઈલો સમાવે, તો તમે તે ફાઈલોને /etc/pm/hooks/ માં ખસેડી શકો.

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

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

ડ્રાઈવર સુધારા ડિસ્કો હવે Red Hat ના ડ્રાઈવર સુધારા કાર્યક્રમ RPM-આધારિત પેકેજીંગને આધાર આપે છે. જો ડ્રાઈવર ડિસ્ક નવું બંધારણ વાપરે, તો RPM પેકેજ થયેલ ડ્રાઈવરોને સમાવવાનું શક્ય છે કે જે સિસ્ટમ સુધારાઓમાં સાચવવામાં આવશે.

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

આથી, સિસ્ટમ પર કે જેને વિવિધ કર્નલ ચલો સ્થાપિત થયેયલ હોય, ત્યારે તમારે સિસ્ટમને દરેક કર્નલ ચલ પર બુટ કરવું પડશે અને ડ્રાઈવર RPM સ્થાપિત કરવી પડશે. ઉદાહરણ તરીકે, જો તમારી સિસ્ટમ પાસે એકદમ-ઘાતક અને વર્ચ્યુઅલાઈઝ થયેલ કર્નલ એમ બંને સ્થાપિત હોય, તો તમારી સિસ્ટમને એકદમ-ઘાતક કર્નલની મદદથી બુટ કરો અને ડ્રાઈવર RPM સ્થાપિત કરો. પછી, સિસ્ટમને વર્ચ્યુઅલાઈઝ થયેલ કર્નલમાં પુનઃબુટ કરો અને ડ્રાઈવર RPM ફરી સ્થાપિત કરો.

dom0 ના જીવનકાળ દરમ્યાન, તમે ૩૨,૭૫૦ વખતો કરતાં વધુ મહેમાનો (એટલે કે. xm create) બનાવી શકતા નથી. ઉદાહરણ તરીકે, જો તમારી પાસે લુપમાં પુનઃબુટ થઈ રહેલ મહેમાનો હોય, તો dom0 એ ૩૨,૭૫૦ વખતોના કુલ મહેમાનોમાં પુનઃબુટ કર્યા પછી બુટ કરવામાં નિષ્ફળ જશે.

જો આ ઘટના થાય, તો dom0 પુનઃશરૂ કરો

Red Hat Enterprise Linux 5.1 NFS સર્વર હવે સંદર્ભિત નિકાસોને આધાર આપે છે. આ નિકાસો NFSv4 પ્રોટોકોલના એક્સટેન્સો પર આધારિત હોય છે. કોઈપણ NFS ક્લાઈન્ટો કે જે આ એક્સટેન્સનોને આધાર નહિં આપે (નામ પ્રમાણે, Red Hat Enterprise Linux પ્રકાશનો કે જે 5.1 પહેલાંના હોય) તેઓ આ નિકાસોનો વપરાશ કરવામાં અસમર્થ રહેશે.

આથી, જો NFS ક્લાઈન્ટ આ નિકાસોને નહિં આધાર આપે, તો આ નિકાસોને વાપરવાનો કોઈપણ પ્રયાસ I/O ત્રુટિને કારણે નિષ્ફળ જશે. અમુક કિસ્સાઓમાં, ક્લાઈન્ટ અમલીકરણ પર આધાર રાખીને, નિષ્ફળતા વધુ જોખમી બની શકશે, સિસ્ટમ ભંગાણની શક્યતાનો સમાવેશ કરીને.

NFS સંદર્ભિત નિકાસો ક્લાઈન્ટો દ્વારા વાપરી શકાય તેવા નથી કે જે તેમને આધાર આપતા નથી તેની ખાતરી કરવા માટે એ અગત્યનું છે કે તમે પૂર્વકાળજી લો.

GFS2 એ GFS નું વધતું ઉન્નતીકરણ છે. આ સુધારો ઘણાબધા નોંધપાત્ર સુધારાઓને લાગુ પડે છે કે જેને ડિસ્ક-પર ફાઈલ સિસ્ટમ બંધારણ બદલવાની જરૂર છે. GFS ફાઈલ સિસ્ટમો GFS2 માં gfs2_convert ઉપયોગીતાની મદદથી ફેરવી શકાય છે, કે જે GFS ફાઈલ સિસ્ટમનો મેટાડેટા અનુલક્ષીને સુધારે છે.

Red Hat Enterprise Linux 5 માં તેનો પરિચય થયો ત્યારથી ઘણું સુધારાયું હોવા છતાં, GFS2 ટેક્નોલોજી પૂરવદર્શન તરીકે રહે છે. વિતરણમાં સમાયેલ પ્રકાશન નોંધો અયોગ્ય રીતે કહે છે કે GFS2 એ સંપૂર્ણપણે આધારભૂત છે. છતાંય, બેંચમાર્ક ચકાસણીઓ નીચેના પર ઝડપી પ્રભાવ સૂચવે છે:

વધુમાં, GFS2 નીચેના ફેરફારોનું પણ લક્ષણ આપે છે:

Red Hat Enterprise Linux 5.1 ને HP BL860c બ્લેડ સિસ્ટમો પર સ્થાપિત કરવાનું IP જાણકારી અરજી પગલાં દરમ્યાન અટકી જશે. આ મુદ્દો મેનીફેસ્ટ કરે છે જ્યારે તમારે બરાબર ને TCP/IP રૂપરેખાંકિત કરો સ્ક્રીન પર બેવાર પસંદ કરવો પડે.

જો આવું થાય, તો ઈથરનેટ આપોઆપભાવતાલ નિષ્ક્રિય કરેલ હોય તેની સાથે સ્થાપન કરો અને પુનઃબુટ કરો. આવું કરવા માટે, ethtool="autoneg=off" પરિમાણ ઉમેરો જ્યારે સ્થાપન મીડિયામાંથી બુટ કરી રહ્યા હોય. આવું કરવાનું છેલ્લી સ્થાપિત સિસ્ટમને અસર કરતું નથી.

nohide નિકાસ વિકલ્પ એ સંદર્ભિત નિકાસો માટે જરૂરી છે (એટલે કે. નિકાસો કે જે સંદર્ભિત સર્વર સ્પષ્ટ કરે). આ એના કારણે છે કે સંદર્ભિત નિકાસોને "cross over" બંધ માઉન્ટ બિંદુની જરૂર પડે. nohide નિકાસ વિકલ્પ એ આવા "cross over" ને સફળ બનાવવા માટે જરૂરી છે.

બંધ માઉન્ટો પર વધુ જાણકારી માટે, man exports 5 નો સંદર્ભ લો.

આ સુધારો lvm2 ઘટના મોનીટરીંગ ડિમનનો સમાવેશ કરે છે. જો તમે પહેલાથી જ lvm2 મીરરીંગ વાપરી રહ્યા હોય, તો બધા મોનીટરીંગ વિધેયો યોગ્ય રીતે સુધારાયેલ છે તેની ખાતરી કરવા માટે નીચેના પગલાંઓ ભરો:

Rapid Virtualization Indexing (RVI) એ હવે 64-bit, 32-bit, અને 32-bit PAE કર્નલો પર આધારભૂત છે. છતાંય, RVI માત્ર 32-બીટ મહેમાન વર્ચ્યુઅલ સરનામાઓને 32-bit PAE હાયપરવિઝર પર જ ભાષાંતરિત કરી શકે છે.

આથી, જો 3840MB કરતાં વધુની RAM ધરાવતું મહેમાન PAE કર્નલ ચલાવી રહ્યું હોય, તો ખોટી સરનામા અનુવાદ ભૂલ ઉદ્ભવશે. આ મહેમાનને ભાંગી શકે છે.

એ આગ્રહણીય છે કે તમે 64-બીટ કર્નલ વાપરો જો તમે RVI હેઠળ 4GB ની ભૌતિક RAM કરતાં વધુ પર મહેમાનો ચલાવવા ઈચ્છો.

AMD Rev F પ્રોસેસરો વાપરી રહેલ ૧૬ કોર અથવા વધુ ચલાવવાનું સિસ્ટમ પુનઃસુયોજનોમાં પરિણમી શકશે જ્યારે સંપૂર્ણપણે-વર્ચ્યુઅલાઈઝ થયેલ મહેમાન સ્થાપનો કરી રહ્યા હોય.

systemtap-runtime પેકેજ સ્થાપિત કરવાનું પરિવહન ચકાસણી ભૂલમાં પરિણમશે જો systemtap પેકેજ એ પહેલાથી જ સ્થાપિત થયેલ હોય. આગળ, Red Hat Enterprise Linux 5 ને 5.1 માં સુધારવાનું પણ નિષ્ફળ જશે જો systemtap પેકેજ એ પહેલાથી જ સ્થાપિત થયલે હોય.

આથી, systemtap પેકેજને rpm -e systemtap-0.5.12-1.e15 આદેશની મદદથી systemtap-runtime સ્થાપિત કરવા પહેલાં અથવા સુધારો કરવા પહેલાં દૂર કરો.

જ્યારે NFSROOT સુયોજીત કરી રહ્યા હોય, ત્યારે BOOTPROTO એ BOOTPROTO=dhcp તરીકે /etc/sysconfig/network-scripts/ifcfg-eth0 માં સુયોજીત થયેલ હોવું જ જોઈએ.

જો તમારા પર્યાવરણ માટે BOOTPROTO માટે અલગ સુયોજનો જરૂરી હોય, તો પછી BOOTPROTO=dhcp ને /etc/sysconfig/network-scripts/ifcfg-eth0 માં કામચલાઉ રીતે સુયોજીત કરો શરૂઆતમાં initrd બનાવ્યા પહેલાં. તમે BOOTPROTO ની મૂળ કિંમત initrd બની જાય પછી પુનઃસુયોજીત કરી શકો છો.

IBM Bladecenter માટે QLogic iSCSI Expansion Card એ ઈથરનેટ અને iSCSI વિધેયો બંને પૂરું પાડે છે. કાર્ડ પરના અમુક ભાગો બંને વિધેયો દ્વારા વહેંચાય છે. છતાંય, વર્તમાન qla3xxx અને qla4xxx ડ્રાઈવરો ઈથરનેટ અને iSCSI વિધેયો વ્યક્તિગત રીતે આધાર આપે છે. બંને ડ્રાઈવરો ઈથરનેટ અને iSCSI વિધેયોને વારાફરતી વપરાશને આધાર આપતા નથી.

આથી, ઈથરનેટ અને iSCSI બંને વિધેયો વારાફરતી વાપરવાનું ઉપકરણને અટકાવશે. આ iSCSI ઉપકરણો પર માહિતીના વિનાશ અને ફાઈલસિસ્ટમ બગાડમાં પરિણમી શકશે, અથવા અન્ય જોડાયેલ ઈથરનેટ ઉપકરણો પર નેટવર્ક ભંગાણોમાં પરિણમી શકશે.

જ્યારે virt-manager ને હાલના મહેમાનમાં ડિસ્ક ઉમેરવા માટે વાપરી રહ્યા હોય, ત્યારે એકસરખા પ્રવેશો મહેમાનની /etc/xen/<domain name> રૂપરેખાંકન ફાઈલમાં બની શકે છે. આ એકસરખા પ્રવેશો મહેમાનને બુટ કરવાથી અટકાવશે.

આથી, તમારે આ એકસરખા પ્રવેશો દૂર કરવા જોઈએ.

પુનરાવર્તિત રીતે મહેમાનને બે યજમાનો વચ્ચે ખસેડવાનું એક યજમાનને દુઃખાવાનું કારણ બની શકશે. જો મહેમાનને સિસ્ટમની બહાર કાઢ્યા પછી અને એક જ મહેમાનને પાછું ખસેડ્યા પહેલાં યજમાન પુનઃબુટ થાય, તો દુઃખાવો થશે નહિં.

sysreport એ sos ની સામે દૂર કરવામાં આવેલ છે. sos સ્થાપિત કરવા માટે, yum install sos ચલાવો. આ આદેશ sos સ્થાપિત કરે છે અને sysreport દૂર કરે છે. એ આગ્રહણીય છે કે તમે આનું પરાવર્તન કરવા માટે હાલની કોઈપણ કિકસ્ટાર્ટ ફાઈલો સુધારો.

sos સ્થાપિત કર્યા પછી, તેને જગાવવા માટે sosreport આદેશ વાપરો. sysreport આદેશ વાપરવાનું ચેતવણી આપશે કે જે કહે કે sysreport એ હવે દૂર થઈ ગયેલ છે; ચાલુ રાખવાનું sosreport ને જગાડશે.

જો તમારે sysreport સાધનને ખાસ રીતે વાપરવાની જરૂર હોય, તો તેને જગાડવા માટે sysreport.legacy આદેશ વાપરો.

sosreport વિશે વધુ જાણકારી માટે, man sosreport અને sosreport --help નો સંદર્ભ લો.

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

પુરવઠીય CD-ROM અને અન્ય સ્તરવાળી ઉત્પાદન CD-ROMs ના સમાવિષ્ટો Red Hat Enterprise Linux 5.1 સ્થાપિત થઈ જાય પછી જ સ્થાપિત થવા જોઈએ.

જ્યારે Red Hat Enterprise Linux 5.1 ને સંપૂર્ણપણે વર્ચ્યુઅલાઈઝ થયેલ મહેમાન પર સ્થાપિત કરી રહ્યા હોય, ત્યારે kernel-xen કર્નલ વાપરશો નહિં. આ કર્નલને સંપૂર્ણપણે વર્ચ્યુઅલાઈઝ થયેલ મહેમાનો પર વાપરવાનું તમારી સિસ્ટમને અટકાવવાનું કારણ બની શકે છે.

જ્યારે Red Hat Enterprise Linux 5.1 ને સંપૂર્ણપણે વર્ચ્યુઅલાઈઝ થયેલ મહેમાન પર સ્થાપિત કરી રહ્યા હોય ત્યારે જો તમે સ્થાપન નંબર વાપરી રહ્યા હોય, તો સ્થાપન દરમ્યાન વર્ચ્યુઅલાઈઝેશન પેકેજ જૂથને નાપસંદ કરવાનું ધ્યાન રાખો. વર્ચ્યુઅલાઈઝેશન પેકેજ જૂથ વિકલ્પ kernel-xen કર્નલ સ્થાપિત કરે છે.

નોંધ કરો કે પેરાવર્ચ્યુઅલાઈઝ થયેલ મહેમાનો આ મુદ્દાથી અસર પામતા નથી. પેરાવર્ચ્યુઅલાઈઝ થયેલ મહેમાનો હંમેશા kernel-xen કર્નલ વાપરે છે.

જો તમે વર્ચ્યુઅલાઈઝ થયેલ કર્નલ વાપરી રહ્યા હોય જ્યારે Red Hat Enterprise Linux 5 માંથી 5.1 માં સુધારો કરી રહ્યા હોય, તો તમારે સુધારો સમાપ્ત કર્યા પછી પુનઃબુટ કરવું જ પડશે. પછી તમારે સુધારાયેલ વર્ચ્યુઅલાઈઝ થયેલ કર્નલની મદદથી સિસ્ટમને બુટ કરવી જોઈએ.

Red Hat Enterprise Linux 5 અને 5.1 ના હાયપરવિઝર એ ABI-સુસંગત નથી. જો તમે સુધારાયેલ વર્ચ્યુઅલાઈઝ થયેલ કર્નલની મદદથી સુધારો કર્યા પછી સિસ્ટમ બુટ નહિં કરો, તો સુધારાયેલ વર્ચ્યુઅલાઈઝેશન RPMs ચાલી રહેલ કર્નલ સાથે બંધબેસશે નહિં.

CIFS ક્લાઈન્ટ આવૃત્તિ 1.48aRH માં સુધારાઈ ગયું. આ 1.48a પ્રકાશન પર આધારિત છે, પેચો સાથે કે જે નીચેના ફેરફારો લાગુ કરે છે:

નોંધ કરો કે EMC Celerra ઉત્પાદનના (NAS Code 5.5.26.x અને નીચે) વપરાશકર્તાઓ માટે, CIFS ક્લાઈન્ટ અટકે છે જ્યારે EMC NAS પરના શેરો વાપરી રહ્યા હોય. આ મુદ્દો નીચેના કર્નલ સંદેશાઓ દ્વારા વર્ગીકૃત થયેલ છે:

કર્નલ:  CIFS VFS: સર્વર પ્રત્યુત્તર આપતું નથી
કર્નલ:  CIFS VFS: cmd 162 mid 380 માટે કોઈ પ્રત્યુત્તર નથી
કર્નલ:  CIFS VFS: RFC1001 માપ 135 એ Mid=384 માટેના SMB કરતાં મોટું છે

CIFS માઉન્ટ પછી, તેના પરની કોઈપણ ફાઈલ અને કાર્યક્રમ વાંચવા/લખવાનું અશક્ય બની જાય છે કે જે માઉન્ટબિંદુ પર I/O નો પ્રયાસ કરે તે અટકી જશે. આ મુદ્દો ઉકેલવા માટે, NAS Code 5.5.27.5 અથવા પછીનામાં સુધારો (EMC Primus કેસ નંબર emc165978 વાપરો).

MODULE_FIRMWARE ટેગો હવે આધારભૂત છે.

ICH9 નિયંત્રકો હવે આધારભૂત છે.

Greyhound પ્રોસેસરો હવે CPUID કોલમાં આધારભૂત છે.

Oprofile હવે નવો Greyhound પ્રતિભાવ ગણક ઘટનાઓને આધાર આપે છે.

Directed DIAG એ હવે z/VM ઉપયોગીતાપણું સુધારવા માટે આધારભૂત છે.

Intel ગ્રાફિક્સ ચિપસેટ એ હવે DRM કર્નલ મોડ્યુલ મારફતે આધારભૂત છે. આગળ, DRM API એ આવૃત્તિ 1.3 માં સીધા રેન્ડરીંગને આધાર આપવા માટે સુધારવામાં આવેલ છે.

ACPI પાવર વ્યવસ્થાપનના સુધારાઓએ S3 suspend-to-RAM અને S4 hibernate ને સુધારેલ છે.

gaim એ હવે pidgin તરીકે ઓળખાય છે.

Intel microcode આવૃત્તિ 1.17 માં સુધારાઈ ગયું. આ નવા Intel પ્રોસેસરો માટે આધાર ઉમેરે છે.

dm-multipath ને EMC Clariion સંગ્રહ પર આંતરિક સક્રિય-સક્રિય ફેઈલઓવર વાપરવાનું હવે આધારભૂત છે.

ચીની ફોન્ટ Zysong એ હવે fonts-chinese પેકેજના ભાગ તરીકે ક્યારેય સ્થાપિત થશે નહિં. Zysong એ હવે અલગ રીતે fonts-chinese-zysong તરીકે પેકેજ થયેલ છે. fonts-chinese-zysong પેકેજ પુરવઠીય CD માં સ્થિત થયેલ છે.

નોંધ કરો કે fonts-chinese-zysong પેકેજ એ ચીની રાષ્ટ્રિય પ્રમાણ GB18030 ને આધાર આપવા માટે જરૂરી છે.

Challenge Handshake Authentication Protocol (CHAP) વપરાશકર્તાનામ અને પાસવર્ડને દરેકને 256 અક્ષરની મર્યાદા છે.

pump એ આ સુધારામાંથી દૂર કરવામાં આવેલ છે. આથી, તમારા નેટવર્ક ઈન્ટરફેસને netconfig મારફતે રૂપરેખાંકિત કરવાનું ભાંગેલ ifcfg સ્ક્રિપ્ટોમાં પરિણમશે.

તમારું નેટવર્ક ઈન્ટરફેસ યોગ્ય રીતે રૂપરેખાંકિત કરવા માટે, તેની જગ્યાએ system-config-network વાપરો. સુધારાયેલ system-config-network પેકેજ સ્થાપિત કરવાનું netconfig દૂર કરશે.

rpm --aid એ લાંબા સમય સુધી આધારભૂત નથી. એ આગ્રહણીય છે કે જ્યારે તમે પેકેજો સુધારી રહ્યા હોય અને સ્થાપિત કરી રહ્યા હોય ત્યારે તમે yum વાપરો.

SATA ભૂલ કે જેણે SATA-લગાવેલ સિસ્ટમોને બુટ પ્રક્રિયા દરમ્યાન અટકાવવાનું કારણ બન્યું અને ડિસ્પ્લેને અઠકાવવા પહેલાં ભૂલમાં પરિણમ્યું તે હવે સુધારાઈ ગયેલ છે.

મલ્ટી-બુટ સિસ્ટમોમાં, parted હવે પ્રથમ પ્રાથમિક પાર્ટીશનનો શરૂઆતી સેક્ટર સાચવે છે કે જ્યાં Windows Vista™ સ્થાપિત થયેલ હોય. આથી, જ્યારે Red Hat Enterprise Linux 5.1 અને Windows Vista™ બંને સાથે મલ્ટી-બુટ સિસ્ટમ સુયોજીત કરી રહ્યા હોય, ત્યારે પછીથી બુટ નહિં કરી શકાય તેવું લાંબા સમય સુધી શક્ય નથી.

rmmod xennet લાંબા સમય સુધી domU ને ભાંગવાનું કારણ બનતું નથી.

4-socket AMD Sun Blade X8400 Server Module સિસ્ટમો કે જેઓને node 0 માં મેમરી રૂપરેખાંકિત થયેલ નહિં હોય તેઓ બુટ દરમ્યાન દુઃખાવો આપશે.

conga અને luci હવે ફેઈલઓવર ડોમેઈનો બનાવવા અને રૂપરેખાંકિત કરવા માટે વાપરી શકાય છે.

જ્યારે Cluster Storage જૂથને yum મારફતે સ્થાપિત કરી રહ્યા હોય, ત્યારે પરિવહન લાંબા સમય સુધી નિષ્ફળ જતું નથી.

સ્થાપન દરમ્યાન, અયોગ્ય SELinux સંદર્ભો લાંબા સમય સુધી /var/log/faillog અને /var/log/tallylog માં સોંપવામાં આવતા નથી.

dual-core AMD પ્લેટફોર્મ પર, cpu-intensive ક્રિયા એ એક cpu nપર લાંબા સમય સુધી CPU કોરને આવૃત્તિઓ બદલવાનું લાંબા સમય સુધી કારણ બનતું નથી.

જ્યારે Red Hat Enterprise Linux 5.1 ને વિભાજીત સ્થાપન મીડિયા (ઉદાહરણ તરીકે, CD અથવા NFSISO) ની મદદથી સ્થાપિત કરી રહ્યા હોય, ત્યારે amanda-server ના સ્થાપન દરમ્યાન ભૂલ આવે છે.

સ્થાપન પ્રક્રિયા દરમ્યાન, એનાકોન્ડા હવે 4GB ની RAM કરતાં વધુ શોધી શકે છે. આ એનાકોન્ડા ને આપોઆપ એ નક્કી કરવા માટે પરવાનગી આપે છે કે શું તેને કર્નલનો kernel-PAE ચલ સ્થાપિત કરવાની જરૂર છે કે નહિં.

EDAC હવે તાજેતરના k8 પ્રોસેસરો પર યોગ્ય જથ્થાની મેમરીનો અહેવાલ આપે છે.

જીનોમ ડેસ્કટોપમાં gdm મારફતે દૂરસ્થ પ્રવેશ કરવાનું લાંબા સમય સુધી પ્રવેશ સ્ક્રીનને અટકવાનું કારણ બનતું નથી.

autofs માંની ભૂલ કે જેણે વિવિધ-માઉન્ટને યોગ્ય રીતે કામ કરવાથી અટકાવેલ છે તે હવે સુધારાઈ ગઈ છે.

utrace ના ઘણાબધા પેચો નીચેના સુધારાઓ લાગુ કરે છે:

RealTime Clock (RTC) ભૂલ કે જેણે એલાર્મ અને સામયિક RTC ઈન્ટ્રપ્ટોને યોગ્ય રીતે કામ કરવાથી અટકાવેલ હતું તે સુધારાઈ ગઈ.

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

આ વિલંબ મોટે ભાગે એ હકીકતને કારણે છે કે જે પેકેજ સ્થાપન તબક્કો એ મોટા ભાગના સ્થાપનના CPU-હેતુલક્ષી તબક્કો જ છે.

યજમાન બસ એડેપ્ટરો કે જે MegaRAID ડ્રાઈવર વાપરે છે તે "મોટો સંગ્રહ" ઈમ્યુલેશન સ્થિતિમાં સુયોજિત થયેલ હોવું જ જોઈએ, નહિં કે "I2O" ઈમ્યુલેશન સ્થિતિમાં. આમ કરવા માટે, નીચેના પગલાંઓ અનુસરો:

જો એડેપ્ટર એ અયોગ્ય રીતે "I2O" ઈમ્યુલેશનમાં સુયોજિત થયેલ હોય, તો સિસ્ટમ i2o ડ્રાઈવર લોડ કરશે. આ નિષ્ફળ જશે, અને યોગ્ય ડ્રાઈવર લોડ કરવાથી અટકાવશે.

પહેલાંના Red Hat Enterprise Linux પ્રકાશનો સામાન્ય રીતે I20 ડ્રાઈવરને MegaRAID ડ્રાઈવર પહેલાં લોડ કરતા નથી. આના સંદર્ભે, હાર્ડવેર જ્યારે Linux સાથે વપરાય ત્યારે હંમેશા "મુખ્ય સંગ્રહ" ઈમ્યુલેશન સ્થિતિમાં સુયોજિત થયેલ હોવું જોઈએ.

લેપટોપ કે જેઓને Cisco Aironet MPI-350 વાયરલેસ કાર્ડ લગાવેલ હોય તે વાયરવાળા ઈથરનેટ પોર્ટ પર કોઈપણ નેટવર્ક-આધારિત સ્થાપન દરમ્યાન DHCP સરનામું મેળવતી વખતે અટકશે.

આના ઉકેલ માટે, તમારા સ્થાપન માટે સ્થાનીક મીડિયા વાપરો. વૈકલ્પિક રીતે, તમે સ્થાપન પહેલાં લેપટોપ BIOS માં વાયરલેસ નિષ્ક્રિય કરી શકો (તમે સ્થાપન સમાપ્ત કર્યા પછી વાયરલેસ કાર્ડ પુનઃ-સક્રિય કરી શકો છો).

વર્તમાનમાં, system-config-kickstart પેકેજ પસંદગી અને નાપસંદગીને આધાર આપતું નથી. જ્યારે system-config-kickstart વાપરી રહ્યા હોય, ત્યારે પેકેજ પસંદગી વિકલ્પ સૂચવે છે કે તે નિષ્ક્રિય કરવામાં આવેલ છે. આવું એટલા માટે છે કારણ કે system-config-kickstart એ જૂથ જાણકારી મેળવવા માટે yum વાપરે છે, પરંતુ તે Red Hat Network સાથે જોડાણ કરવા માટે yum રૂપરેખાંકિત કરવા માટે અસમર્થ છે.

હાલમાં, તમારે તમારી કિકસ્ટાર્ટ ફાઈલોમાં પેકેજ વિભાગો જાતે સુધારવાની જરૂર રહેશે. જ્યારે કિકસ્ટાર્ટ ફાઈલ ખોલવા માટે system-config-kickstart વાપરી રહ્યા હોય, ત્યારે તે તેમાં બધી પેકેજ જાણકારી સાચવશે અને જ્યારે તમે સંગ્રહો ત્યારે તેમાં ફરીથી લખે છે.

/var/log/boot.log માં બુટ-સમય લોગીંગ એ Red Hat Enterprise Linux 5 ની આ આવૃત્તિમાં ઉપલબ્ધ નથી. સમતુલ્ય વિધેય ભવિષ્યના સુધારામાં ઉમેરવામાં આવશે.

જ્યારે Red Hat Enterprise Linux 4 માંથી Red Hat Enterprise Linux 5 માં સુધારી રહ્યા હોય, ત્યારે જમાવટ માર્ગદર્શન આપોઆપ સ્થાપિત થશે નહિં. તમારે સુધારો સમાપ્ત કર્યા પછી તેને જાતે સ્થાપિત કરવા માટે pirut વાપરવાની જરૂર છે.

જો X ચાલી રહ્યું હોય અને vesa સિવાયનું ડ્રાઈવર વાપરી રહ્યું હોય તો સિસ્ટમ kexec/kdump કર્નલમાં સફળતાપૂર્વક રીબુટ થશે નહિં. આ સમસ્યા માત્ર ATI Rage XL ગ્રાફિક્સ ચીપસેટો સાથે જ અસ્તિત્વમાં છે.

જો X એ ATI Rage XL સાથે જોડાયેલ સિસ્ટમ પર ચાલી રહ્યું હોય, તો ખાતરી કરો કે તે kexec/kdump કર્નલમાં સફળતાપૂર્વક રીબુટ કરવા માટે vesa ડ્રાઈવર વાપરી રહ્યું છે.

જ્યારે Red Hat Enterprise Linux 5 ને nVidia CK804 ચિપસેટ સ્થાપિત થયેલ મશીન પર વાપરી રહ્યા હોય, ત્યારે નીચેના કર્નલ સંદેશાઓ દેખાશે:

kernel: assign_interrupt_mode Found MSI capability
kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

આ સંદેશાઓ સૂચવે છે કે ચોક્કસ PCI-E પોર્ટો IRQ ની અરજી કરતા નથી. આગળ, આ સંદેશાઓ, કોઈપણ રીતે, મશીનની પ્રક્રિયાને અસર કરતા નથી.

દૂર કરી શકાય તેવા સંગ્રહ ઉપકરણો (જેમ કે CDs અને DVDs) આપોઆપ માઉન્ટ થતા નથી જ્યારે તમે રુટ તરીકે પ્રવેશેલ હોય. આથી, તમારે ઉપકરણને જાતે ગ્રાફિકવાળા ફાઈલ વ્યવસ્થાપકની મદદથી માઉન્ટ કરવાની જરૂર રહેશે.

વૈકલ્પિક રીતે, તમે ઉપકરણને /media હેઠળ માઉન્ટ કરવા માટે નીચેનો આદેશ ચલાવી શકો છો:

mount /dev/<device name> /media

IBM System z એ પારંપરિક Unix-શૈલી ભૌતિક કન્સોલ પૂરું પાડતું નથી. આથી, IBM System z માટેનું Red Hat Enterprise Linux 5 એ આરંભિક સ્થાપન કાર્યક્રમને લોડ કરવા દરમ્યાન firstboot વિધેયને આધાર આપતું નથી.

IBM System z પર Red Hat Enterprise Linux 5 નું સુયોજન યોગ્ય રીતે આરંભ કરવા માટે, સ્થાપન પછી નીચેના આદેશો ચલાવો:

જ્યારે Red Hat Enterprise Linux 5 માંથી Red Hat Enterprise Linux 5.1 માં Red Hat Network મારફતે સુધારો કરી રહ્યા હોય, ત્યારે yum તમને redhat-beta કી આયાત કરવા માટે પૂછશે નહિં. આથી, એ સલાહનીય છે કે તમે redhat-beta કીને જાતે સુધારો કરવા પહેલાં આયાત કરો. આવું કરવા માટે, નીચેનો આદેશ ચલાવો:

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta

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

આને ઉકેલવા માટે, બધા ઉપકરણ અને mpath કડી પ્રવેશોને /etc/lvm/.cache માંથી કાઢી નાંખો કે જે stale LUN લગતા હોય.

આ પ્રવેશો કયા છે તે શોધવા માટે, નીચેનો આદેશ ચલાવો:

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

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

lrwxrwxrwx 1 root root 7 Aug  2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwxrwx 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

જ્યારે CD અથવા DVD માંથી સંપૂર્ણપણે વર્ચ્યુઅલાઈઝ થયેલ Windows™ મહેમાન બનાવવાનો પ્રયાસ કરી રહ્યા હોય, ત્યારે મહેમાન સ્થાપનનું બીજું પગલું રીબુટ કરવા પર ચાલુ રહેશે નહિં.

આનો ઉકેલ લાવવા માટે, CD / DVD ઉપકરણ માટે પ્રવેશ યોગ્ય રીતે ઉમેરીને /etc/xen/<name of guest machine> માં ફેરફાર કરો.

જો સાદી ફાઈલમાં સ્થાપન વર્ચ્યુઅલ ઉપકરણ તરીકે વાપરવામાં આવે, તો /etc/xen/<name of guest machine> ની disk લીટી નીચેના જેવી વંચાશે:

disk = [ 'file:/PATH-OF-SIMPLE-FILE,hda,w']

યજમાન પર /dev/dvd તરીકે સ્થિત થયેલ DVD-ROM ઉપકરણ સ્થાપનના તબક્કા ૨ માં hdc તરીકે 'phy:/dev/dvd,hdc:cdrom,r' જેવો પ્રવેશ ઉમેરીને ઉપલબ્ધ બનાવી શકાય છે. જેમ કે, ડિસ્ક લીટી હવે નીચે બતાવ્યા અનુસાર વંચાવી જોઈએ:

disk = [ 'file:/opt/win2003-sp1-20061107,hda,w', 'phy:/dev/dvd,hdc:cdrom,r']

વાપરવા માટેનો ચોક્કસ ઉપકરણ પાથ તમારા હાર્ડવેર પર આધાર રાખીને બદલાઈ શકશે.

જો sctp મોડ્યુલ એ કર્નલમાં ઉમેરાયેલ નહિં હોય, તો netstat ને -A inet અથવા -A inet6 વિકલ્પ સાથે ચલાવવાનું નીચેના સંદેશા સાથે અડધેથી બંધ થઈ જશે:

netstat: આ સિસ્ટમ પર `AF INET (sctp)' માટે કોઈ આધાર નથી.        

આને અવગણવા માટે, sctp કર્નલ મોડ્યુલ સ્થાપિત કરો.

વર્તમાન કર્નલો Data Terminal Ready (DTR) સંકેતોને બુટ સમય દરમ્યાન સીરીયલ પોર્ટો પર છાપવા પહેલાં મૂકતા નથી. DTR મૂકવાનું અમુક ઉપકરણો દ્વારા જરૂરી છે; આના પરિણામે, કર્નલ બુટ સંદેશાઓ આવા ઉપકરણો પર સીરીયલ કન્સોલ પર છપાતા નથી.

AMD 8132 અને HP BroadCom HT100 અમુક પ્લેટફોર્મ પર વાપરવામાં આવતા હતા (જેમ કે HP dc7700) કે જે MMCONFIG ચક્રોને આધાર આપતા નથી. જો તમારી સિસ્ટમ કોઈપણ ચિપસેટ વાપરે, તો તમારું PCI રૂપરેખાંકન લીગસી PortIO CF8/CFC પદ્ધતિ વાપરતું હોવું જોઈએ. આને રૂપરેખાંકિત કરવા માટે, સિસ્ટમને સ્થાપન દરમ્યાન -pci nommconfig પરિમાણ સાથે બુટ કરો અને pci=nommconf ને GRUB માં પુનઃબુટ કર્યા પછી ઉમેરો.

આગળ, AMD 8132 ચિપસેટ Message Signaled Interrupts (MSI) ને આધાર આપતું નથી. જો તમારી સિસ્ટમ આ ચિપસેટ વાપરે, તો તમારે MSI પણ નિષ્ક્રિય કરવું જોઈએ. આવું કરવા માટે, સ્થાપન દરમ્યાન કર્નલ પરિમાણ -pci nomsi વાપરો અને પુનઃબુટ કર્યા પછી GRUB માં pci=nomsi ઉમેરો.

છતાંય, જો તમારું ચોક્કસ પ્લેટફોર્મ કર્નલ દ્વારા બ્લેકલીસ્ટ થયેલ હોય, તો તમારી સિસ્ટમને પછીથી ઉલ્લેખ થયેલ pci કર્નલ પરિમાણોની જરૂર રહેતી નથી. નીચેના HP પ્લેટફોર્મ કર્નલ દ્વારા પહેલાથી જ બ્લેકલીસ્ટ થયેલ છે:

જ્યારે એકદમ-ઘાતક (બિન-વર્ચ્યુઅલાઈઝ થયેલ) કર્નલ ચલાવી રહ્યા હોય, ત્યારે X સર્વર EDID જાણકારી મોનીટરમાંથી પુનઃપ્રાપ્ત કરવા માટે સમર્થ હશે નહિં. જ્યારે આવું થાય, ત્યારે ગ્રાફિક્સ ડ્રાઈવર 800x600 કરતાં મોટું રીઝોલ્યુશન દર્શાવવામાં અસમર્થ થઈ જશે.

આ ઉકેલવા માટે, /etc/X11/xorg.conf ના ServerLayout વિભાગમાં નીચેનું વાક્ય ઉમેરો:

Option "Int10Backend" "x86emu"

આ પ્રકાશનમાં સમાવવામાં આવેલ વર્ચ્યુઅલ મશીન વ્યવસ્થાપક (virt-manager) વપરાશકર્તાઓને પેરાવર્ચ્યુઅલાઈઝ થયેલ મહેમાન સ્થાપકને વધારાની બુટ દલીલો સ્પષ્ટ કરવા માટે પરવાનગી આપતું નથી. આ ખરું છે જો જ્યારેપણ આવી દલીલો ચોક્કસ પ્રકારના હાર્ડવેર પર પેરાવર્ચ્યુઅલાઈઝ થયેલ મહેમાનોના વિશિષ્ટ પ્રકારો સ્થાપિત કરવા માટે જરૂરી હોય.

આ મુદ્દો virt-manager ના ભવિષ્યના પ્રકાશનમાં સંબોધવામાં આવશે. આદેશ વાક્યમાંથી પેરાવર્ચ્યુઅલાઈઝ થયેલ મહેમાનો સ્થાપિત કરવામાં ચોક્કસ કર્નલ દલીલો સ્પષ્ટ કરવા માટે, virt-install વાપરો.

મૂળભૂત dm-multipath રૂપરેખાંકન સાથે, Netapp ઉપકરણો પહેલાંથી નિષ્ફળ પાથ પુનઃસંગ્રહાય તે પછી ફેઈલબેક પૂરું કરવા માટે થોડી મિનિટો લેશે. આ સમસ્યા ઉકેલવા માટે, નીચેના Netapp ઉપકરણ રૂપરેખાંકનને multipath.conf ફાઈલના devices વિભાગમાં ઉમેરો:

devices {
        device {
                vendor                  "NETAPP"
                product                 "LUN"
                getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
                prio_callout            "/sbin/mpath_prio_netapp /dev/%n"
                features                "1 queue_if_no_path"
                hardware_handler        "0"
                path_grouping_policy    group_by_prio
                failback                immediate
                rr_weight               uniform
                rr_min_io               128
                path_checker            directio
        }