Copyright 2008 Red Hat, Inc.. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the security@redhat.com key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
ଏହି ଦଲିଲଟି Red Hat Enterprise Linux 5.3 ପାଇଁ ପ୍ରକାଶନ ଟିପ୍ପଣୀ ବର୍ଣ୍ଣନା କରିଥାଏ.
ଏହି ବିଭାଗଟି ଆନାକୋଣ୍ଡା ଏବଂ Red Hat Enterprise Linux 5.3 ର ସ୍ଥାପନ ନିର୍ଦ୍ଦିଷ୍ଟ ସୂଚନା ମାନଙ୍କୁ ଧାରଣ କରିଅଛି।
Red Hat Network ନୂତନ ଏବଂ ପରିବର୍ତ୍ତିତ ପ୍ୟାକେଜ ଗୁଡିକୁ ସ୍ଥାପନ କରିପାରେ ଏବଂ ଗୋଟିଏ ସ୍ଥିତବାନ Red Hat Enterprise Linux 5 ତନ୍ତ୍ରକୁ ଉନ୍ନତତର କରିପାରେ। ବୈକଳ୍ପିକ ରୂପରେ, Anaconda ସ୍ଥିତବାନ Red Hat Enterprise Linux 5 ତନ୍ତ୍ରକୁ ଉନ୍ନୟନ କରିପାରେ କିମ୍ୱା Red Hat Enterprise Linux 5.3 ର ତାଜା ସ୍ଥାପନା କରିପାରେ।
ଟୀକା: Red Hat Enterprise Linux 5.3 ର ବିଟା ପ୍ରକାଶନରୁ ଏହି GA ପ୍ରକାଶନକୁ ଉନ୍ନତତର କରିବାକୁ ଏହା ସମର୍ଥନ ଦିଏନାହିଁ।
ଆଗକୁ, ଯଦିଚ Anaconda Red Hat Enterprise Linux ର ପୂର୍ବର ମୁଖ୍ୟ ସଂସ୍କରଣ Red Hat Enterprise Linux 5.3 ରେ ଉନ୍ନୟନ ପାଇଁ ଏକ ବିକଳ୍ପ ଦେଇଥାଏ। Red Hat ଏହାକୁ ସମର୍ଥନ ଦିଏନାହିଁ। ଅଧିକନ୍ତୁ, Red Hat Enterprise Linux ର କୌଣସି ମୁଖ୍ୟ ସଂସ୍କରଣ ମଧ୍ଯରେ ଥିବା ଉନ୍ନୟନକୁ Red Hat ସମର୍ଥନ ଦିଏନାହିଁ।(ମୁଖ୍ୟ ସଂସ୍କରଣ ପୂର୍ଣ ସଂଖ୍ୟା ଦ୍ୱାରା ସୂଚିତ କରାଯାଇଥାଏ। ଉଦାହରଣ ସ୍ୱରୂପ, Red Hat Enteprise Linux 4 ଏବଂ Red Hat Enterprise Linux 5 ଦ୍ୱୟ Red Hat Enterprise Linux ର ମୁଖ୍ୟ ସଂସ୍କରଣ ଅଟେ)
ମୁଖ୍ୟ ପ୍ରକାଶନ ଗୁଡିକର ଏପଟରୁ ସେପଟ ଅନ୍ତଃସ୍ଥିତ ଉନ୍ନୟନ ସମସ୍ତ ତନ୍ତ୍ର ସଜ୍ଜା, ସେବା କିମ୍ୱା ପସନ୍ଦଯୋଗ୍ୟ ବିନ୍ୟାସକୁ ସଂରକ୍ଷିତ କରି ରଖିନଥାଏ। ଏହିପରି ଭାବରେ, ତାଜା ସ୍ଥାପନାକୁ Red Hat କଡା ସ୍ୱୀକୃତି ଦେଇଥାଏ ଯେତେବେଳେ ଗୋଟିଏ ମୁଖ୍ୟ ସଂସ୍କରଣରୁ ଅନ୍ୟକୁ ଉନ୍ନୟନ କରାଯାଇଥାଏ।
Anacondaର ପାଠ୍ୟ ଧାରା ସ୍ଥାପନ ବର୍ତ୍ତମାନ ସ୍ଥାପନ କ୍ରିୟା ସମାପ୍ତ କରିବା ପାଇଁ ଆଭାସୀ ନେଟୱର୍କ କମ୍ପୁଟିଙ୍ଗ (VNC)କୁ ବଦଳ ହେବାର ବିକଳ୍ପ ପ୍ରଦାନ କରୁଅଛି।
ସଂଗୁପ୍ତ ସଫ୍ଟୱେର RAID ସଦସ୍ୟ ଡ଼ିସ୍କଗୁଡ଼ିକୁ ନିର୍ମାଣ କିମ୍ବା ବ୍ୟବହାର କରି (ଯେପରି, software RAID
ବିଭାଜନ)ଟି ସମର୍ଥିତ ନୁହଁ। ଯଦିଚ, ସଂଗୁପ୍ତ ସଫ୍ଟୱେର RAID ସାରଣୀ ନିର୍ମାଣ କରି (ଉଦାହରଣ ସ୍ୱରୂପ, /dev/md0
)ଟି ସମର୍ଥିତ।
RHEL5 ପାଇଁ NFS ପୂର୍ବନିର୍ଦ୍ଧାରିତ "locking". ତେଣୁ, ସ୍ଥାପନ ସହଭାଗ କରିବା ପୂର୍ବରୁ nfs କୁ ବ୍ୟବହାର କରି ଡ଼େମନ ବନ୍ଦକରିବା ଆରମ୍ଭ କରିବାକୁ ଆନାକୋଣ୍ଡାର %post ବିଭାଗରୁ ସହଭାଗ କରାଯାଇଥିବା nfs କୁ ସ୍ଥାପନ କରିବା ପାଇଁ, mount -o nolock,udp
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ।
iBFT-ବିନ୍ଯାସିତ ନେଟୱାର୍କ ଉପକରଣ ଥିବା ଗୋଟିଏ ତନ୍ତ୍ରରେ ସି.ଡି.-ରମ କିମ୍ବା ଡି.ଭି.ଡି.-ରମରୁ ସ୍ଥାପନ କରିବା ସମୟରେ, ନେଟୱାର୍କ ଦ୍ବାରା ବିନ୍ଯାସ ନ କରାଯିବା ପର୍ଯ୍ଯନ୍ତ ଆନାକୋଣ୍ଡା କୌଣସି iBFT-ବିନ୍ଯାସିତ ଭଣ୍ଡାର ଉପକରଣ ମାନଙ୍କୁ ଅନ୍ତର୍ଭୂକ୍ତ କରି ନ ଥାଏ। ସ୍ଥାପନ ପାଇଁ ନେଟୱାର୍କିଙ୍ଗକୁ ସକ୍ରିୟ କରିବା ପାଇଁ, ସ୍ଥାପନ ବୁଟ ପ୍ରୋମ୍ପ୍ଟରେ linux updates=http://
ନିର୍ଦ୍ଦେଶକୁ ବ୍ଯବହାର କରନ୍ତୁ। ଏହା ମନେ ରଖନ୍ତୁ ଯେ, [any]
କୁ ଗୋଟିଏ ୟୁ.ଆର.ଏଲ. ଦ୍ବାରା ପରିବର୍ତ୍ତନ କରନ୍ତୁ।
[any]
ଯଦି ଆପଣଙ୍କ ତନ୍ତ୍ର ଗୋଟିଏ ଅପରିବର୍ତ୍ତିତ IP ବିନ୍ୟାସ ଆବଶ୍ୟକ କରିଥାଏ, ତେବେ linux updates=http://
ନିର୍ଦ୍ଦେଶର ପ୍ରୟୋଗ କରନ୍ତୁ।
[କୌଣସି]
ip=[IP address]
netmask=[netmask]
dns=[dns]
ଗୋଟିଏ ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ Red Hat Enterprise Linux 5.3 କୁ ସ୍ଥାପନ କରିବା ସମୟରେ, kernel-xen
କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରନ୍ତୁ ନାହିଁ। ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ ଏହି କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରିବା ଦ୍ବାରା ଏହା ଆପଣଙ୍କ ତନ୍ତ୍ରକୁ ଅଟକାଇଦେବ।
ଆପଣ ଗୋଟିଏ ଆଭାସୀକୃତ ଅତିଥିରେ Red Hat Enterprise Linux 5.3 କୁ ସ୍ଥାପନ କରିବା ସମୟରେ ଗୋଟିଏ ସ୍ଥାପନ ସଂଖ୍ଯା ବ୍ଯବହାର କରୁଥିଲେ, ସ୍ଥାପନ ସମୟରେ ଆଭାସୀକରଣ
ପ୍ଯାକେଜ ସମୂହକୁ ବିଚୟନ କରିବା ପାଇଁ ନିଶ୍ଚିତ ହୁଅନ୍ତୁ। ଆଭାସୀକରଣ
ପ୍ଯାକେଜ ସମୂହ ବିକଳ୍ପ kernel-xen
କର୍ଣ୍ଣଲକୁ ସ୍ଥାପନ କରିଥାଏ।
ଏହା ମନେ ରଖନ୍ତୁ ଯେ ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ଗୁଡିକ ଏହି ସମସ୍ଯା ଦ୍ବାରା ପ୍ରଭାବିତ ହୁଅନ୍ତି ନାହିଁ। ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ଗୁଡିକ ସର୍ବଦା kernel-xen
କର୍ଣ୍ଣଲକୁ ବ୍ଯବହାର କରିଥାଆନ୍ତି।
Red Hat Enterprise Linux 5 ରୁ 5.2, କୁ ଉନ୍ନୟନ କରିବା ସମୟରେ ଯଦି ଆପଣ ଆଭାସୀକୃତ କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରୁଛନ୍ତି, ଉନ୍ନୟନ ସମାପ୍ତ ହେବା ପରେ ଆପଣ ପୁନର୍ଚାଳନ କରିବା ଉଚିତ। ତାପରେ ଆପଣ ଅଦ୍ୟତନ ଆଭାସୀକୃତ କର୍ଣ୍ଣଲ କୁ ବ୍ୟବହାର କରି ତନ୍ତ୍ରକୁ ବୁଟ କରିବା ଉଚିତ
Red Hat Enterprise Linux 5 ଏବଂ 5.2 ର ହାଇପରଭାଇଜର ଗୁଡିକ ABI ସୁସଂଗତି ନୁହଁନ୍ତି। ଯଦି ଉନ୍ନୟନ ମାନଙ୍କ ମଧ୍ଯରେ ଆପଣ ପୁନର୍ଚାଳନ ନ କରନ୍ତି, ଉନ୍ନୟନ କରାଯାଇଥିବା ଆଭାସୀକରଣ RPM ଗୁଡିକ ଚଳନ୍ତି କର୍ଣ୍ଣଲ ସହିତ ମିଶିବ ନାହିଁ।
ଯେତେବେଳେ Red Hat Enterprise Linux 5.1କୁ ଉନ୍ନତତର କରୁଛନ୍ତି ଅଥବା ପରେ Red Hat Enterprise Linux 4.6 ରୁ କରୁଛନ୍ତି, ଫଳସ୍ୱରୂପ gcc4
ଉନ୍ନୟନ କୁ ନିଷ୍ଫଳ କରିପାରେ। ସେହିପରି, gcc4
ପ୍ୟାକେଜକୁ ଉନ୍ନୟନ ପୂର୍ବରୁ ହାତରେ ହଟାଇଦେବା ଦରକାର।
firstboot
ଭାଷା ପ୍ଲଗଇନକୁ ହଟାଇ ଦିଆଯାଇଛି, କାରଣ ଗୋଟିଏ ନୂତନ ଭାଷା ବଛାହେଲା ବେଳେ ଏହା ତନ୍ତ୍ରକୁ ଠିକଭାବରେ ଏବଂ ସମ୍ପୂର୍ଣ ରୂପେ ବନ୍ୟାସ କରିପାରେ ନାହିଁ।
ସ୍ଥାପନ ସମୟରେ ଚ୍ଯାଲେଞ୍ଜ ହେଣ୍ଡସେକ ଅଥେଣ୍ଟିକେସନ ପ୍ରୋଟୋକଲ (CHAP) ର ବ୍ୟବହାର ସହାୟପ୍ରାପ୍ତ ହୋଇନଥାଏ । ସେହିପରି CHAP କେବଳ ସ୍ଥାପନ ପ୍ରକ୍ରିୟା ପରେ ସମର୍ଥ କରାଯିବା ଉଚିତାଧିକ ଅକ୍ଷର ସୀମା ୨୫୬ ଅଟେ।
ଯଦି ଆପଣଙ୍କ ତନ୍ତ୍ର iFBT ଯନ୍ତ୍ର ସାହାଯ୍ୟରେ ବୁଟ କରିଥାଏ, CHAPକୁ iFBT BIOS/ ଫର୍ମୱେର ସଜ୍ଜୀକରଣ ପରଦାରେ ବିନ୍ୟାସ କରନ୍ତୁ। ଆପଣଙ୍କ CHAP ସଜ୍ଜାର ପ୍ରୟୋଗ ଆଗାମୀ ବୁଟରେ କରାଯିବ।
ଯଦି ଆପଣଙ୍କ ତନ୍ତ୍ର PXE iSCSI ଯନ୍ତ୍ର ସାହାଯ୍ୟରେ ବୁଟ କରିଥାଏ, CHAP କୁ iscsiadm
ଦ୍ୱାରା ବିନ୍ୟାସ କରନ୍ତୁ। ବିନ୍ୟାସ ପରେ, mkinitrd
ର ପ୍ରୟୋଗ ସୁନିଶ୍ଚିତ କରିବା ପାଇଁ CHAP ସଜ୍ଜାର ପ୍ରୟୋଗ ଆଗାମୀ ବୁଟରେ କରାଯିବ।
ସ୍ଥାପନ ସମୟରେ ଅତିଥିର ବ୍ୟବସ୍ଥା କରୁଥିଲାବେଳେ, ଅତିଥି ପାଇଁ RHN ସାଧନ ବିକଳ୍ପ ଉପଲବ୍ଧ ହୋଇନଥାଏ। ଯେତେବେଳେ ଏହା ଘଟେ, ସେତେବେଳେ ତନ୍ତ୍ରକୁ dom0
ଦ୍ୱାରା ବ୍ୟବହୃତ ହେଉଥିବା ଅଧିକାର ଠାରୁ ପୃଥକ ଗୋଟିଏ ଅତିରିକ୍ତ ଅଧିକାର ଆବଶ୍ୟକ ହୋଇଥାଏ।
ଅତିଥି ପାଇଁ ଖର୍ଚ୍ଚ ହେଉଥିବା ଅତିରିକ୍ତ ଅଧିକାରକୁ ଅଟକାଇବା ପାଇଁ, Red Hat Networkରେ ତନ୍ତ୍ର ପଞ୍ଜିକୃତ ହେବାକୁ ଚେଷ୍ଟାକରିବା ପୂର୍ବରୁ rhn-virtualization-common
ପ୍ୟାକେଜକୁ ହସ୍ତକୃତଭାବରେ ସ୍ଥାପନ କରନ୍ତୁ।
ଏକାଧିକ ନେଟୱର୍କ ଅନ୍ତରାପୃଷ୍ଠ ବିଶିଷ୍ଟ ତନ୍ତ୍ରରେ Red Hat Enterprise Linux 5.3 ସ୍ଥାପନ କରି ଏବଂ IPv6 ଠିକଣାକୁ ହସ୍ତକୃତ ଭାବରେ ଉଲ୍ଲେଖ କରି ଫଳସ୍ୱରୂପ ଆମେ ଆଂଶିକ ନିର୍ଭୁଲ ନେଟୱର୍କିଙ୍ଗ ବିନ୍ୟାସ ପାଇପାରିବା। ଯେତେବେଳେ ଏହା ଘଟେ, ସ୍ଥାପିତ ତନ୍ତ୍ରରେ ଆପଣଙ୍କର IPv6 ବିନ୍ୟାସ ଦୃଶ୍ୟମାନ ହେବ ନାହିଁ।
ଏହାର ସମାଧାନ ପାଇଁ, /etc/sysconfig/network
ରେ NETWORKING_IPV6
କୁ yes
ସେଟ କରନ୍ତୁ। ତାପରେ, ଆପଣଙ୍କର ନେଟୱର୍କ ସଂଯୋଗକୁ service network restart
ନିର୍ଦ୍ଦେଶ ବ୍ୟବହାର କରି ପୁନଃ ପ୍ରାରମ୍ଭ କରନ୍ତୁ।
ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ରରେ yum-rhn-plugin-0.5.2-5.el5_1.2
(କିମ୍ବା ପୂର୍ବ ସଂସ୍କରଣ) ସ୍ଥାପିତ ଅଛି, ଆପଣ Red Hat Enterprise Linux 5.3 କୁ yum update
ମାଧ୍ୟମରେ ଉନ୍ନୟନ କରିବାରେ ଅସମର୍ଥ ହେବେ। ଏହାର ସମାଧାନ ପାଇଁ, yum update
ଚଲାଇବା ପୂର୍ବରୁ ଆପଣଙ୍କର yum-rhn-plugin
କୁ ନୂତନତମ ସଂସ୍କରଣକୁ ଉନ୍ନୟନ କରନ୍ତୁ (yum update yum-rhn-plugin
ବ୍ୟବହାର କରି)।
ପୂର୍ବରୁ, anaconda 8 ରୁ ଅଧିକ SmartArray ନିୟନ୍ତ୍ରକ ବ୍ୟବହାର କରୁନଥିଲା। ଏହି ଅଦ୍ୟତନରେ, ସେହି ସମସ୍ୟାଟିର ସମାଧାନ ହୋଇଯାଇଛି।
OEM ଦ୍ୱାରା ଦିଆଯାଇଥିବା ଡ୍ରାଇଭର ଫାଇଲଟି ଗୋଟିଏ ପ୍ରତିଛବି ଫାଇଲ (*.img
), ଯିଏକି ଏକାଧିକ ସମ୍ଭାବ୍ୟ ଡ୍ରାଇଭର ପ୍ୟାକେଜ ଏବଂ କର୍ଣ୍ଣଲ ଏକକାଂଶ ଧାରଣ କରିଥାଏ। ଏହି ଡ୍ରାଇଭରଗୁଡ଼ିକ ସ୍ଥାପନ ସମୟରେ ହାର୍ଡୱେରକୁ ସମର୍ଥନ ଦେବା ପାଇଁ ବ୍ୟବହୃତ ହେଇଥାଏ ଯାହାକୁକି Red Hat Enterprise Linux 5 ଦ୍ୱାରା ଚିହ୍ନିହୋଇନଥାଏ। ଥରେସେହି ଡ୍ରାଇଭର ପ୍ୟାକେଜ ଏବଂ କର୍ଣ୍ଣଲ ଏକକାଂଶଗୁଡ଼ିକ ତନ୍ତ୍ରରେ ସ୍ଥାପିତ ହୋଇଗଲା ମାତ୍ରେ, ସେମାନଙ୍କୁ ପ୍ରାରମ୍ଭିକ RAM ଡିସ୍କ (initrd
)ରେ ରଖାଯାଇଥାଏ, ଯାହାଫଳରେ ତନ୍ତ୍ର ବୁଟ ହେବା ସମୟରେ ସେମାନଙ୍କୁ ଧାରଣ କରାଯାଇଥାଏ।
ଏହି ପ୍ରକାଶନ ସହିତ, ସ୍ଥାପନ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଡ୍ରାଇଭର ଡିସ୍କକୁ ଖୋଜିପାଇଥାଏ (ଏହାର ଫାଇଲ ତନ୍ତ୍ର ନାମପଟିରେ ସ୍ଥିତବାନ), ଯାହାଫଳରେ ସ୍ଥାପନ ସମୟରେ ସେହି ଡ଼ିସ୍କର ବିଷୟବସ୍ତୁକୁ ବ୍ୟବହାର କରିଥାଏ। ଏହି ଆଚରଣଟି ସ୍ଥାପନ ନିର୍ଦ୍ଦେଶ ନାମା ବିକଳ୍ପ dlabel=on
ଦ୍ୱାରା ନିୟନ୍ତ୍ରିତ ହୋଇଥାଏ, ଯାହାକି ସ୍ୱୟଂଚାଳିତ ସନ୍ଧାନକୁ ସକ୍ରିୟ କରିଥାଏ। ଏହି ପ୍ରକାଶନ ପାଇଁ dlabel=on
ଟି ହେଉଛି ପୂର୍ବନିର୍ଦ୍ଧାରିତ ବିନ୍ୟାସ।
ଫାଇଲ ତନ୍ତ୍ର ନାମପଟି OEMDRV
ସହିତ ସମସ୍ତ ବ୍ଲକ ଉପକରଣଗୁଡ଼ିକୁ ଯାଞ୍ଚ କରାଯାଇଥାଏ ଏବଂ ଡ୍ରାଇଭରଗୁଡ଼ିକୁ ସେମାନଙ୍କୁ ଖୋଜି ପାଇଥିବା କ୍ରମରେ ଏହି ଉପକରଣରୁ ଧାରଣ କରାଯାଇଥାଏ.
vfat
ଫାଇଲ ତନ୍ତ୍ର ଧାରଣ କରିଥିବା ସ୍ଥିତବାନ ସଂଗୁପ୍ତ ବ୍ଲକ ଉପକରଣଗୁଡ଼ିକ ବିଭାଜନ ଅନ୍ତରାପୃଷ୍ଠରେ foreign
ପ୍ରକାରରେ ଦେଖାଯିବେ; ସେହିପରି, ଏହି ଉପକରଣଗୁଡ଼ିକ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ତନ୍ତ୍ରବୁଟ ସମୟରେ ସ୍ଥାପିତ ହୋଇଥାଏ। ଏହାକୁ ନିଶ୍ଚିତ କରିବା ପାଇଁ, ସେମାନଙ୍କ ପାଇଁ /etc/fstab
ରେ ଉପଯୁକ୍ତ ଭରଣ ଯୋଗକରନ୍ତୁ। ଏହାକୁ କିପରି କରିବେ ତାହାର ବିବରଣୀ ପାଇଁ, man fstab
କୁ ଅନୁସରଣ କରନ୍ତୁ।
Red Hat Enterprise Linux 5.2ର ସ୍ଥାପନ ପାଇଁ ସର୍ବନିମ୍ନ 1GB RAM ଆବଶ୍ଯକ,ପରାମର୍ଶିତ RAM 2GB ଅଟେ। ଯଦି କୌଣସି ମେସିନରେ 1GBରୁ କମ RAM ଥାଏ, ତାହାହେଲେ ସ୍ଥାପନ ପ୍ରକ୍ରିୟାଟି ଅଟକି ଯାଇପାରେ।
ଅଧିକନ୍ତୁ, 1GB RAM ବିଶିଷ୍ଟ PowerPC-ଆଧାରିତ ମେସିନ ଗୁଡିକ କିଛି RAM-ନିର୍ଦ୍ଦିଷ୍ଟ କାର୍ଯ୍ଯଭାରରେ ଉଲ୍ଲେଖନୀୟ ପ୍ରଦର୍ଶନରେ ସମସ୍ଯାର ସମ୍ମୁଖୀନ ହେଇଥାନ୍ତି। ଗୋଟିଏ Red Hat Enterprise Linux 5.2 ତନ୍ତ୍ର ପାଇଁ RAM-ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରକ୍ରିୟାମାନଙ୍କୁ ଅନୁକୂଳ ଭାବରେ ପ୍ରଦର୍ଶନ କରିବା ପାଇଁ, ମେସିନରେ 4GBର RAM ରଖିବା ପାଇଁ ପରାମର୍ଶ ଦିଆଯାଇଥାଏ। 512MB RAM PowerPC ମେସିନରେ ଚାଲୁଥିବା Red Hat Enterprise Linux 4.5 କିମ୍ବା ପୂର୍ବବର୍ତ୍ତୀ ସଂସ୍କରଣକୁ ଭୌତିକ ପୃଷ୍ଠାର ସମାନ ସଂଖ୍ଯକ ଭୌତିକ ପୃଷ୍ଠା ଏହି ମେସିନରେ ଅଛି ବୋଲି ଏହା ନିଶ୍ଚିତ କରିଥାଏ।
anaconda
ବର୍ତ୍ତମାନ OSA Express3 cards ପାଇଁ CHPIDରେ ଥିବା ଉଭୟ ସଂଯୋଗିକୀକୁ ସମର୍ଥନ କରେ। ସ୍ଥାପନ କ୍ରିୟାର ପ୍ରାଥମିକ ଅବସ୍ଥାରେ ସ୍ଥାପକ ସଂଯୋଗିକୀ କ୍ରମିକ ସଂଖ୍ୟା ପଚାରିବ। ସେହି ସଂଯୋଗିକୀ ପାଇଁ ପ୍ରଦତ୍ତ ମୂଲ୍ୟ ସ୍ଥାପିତ ନେଟୱର୍କ ଅନ୍ତରାପୃଷ୍ଠ ଆରମ୍ଭ ସ୍କ୍ରିପ୍ଟ ଉପରେ ମଧ୍ଯ ପ୍ରଭାବ ପକାଇଥାଏ। ଯେତେବେଳେ ସଂଯୋଗିକୀ 1କୁ ଚୟନ କରାଯାଇଥିଲା, ସେତେବେଳେ ମୂଲ୍ୟ portno=1
କୁ ifcfg-eth*
ଫାଇଲର OPTIONS ପ୍ରାଚଳରେ ଯୋଗ କରାଯାଇଥାଏ।
z/VM ଅନ୍ତର୍ଗତରେ ସ୍ଥାପନ କରିବା ସମୟରେ, ଆପଣ PORTNO=0
କୁ (ସଂଯୋଗିକୀ 0କୁ ବ୍ୟବହାର କରିବା ପାଇଁ) ଅଥବା PORTNO=1
କୁ (ସଂଯୋଗିକୀ 1କୁ ବ୍ୟବହାର କରିବା ପାଇଁ) ଧାରା ପଚାରିବାକୁ ଏଡ଼ାଇବା ପାଇଁ CMS ବିନ୍ୟାସ ଫାଇଲରେ ଯୋଗ କରି ପାରିବେ।
DASD ବ୍ଲକ ଯନ୍ତ୍ର ଉପରେ ସ୍ଥିତବାନ Linux କିମ୍ବା Linux ବିହିନ ଫାଇଲତନ୍ତ୍ରଗୁଡ଼ିକ ସହିତ ଗୋଟିଏ ମେସିନରେ ସ୍ଥାପନା ସ୍ଥାପକକୁ ଅଟକ ରଖିପାରେ। ଯଦି ଏହା ଘଟେ, ତେବେ DASD ଯନ୍ତ୍ରରେ ଆପଣ ବ୍ୟବହାର କରିବାକୁ ଚାହୁଁଥିବା ସମସ୍ତ ସ୍ଥିତବାନ ବିଭାଜନଗୁଡ଼ିକୁ ବାହାର କରିବା ଆବଶ୍ୟକ ଏବଂ ସ୍ଥାପକକୁ ପୁନଃ ପ୍ରାରମ୍ଭ କରନ୍ତୁ।
ଯଦି ଆପଣଙ୍କ ତନ୍ତ୍ରରେ କେବଳ 512MB ର RAM ଥାଏ, ତେବେ Red Hat Enterprise Linux 5.3କୁ ସ୍ଥାପନ କରିବାର ପ୍ରୟାସ ବିଫଳ ହୋଇଥାଏ। ଏହାକୁ ପ୍ରତିରୋଧ କରିବା ପାଇଁ, ପ୍ରଥମେ ଗୋଟିଏ ମୂଳ ସ୍ଥାପନା ସମ୍ପାଦନ କରନ୍ତୁ ଏବଂ ଏହି ସ୍ଥାପନ ସମାପ୍ତ ହେଲାପରେ ବାକି ସମସ୍ତ ପ୍ୟାକେଜକୁ ସ୍ଥାପନ କରନ୍ତୁ।
yum
କୁ ବ୍ଯବହାର କରି 32-ବିଟ ସୁସଂଗତି ସ୍ତର
ରୁ ପ୍ଯାକେଜ ମାନଙ୍କୁ ସ୍ଥାପନ କରିବା ସମୟରେ ଡିସ୍କ ବିଫଳ ହୋଇପାରେ। ଏହା ବିଫଳ ହେଲେ, ଏହା Red Hatପ୍ଯାକେଜର ହସ୍ତାକ୍ଷରିତ ଚାବି ଯୋଗୁଁ ହୋଇଥାଏ ଯାହାକୁ RPM ତଥ୍ଯାଧାରରେ ଆୟତ କରାଯାଇ ନାହିଁ। ଆପଣ Red Hat Network ସହିତ ସଂଯୋଗ କରି ନ ଥିଲେ ଏବଂ ଅଦ୍ଯତନ ମାନଙ୍କୁ ପ୍ରାପ୍ତ କରି ନ ଥିଲେ ଏହା ଘଟିଥାଏ। ଚାବିକୁ ହସ୍ତକୃତ ଭାବରେ ଆୟତ କରିବା ପାଇଁ, ରୁଟ ଚାଳକ ଭାବରେ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶ ଚଳାନ୍ତୁ:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
ଥରେ Red Hat GPG ଚାବିକୁ ଆୟତ କରିସାରିଲା ପରେ, ଆପଣ ବର୍ତ୍ତମାନ32-ବିଟ ସୁସଂଗତି ସ୍ତର
ଡିସ୍କରୁ ପ୍ଯାକେଜ ମାନଙ୍କୁ ସ୍ଥାପନ କରିବା ପାଇଁ yum
କୁ ବ୍ଯବହାର କରିପାରିବେ।
ଏହା ମନେ ରଖନ୍ତୁ ଯେ ଡିସ୍କରୁ ସ୍ଥାପନ କରିବା ସମୟରେ, ସ୍ଥାପନ ସମୟରେ ପ୍ରମୂଖ ପ୍ରଚାଳନ ତନ୍ତ୍ର ନିର୍ଭରକ ମାନଙ୍କୁ ସମ୍ବୋଧନ କରାଯାଇଛି ବୋଲି ନିଶ୍ଚିତ ହେବାକୁ rpm
ପରିବର୍ତ୍ତେ yum
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ।
Linux Unified Key Setup (LUKS) ବିଶେଷ ବିବରଣୀ ବ୍ୟବହାର କରି Red Hat Enterprise Linux 5.3 ବ୍ଲକ ଉପକରଣ ସଂଗୁପ୍ତ ପାଇଁ ସମର୍ଥନ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ। ଗୋଟିଏ ଉପକରଣକୁ ସଂଗୁପ୍ତ କରିବା ଦ୍ୱାରା ବ୍ଲକ ଉପକରଣରେ ସମସ୍ତ ତଥ୍ୟକୁ ଅନାଧିକୃତ ବ୍ୟବହାରରୁ ସୁରକ୍ଷିତ କରିଥାଏ, ଯଦିଚ ସେହି ଉପକରଣଟିକୁ ତନ୍ତ୍ରରୁ କଢ଼ା ସରିଛି। ଗୋଟିଏ ସଂଗୁପ୍ତ ଉପକରଣର ବିଷୟବସ୍ତୁକୁ ଦେଖିବା ପାଇଁ, ଚାଳକ ବୈଧିକରଣ ପାଇଁ ନିଶ୍ଚିତ ଭାବେ ପ୍ରବେଶ ସଂକେତ କିମ୍ବା କି ପ୍ରଦାନ କରିବା ଉଚିତ।
ଡିସ୍କ ସଂଗୁପ୍ତ ବିନ୍ୟାସ ସୂନା ପାଇଁ Red Hat Enterprise Linux ସ୍ଥାପନା ପୁସ୍ତକର ବିଷୟ 28କୁ http://redhat.com/docs/ରେ ଅନୁସରଣ କରନ୍ତୁ
mac80211 ଥାକ (ପୂର୍ବରୁ ପରିଚିତ devicescape/d80211 ଥାକ) ବର୍ତ୍ତମାନ Red Hat Enterprise Linux 5.3ରେ ସମର୍ଥିତ। ଏହା iwlwifi 4965GN
ବେତାର ଡ୍ରାଇଭରକୁ Intel® Wifi ସଂଯୋଗ 4965 ହାର୍ଡୱେର ପାଇଁ ସକ୍ରିୟ ହୋଇଥାଏ ଯାହାକି ଯେକୌଣସି Wi-Fi ନେଟୱାର୍କ ସହିତ ସଂଯୋଗ କରିବା ପାଇଁ ନିର୍ଦ୍ଦିଷ୍ଟ ବେତାର ଉପକରଣ ମାନଙ୍କୁ ଅନୁମତି ପ୍ରଦାନ କରିଥାଏ।
ଯଦିଚ mac80211 ଉପାଦାନ Red Hat Enterprise Linux 5.3 ରେ ସମର୍ଥିତ, ସଙ୍କେତଗୁଡ଼ିକ କର୍ଣ୍ଣଲ ପାଇଁ ସଙ୍କେତ ତାଲିକାରେ ଅନ୍ତର୍ଭୁକ୍ତ ହୋଇନଥାଏ।
GFS2 GFS ର ଗୋଟିଏ ବର୍ଦ୍ଧିତ ଉନ୍ନୟନ ଅଟେ। ଏହି ଅଦ୍ଯତନ ଏକାଧିକ ମହତ୍ବପୂର୍ଣ୍ଣ ଉନ୍ନୟନ ଲାଗୁ କରିଥାଏ ଯାହାକି ଅନ-ଡିସ୍କ ଫାଇଲତନ୍ତ୍ର ଶୈଳୀରେ ଗୋଟିଏ ପରିବର୍ତ୍ତନ ଆବଶ୍ଯକ କରିଥାଏ। GFS ଫାଇଲତନ୍ତ୍ରକୁ GFS2 ରେ gfs2_convert
ଉପଯୋଗୀତାକୁ ବ୍ଯବହାର କରି ରୂପାନ୍ତରିତ କରିହେବ, ଯାହାକି ତଦନୁଯାୟୀ GFS ଫାଇଲତନ୍ତ୍ରର ଅଧିତଥ୍ଯକୁ ଅଦ୍ଯତନ କରିଥାଏ।
Red Hat Enterprise Linux 5.2ରେ, GFS2 କୁ ମୂଲ୍ୟାଙ୍କନ କରିବା ଉଦ୍ଦେଶ୍ୟରେ କର୍ଣ୍ଣଲ ଏକକାଂଶ ଆକାରରେ ପ୍ରଦାନ କରାଯାଇଥାଏ। ପରବର୍ତ୍ତି ସ୍ତରରେ, Red Hat Enterprise Linux ର ପୁରୁଣା ସଂସ୍କରଣରୁ ଉନ୍ନୟନ କରିବା ଏକକାଂଶ ଦ୍ୱନ୍ଦ ହେତୁ ବିଫଳ ହୋଇଥିଲା। Red Hat Enterprise Linux 5.3ରେ, GFS2 ଟି ବର୍ତ୍ତମାନ କର୍ଣ୍ଣଲର ପ୍ୟାକେଜ। ସ୍ଥାପକଟି ସ୍ୱୟଂଚାଳିତ ଭାବରେ ପୂର୍ବ GFS2 କର୍ଣ୍ଣଲ ଏକକାଂଶଗୁଡ଼ିକୁ ଉନ୍ନୟନ ସମୟରେ କାଢ଼ିଦେଇଥାଏ।
OEM ଦ୍ୱାରା ପ୍ରଦତ୍ତ, ଡ୍ରାଇଭର ଡିସ୍କଟି ଗୋଟିଏ ପ୍ରତିଛବି ଫାଇଲ (*.img
), ଏକାଧିକ ଡ୍ରାଇଭର RPM ଏବଂ କର୍ଣ୍ଣଲ ଏକକାଂଶଗୁଡ଼ିକୁ ଧାରଣ କରି।ଏହି ଡ୍ରାଇଭରଗୁଡ଼ିକୁ ସ୍ଥାପନ ସମୟରେ ହାର୍ଡୱେରକୁ ସମର୍ଥନ କରିବା ପାଇଁ ବ୍ୟବହୃତ ହୋଇଥାଏ ଯାହା ବିନା ଚିହ୍ନି ପାରିନଥାନ୍ତେ। RPM ଗୁଡ଼ିକ ତନ୍ତ୍ରରେ ସ୍ଥାପିତ ହୋଇଥାଏ ଏବଂ initrd ରେ ରଖାଯାଇଥାଏ। ଯାହା ଫଲରେ ଯନ୍ତ୍ର ପୁନଃ ପ୍ରାରମ୍ଭ ସମୟରେ ସମର୍ଥିତ ହୋଇଥାଏ।
Red Hat Enterprise Linux 5.3 ସହିତ, ସ୍ଥାପନ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଏହାର ଫାଇଲ ତନ୍ତ୍ର ନାମପଟି ଉପରେ ଆଧାରିତ ଡ୍ରାଇଭର ଡ଼ିସ୍କର ଉପସ୍ଥିତିକୁ ଜାଣିପାରେ, ଏବଂ ସ୍ଥାପନ ସମୟରେ ଡ଼ିସ୍କର ବିଷୟବସ୍ତୁକୁ ବ୍ୟବହାର କରିଥାଏ। ଏହି ଆଚରଣଟି ସ୍ଥାପନ ନିର୍ଦ୍ଦେଶନାମା ବିକଳ୍ପ dlabel=on
ଦ୍ୱାରା ନିୟନ୍ତ୍ରିତ ହୋଇଥାଏ, ଯାହାକି ସ୍ୱୟଂଚାଳିତ ସନ୍ଧାନକୁ ସକ୍ରିୟ କରିଥାଏ। ଫାଇଲ ତନ୍ତ୍ର ନାମପଟି OEMDRV
ସହିତ ସମସ୍ତ ବ୍ଲକ ଉପକରଣଗୁଡ଼ିକୁ ଯାଞ୍ଚ କରାଯାଇଥାଏ ଏବଂ ଡ୍ରାଇଭରଗୁଡ଼ିକୁ ଏହି ଉପକରଣରୁ ସେମାନେ ଦେଖାଯାଉଥିବା କ୍ରମରେ ଧାରଣ କରାଯାଇଥାଏ।
Red Hat Enterprise Linux 5.3 ବର୍ତ୍ତମାନ iSCSI Boot Firmware Table (iBFT) କୁ ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ ସମର୍ଥନ କରୁଅଛି ଯାହାକି iSCSI ଉପକରଣରୁ ବୁଟ କରିବାକୁ ଅନୁମତି ଦେଇଥାଏ। ଏହି ସମର୍ଥନ iSCSI ଡ଼ିସ୍କଗୁଡ଼ିକୁ (ନୋଡଗୁଡ଼ିକ) ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଆରମ୍ଭ ହେବା ପାଇଁ ତିହ୍ନଟ ନହେଉ ବୋଲି ଆବଶ୍ୟକ କରିଥାଏ; ସ୍ଥାପିତ ତନ୍ତ୍ରଟି କଦାପି ସ୍ୱୟଂଚାଳିତ ଭାବରେ iSCSI ଡ଼ିସ୍କଗୁଡ଼ିକ ସହିତ ସଂଯୋଗ କିମ୍ବା ଲଗଇନ ହୋଇନଥାଏ ଯେତେବେଳେ ରନଲେବେଲ 3 କିମ୍ବା 5ରେ ପ୍ରବେଶ କରନ୍ତି।
iSCSI କୁ ସାଧାରଣତଃ ପ୍ରମୂଖ ଚାଳକ ଫାଇଲତନ୍ତ୍ର ପାଇଁ ବ୍ୟବହାର କରାଯାଇଥାଏ, ଯେଉଁଥିରେ ଏହି ପରିବର୍ତ୍ତନ କୌଣସି ପାର୍ଥକ୍ୟ ପକାଇନଥାଏ, ଯେହେତୁ ରନଲେବେଲ ପ୍ରବେଶ କରିବା ପୂର୍ବରୁ ଆବଶ୍ୟକୀୟ iSCSI ଡ଼ିସ୍କ ସହିତ initrd ସଂଯୋଗ ଏବଂ ଲଗଇନ ହୋଇଥାଏ।
ଯଦିଚ iSCSI ଡ଼ିସ୍କ ମୂଖ୍ୟ ଚାଳକ ହୋଇନଥିବା ଡିରେକ୍ଟୋରୀରେ ସ୍ଥାପିତ ହେବା ଆବଶ୍ୟକ, ଉଦାହରଣ ସ୍ୱରୂପ /home
କିମ୍ବା /srv
, ତାପରେ ଏହି ପରିବର୍ତ୍ତନ ଆପଣଙ୍କ ଉପରେ ପ୍ରଭାବ ପକାଇବ, ଯେହେତୁ ସ୍ଥାପିତ ତନ୍ତ୍ର ଏବେ ଆଉ ସ୍ୱୟଂଚାଳିତଭାବରେ iSCSI ଡ଼ିସ୍କଗୁଡ଼ିକ ସହିତ ସଂଯୋଗ କିମ୍ବା ଲଗଇନ ହୋଇନଥାଏ ଯାହାକି ପ୍ରମୂଖ ଚାଳକ ଫାଇଲତନ୍ତ୍ର ସହିତ ବ୍ୟବହାର ହୋଇନଥାଏ।
ପ୍ରମୁଖ ଚାଳକ ହୋଇନଥିବା ଡ଼ିରେକ୍ଟୋରୀରେ ସ୍ଥାପିତ iSCSI ଡ଼ିସ୍କଗୁଡ଼ିକୁ ବ୍ୟବହାର କରିବା ଏବେବି ସମ୍ଭବ, କିନ୍ତୁ ନିମ୍ନଲିଖିତ ବିକଳ୍ପ ଧାରାଗୁଡ଼ିକ ମଧ୍ଯରୁ ଗୋଟିକୁ ବ୍ୟବହାର କରିବା ଆବଶ୍ୟକ କରିଥାଏ:
ପ୍ରମୁଖ ଚାଳକ ହୋଇନଥିବା ଡ଼ିରେକ୍ଟୋରୀରେ ସ୍ଥାପିତ iSCSI ଡ଼ିସ୍କଗୁଡ଼ିକୁ ବ୍ୟବହାର ନକରି ତନ୍ତ୍ର ସ୍ଥାପନା କରନ୍ତୁ ଏବଂ ପରେ ଉପଯୁକ୍ତ ଡ଼ିସ୍କ ଏବଂ ସ୍ଥାପନ କ୍ଷେତ୍ରକୁ ହସ୍ତକୃତ ଭାବରେ ବିନ୍ୟସ କରନ୍ତୁ।
ସ୍ଥାପିତ ତନ୍ତ୍ରକୁ ରନଲେବେଲ 1ରେ ବୁଟ କରନ୍ତୁ, ଏବଂ କୌଣସି iSCSI ଡ଼ିସ୍କକୁ ଚିହ୍ନଟ କରନ୍ତୁ ଯାହାକି ପ୍ରତ୍ୟେକ ଡ଼ିସ୍କରେ ଥରେ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶ ବ୍ୟବହାର କରି ସ୍ୱୟଂଚାଳିତ ଭାବରେ ପ୍ରାରମ୍ଭ ହେବାକୁ ପ୍ରମୁଖ ଚାଳକ ଫାଇଲ ତନ୍ତ୍ର ପାଇଁ ବ୍ୟବହାର ହୋଇନଥାଏ:
iscsiadm -m node -T
target-name
-p ip:port
-o update -n node.startup -v automatic
rhythmbox ଧ୍ୱନୀ ଚାଳକ ସଂସ୍କରଣ 0.11.6କୁ ଅଦତିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ନିଜସ୍ୱ GStreamer ପ୍ଲଗଇନଗୁଡ଼ିକୁ ବ୍ୟବହାର କରିବା ପାଇଁ ବିକଳ୍ପ ପ୍ରଦାନ କରିଥାଏ।
ଥଣ୍ଡରବାର୍ଡ ନୂତନତମ ସ୍ଥାୟୀ ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 3.7.1ରେ ପୁନଃ ସ୍ଥାପିତ ହୋଇଛି।ଏହି ଅଦ୍ୟତନ ବହୁତଗୁଡ଼ିଏ ଅପଷ୍ଟ୍ରିମ ଗୁଣ ଏବଂ ତ୍ରୁଟି ନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ, ସେଥିର ଅନ୍ତର୍ଭୁକ୍ତ:
mirror --script
ଦ୍ୱାରା ସୃଷ୍ଟିହୋଇଥିବା (ଯାହାକି ଅନଧିକୃତ ଅଧିକାର ପ୍ରଦାନ) lftp ଲିଖିତ ସ୍କ୍ରିପ୍ଟରେ ପ୍ରବାହିତ ସୁରକ୍ଷା ବର୍ତ୍ତମାନ ଠିକ ହୋଇଯାଇଛି।
-c
ବିକଳ୍ପ ସହିତ lftp ବ୍ୟବହାର କରି lftp କୁ ଅଟକରଖିନଥାଏ।
lftp ପରିବହନ ସମୟରେ କେବେକି ଫାଇଲକୁ ନଷ୍ଟ କରିନଥାଏ sftp
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରି।
ଏହି ପ୍ରକାଶନରେ ପ୍ରୟୋଗ କରାଯାଇଥିବା ଅଦ୍ୟତନ lftp ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇଁ, http://lftp.yar.ru/news.htmlକୁ ଅନୁସରଣ କରନ୍ତୁ।
TTY ନିବେଶ ସମ୍ପାଦନ ବର୍ତ୍ତମାନ ସମର୍ଥିତ। ଯଦି କୌଣସି ପଦ୍ଧତି TTY ନିବେଶ ସମ୍ପାଦନ ପାଇଁ ଚିହ୍ନିତ ଅଛି, ତେବେ TTY ଗୁଡ଼ିକରୁ ପଢାଯାଉଥିବା ତଥ୍ୟକୁ ସମ୍ପାଦନ କରାଯାଇଥାଏ; ଏହା ସମ୍ପାଦନ ଅନୁଲିପିରେ TTY
ଧାରାରେ ଦର୍ଶାଯିବ।
ଆପଣ pam_tty_audit
ଏକକାଂଶକୁ ଗୋଟିଏ ପଦ୍ଧତିକୁ ଚିହ୍ନିବା ପାଇଁ ବ୍ୟବହାର କରିପାରିବେ (ଏବଂ ଏହାର ନିମ୍ନସ୍ତରର ପଦ୍ଧତି) ପାଇଁ TTY ନିବେଶ ସମ୍ପାଦନକୁ ବ୍ୟବହାର କରିପାରିବେ। ଏହାକୁ କିପରି କରାଯିବ ତାହାର ନିର୍ଦ୍ଦେଶ ପାଇଁ, man pam_tty_audit(8)
କୁ ଅନୁସରଣ କରନ୍ତୁ।
TTY ସମ୍ପାଦନ ଅନୁଲିପି ସମ୍ପାଦିତ ପଦ୍ଧତି ଦ୍ୱାରା ପଢାଯାଇଥିବା ସଠିକ କି ଷ୍ଟ୍ରୋକକୁ ଧାରଣ କରିଥାଏ। ତଥ୍ୟ ଅବସଙ୍କେତକୁ ସହଜମୟ କରିବା ପାଇଁ, USER_TTY
ଅନୁଲିପି ପ୍ରକାରକୁ ବ୍ୟବହାର କରି bash
ସଠିକ ନିର୍ଦ୍ଦେଶ ନାମାକୁ ସମ୍ପାଦନ କରିଥାଏ
"TTY" ସମ୍ପାଦନ ଅନୁଲିପି ସମ୍ପାଦିତ ପ୍ରଣାଳୀଗୁଡ଼ିକରୁ TTY ପଢ଼ିଥିବା ସମସ୍ତ ତଥ୍ୟକୁ ଧାରଣ କରିଥାଏ। ଏହା TIOCSTI ioctl
ତନ୍ତ୍ର ଡାକରା ଦ୍ୱାରା ନିବେଶ ଧାରାରେ ଭର୍ତ୍ତି କରାଯାଇଥିବା ତଥ୍ୟକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ।
SystemTap ସଂସ୍କରଣ 0.7.2 ରେ ପୁନଃ ସ୍ଥାପିତ. SystemTap ର ଏହି ଅଦ୍ୟତନ କିଛି ମୂଖ୍ୟ ଗୁଣ ସହିତ କିଛି ଗୌଣ ଉନ୍ନତିକୁ ଆରମ୍ଭ କରିଥାଏ। ଏହି ନୂତନ ଗୁଣଗୁଡ଼ିକରେ ଅନ୍ତରଭୁକ୍ତ:
SystemTap ବର୍ତ୍ତମାନ x86, x86-64 ଏବଂ PowerPC ସଂରଚନାରେ ସାଂକେତିକ ଅନୁସନ୍ଧାନକୁ ସମର୍ଥନ କରିଥାଏ। ଏହା ଚାଳକ-ସ୍ଥାନ ପ୍ରୟୋଗଗୁଡ଼ିକରେ ଏବଂ ସହଭାଗୀ ଲାଇବ୍ରେରୀରେ ଅନୁସନ୍ଧାନକୁ ରଖିବା ପାଇଁ SystemTap ସ୍କ୍ରିପ୍ଟକୁ ସକ୍ରିୟ କରିଥାଏ। ଫଳସ୍ୱରୂପ, କିଛି ଚାଳକ-ସ୍ଥାନ ପ୍ରୟୋଗରେ କର୍ଣ୍ଣଲ ଅନୁସନ୍ଧାନ ପରି SystemTap ବର୍ତ୍ତମାନ ସମାନ ସ୍ତରର ତ୍ରୁଟିନିବାରଣକାରୀ ଅନୁସନ୍ଧାନ ପ୍ରଦାନ କରିଥାଏ।
ଉଦାହରଣ ସ୍ୱରୂପ, ଯଦି coreutils-debuginfo
ସ୍ଥାପିତ ହୋଇଛି, ls
ନିର୍ଦ୍ଦେଶକୁ /usr/share/doc/systemtap-
ବ୍ୟବହାର କରି ଆପଣ କୋଲଗ୍ରାଫ ମୁଦ୍ରଣ କରିପାରିବେ, ଯେପରି କି:
version
/examples/general/callgraph.stp
stap para-callgraph.stp 'process("ls").function("*")' -c 'ls -l'
ବାଇନାରୀ ଏବଂ ତ୍ରୁଟି ନିବାରଣ ସୂଚନା RPMଗୁଡ଼ିକ ମଧ୍ଯରେ ଥିବା ଗୋଟିଏ ଅଜ୍ଞାତ ସଂସ୍କରଣ ଅମେଳକର ସମ୍ଭାବନାକୁ କମାଇବା ପାଇଁ, Red Hat ଉପଦେଶ ଦିଏ ଯେ ଆପଣ +:.debug:/usr/lib/debug:build
ମୂଲ୍ୟ ପାଇଁ ଚଳ SYSTEMTAP_DEBUGINFO_PATH
ପରିବେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ।
ସାଙ୍କେତିକ ଅନୁସନ୍ଧାନ ପାଇଁ SystemTapର ସମର୍ଥନ ମଧ୍ଯ ଏହା ପ୍ରକାଶନର କର୍ଣ୍ଣଲରେ ଥିବା ଚିହ୍ନଟ ପର୍ଯ୍ୟନ୍ତ ଲମ୍ବିଥାଏ। ଏହି ଚିହ୍ନଟଗୁଡ଼ିକୁ ବ୍ୟବହାର କରିବ ପାଇଁ, kernel-trace
କର୍ଣ୍ଣଲ ଏକକାଂଶକୁ /etc/rc.local
ରେ ଧାରଣ କରନ୍ତୁ (modprobe kernel-trace
କୁ ବ୍ୟବହାର କରି)।
SystemTap ସୁଦୂର ସଂକଳନ ସର୍ଭିସକୁ ସମର୍ଥନ କରିଥାଏ। ଏହା SystemTap କ୍ଲାଏଣ୍ଟରେ ତ୍ରୁଟିମୁକ୍ତ ସୂଚନା/ସଂକଳକ ସର୍ଭର ପରି କାର୍ଯ୍ୟ କରିବା ପାଇଁ ନେଟୱର୍କରେ ଗୋଟିଏ କମ୍ପୁଟରକୁ ସକ୍ରିୟ କରିଥାଏ। କ୍ଲାଏଣ୍ଟ mDNS ବ୍ୟବହାର କରି ସର୍ଭରକୁ ସ୍ୱୟଂ-ଚିହ୍ନଟ କରିଥାଏ (avahi), ଏବଂ କାର୍ଯ୍ୟ କରିବା ପାଇଁ କେବଳ systemtap-client
ଏବଂ systemtap-runtime
ପ୍ୟାକେଜଗୁଡ଼ିକୁ ଆବଶ୍ୟକ କରିଥାଏ।
ଏବେ ପର୍ଯ୍ୟନ୍ତ, ଏହି ବିଶେଷ ଗୁଣ ସଂଗୁପ୍ତ ପରି ସୁରକ୍ଷା ବ୍ୟବସ୍ଥା ବ୍ୟବହାର କରିନଥାଏ। ତେଣୁ, ସୁଦୂର ସଂକଳନ ସର୍ଭିସକୁ କେବଳ ବିଶ୍ୱସ୍ତ ନେଟୱର୍କ ମଧ୍ଯରେ ବ୍ୟବହାର କରିବା ଉଚିତ। ଅଧିକ ସୂଚନା ପାଇଁ, man stap-server
କୁ ଅନୁସରଣ କରନ୍ତୁ।
ଏହି ପ୍ରକାଶନ ପାଇଁ କର୍ଣ୍ଣଲ ଅଦ୍ୟତନରେ ଗୋଟିଏ କର୍ଣ୍ଣଲ ଅନୁଲଗ୍ନ ଅନ୍ତର୍ଭୁକ୍ତ ଯାହାକି SystemTap ସ୍କ୍ରିପ୍ଟର ବନ୍ଦକୁ ମହତ୍ତ୍ୱପୂର୍ଣ୍ଣ ଭାବରେ ଉନ୍ନତି କରିଥାଏ। ଏହି ସଂଯୁକ୍ତ କର୍ଣ୍ଣଲ API ଅନୁଲଗ୍ନ ବ୍ୟକ୍ତିଗତ ଅନୁସନ୍ଧାନ କଢ଼ା ପ୍ରୟୋଗରୁ ଅଦରକାରୀ ସଂକାଳନକୁ ନଷ୍ଟ କରିଦେଇଥାଏ। ଫଳସ୍ୱରୂପ, ଶତାଧିକ କର୍ଣ୍ଣଲ ଅନୁସନ୍ଧାନ ବିଶିଷ୍ଟ SystemTap ସ୍କ୍ରିପ୍ଟର ପ୍ରଣାଳୀ ତିବ୍ରଗତିରେ ଚାଲୁଥାଏ।
ଏହା ମୁଖ୍ୟତଃ ପ୍ରଶାସକମାନଙ୍କ ପାଇଁ ଉପଯୋଗୀ ଯାହାକି ଅନେକ କର୍ଣ୍ଣଲ ଘଟଣାଗୁଡ଼ିକୁ ଧରିରଖି ୱାଇଲ୍ଡ କାର୍ଡ ଧାରଣ କରିଥିବା ଅନୁସନ୍ଧାନ ସହିତ ସ୍କ୍ରିପ୍ଟ ବ୍ୟବହାର କରିଥାଏ, ଯେପରି କି probe syscall.* {}
।
ଏହି ପ୍ରକାଶନରେ ଅନ୍ତର୍ଭୁକ୍ତ SystemTap ଅଦ୍ୟତନଗୁଡ଼ିକର ସମ୍ପୂର୍ଣ୍ଣ ତାଲିକା ପାଇଁ, ନିମ୍ନଲିଖିତ URL କୁ ଅନୁସରଣ କରନ୍ତୁ:
http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=blob_plain;f=NEWS;hb=rhel53
Cluster ପରିଚାଳକ ଉପଯୋଗୀତା (cman) ସଂସ୍କରଣ 2.0.97କୁ ଅଦ୍ୟତିତ ହୋଇସାରିଛି। ଏହା ବହୁତଗୁଡ଼ିଏ ତ୍ରୁଟିନିବାରଣ ଏବଂ ଉନ୍ନତିକୁ ପ୍ରୟୋଗ କରିଥାଏ, ମୁଖ୍ୟତଃ:
cman ବର୍ତ୍ତମାନ ନିମ୍ନଲିଖିତ ଫର୍ମୱେର ସଂସ୍କରଣ ବ୍ୟବହାର କରନ୍ତି: APC AOS v3.5.7 ଏବଂ APC rpdu v3.5.6. ଏହା APC 7901 କୁ ସାଧାରଣ ନେଟୱର୍କ ପରିଚାଳନା ପ୍ରୋଟୋକଲ (SNMP)କୁ ସଠିକ ଭାବରେ ବ୍ୟବହାର କରି ତ୍ରୁଟି ନିବାରଣ କରିଥାଏ।
fence_drac
, fence_ilo
, fence_egenera
, ଏବଂ fence_bladecenter
ଏଜେଣ୍ଟ ବର୍ତ୍ତମାନ ssh
କୁ ସମର୍ଥନ କରେ।
fence_xvmd
କି ଫାଇଲଗୁଡ଼ିକ ବର୍ତ୍ତମାନ ବିନା ପୁନଃ ପ୍ରାରମ୍ଭରେ ପୁନର୍ଧାରଣ ହୋଇଥାଏ।
ଗୋଟିଏ ଫେନ୍ସ ପଦ୍ଧତି ବର୍ତ୍ତମାନ 8 ଫେନ୍ସ ଉପକରଣଗୁଡ଼ିକ ପର୍ଯ୍ୟନ୍ତ ସମର୍ଥନ କରିଥାଏ।
sudo ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 1.6.9.ରେ ପୁନଃ ସ୍ଥାପିତ ହୋଇସାରିଛି sudoର ଏହି ସଂସ୍କରଣ LDAPକୁ ସମର୍ଥନ କରେ, ଏବଂ sudo ଅଧିକାର ପାଇଁ ଆଧାର ସନ୍ଧାନ ପରିବର୍ତ୍ତେ ଉପ-ବୃକ୍ଷ ସନ୍ଧାନକୁ ଅନୁମତି ଦେଇଥାଏ (ଯେପରିକି, କେବଳ ବୃକ୍ଷ-ସ୍ତର)। ଏହା ଚାଳକ ବିଶେଷ ଅଧିକାରକୁ ପରିଚାଳନା କରିବା ପାଇଁ ସହଜମୟ କରିବାକୁ ପ୍ରଶାସକଙ୍କୁ sudo ଅଧିକାରକୁ ବିଭାଜନ କରିବା ପାଇଁ ଅନୁମତି ଦେଇଥାଏ।
RedHat Package Manager (RPM) ବର୍ତ୍ତମାନ Fedora 9 ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣରେ ପୁନଃସ୍ଥାପିତ ହୋଇସାରିଛି। rpm ବର୍ତ୍ତମାନ ମଲ୍ଟି-ଆର୍କ ତନ୍ତ୍ରରେ ଦ୍ୱିତୀୟକ ସଂରଚନା-ବିଶିଷ୍ଟ ମାକ୍ର ଫାଇଲଗୁଡ଼ିକରେ ଯୋଗ ହୋଇଥାଏ। ଏହା ସହିତ, rpm ବର୍ତ୍ତମାନ Red Hat Enterprise Linux 5ରେ ଅନ୍ତର୍ଭୁକ୍ତ ହେବା ପାଇଁ ସମସ୍ତ ପ୍ରମାଣପତ୍ର ଯୋଗ୍ୟତା ହାସଲ କରିସାରିଛି।
ଏହି ଅଦ୍ୟତନ ମଧ୍ଯ ଅନେକ ଅପଷ୍ଟ୍ରିମ ଉନ୍ନତି ଏବଂ ତ୍ରୁଟି ନିବାରଣକୁ rpm ରେ ପ୍ରୟୋଗ କରିଥାଏ, ନିମ୍ନଲିଖିତମାନଙ୍କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି:
rpm ଏବେ ଆଉ ଅଦରକାରୀ .rpmnew
ଏବଂ .rpmsave
ଫାଇଲଗୁଡ଼ିକୁ multi-arch ତନ୍ତ୍ରରେ ସୃଷ୍ଟି କରେନାହିଁ।
rpmର rpmgiNext()
ଫଳନରେ ଥିବା ତ୍ରୁଟି ସଠିକ ତ୍ରୁଟି ଖବରକୁ ଅଟକାଇଥାଏ। ଏହି ଅଦ୍ୟତନ ତ୍ରୁଟି ଖବର କରିବା ପାଇଁ ଉପଯୁକ୍ତ ଅର୍ଥ ବିନ୍ୟାସ ପ୍ରୟୋଗ କରିଥାଏ, ଯାହା ଫଳରେ ଏହା ନିଶ୍ଚିତ କରିଥାଏ ଯେ rpm ସମସ୍ତ କ୍ଷେତ୍ରରେ ସଠିକ ପ୍ରସ୍ଥାନ ସଂକେତ ଦେଇଥାଏ।
opensm ଲାଇବ୍ରେରୀ APIରେ ଛୋଟ ପରିବର୍ତ୍ତନକୁ ଅନ୍ତର୍ଭୁକ୍ତକରି opensm
ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 3.2କୁ ଅଦ୍ୟତିତ ହୋଇଥାଏ।
opensm.conf
ଫାଇଲର ଶୈଳୀ ପରିବର୍ତ୍ତନ ହୋଇଯାଇଛି। ଯଦି ଆପଣ ଆପଣଙ୍କର ସ୍ଥିତବାନ opensm.conf
ରେ ଇଚ୍ଛାମୁତାବକ ପରିବର୍ତ୍ତନ କରିଛନ୍ତି, ତେବେ rpm ସ୍ୱୟଂଚାଳିତ ଭାବରେ ନୂତନ opensm.conf
ଫାଇଲକୁ /etc/ofed/opensm.conf.rpmnew
ପରି ସ୍ଥାପନ କରିଦେବ।. ଆପଣଙ୍କୁ ଆପଣଙ୍କର ପରିବର୍ତ୍ତନଗୁଡ଼ିକୁ ଏହି ଫାଇଲ ମଧ୍ଯକୁ ସ୍ଥାନାନ୍ତରିତ କରିବାକୁ ହେବ ଏବଂ ତାପରେ ସ୍ଥିତବାନ opensm.conf ଫାଇଲକୁ ଫଳାଫଳ ସହିତ ବଦଳାଇ ଦିଅନ୍ତୁ।
ଅପଷ୍ଟ୍ରିମ Open Fabrics Enterprise Distribution (OFED) ସଙ୍କେତ ଆଧାରକୁ ଏହି ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପାଇଁ ସର୍ବାଧିକ ସ୍ତରୀୟ ସକ୍ରିୟଣକୁ ପ୍ରଦାନ କରିବାକୁ Red Hat ନିକଟରୁ ସନ୍ଧାନ କରୁଅଛି। ଏହି କାରଣରୁ, Red Hat କେବଳ API/ABI ସୁସଂଗତକୁ ଛୋଟ ପ୍ରକାଶନଗୁଡ଼ିକ ମଧ୍ଯରେ ଅପଷ୍ଟ୍ରିମ ପ୍ରକଳ୍ପ ପର୍ଯ୍ୟନ୍ତ ସୁରକ୍ଷିତ ରଖିଥାଏ। Red Hat Enterprise Linuxର ସାଧାରଣ ବିକାଶ ଅଭ୍ୟାସରୁ ଏହା ଗୋଟିଏ ବ୍ୟତିକ୍ରମ।
ଏହି କାରଣରୁ, OFED ଥାକ ଉପରେ ନିର୍ମିତ ଥିବା ଅନୁରୋଧକୁ (ନିମ୍ନରେ ତାଲିକାଭୁକ୍ତ), Red Hat Enterprise Linuxର ଗୋଟିଏ ଛୋଟ ପ୍ରକାଶନରୁ ଅନ୍ୟ ଏକ ନୂତନ ପ୍ରକାଶନକୁ ପଠାଇବା ସମୟରେ ପୁନଃସଙ୍କଳନ କିମ୍ବା ଉତ୍ସ-ସ୍ତରୀୟ ସଙ୍କେତ ପରିବର୍ତ୍ତନଗୁଡ଼ିକୁ ଆବଶ୍ୟକ କରିପାରେ।
ଏହା ସାଧାରଣତଃ Red Hat Enterprise Linux ସଫ୍ଟୱେର ଥାକରେ ନିର୍ମିତ ଅନ୍ୟ ପ୍ରୟୋଗ ପାଇଁ ଆବଶ୍ୟକ ହୋଇନଥାଏ। ପ୍ରଭାବିତ ଉପାଦାନଗୁଡ଼ିକ ହେଉଛି:
dapl
compat-dapl
ibsim
ibutils
infiniband-diags
libcxgb3
libehca
libibcm
libibcommon
libibmad
libibumad
libibverbs
libipathverbs
libmlx4
libmthca
libnes
librmdacm
libsdp
mpi-selector
mpitests
mstflint
mvapich
mvapich2
ofed-docs
openib
openib-mstflint
openib-perftest
openib-tvflash
openmpi
opensm
perftest
qlvnictools
qperf
rds-ସାଧନଗୁଡ଼ିକ (ଭବିଷ୍ୟତ)
srptools
tvflash
Net-SNMP ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 5.3.2.2ରେ ପୁନଃ-ସ୍ଥାପିତ ହେଇସାରିଛି। ଏହି ଅଦ୍ୟତନ Stream Control Transmission Protocol (SCTP) ସମର୍ଥନ ଯୋଗ କରିଥାଏ (RFC 3873 ଅନୁସାରେ, http://www.ietf.org/rfc/rfc3873.txt) ଏବଂ ଦୁଇଟି ନୂତନ ବିନ୍ୟାସ ବିକଳ୍ପ ସହିତ ପରିଚିତ କରାଇଥାଏ (/etc/snmpd.conf
ରେ ବ୍ୟବହାର କରିବା ପାଇଁ):
dontLogTCPWrappersConnects
-- ସଂଯୋଗ ପ୍ରଚେଷ୍ଟାଗୁଡ଼ିକୁ ଲଗଇନ ହେବାରୁ ଅଟକାଇଥାଏ।
v1trapaddress
-- ବାହାରୁଥିବା SNMP ଜାଲ ମଧ୍ଯରେ ଗୋଟିଏ ଏଜେଣ୍ଟର IP ଠିକଣାକୁ ସେଟକରିବା ପାଇଁ ପ୍ରଶାସକମାନଙ୍କୁ ସକ୍ରିୟ କରାଇଥାଏ।
ଏହି ଅଦ୍ୟତନ ଅପଷ୍ଟ୍ରିମରୁ ମିଳୁଥିବା କେତେକ ତ୍ରୁଟିନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ, ନିମ୍ନଲିଖିତମାନଙ୍କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି:
snmpd
ଡେମନ ବର୍ତ୍ତମାନ 255ରୁ ଅଧିକ ନେଟୱର୍କ ଅନ୍ତରାପୃଷ୍ଠ ବିଶିଷ୍ଟ ତନ୍ତ୍ରରେ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟକରୁଅଛି। ଏହା ସହିତ, snmpd
ମଧ୍ଯ ବର୍ତ୍ତମାନ ଗୋଟିଏ ତ୍ରୁଟି ଖବର କରିଥାଏ ଯେତେବେଳେ ଏହା 65535ରୁ ଅଧିକ ଯେକୌଣସି ସଞ୍ଚାର ଦ୍ୱାରକୁ ଉତ୍ତର ଦେବାପାଇଁ ବିନ୍ୟାସିତ ହୋଇଥାଏ।
ଗୋଟିଏ ଘଡ଼ିସନ୍ଧି ମୁହୂର୍ତ୍ତ ଯାହାଫଳରେ snmpd
ଡ଼େମନକୁ /proc
ରୁ ପଢ଼ିବା ସମୟରେ ଫାଇଲ ବର୍ଣ୍ଣନାକାରୀକୁ ଖସି ପଳାଇଥାଏ, ତାହା ଏବେ ଠିକ ହୋଇଯାଇଛି.
snmpd
ଡ଼େମନ hrProcessorLoad
ବସ୍ତୁ IDs (OID)କୁ ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ ଖବର କରିଥାଏ, ଏକାଧିକ-CPU ହାର୍ଡୱେରରେ ମଧ୍ୟ। ମନେରଖନ୍ତୁ, ଯଦିଚ, ଏହା ଡ଼େମନ ଆରମ୍ଭରୁ OIDର ମୂଲ୍ୟ ନିର୍ଦ୍ଧାରଣ କରିବା ପାଇଁ ପାଖାପାଖି ଏକ ମିନଟ ସମୟ ଲାଗିଥାଏ।
net-snmp-devel
ପ୍ୟାକେଜ ବର୍ତ୍ତମାନ lm_sensors-devel
ପ୍ୟାକେଜ ଉପରେ ନିର୍ଭର କରିଥାଏ।
openssl
ପ୍ୟାକେଜଗୁଡ଼ିକ OpenSSL ଲାଇବ୍ରେରୀକୁ ଗୋଟିଏ ନୂତନ ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣକୁ ଉନ୍ନତ କରିଥାଏ, ଯାହାକି ବର୍ତ୍ତମାନ Federal Information Processing Standards validation process (FIPS-140-2)ରେ ଚାଲୁଅଛି। Red Hat Enterprise Linux 5ରେ openssl
ପ୍ୟାକେଜଗୁଡ଼ିକର ପୂର୍ବ ପ୍ରକାଶନ ସହିତ OpenSSL ଲାଇବ୍ରେରୀ ବିଶେଷଗୁଣର ଯୁଗଳତା ଏବଂ ABI ସୁସଂଗତି ପାଳନ କରୁଅଛି କି ନାହିଁ ତାହା ନିଶ୍ଚିତ କରିବା ପାଇଁ FIPS ଧାରାଟି ପୂର୍ବନିର୍ଦ୍ଧାରିତ ରୂପେ ନିଷ୍କ୍ରିୟ ହୋଇଛି।
ଏହି ଅଦ୍ୟତନ ନିମ୍ନଲିଖିତ ଅପଷ୍ଟ୍ରିମ ନିର୍ଦ୍ଧାରଣକୁ ମଧ୍ଯ ପ୍ରୟୋଗ କରିଥାଏ:
ପୂର୍ବନିର୍ଦ୍ଧାରିତ ରୂପେ, zlib
ସଙ୍କୋଚନଟି SSL ଏବଂ TLS ସଂଯୋଗ ପାଇଁ ବ୍ୟବହୃତ ହୋଇଥାଏ। IBM System z ସଂରଚନାଗୁଡ଼ିକରେ ଆଭ୍ୟନ୍ତରୀଣ ସଞ୍ଚାଳକ ଗୂଢ଼ଲେଖୀ ଫଳନ (CPACF)କୁ ସହାୟତା କରିଥାଏ, ସଙ୍କୋଚନ CPU ଧାରଣର ମୂଖ୍ୟ ଅଂଶ ହୋଇଥାଏ, ଏବଂ ସର୍ବମୋଟ କାର୍ଯ୍ୟକାରୀତାକୁ ସଙ୍କୋଚନ ଗତି ଦ୍ୱାରା ନିର୍ଦ୍ଧାରଣ କରାଯାଇଥାଏ (ସଂଗୁପ୍ତ ଗତି ଉପରେ ଆଧାରିତ ହୋଇନଥାଏ)। ଯେତେବେଳେ ସଙ୍କୋଚନକୁ ନିଷ୍କ୍ରିୟ କରାଯାଇଥାଏ, ସର୍ବମୋଟ କାର୍ଯ୍ୟକ୍ଷମତାଟି ଅଧିକ ହୋଇଥାଏ। ଏହି ଅଦ୍ୟତିତ ପ୍ୟାକେଜଗୁଡ଼ିକରେ, SSL ଏବଂ TLS ସଂଯୋଗ ପାଇଁ zlib
ସଙ୍କୋଚନକୁ OPENSSL_NO_DEFAULT_ZLIB
ପରିବେଶ ପ୍ରାଚଳ ସହିତ ନିଷ୍କ୍ରିୟ କରାଯାଇପାରେ। ମନ୍ଥର ନେଟୱର୍କରେ TLS ସଂଯୋଗ ପାଇଁ, ସଙ୍କୋଚନକୁ ତ୍ୟାଗ କରିବା ଭଲ, ଯାହା ଫଳରେ ପରିବହନ ହେବାକୁ ଥିବା ତଥ୍ୟର ଆକାର କମ ଥାଏ।
s_client
ଏବଂ s_server
ବିକଳ୍ପ ସହିତ openssl
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରୁଥିବା ସମୟରେ, ପୂର୍ବନିର୍ଦ୍ଧାରିତ CA ପ୍ରମାଣପତ୍ର ଫାଇଲ (/etc/pki/tls/certs/ca-bundle.crt
)କୁ ପଢ଼ାହୋଇନଥିଲା। ଫଳସ୍ୱରୂପ ପ୍ରମାଣପତ୍ର ଯାଞ୍ଚ ବିଫଳ ହୋଇଥାଏ। ପ୍ରମାଣପତ୍ରଗୁଡ଼ିକର ଯାଞ୍ଚ ସଫଳ ହେବାକୁ, -CAfile /etc/pki/tls/certs/ca-bundle.crt
ବିକଳ୍ପକୁ ବ୍ୟବହାର କରିବାକୁ ହେବ। ଏହି ଅଦ୍ୟତିତ ପ୍ୟାକେଜଗୁଡ଼ିକରେ, ପୂର୍ବନିର୍ଦ୍ଧାରିତ CA ପ୍ରମାଣପତ୍ର ଫାଇଲ ପଢ଼ିଥାଏ, ଏବଂ କେବେବି -CAfile
ବିକଳ୍ପରେ ଦର୍ଶାଇବାକୁ ପଡ଼ିନଥାଏ।
yum କୁ ସଂସ୍କରଣ 3.2.18ରେ ପୁନଃ-ସ୍ଥାପନ କରାଯାଇଛି। ଏହି ଅଦ୍ୟତନ yum କୁ ପ୍ରୟୋଗ କରାଯାଉଥିବା ଗତିରେ ଉନ୍ନତି ଆଣିଥାଏ, ଯାହାଫଳରେ ପ୍ରତ୍ୟେକ ଛୋଟ ପ୍ରକାଶନରେ ବର୍ଦ୍ଧିଷ୍ନୁ ପ୍ୟାକେଜ ସଂଖ୍ୟାକୁ ଅଟକାଇ ସମସ୍ୟାକୁ କମ କରିଥାଏ। ଏହା ସଙ୍ଗେ ନିମ୍ନଲିଖିତମାନଙ୍କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି, ଏହି ଅଦ୍ୟତନ ମଧ୍ଯ ପୁନର୍ସ୍ଥାପନ ନିର୍ଦ୍ଦେଶକୁ ପରିଚିତ କରାଇଥାଏ, ଅନେକ ନିର୍ଦ୍ଦେଶ ପାଇଁ ଅନ୍ତରାପୃଷ୍ଠକୁ ଉନ୍ନତ କରିଥାଏ, ଏବଂ ଅନେକ ତ୍ରୁଟି ସଂଶୋଧନକୁ ପ୍ରୟୋଗ କରିଥାଏ:
କୌଣସି yum ନିର୍ଦ୍ଦେଶ ବିଫଳ ହୋଇଥାଏ ଯଦି -c
ବିକଳ୍ପକୁ ୱେବ ଠିକଣାରେ (http) ଥିବା ଗୋଟିଏ ବିନ୍ୟାସ ଫାଇଲକୁ ନିର୍ଦ୍ଦିଷ୍ଟ କରିବା ପାଇଁ ବ୍ୟବହୃତ ହୋଇଥାଏ। ଏହି ତ୍ରୁଟିକୁ ବର୍ତ୍ତମାନ ସଂଶୋଦନ କରାସରିଛି।
yumରେ ଥିବା checkSignal()
ଫଳନ ଗୋଟିଏ ଭୁଲ ପ୍ରସ୍ଥାନ ଫଳନକୁ ଡାକିଥାଏ; ସେହିପରି, yum ରୁ ପ୍ରସ୍ଥାନ କରିବା ସମୟରେ ଫଳସ୍ୱରୂପ ପଛୁଆ ସନ୍ଧାନ କରିଥାଏ। ଏହି ପ୍ରକାଶନ ସହିତ, yum ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ ପ୍ରସ୍ଥାନ କରିଥାଏ।
ଫ୍ଲାଶ-ପ୍ଲଗଇନ
ପ୍ୟାକେଜକୁ ସଂସ୍କରଣ 10.0.12.36 ରେ ପୁନଃ ସ୍ଥାପନା କରାସରିଛି। ଏହି ଅଦ୍ୟତନ ଅନେକ ସୁରକ୍ଷା ପ୍ରଦାନକୁ ପ୍ରୟୋଗ କରିଥାଏ ଯାହାକି ପୂର୍ବ ଫ୍ଲାଶ-ପ୍ଲଗଇନ
ASYNC ଅଦ୍ୟତନରେ ଅନ୍ତର୍ଭୁକ୍ତ ଥାଏ। ଏହା ପରେ ମଧ୍ଯ, ଏହି ଅଦ୍ୟତିତ ପ୍ଲଗଇନ Adobe Flash Player 10 ଧାରଣ କରିଥାଏ, ଯେଉଁଥିରେ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ନିବାରଣ ଏବଂ ବିଶେଷଗୁଣ ଉନ୍ନତି ଅନ୍ତର୍ଭୁକ୍ତ:
ଧ୍ୱନି ନିର୍ଗମରେ ଘଡ଼ିସନ୍ଧି ସମସ୍ୟାକୁ ଠିକ କରାବା ପାଇଁ Linux ପ୍ଲାଟଫର୍ମ ଉପରେ ଉନ୍ନତ ଧରଣର ସ୍ଥିରତା।
ଇଚ୍ଛାଧୀନ ଛଣା ଏବଂ ପ୍ରଭାବ, ପ୍ରକୃତ 3D ରୂପାନ୍ତରଣ ଏବଂ ସଜୀବନ, ଉନ୍ନତ ଧ୍ୱନୀ ସଞ୍ଚାଳନ, ଗୋଟିଏ ନୂତନ, ଅଧିକ ଅନୁନେୟ ପାଠ୍ୟ ଯନ୍ତ୍ର, ଏବଂ GPU ହାର୍ଡୱେର ତ୍ୱରଣ ପାଇଁ ନୂତନ ସମର୍ଥନ।
ଏହି ଅଦ୍ୟତନ ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇଁ, Adobe Flash Player 10 ପ୍ରକାଶନ ଟିପ୍ପଣୀକୁ ନିମ୍ନଲିଖିତ ସଂଯୋଗରେ ଅନୁସରଣ କରନ୍ତୁ:
http://www.adobe.com/support/documentation/en/flashplayer/10/Flash_Player_10_Release_Notes.pdf
gdb ବର୍ତ୍ତମାନ ସଂସ୍କରଣ 6.8ରେ ପୁନଃସ୍ଥାପିତ ହୋଇସାରିଛି। ଏହା ଅନେକ ଅପଷ୍ଟ୍ରିମ ବିଶେଷ ଗୁଣକୁ ଅଦ୍ୟତନ କରିଥାଏ ଏବଂ ତ୍ରୁଟି ନିବାରଣ କରିଥାଏ, ଉଲ୍ଲେଖନୀୟ ଭାବେ: C++ ଢାଞ୍ଚା, ନିର୍ମାଣକାରୀ ଏବଂ ଲାଇନ ଭିତର ଫଳନ ମଧ୍ଯରେ ବ୍ରେକପଏଣ୍ଟ ପାଇଁ ସମର୍ଥନ।
ଏହି ପ୍ରକାଶନରେ ପ୍ରୟୋଗ କରାଯାଇଥିବା gdb ଅଦ୍ୟତନ ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇଁ, http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/NEWS?rev=1.259.2.1 &cvsroot=src କୁ ଅନୁସରଣ କରନ୍ତୁ।
AMD Family10h ସଂଞ୍ଚାଳକ ପାଇଁ ନୂତନ ହାର୍ଡୱେର ସଂକ୍ଷିପ୍ତ ଚିତ୍ରଣ ସମର୍ଥନକୁ Red Hat Enterprise Linux 5.3 ପାଇଁ ଯୋଗ କରାଯାଇଛି। ଏହି ନୂତନ AMD CPUଗୁଡ଼ିକ ନିର୍ଦ୍ଦେଶ ଆଧାରିତ ନମୁନା ସଂଗ୍ରହ (IBS)କୁ ସମର୍ଥନ କରିଥାଏ। IBS ସମର୍ଥନ ସୂଚନା ସଂଗ୍ରହ କରିବା ପାଇଁ oProfile ଡ୍ରାଇଭରରେ ପରିବର୍ତ୍ତନ ଆବଶ୍ୟକ କରିଥାଏ ଏବଂ ଏହି ନୂତନ ବିଶେଷଗୁଣ ସହିତ ସଂଶ୍ଳିଷ୍ଟ ନୂତନ ମଡେଲ ନିର୍ଦ୍ଦିଷ୍ଟ ପଞ୍ଜିକରଣ (MSRs)କୁ ଆରମ୍ଭ କରିଥାଏ।
ଏହି ଅଦ୍ୟତନ ନୂତନ IBS_FETCH
ଏବଂ IBS_OP
ସଂକ୍ଷିପ୍ତ ଚିତ୍ରଣ ନମୁନା ସଂଗ୍ରହକୁ ପ୍ରତି CPU ବଫର ଏବଂ oProfile ଡ୍ରାଇଭରରେ ଯୋଗ କରିଥାଏ। ନୂତନ ନିୟନ୍ତ୍ରଣ ଭରଣଗୁଡ଼ିକ ମଧ୍ଯ IBS ନମୁନା ସଂଗ୍ରହ ପାଇଁ /dev/oprofile
ରେ ଯୋଗ କରାଯାଇଛି। ଏହି ପରିବର୍ତ୍ତନଗୁଡ଼ିକ ଡ୍ରାଇଭରର କେବଳ ଗୋଟିଏ ସଂସ୍କରଣ ପୂର୍ବ PMC ସହିତ ପଛୁଆ ସୁସଂଗତ, ଏବଂ oProfile 0.9.3 ରେ ଏହି ନୂତନ ତଥ୍ୟକୁ ବ୍ୟବହାର କରିବା ପାଇଁ ଗୋଟିଏ ପୃଥକ ପ୍ୟାଚ ଉପଲବ୍ଧ।
IBS ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇଁ: ନିର୍ଦ୍ଦେଶ ଆଧାରିତ ନମୁନା ସଂଗ୍ରହ: AMD Family 10h ସଞ୍ଚାଳକ ପାଇଁ ଗୋଟିଏ ନୂତନ ବିଶ୍ଳେଷଣ ବିଧି, November 19, 2007 କୁ ଅନୁସରଣ କରନ୍ତୁ
Squid ନୂତନତମ ସ୍ଥାୟୀ ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ (STABLE21)ରେ ପୁନଃ ସ୍ଥାପିତ ହୋଇଛି।ଏହି ଅଦ୍ୟତନ ବହୁତଗୁଡ଼ିଏ ତ୍ରୁଟିକୁ ଈଙ୍ଗିତ କରିଥାଏ, ସେଥିର ଅନ୍ତର୍ଭୁକ୍ତ:
squid init
ସ୍କ୍ରିପ୍ଟ ସର୍ବଦା ଭୁଲ ଭାବରେ 0ର ଗୋଟିଏ ପ୍ରସ୍ଥାନ କୋଡ ଫେରାଇଥାଏ। ଏହି ତ୍ରୁଟିଟି ବର୍ତ୍ତମାନ ଠିକ ହୋଇସାରିଛି,ଲିନକ୍ସ ମାନକ ଆଧାର ସହିତ ବର୍ତ୍ତମାନ squid ଅନୁବର୍ତ୍ତି କରି।
refresh_stale_hit
ବ୍ୟବହାର କରି ଡିରେକ୍ଟିଭ ତ୍ରୁଟି ସନ୍ଦେଶ ଘଟାଇଥାଏ ଘଣ୍ଟା ପଛକୁ ଯାଇଥାଏ
, squid ଲଗ ଫାଇଲରେ ଦେଖାଦେଇ।
squid ସ୍ଥାପନା ପଦ୍ଧତି /usr/local/squid
ଡିରେକ୍ଟୋରୀର ଏହି ପ୍ରକାଶନରେ ସଠିକ ନିଜସତ୍ୱ ନିର୍ଧାରଣ କରିନଥାଏ, ଚାଳକ squid
ଟି ବର୍ତ୍ତମାନ /usr/local/squid
ର ପୂର୍ବନିର୍ଦ୍ଧାରିତ ମାଲିକ।
ଯେତେବେଳେ squid ଫଳନ hash_lookup()
କୁ ବ୍ୟବହାର କରିବା ପାଇଁ ଚେଷ୍ଟା କରେ, ସେତେବେଳେ ଏହା signal 6
କୁ ପରିତ୍ୟାଗ କରିପାରେ।
squid_unix_group
ବ୍ୟବହାର କରିବା ଦ୍ୱାରା squid ନଷ୍ଟ ହୋଇପାରେ।
httpd
, ଆପାଚେ HTTP ସର୍ଭର ପ୍ୟାକେଜ, ବର୍ତ୍ତମାନ ପରୀକ୍ଷଣୀୟ ଘଟଣା Multi-Processing Model (MPM) କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ। keepalive ସଂଯୋଗକୁ ନିୟନ୍ତ୍ରଣ କରିବା ପାଇଁ ଏହି MPM ସମର୍ପିତ ଥ୍ରେଡ଼କୁ ବ୍ୟବହାର କରି କାର୍ଯ୍ୟକ୍ଷମତାକୁ ଉନ୍ନତତର କରିଥାଏ।
ସମ୍ପାଦନ ଉପତନ୍ତ୍ର ଦ୍ୱାରା କର୍ଣ୍ଣଲରେ ନିର୍ମାଣ ହୋଇଥିବା ସମ୍ପାଦନ ଦଲିଲଗୁଡ଼ିକୁ ସଂରକ୍ଷଣ ଏବଂ ସନ୍ଧାନ କରିବା ପାଇଁ ସମ୍ପାଦନ ପ୍ୟାକେଜ ଚାଳକ-ସ୍ଥାନ ଉପଯୋଗୀତାଗୁଡ଼ିକୁ ଧାରଣ କରିଥାଏ। ସମ୍ପାଦନ ପ୍ୟାକେଜଗୁଡ଼ିକ ନୂତନ ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 1.7.7 କୁ ଅଦ୍ୟତିତ କରିଥାଏ, ଯାହାକି ଉଭୟ ଉନ୍ନତି ଏବଂ ପୂର୍ବ ସମ୍ପାଦନ ପ୍ୟାକେଜଗୁଡ଼ିକରେ ତ୍ରୁଟି ନିବାରଣ ପ୍ରଦାନ କରିଥାଏ।
ଏହି ଅଦ୍ୟତିତ ସମ୍ପାଦନ ପ୍ୟାକେଜଗୁଡ଼ିକ ନିମ୍ନଲିଖିତ ଉନ୍ନତିଗୁଡ଼ିକୁ ଯୋଗ କରିଥାଏ:
ସମ୍ପାଦିତ ତନ୍ତ୍ରଟି ବର୍ତ୍ତମାନ ସୂଦୁର ଲଗିଙ୍ଗ କାର୍ଯ୍ୟକରିବାରେ ସକ୍ଷମ।
auditctl ଉପଯୋଗୀତା ବର୍ତ୍ତମାନ ସମ୍ପାଦନ ନିୟମାବଳୀରେ ଏକାଧିକ କିକୁ ସମର୍ଥନ କରିଥାଏ।
ଗୋଟିଏ ନମୁନା STIG ନିୟମାବଳୀ ଫାଇଲ (stig.rules) ଯାହାକି auditctl ନିୟମ ଧାରଣ କରିଥାଏ ତାହା ସେତେବେଳେ ଧାରଣ କରାଯାଇଥାଏ ଯେତେବେଳେ ଏହି ଅଦ୍ୟତିତ ପ୍ୟାକେଜଗୁଡ଼ିକ ଉଦାହରଣ ଭାବରେ ଦିଆଯାଇଥିବା init ସ୍କ୍ରିପ୍ଟଗୁଡ଼ିକ ଦ୍ୱାରା ସମ୍ପାଦନ ଡ଼େମନ ଆରମ୍ଭ ହୋଇଥାଏ।
ଗୋଟିଏ ନୂତନ ଉପଯୋଗୀତା, ausyscallକୁ ross-referencing syscall ନାମ ଏବଂ ସଂଖ୍ଯା ସୂଚନା ଉଦ୍ଦେଶ୍ୟରେ ଯୋଗ କରାଯାଇଛି।
aureport ବର୍ତ୍ତମାନ ସମ୍ପାଦନ ଘଟଣାଗୁଡ଼ିକରେ ଦେଖାଉଥିବା କି ବିଷୟରେ ଖବର ପ୍ରଦାନ କରିଥାଏ।
ausearch ଏବଂ aureport ପ୍ରଗ୍ରାମଗୁଡ଼ିକ ପାଇଁ ବିଶ୍ଳେଷଣ କରୁଥିବା ଘଟଣା ତାଲିକାକୁ ଉନ୍ନତ କରାସରିଛି।
libgomp
କୁ ସଂସ୍କରଣ 4.3.2-7.el5ରେ ପୁନଃ-ସ୍ଥାପନ କରାଯାଇଛି। ପୁନଃ-ସ୍ଥାପନ OpenMP
କାର୍ଯ୍ୟକ୍ଷମତାକୁ ଉନ୍ନତତର କରିଥାଏ ଏବଂ OpenMP
ସଂସ୍କରଣ 3.0 ପାଇଁ gcc43
ସଂକଳକ ସହିତ ବ୍ୟବହାର ହେଉଥିବା ସମୟରେ ସମର୍ଥନ ଯୋଗ କରିଥାଏ।
iSCSI ଲକ୍ଷ୍ୟ କ୍ଷମତା, Linux ଲକ୍ଷ୍ୟ (tgt) ଫ୍ରେମୱର୍କ ଅଂଶ ଭାବରେ ଦିଆଯାଇଥାଏ, ପୂର୍ଣ୍ଣ ସମର୍ଥନ ପାଇଁ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନରୁ Red Hat Enterprise Linux 5.3କୁ ଅଣାଯାଇଥାଏ। Linux ଲକ୍ଷ୍ୟ ଫ୍ରେମୱର୍କ ଗୋଟିଏ ତନ୍ତ୍ରକୁ SCSI ପ୍ରାରମ୍ଭକାରୀ ଅନ୍ୟ ତନ୍ତ୍ରମାନଙ୍କୁ ବ୍ଲକ-ସ୍ତରୀୟ SCSI ଭଣ୍ଡାର ସେବା ପ୍ରଦାନ କରିବା ପାଇଁ ଅନୁମତି ଦେଇଥାଏ। ଏହି କ୍ଷମତାକୁ ଆରମ୍ଭରୁ ଗୋଟିଏ ନେଟୱର୍କ ଉପରେ ଯେକୌଣସି iSCSI ପ୍ରାରମ୍ଭକାରୀ ଭଣ୍ଡାରକୁ ସର୍ଭିସ ଦେବା ପାଇଁ Linux iSCSI ଲକ୍ଷ୍ୟ ଆକାରରେ ପ୍ରୟୋଗ କରାଯାଇଥାଏ।
iSCSI ଲକ୍ଷ୍ୟକୁ ବିନ୍ୟାସ କରିବା ପାଇଁ, scsi-target-utils RPMକୁ ସ୍ଥାପନ କରନ୍ତୁ ଏବଂ ନିମ୍ନଲିଖିତ ଫାଇଲଗୁଡ଼ିକ ମଧ୍ଯରେ ଥିବା ନିର୍ଦ୍ଦେଶକୁ ଅନୁସରଣ କରନ୍ତୁ: /usr/share/doc/scsi-target-utils-
ଏବଂ [version]
/README/usr/share/doc/scsi-target-utils-
[version]
/README.iscsi
ALSAରେ ଥିବା Intel High Definition Audio driver ଅଦ୍ୟତିତ ହୋଇଛି।
ଉଚ୍ଚ ପରିଭାସୀ ମଲ୍ଟିମେଡିଆ ଅନ୍ତରାଫଳକ (HDMI) ଧ୍ୱନି ବର୍ତ୍ତମାନ AMD ATI ଏକତ୍ରିତ ଚିପସେଟରେ ସମର୍ଥିତ ଅଟେ।
ନିମ୍ନଲିଖିତ Wacom ଆଲେଖି ଟ୍ୟାବଲେଟଗୁଡ଼ିକ ବର୍ତ୍ତମାନ linuxwacom
ଡ୍ରାଇଭର ଦ୍ୱାରା ସମର୍ଥନପ୍ରାପ୍ତ:
Cintiq 20WSX
Intuos3 4x6
lpfc
ଡ୍ରାଇଭର ଏମୁଲେକ୍ସ ଫାଇବର ଚ୍ୟାନେଲ ହୋଷ୍ଟ ବସ ଏଡପଟର ପାଇଁ ସଂସ୍କରଣ 8.2.0.33.2p କୁ ଉନ୍ନୟନ କରାଯାଇଛି। ଏହା ମହତ୍ବପୂର୍ଣ୍ଣ ଭାବରେ ଅନେକ ଉର୍ଦ୍ଧଗାମୀ ପରିବର୍ତ୍ତନ ମାନଙ୍କୁ ଲାଗୁ କରିଥାଏ:
NETLINK_SCSITRANSPORT ସକେଟ ବର୍ତ୍ତମାନ ବ୍ୟବହାର ହେଉଛି
ସମାଧାନ ହୋଇଥିବା ଆରମ୍ଭହୋଇନଥିବା ନୋଡ ଅଭିଗମ୍ୟତା।
NPIV ସକ୍ରିୟ ଥିବା ସମୟରେ ଘଟିଥିବା echotest ବିଫଳତା ତ୍ରୁଟିକୁ ଠିକ କରାଯାଇଛି।
fcauthd
1.19 ଟି ବର୍ତ୍ତମାନ ଫାଇବର ଚ୍ୟାନେଲ ପ୍ରାଧିକରଣ ପାଇଁ ଆବଶ୍ୟକ।
dm-multipath
ରେ ବର୍ତ୍ତମାନ IBM DS4000 ପାଇଁ inbox ସମର୍ଥନ ଅଛି.
ixgbe
ଡ୍ରାଇଭର ବର୍ତ୍ତମାନ 82598AT ଡୁଆଲ-ପୋର୍ଟ ଏଡପଟର ଏବଂ 82598 CX4 ଏଡପଟରକୁ ସମର୍ଥନ କରୁଅଛି।
Digi Neo PCI Express 4 HiProfile
I/O ଏଡପଟରଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେବା ପାଇଁ jsm
ଡ୍ରାଇଭରକୁ ଅଦ୍ୟତିତ କରାଯାଇଛି.
hp-ilo: ଡ୍ରାଇଭର ଯୋଗ କରାଯାଇଛି, HP Integrated Lights Out (iLO) technology ପାଇଁ ସମର୍ଥନ ପ୍ରଦାନ କରି.
radeon_tp
ଡ୍ରାଇଭରଟି ବର୍ତ୍ତମାନ ଏହି ପ୍ରକାଶନରେ ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ ସମର୍ଥିତ। ଏହି ଡ୍ରାଇଭର ATI R500/R600 ଚିପସେଟକୁ ସକ୍ରିୟ କରିଥାଏ।
ଏହି ଚାଳକଟି ମଧ୍ଯ ନିମ୍ନଲିଖିତ କ୍ଷମତା ଗୁଡିକୁ ପ୍ରଦର୍ଶନ ପ୍ରଦାନ କରିଥାଏ:
R500/R600 ଚିପସେଟ ଗୁଡିକରେ ମୋଡସେଟିଙ୍ଗ କରିବା
R500 ଚିପସେଟ ଗୁଡିକରେ 2D ତ୍ୱରଣ
R600 ଚିପସେଟ ଗୁଡିକରେ ସ୍ୟେଡୋ ଫ୍ରେମବଫର ତ୍ୱରଣ
powernow-k8
ଡ୍ରାଇଭର ବର୍ତ୍ତମାନ ଧାରଣଯୋଗ୍ୟ ଏକକାଂଶ ଭାବରେ ଏହି ପ୍ରକାଶନରେ ଅନ୍ତର୍ଭୁକ୍ତ। ଏହା ନିଶ୍ଚିତ କରେ ଯେ ସ୍ଥିତବାନ ଡ୍ରାଇଭର ଫ୍ରେମୱର୍କଗୁଡ଼ିକ (ଯେପରି କି Red Hat Driver Update Model ଏବଂ Dell DKMS) ଚାଳକମାନଙ୍କୁ RPM ପ୍ୟାକେଜଗୁଡ଼ିକ ପରି କର୍ଣ୍ଣଲକୁ ଉନ୍ନତତର ନକରି powernow-k8
ଡ୍ରାଇଭର ଅଦ୍ୟତନ ଦେଇପାରିବେ।
ଏହି ପ୍ରକାଶନ ପାଇଁ, ପୁରୁଣା ମୁଦ୍ରଣୀଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେବା ପାଇଁ Red Hat pnm2ppa
କୁ ପୁଣିଥରେ ଯୋଗ କରୁଅଛି. ମନେରଖନ୍ତୁ, ଯଦ୍ୟପି, ଏହି ସମର୍ଥନକୁ ଅପସନ୍ଦ କରାଯାଇଛି ଏବଂ ଏହାକୁ ପରବର୍ତ୍ତି ମୁଖ୍ୟ ପ୍ରକାଶନଗୁଡ଼ିକରେ ବାଦକରିଦିଆଯିବ.
ccid
ଡ୍ରାଇଭରଟି USB ସ୍ମାର୍ଟକାର୍ଡ କିବୋର୍ଡଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେବା ପାଇଁ ପୁଣିଥରେ ସ୍ଥାପିତ ହୋଇଛି।
USB ଭିଡ଼ିଓ ଉପକରଣ ପାଇଁ uvcvideo
ଡ୍ରାଇଭର Red Hat Enterprise Linux 5.3ର କର୍ଣ୍ଣଲରେ ଯୋଗ କରାସରିଛି।
Broadcom NetXtreme II ନେଟୱର୍କ କାର୍ଡ଼ ପାଇଁ ଥିବା bnx2
ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 1.7.9କୁ ଅଦ୍ୟତିତ କରାହୋଇଛି. ଏହି ଅଦ୍ୟତନ ଇଥରନେଟ ମୁଦ୍ରା ବଫର ବିକଳ୍ପକୁ ନିୟନ୍ତ୍ରକରେ ଠିକ କରିଥାଏ ଯାହାକି ବୁଟ ସମୟରେ ତନ୍ତ୍ରରେ ଆତଙ୍କ ସୃଷ୍ଟି କରୁଥିବା ଗୋଟିଏ ତ୍ରୁଟିକୁ ଠିକ କରିବା ପାଇଁ bnx2
କୁ ବ୍ୟବହାର କରିଥାଏ।
Intel PRO/1000 ଇଥରନେଟ ଉପକରଣ ପାଇଁ e1000e
ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 0.3.3.3-k2କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି. ଏହା ଅଦ୍ୟତନ ସହିତ, ସମର୍ଥିତ ଉପକରଣଗୁଡ଼ିକର EEPROM ଏବଂ NVM ବର୍ତ୍ତମାନ ଲେଖା ପ୍ରତିରୋଧିତ.
Intel Gigabit ଇଥରନେଟ ଏଡପଟରଗୁଡ଼ିକ ପାଇଁ igb
: ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 1.2.45-k2କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି, 82576 ଆଧାରିତ ଉପକରଣଗୁଡ଼ିକ ପାଇଁ ସମର୍ଥନ ଯୋଗକରାଯାଉଛି।
Intel(R) 10 Gigabit PCI Express ନେଟୱର୍କ ଉପକରଣଗୁଡ଼ିକ ପାଇଁ ixgbe
ଡ୍ରାଇଭର ସଂସ୍କରଣ 1.3.18-k4କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
niu
ଡ୍ରାଇଭରକୁ Red Hat Enterprise Linux 5.3ରେ ଯୋଗ କରାଯାଇଛି, Sun CP3220 ରେ 10Gbps ଇଥରନେଟ ଉପକରଣ ପାଇଁ ସମର୍ଥନ ଯୋଗକରି।
ipw2100
ଏବଂ ipw2200
ଡ୍ରାଇଭରଗୁଡ଼ିକୁ IntelPRO ବେତାର ଉପକରଣଗୁଡ଼ିକ ପାଇଁ କର୍ଣ୍ଣଲ 2.6.25ରୁ Red Hat Enterprise Linux 5.3 କୁ ବ୍ୟାକପୋର୍ଟ କରାଯାଇଛି।
bcm43xx
ଡ୍ରାଇଭର ବ୍ରୋଡକମ ବେତାର ଉପକରଣଗୁଡ଼ିକୁ ଲିନକ୍ସ କର୍ଣ୍ଣଲ 2.6.25 ରୁ Red Hat Enterprise Linux 5.3 କୁ ବ୍ୟାକପୋର୍ଟ କରାଯାଇଛି।
ieee80211
ବେତାର ଉପକରଣ ପାଇଁ ସମର୍ଥନ ଉପାଦାନ ଲିନକ୍ସ କର୍ଣ୍ଣଲ 2.6.25ରୁ Red Hat Enterprise Linux 5.3କୁ ବ୍ୟାକପୋର୍ଟ କରାଯାଇଛି।
zd1211rw
ଡ୍ରାଇଭର ZyDas ବେତାର ଉପକରଣ ଅନ୍ତିମ non-mac80211 ସଂସ୍କରଣ ସହିତ ମେଳାଇବା ପାଇଁ ଲିନକ୍ସ 2.6.25 ପୂର୍ବରୁ ଅଦ୍ୟତିତ ହୋଇଛି।
iwlwifi
ଡ୍ରାଇଭରଗୁଡ଼ିକୁ iwl4965
ବେତାର ଉପକରଣ 802.11n କୁ ସମର୍ଥନ ଯୋଗକରି, ସଂସ୍କରଣ 2.6.26ରୁ ଅଦ୍ୟତିତ କରାଯାଇଛି. କେତେକ ତ୍ରୁଟିନିବାରଣ ଡ୍ରାଇଭରର ସଂସ୍କରଣ-2.6.26 ପରେ ଅନ୍ତରଭୁକ୍ତ କରାଯାଇଛି ଏବଂ ମଧ୍ଯ ବ୍ୟାକପର୍ଟ ଡ୍ରାଇଭରରେ ସାମିଲ କରାଯାଇଛି.
Myricom Myri-10G ଇଥରନେଟ ଉପକରଣ ପାଇଁ myri10ge
ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 1.3.2-1.269କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି.
netxen
ଡ୍ରାଇଭର NetXen ନେଟୱର୍କ କାର୍ଡକୁ ସଂସ୍କରଣ 3.4.18କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
bnx2x
ଡ୍ରାଇଭର ବ୍ରୋଡ଼କମ ଏଭରେଷ୍ଟ ନେଟୱର୍କ ଉପକରଣଗୁଡ଼ିକୁ 57711 ହାର୍ଡୱେରକୁ ସମର୍ଥନ କରିବା ପାଇଁ ସଂସ୍କରଣ 1.45.23 କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
forcedeth-msi
ଡ୍ରାଇଭକୁ ତ୍ରୁଟିନିବାରଣ କରିବା ପାଇଁ ଅଦ୍ୟତିତ କରାଯାଇଛି ଯାହାକୁି ପ୍ରକୃତ ଲିଙ୍କ-ଅପ ନିର୍ଦ୍ଧାରଣକୁ ଅଟକାଇବା ପାଇଁ ନିଯୁକ୍ତ କରାଯାଇଛି.
ath5k
ଡ୍ରାଇଭର Atheros ବେତାର ଉପକରଣଗୁଡ଼ିକୁ ଲିନକ୍ସ କର୍ଣ୍ଣଲ 2.6.26ରୁ Red Hat Enterprise Linux 5.3 କୁ ବ୍ୟାକପୋର୍ଟ କରାଯାଇଛି।
rt2x00
ଡ୍ରାଇଭରଗୁଡ଼ିକ Ralink ବେତାର ଉପକରଣ ପାଇଁ ଲିନକ୍ସ କର୍ଣ୍ଣଲ 2.6.26ରୁ Red Hat Enterprise Linux 5.3 କୁ ବ୍ୟାକପୋର୍ଟ ହୋଇଛି।
rtl8180
ଏବଂ rtl8187
ଡ୍ରାଇଭରଗୁଡ଼ିକ Realtek ବେତାର ଉପକରଣଗୁଡ଼ିକ ପାଇଁ ଲିନକ୍ସ କର୍ଣ୍ଣଲ 2.6.26ରୁ Red Hat Enterprise Linux 5.3କୁ ବ୍ୟାକପୋର୍ଟ ହୋଇଛି.
cxgb3
: ଡ୍ରାଇଭର (ଅନୁରୂପ ଫର୍ମୱେର ସହିତ) ବର୍ତ୍ତମାନ ଏହି ପ୍ରକାଶନରେ ଅନ୍ତର୍ଭୁକ୍ତ। ଏହି ଡ୍ରାଇଭର Chelsio RDMA 10Gb PCI-E ଇଥରନେଟ ଏଡାପଟର କୁ ସମର୍ଥନ କରେ।
3w-xxxx
: ସଂସ୍କରଣ 1.26.03କୁ ଅଦ୍ୟତିତ 3ware SATA RAID ନିୟନ୍ତ୍ରକ ପାଇଁ ଡ୍ରାଇଭର. ଏହା ବହୁତଗୁଡ଼ିଏ ଅପଷ୍ଟ୍ରିମ ପରିବର୍ତ୍ତନକୁ ପ୍ରୟୋଗ କରିଥାଏ, ଦୃଷ୍ଟାନ୍ତ ସ୍ୱରୂପ:
2GBରୁ ଅଧିକ RAM ସହିତ ଗୋଟିଏ ତନ୍ତ୍ରରେ 3ware 7000 କିମ୍ବା 8000 କ୍ରମ କାର୍ଡ ବ୍ୟବହାର କରି ଗୋଟିଏ ତ୍ରୁଟି ନିବାରଣ କରିଥିଲେ, ଯାହାକି ତଥ୍ୟ ନଷ୍ଟ କରୁଥାଏ।
4GBରୁ ଅଧିକ RAM ବିଶିଷ୍ଟ ତନ୍ତ୍ରରେ 3ware 8006 କ୍ରମ କାର୍ଡ ବ୍ୟବହାର କରି ଆନାକୋଣ୍ଡା 64-ବିଟ ସଂରଚନା ଉପରେ ନିର୍ଭର କରିନଥାଏ।
irq ନିୟନ୍ତ୍ରକ ବର୍ତ୍ତମାନ ମୁକ୍ତ ଯେତେବେଳେ __tw_shutdown()
ଟି ଆରମ୍ଭ ହୋଇଥାଏ। ଯଦି ବନ୍ଦକରିବା ସମୟରେ କୌଣସି ବାଧା ହୁଏ ତେବେ, ଏହା ସମ୍ଭାବ୍ୟ null pointer de-reference କୁ ବାରଣ କରିଥାଏ।
କେଶିଙ୍ଗ ପଦ୍ଧତି ପୃଷ୍ଠାକୁ ବର୍ତ୍ତମାନ ଅନ କରିବା ପାଇଁ RCD ବିଟ।
ioctl
ପୁନର୍ବିନ୍ୟାସ ଏବଂ scsi
ପୁନର୍ବିନ୍ୟାସ ବର୍ତ୍ତମାନ କ୍ରମରେ ଅଛି, ଯାହା ଫଳରେ ସେମାନଙ୍କ ମଧ୍ଯରେ ଧକ୍କାହୋଇନଥାଏ।
3w-9xxx
: ସଂସ୍କରଣ 2.26.08 କୁ ଅଦ୍ୟତିତ 3ware SATA RAID ନିୟନ୍ତ୍ରକ ପାଇଁ ଡ୍ରାଇଭର. ଏହା ବହୁତଗୁଡ଼ିଏ ଅପଷ୍ଟ୍ରିମ ପରିବର୍ତ୍ତନକୁ ପ୍ରୟୋଗ କରିଥାଏ, ଦୃଷ୍ଟାନ୍ତ ସ୍ୱରୂପ:
pci_unmap_single()
ଡାକରା 4GB ରୁ ଅଧିକ RAM ବିଶିଷ୍ଟ ତନ୍ତ୍ର ସହିତ ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିଥାଏ
ମନ୍ଥର ଲେଖା କାର୍ଯ୍ୟକାରିତା ଘଟାଇଥାଏ ଯାହାକି ଗୋଟିଏ ତ୍ରୁଟି ନିବାରଣ କରିଥାଏ।
DMA ମାସ୍କ ବିନ୍ୟାସ ବର୍ତ୍ତମାନ 32-ବିଟକୁ ଓଲଟି ଯାଇଛି ଯଦି 64-ବିଟ ବିଫଳ ହୁଏ।
3ware 9690SA SAS ନିୟନ୍ତ୍ରକ ଉପକରଣ ପାଇଁ ଅତିରିକ୍ତ ସମର୍ଥନ।
megaraid_sas
: ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 4.01-rh1 କୁ ଅଦ୍ଯତନ କରାଯାଇଛି। ଏହି ଅଦ୍ୟତନ ଦ୍ୱାରା ଅନେକ ତ୍ରୁଟି ନିବାରଣଗୁଡ଼ିକୁ ପ୍ରୟୋଗ କରାଯାଇଥାଏ, ଅନ୍ତର୍ଭୁକ୍ତ କରି:
MFI_POLL_TIMEOUT_SECS
ଟି ବର୍ତ୍ତମାନ 60 ସେକଣ୍ଡ।
ଅନବରତ ଚିପ ପୁନଃସ୍ଥାପନ ଏବଂ ଫ୍ରେମ ଗଣନା ହେତୁ ସମୟସମାପ୍ତ ଘଟାଉଥିବା ତ୍ରୁଟିକୁ ଠିକ କରାଯାଇଛି।
LSI Generation 2 Controllers (0078, 0079) ପାଇଁ ସମର୍ଥନ ଯୋଗ କରାଯାଇଛି।
ଫର୍ମୱେର ବନ୍ଦକୁ ଉନ୍ନତ କରିବା ପାଇଁ ବନ୍ଦ ସାରଣୀରେ DCMD କୁ ବନ୍ଦ କରିବା ପାଇଁ ଗୋଟିଏ ନିର୍ଦ୍ଦେଶ ଯୋଗକରାଯାଇଛି।
ହାର୍ଡୱେର ଲିନକ୍ସ ଡ୍ରାଇଭରରେ ଅପ୍ରତ୍ୟାଶିତ ବ୍ୟାଘାତ ଘଟାଉଥିବା ତ୍ରୁଟିକୁ ଠିକ କରାଯାଇଛି।
ନିମ୍ନଲିଖିତ ଉନ୍ନତିଗୁଡ଼ିକୁ ପ୍ରଦାନ କରି, SCSI ଉପକରଣ ନିୟନ୍ତ୍ରକ ସଂରଚନା (scsi_dh
) କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି:
ଗୋଟିଏ ଜାତିଗତ ALUA (ଅସମମିତ ଯୁକ୍ତିଯୁକ୍ତ ଏକକ ଅଭିଗମ୍ୟତା) ନିୟନ୍ତ୍ରକକୁ କାର୍ଯ୍ୟକାରୀ କରାଯାଇଛି.
LSI RDAC SCSI ଆଧାରିତ ଭଣ୍ଡାର ଉପକରଣ ପାଇଁ ସମର୍ଥନ ଯୋଗ କରାଯାଇଛି.
qla2xxx
ଡ୍ରାଇଭର ପାଇଁ QLogic ଫାଇବର ଚ୍ୟାନେଲ ହୋଷ୍ଟ ବସ ଏଡପଟରକୁ ଅଦ୍ୟତିତ କରାଯାଇଛି, ISP84XX ପ୍ରକାର କାର୍ଡ଼ଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେବା ପାଇଁ.
ଆଭାସି ଟ୍ୟାପ ଉପକରଣଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେଇ, SCSI (vSCSI) ଉପକରଣଗୁଡ଼ିକୁ ସମତାଳରେ ରଖିବା ପାଇଁ ibmvscsi
ଡ୍ରାଇଭରଗୁଡ଼ିକୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।କରାଯାଇଛି.
lpfc
: ଡ୍ରାଇଭର ସଂସ୍କରଣ 8.2.0.30କୁ ଅଦ୍ଯତିତ କରାଯାଇଛି। ଏହି ଅଦ୍ଯତନ ମହତ୍ବପୂର୍ଣ୍ଣ ଭାବରେ ଅନେକ ପରିବର୍ତ୍ତନ ମାନଙ୍କୁ ଅନ୍ତରଭୁକ୍ତ କରିଥାଏ:
PowerPC ସଂରଚନାରେ PCI ଏଡପଟରଗୁଡ଼ିକ ପାଇଁ ଉନ୍ନତ ତ୍ରୁଟି ନିୟନ୍ତ୍ରଣ (EEH)
ସମର୍ଥିତ NPIV ଆଭାସୀ ସଂଯୋଗିକୀଗୁଡ଼ିକର ସଂଖ୍ୟା ବୃଦ୍ଧି କରାହେଲା
I/O ଧାଡ଼ି ଗଭୀରତାକୁ ନିୟନ୍ତ୍ରଣ କରିବା ପାଇଁ ଉନ୍ନତ ଡ୍ରାଇଭର ତର୍କ
ଇଥରନେଟ (FCoE) ଏଡପଟରଗୁଡ଼ିକ ଉପରେ ଫାଇବର ଚ୍ୟାନେଲ ପାଇଁ ଅତିରିକ୍ତ ସମର୍ଥନ
ନୂତନ ହାର୍ଡୱେର ପାଇଁ SANରୁ ବୁଟକରିବା ବର୍ତ୍ତମାନ ସମର୍ଥିତ
HP Smart Array ନିୟନ୍ତ୍ରକ ପାଇଁ cciss
ଡ୍ରାଇଭରକୁ ସଂସ୍କରଣ 3.6.20-RH2କୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
relayfs
ରେ ପୂର୍ବରୁ 64MBର ବଫର ଆକାର ସୀମା ଥିଲା। ଏହି ଅଦ୍ୟତନରେ, ସ୍ମୃତି ସ୍ଥାନ ବଫରରେ relayfs ପାଇଁ ବଣ୍ଟିତ ସ୍ମୃତି ସ୍ଥାନର ସୀମା 4095MBକୁ ବୃଦ୍ଧି କରାଯାଇଛି। ଏହା SystemTap ଏବଂ ଅନ୍ୟାନ୍ୟ ଖୋଜିବା ସାଧନକୁ ଯାହାକି ଅଧିକ ଘଟଣା ଖୋଜିବା ପାଇଁ relayfs
କୁ ଉପଯୋଗ କରିଥାଏ, ସେମାନଙ୍କୁ ଅନୁମତି ଦେଇଥାଏ।
Dell Remote Access Controller 4
(DRAC4) ପାଇଁ ଥିବା ଡ୍ରାଇଭର ଉପସ୍ଥିତ ନଥିଲା. ଫଳସ୍ୱରୂପ, DRAC4 ଦ୍ୱାରା ପ୍ରଦତ୍ତ ଯେକୌଣସି ଆଭାସୀ ଉପକରଣକୁ କର୍ଣ୍ଣଲ ଦ୍ୱାରା ଖୋଜିପାରିନଥିଲେ। ଏହି ଅଦ୍ୟତନରେ, pata_sil680 କର୍ଣ୍ଣଲ ଏକକାଂଶ ଯାହାକି ଉପଯୁକ୍ତ ଡ୍ରାଇଭର ପ୍ରଦାନ କରିଥାଏ ତାହାକୁ ଯୋଗକରାଯାଇଛି, ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
ସନ୍ଦେଶ ବଫର ପାଇଁ ଥିବା ରିଲେ ଅନ୍ତରାପୃଷ୍ଠ କେବଳ ଅନଲାଇନ CPUଗୁଡ଼ିକ ପାଇଁ ବଣ୍ଟିତ ହୋଇଥାଏ ଯେତେବେଳେ relay_open()
କୁ ଡକାଯାଇଥାଏ। ଫଳସ୍ୱରୂପ, ଯଦି relay_open()
କୁ ଡକାଗଲା ପରେ ଗୋଟିଏ ଅଫଲାଇନ CPUକୁ ଅନ କରାଯାଏ, ତେବେ କର୍ଣ୍ଣଲ ଆତଙ୍କ ଘଟିପାରେ। ଏହି ଅଦ୍ୟତନରେ, ଗୋଟିଏ ନୂତନ ସନ୍ଦେଶ ବଫରକୁ ବଣ୍ଟନ କରାଯାଇଥାଏ ଯଦି କୌଣସି ନୂତନ CPUsକୁ ଯୋଗ କରାଯାଇଥିବ।
8250 ଆଧାରିତ କ୍ରମିକ ସଂଯୋଗିକୀଗୁଡ଼ିକ ପାଇଁ ଥିବା ଡ୍ରାଇଭରକୁ DSR/DTR ହାର୍ଡୱେର ପ୍ରବାହ ନିୟନ୍ତ୍ରଣ ପାଇଁ ସମର୍ଥନ ଯୋଗକରିବାକୁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
କର୍ଣ୍ଣଲରେ Dell Wireless Wide Area Network (WWAN) କାର୍ଡଗୁଡ଼ିକ ପାଇଁ ସମର୍ଥନ ଯୋଗ କରାଯାଇଛି। ବର୍ତ୍ତମାନ ସମର୍ଥିତ ଉପକରଣଗୁଡ଼ିକ ହେଉଛି:
Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card
Dell Wireless 5500 Mobile Broadband HSDPA Mini-Card
Dell Wireless 5505 Mobile Broadband HSDPA Mini-Card
Dell Wireless 5700 Mobile Broadband CDMA/EVDO ExpressCard
Dell Wireless 5510 Mobile Broadband HSDPA ExpressCard
Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card
Dell Wireless 5700 Mobile Broadband CDMA/EVDO Mini-Card
Dell Wireless 5720
Dell Wireless HSDPA 5520
Dell Wireless HSDPA 5520
Dell Wireless 5520 Voda I Mobile Broadband (3G HSDPA) Mini-Card
thinkpad_acpi
କର୍ଣ୍ଣଲ ଏକକାଂଶ ନୂତନ ଥିଙ୍କପେଡ ମଡେଲ ପାଇଁ ଉନ୍ନତ ସମର୍ଥନ ଦେବାକୁ ଅଦ୍ୟତନ କରାଯାଇଛି।
ସଫ୍ଟ ଲକଅପ ଖୋଜାଳି ବର୍ତ୍ତମାନ ଚେତାବନୀ ସନ୍ଦେଶ ପରିବର୍ତ୍ତେ ଗୋଟିଏ କର୍ଣ୍ଣଲ ଆତଙ୍କ ସତର୍କ ସୂଚନାକୁ ବିନ୍ୟାସ କରୁଅଛି। ଏହା ଚାଳକମାନଙ୍କ ପାଇଁ ସଫ୍ଟ ଲକଅପ ସମୟରେ ନ୍ୟାୟିକ ଉଦ୍ଦେଶ୍ୟରେ କ୍ରାଶ ଡମ୍ପ ସୃଷ୍ଟି ଏବଂ ବିଶ୍ଳେଷଣ କରିବାକୁ ସମ୍ଭବପର କରିଥାଏ।
ଆତଙ୍କର ସତର୍କ ସୂଚନା ସୃଷ୍ଟି କରିବା ପାଇଁ ସଫ୍ଟ ଲକଅପ ଖୋଜାଳି ବିନ୍ୟାସ କରିବାକୁ, କର୍ଣ୍ଣଲ ପ୍ରାଚଳ soft_lockup
କୁ 1
ରେ ସେଟକରନ୍ତୁ। ଏହି ପ୍ରାଚଳଟି ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଭାବେ 0
ସେଟ କରାଯାଇଥାଏ।
ପରବର୍ତ୍ତୀ-ପିଢ଼ି Intel Microarchitecture (Nehalem) ଉପରେ ଆଧାରିତ ପ୍ରଚାଳନ ତନ୍ତ୍ରକୁ oprofile
ଚିହ୍ନିପାରିନଥାଏ। ଫଳସ୍ୱରୂପ, କାର୍ଯ୍ୟକ୍ଷମତା ନିରିକ୍ଷଣ ସଂସ୍ଥାକୁ ବ୍ୟବହାର କରାଯାଇପାରିବ ନାହିଁ ଏବଂ ପ୍ରଚାଳନତନ୍ତ୍ର ଘଡ଼ି ବ୍ୟାହାତରେ ପଡ଼ିଥାଏ। କର୍ଣ୍ଣଲକୁ ଏହି ସମସ୍ୟାର ସମାଧାନ ପାଇଁ ଅଦ୍ୟତିତ କରାଯାଇଥାଏ।.
CPU ଶକ୍ତି ସ୍ଥିତି, C3, ପାଇଁ Next-Generation Intel Microarchitecture (Nehalem)ରେ କର୍ଣ୍ଣଲରେ ସମର୍ଥନ ଯୋଗ କରାଯାଇଛି। C3 (ସୁପ୍ତ ସ୍ଥିତି ନାମରେ ମଧ୍ଯ ପରିଚିତ) ଭରଣ କରିବାର କ୍ଷମତା ନିଷ୍କ୍ରିୟ ଥିବା ସମୟରେ CPUର ଶକ୍ତି କ୍ଷମତାକୁ ଉନ୍ନତତର କରିଥାଏ।
ପୂର୍ବରୁ, କର୍ଣ୍ଣଲରେ ସେଟ କରାଯାଇଥିବା MAX_ARG_PAGES
ସୀମା ଖୁବ କମ, ଏବଂ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ପରିଲକ୍ଷିତ ହୋଇଥାଏ: ଏହି ଅଦ୍ୟତନରେ
execve: ସ୍ୱତନ୍ତ୍ରଚର ତାଲିକା ଖୁବବଡ଼, ଏହି ସୀମାକୁ ଥାକ ଆକାରର 25 ପ୍ରତିଶତ ପର୍ଯ୍ୟନ୍ତ ବୃଦ୍ଧି କରାଯାଇଥାଏ, ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
autofs4
ଅଦ୍ୟତନଗୁଡ଼ିକ linux କର୍ଣ୍ଣଲ ସଂସ୍କରଣ 2.6.27ରୁ Red Hat Enterprise Linux 5.3 କୁ ଅଦ୍ୟତିତ ହୋଇଛି।
Red Hat Enterprise Linux 5.3 ବର୍ତ୍ତମାନ ସେହି ଆଭ୍ୟନ୍ତରିଣ ଫାଇଲଗୁଡ଼ିକୁ ଉଲ୍ଲେଖ କରିବାର କ୍ଷମତାକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ ଯାହାକି ସିଧାସଳଖ ଭାବେ ଗୋଟିଏ ଫାଇଲ ସହିତ ସଂଯୋଗ ହେବା ପରିବର୍ତ୍ତେ ଚାଳକ ସ୍ଥାନ ଦରଖାସ୍ତର ବିଭାଜିତ ନକଲରେ ସଂଯୋଗ ହୋଇଥାଏ। /proc/sys/kernel/core_pattern
ରେ |
କୁ ରଖିବା ଦ୍ୱାରା ଏହା ସକ୍ରିୟ ହୋଇଥାଏ। ଯେତେବେଳେ ଆଭ୍ୟନ୍ତରିଣ ଫାଇଲକୁ ସନ୍ନିକ୍ଷେପ କରାଯାଏ, ଉଲ୍ଲିଖିତ ପ୍ରୟୋଗର ଗୋଟିଏ ନକଲ ନିଷ୍ପାଦିତ ହୋଇଥାଏ, ଏବଂ ଆଭ୍ୟନ୍ତରିଣ ଫାଇଲଟି ନିଜର stdin ସହିତ ସଂଯୁକ୍ତ ହୋଇଥାଏ। ଏହା ଆଭ୍ୟନ୍ତରିଣ ଫାଇଲକୁ ସଂବର୍ଧିତ,ବିଶ୍ଳେଷଣ ଏବଂ ଆଭ୍ୟନ୍ତରିଣ ସନ୍ନିକ୍ଷେପ ସମୟରେ ସକ୍ରିୟ ଭାବେ ନିୟନ୍ତ୍ରିତ ହେବା ପାଇଁ ଅନୁମତି ଦେଇଥାଏ।
path/to/application
ଫାଇଲ /proc/cpuinfo
ବର୍ତ୍ତମାନ ପ୍ରତ୍ୟେକ ବ୍ୟକ୍ତିଗତ CPU ଦ୍ୱାରା ବ୍ୟବହୃତ Advanced Programmable Interrupt Controller (APIC)ର ପରିଚୟ ଖବର କରିଥାଏ।
ଯନ୍ତ୍ର ଯାଞ୍ଚ ବ୍ୟତିକ୍ରମ (MCE) କର୍ଣ୍ଣଲ ଉପତନ୍ତ୍ରକୁ ନୂତନ ତନ୍ତ୍ର ଦ୍ୱାରା ଆବଶ୍ୟକ ହେଉଥିବା ବୃହତ ସ୍ମୃତି ସ୍ଥାନ ବିନ୍ୟାସକୁ ସମର୍ଥନ ଦେବା ପାଇଁ ଉନ୍ନତତର କରାଯାଉଇଛି।
ସାମ୍ବା ମାଧ୍ଯମରେ ଫାଇଲତନ୍ତ୍ରକୁ ସ୍ଥାପନ କରିବା ସମୟରେ ସ୍ଥାପନ ନିର୍ଦ୍ଦେଶ ବର୍ତ୍ତମାନ କର୍ବୋରସ ପ୍ରାଧିକରଣକୁ ସମର୍ଥନ କରୁଅଛି। sec=krb5
କିମ୍ବା sec=krb5i
ସ୍ୱିଚ ଗୋଟିଏ ଚାଳକ ସ୍ଥାନ ପ୍ରୟୋଗ (cifs.upcall
)କୁ ଡ଼ାକିବା ପାଇଁ କର୍ଣ୍ଣଲକୁ ଅନୁମତି ଦେଇଥାଏ ଯାହାକି SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) ସୁରକ୍ଷା blob (Binary Large OBject) ପ୍ରଦାନ କରିଥାଏ। କର୍ଣ୍ଣଲ ଏହି blobକୁ ସର୍ଭର ଏବଂ ସ୍ଥାପନ ଅନୁରୋଧ ଫାଇଲତନ୍ତ୍ର ସହିତ ପ୍ରାଧିକରଣ କରିବା ପାଇଁ ବ୍ୟବହାର କରିପାରିବ।
ଯଦି ଆପଣ କର୍ଣ୍ଣଲ ପ୍ରାଚଳ kernel.unknown_nmi_panic
କୁ IOAPIC NMI ୱାଚଡ଼ଗ ପଦ୍ଧତିକୁ ବ୍ୟବହାର କରୁଥିବା ଗୋଟିଏ ତନ୍ତ୍ରରେ ବିନ୍ୟାସ କରନ୍ତି, ତେବେ କର୍ଣ୍ଣଲ ଆତଙ୍କ ଦେଖାଦେବ। ଏହା NMI ୱାଚଡ଼ଗ ଉତ୍ସ NMIs କୁ ସୁରକ୍ଷିତ ଭାବରେ ନିଷ୍କ୍ରିୟ କରିନପାରୁଥିବାରୁ ଘଟିଥାଏ।
ଏହି ପ୍ରକାଶନରେ, NMI ୱାଚଡ଼ଗ ସଙ୍କେତକୁ NMI ଉତ୍ସକୁ ସୁରକ୍ଷିତ ଭାବରେ ନିଷ୍କ୍ରିୟ କରିବା ପାଇଁ ସଂଶୋଧନ କରାଯାଇଛି। ସେହିପରି, ଆପଣ ବର୍ତ୍ତମାନ ସୁରକ୍ଷିତ ଭାବରେ ସେହି କର୍ଣ୍ଣଲ ପ୍ରାଚଳ kernel.unknown_nmi_panic
କୁ IOAPIC NMI ୱାଚଡ଼ଗ ପଦ୍ଧତିକୁ ବ୍ୟବହାର କରୁଥିବା ତନ୍ତ୍ରରେ ବିନ୍ୟାସ କରିପାରିବେ।
powernowk8
ଡ୍ରାଇଭର ଚାଲୁଥିବା CPUଗୁଡ଼ିକରେ ଯଥେଷ୍ଟ ଯାଞ୍ଚ କରୁନାହିଁ। ଫଳସ୍ୱରୂପ, ଯେତେବେଳେ ସେହି ଡ୍ରାଇଭରଟି ଆରମ୍ଭ ହୁଏ, କର୍ଣ୍ଣଲ oops ତ୍ରୁଟି ସନ୍ଦେଶ ଖବର ହୋଇପାରେ। ଏହି ଅଦ୍ୟତନରେ powernowk8
ଡ୍ରାଇଭର ଯାଞ୍ଚ କରେ ଯେ ସମର୍ଥିତ CPUଗୁଡ଼ିକର ସଂଖ୍ୟା (supported_cpus
) ଅନଲାଇନ CPUଗୁଡ଼ିକର ସଂଖ୍ୟା ସହିତ ସମାନ କି ନୁହଁ। (num_online_cpus
), ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
କର୍ଣ୍ଣଲ ଉପତନ୍ତ୍ର CPUFreq
, ଯାହାକି CPU ଆବୃତ୍ତି ଏବଂ ଭଲଟେଜକୁ ମାପିଥାଏ, ତାହା Cell Processors ପାଇଁ ଉନ୍ନତ ସମର୍ଥନ ସହିତ ଅଦ୍ୟତିତ ହୋଇଥାଏ। ଏହି ଅଦ୍ୟତନ ଗୋଟିଏ Synergistic Processing Unit (SPU) ଜଣାଥିବା CPUFreq governorକୁ କାର୍ଯ୍ୟକାରୀ କରିଥାଏ ଯାହାକି Cell processor ଗୁଡ଼ିକର ଶକ୍ତି ପରିଚାଳନାକୁ ଉନ୍ନତତର କରିଥାଏ।
ତ୍ରୁଟି ଅନୁସନ୍ଧାନ ଏବଂ ସଂଶୋଧନ (EDAC) ଟି ବର୍ତ୍ତମାନ Red Hat Enterprise Linux 5.3ରେ Cell Broadband Engine Architecture ଉପରେ ସମର୍ଥିତ। EDACକୁ ସକ୍ରିୟ କରିବା ପାଇଁ, ନିର୍ଦ୍ଦେଶ: modprobe cell_edac
କୁ ବ୍ୟବହାର କରନ୍ତୁ।
ଏହି ଏକକାଂଶଟି ଆପଣଙ୍କର କର୍ଣ୍ଣଲରେ ଯୋଗ ହୋଇଛି କି ନାହିଁ ଯାଞ୍ଚ କରିବାକୁ, ନିମ୍ନଲିଖିତ ପରି ଫଳାଫଳ ପାଇବା ପାଇଁ /var/log/dmesg କୁ ଯାଞ୍ଚ କରନ୍ତୁ:
EDAC MC: Ver: 2.0.1 Oct 4 2008 EDAC MC0: Giving out device to cell_edac MIC: DEV cbe-mic EDAC MC1: Giving out device to cell_edac MIC: DEV cbe-mic
ଯଦି ସଂଶୋଧନଯୋଗ୍ୟ ସ୍ମୃତି ତ୍ରୁଟିର ସମ୍ମୁଖିନ ହୁଅନ୍ତି, ତେବେ ନିମ୍ନଲିଖିତ ସନ୍ଦେଶ କୋନସୋଲକୁ ଫେରିଯିବ:
EDAC MC0: CE page 0xeff, offset 0x5700, grain 0, syndrome 0x51, row 0, ଚ୍ୟାନେଲ 0, ସ୍ତର "":
ୱାଚପଏଣ୍ଟ ସହିତ ଏକାଧିକ ଥ୍ରେଡ଼ ସହଭାଗୀ ପ୍ରାଚଳ ବ୍ୟବହାର କରି ହାର୍ଡୱେର ତ୍ରୁଟିନିବାରଣ GNU ତ୍ରୁଟିନିବାରକ(GDB
)କୁ ଚଞ୍ଚଳ କରିବା ଘଟଣାକୁ ହରାଇଥାଏ। କର୍ଣ୍ଣଲ GDB
କୁ ଅନବରତ ୱାଚପଏଣ୍ଟକୁ ଚଳ ଚଞ୍ଚଳ କରିବା,ତ୍ରିଟିନିବାରଣ ଅଧିବେଶନର ବିଶ୍ୱସ୍ତତା ଉନ୍ନତିକୁ ଅନୁମତି ଦେବା ପାଇଁ ଅଦ୍ୟତିତ ହୋଇଥାଏ।
କର୍ଣ୍ଣଲ ଘଟଣାଗୁଡ଼ିକୁ ତୀବ୍ର ଗତିରେ ଅନୁସନ୍ଧାନ କରିବା ପାଇଁ ଚାଳକମାନଙ୍କୁ ଅନୁମତି ଦେଇ kprobe-booster ଟି ବର୍ତ୍ତମାନ ia64 ଏବଂ x86_64 ସଂରଚନାରେ ସମର୍ଥିତ। ଏହି ବିଶେଷଗୁଣଟି 64-ବିଟ ସଂରଚନାରେ ଚାଲୁଥିବା ସର୍ଭରରେ ଅନୁସନ୍ଧାନ ଶାଧନ ଦ୍ୱାରା ଘଟିଥିବା ପ୍ରଭାରକୁ ମଧ୍ଯ ଘଟାଇଥାଏ (ଯେପରି କି, SystemTap ଏବଂ Kprobes)।
_PTC
(ସଞ୍ଚାଳକ ଥ୍ରଟଲିଙ୍ଗ ନିୟନ୍ତ୍ରକ), _TSS
(ଥ୍ରଟଲିଙ୍ଗ ସମର୍ଥିତ ସ୍ଥିତ) ଏବଂ _TPC
(ଥ୍ରଟଲିଙ୍ଗ ଉପସ୍ଥିତି କ୍ଷମତା) ବସ୍ତୁଗୁଡ଼ିକ ପାଇଁ କର୍ଣ୍ଣଲରେ ସମର୍ଥନ ଯୋଗକରାଯାଇଛି। ଏହି ସମର୍ଥନ, ଯାହାକି ଉନ୍ନତ ବିନ୍ୟାସ ଏବଂ ଶକ୍ତି ଅନ୍ତରାପୃଷ୍ଠ ବିବରଣୀ (ACPI) ଉନ୍ନତ ସଞ୍ଚାଳକ ଥ୍ରଟଲିଙ୍ଗ ପରିଚାଳନା ପ୍ରଦାନ କରିଥାଏ।
zipl.confରେ, ଗୋଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନ ମଧ୍ଯରେ ଥିବା ଦୁଇଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନ ଭିତରେ ରଖାଯାଇଥିବା ପ୍ରାଚଳକୁ (ଯେପରିକି parameters='vmhalt="LOGOFF"'
) ଭୁଲ ଭାବରେ ବିଶ୍ଳେଷଣ କରାଯାଇଥାଏ। ଫଳସ୍ୱରୂପ, କର୍ଣ୍ଣଲ-kdump ପ୍ୟାକେଜକୁ ସ୍ଥାପନ କରିବା ବିଫଳ ହୋଇ ପାରେ, ଏବଂ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ଦର୍ଶାଇଥାଏ:
ଖରାପ ମାରାତ୍ମକ ତ୍ରୁଟି: ଉପଯୁକ୍ତ ପ୍ରତିରୂପ ଖୋଜିବାରେ ଅସମର୍ଥଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିବା ପାଇଁ, ପ୍ରାଚଳଗୁଡ଼ିକୁ ଗୋଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନ ମଧ୍ଯରେ ଥିବା ଦୁଇଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନ ଭିତରେ ରଖାଯିବା ଉଚିତ (ଯେପରି,
parameters="vmhalt='LOGOFF'"
)
ବାକ୍ୟ ବିନ୍ୟାସ ସଂରଚନା ଗୋଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନ ମଧ୍ଯରେ ଥିବା ଦୁଇଟିକିଆ ଉଦ୍ଧୃତ ଚିହ୍ନଟି Red hat Enterprise Linux 5ରେ ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଭାବରେ ଅଛି।
Dual-Core Intel Itanium 2 ପ୍ରଚାଳନ ତନ୍ତ୍ର ଭିନ୍ନଭାବରେ ପୂର୍ବ Intel Itanium ପ୍ରଚାଳନ ତନ୍ତ୍ରରେ ମେସିନ ଯାଞ୍ଚ ସଂରଚନା (MCA) ବିବରଣୀ ଭରଣ କରିସାରିଛି। କ୍ୟାଶେ ଯାଞ୍ଚ ଏବଂ ବସ ଯାଞ୍ଚ ସକ୍ଷ୍ୟ ପରିଚାୟକ ବର୍ତ୍ତମାନ କିଛି କ୍ଷେତ୍ରରେ ଭିନ୍ନ। କର୍ଣ୍ଣଲକୁ ସଠିକ ଲକ୍ଷ୍ୟ ପରିଚାୟକ ଖୋଡିବା ପାଇଁ ଅଦ୍ୟତିତ କରାଯାଇଥାଏ।
କର୍ଣ୍ଣଲ ଘଟଣାଗୁଡ଼ିକୁ ତୀବ୍ର ଗତିରେ ଅନୁସନ୍ଧାନ କରିବା ପାଇଁ ଚାଳକମାନଙ୍କୁ ଅନୁମତି ଦେଇ kprobe-booster ଟି ବର୍ତ୍ତମାନ ia64 ଏବଂ x86_64 ସଂରଚନାରେ ସମର୍ଥିତ। ଏହି ବିଶେଷଗୁଣଟି 64-ବିଟ ସଂରଚନାରେ ଚାଲୁଥିବା ସର୍ଭରରେ ଅନୁସନ୍ଧାନ ଶାଧନ ଦ୍ୱାରା ଘଟିଥିବା ପ୍ରଭାରକୁ ମଧ୍ଯ ଘଟାଇଥାଏ (ଯେପରି କି, SystemTap ଏବଂ Kprobes)।
ଏହି ଅଦ୍ୟତନରେ, pselect()
ଏବଂ ppoll()
ତନ୍ତ୍ର ଡ଼ାକରା ପାଇଁ ସମର୍ଥନକୁ କର୍ଣ୍ଣଲରେ ଯୋଗକରାଯାଇଛି।
ଏହି ବିଭାଗଟି Red Hat Enterprise Linuxର ଆଭାସୀକରଣ ସାଧନରେ କରାଯାଇଥିବା ଅଦ୍ୟତନଗୁଡ଼ିକର ସୂଚନା ମାନଙ୍କୁ ଧାରଣ କରିଅଛି ଯାହାକି ଦଲିଲରେ ଥିବା ଅନ୍ଯ କୌଣସି ଭାଗକୁ ସୂଚୀତ କରୁନାହିଁ।
blktap ଅଧିନରେ ଥିବା ଆଭସୀ ଅତିଥିର ପରିବହନ ପରିସଂଖ୍ୟାନ ଉପରେ ନଜର ରଖିବା ପାଇଁ କାର୍ଯ୍ୟକାରିତା ପ୍ରଦାନ କରି, blktap (blocktap) userspace ଯନ୍ତ୍ର ବାକ୍ସକୁ ଅଦ୍ୟତନ କରାସରିଛି।
Intel Extended Page Table (EPT) ବିଶେଷ ଗୁଣ ପାଇଁ ସମର୍ଥନ ଯୋଗ କରାଯାଇଛି, ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥିର କାର୍ଯ୍ୟକ୍ଷମତାକୁ ETP ସମର୍ଥିତ ହାର୍ଡୱେରରେ ଉନ୍ନତ କରାଯାଇଛି।
ଅତିଥି ପାଇଁ e1000
ନେଟୱର୍କ ଉପକରଣର ଯାନ୍ତ୍ରାନୁକରଣକୁ ଏହି ଅଦ୍ୟତନରେ ଯୋଡ଼ାଯାଇଛି, କେବଳ ia64 ସଂରଚନାରେ Windows 2003 ଅତିଥିକୁ ସମର୍ଥନ ଦେଇ। e1000 ଯାନ୍ତ୍ରାନୁକରଣକୁ ବ୍ୟବହାର କରିବା ପାଇଁ, xm ନିର୍ଦ୍ଦେଶକୁ ନିଶ୍ଚିତଭାବରେ ବ୍ୟବହାର କରିବା ଉଚିତ।
virtio
ପାଇଁ ଡ୍ରାଇଭରଗୁଡ଼ିକ, KVMରେ I/O ଆଭାସୀକରଣ ପାଇଁ ପ୍ଲାଟଫର୍ମ, ବର୍ତ୍ତମାନ Linux Kernel 2.6.27ରୁ Red Hat Enterprise Linux 5.3 କୁ ବେକପୋର୍ଟେଡ ହୋଇଛି। ଏହି ଡ୍ରାଇଭରଗୁଡ଼ିକ KVM ଅତିଥିମାନଙ୍କୁ ଉଚ୍ଚସ୍ତରୀୟ I/O କାର୍ଯ୍ୟକ୍ଷମତା ପାଇବା ପାଇଁ ସକ୍ରିୟ କରାଯାଇଛି। ବିଭିନ୍ନ ପ୍ରକାର ଚାଳକ ସ୍ଥାନ ଉପାଦାନଗୁଡ଼ିକ ଯେପରିକି: anaconda
, kudzu
, lvm
, selinux
ଏବଂ mkinitrd
କୁ ମଧ୍ଯ virtio ଯନ୍ତ୍ରଗୁଡ଼ିକୁ ସମର୍ଥନ ଦେବା ପାଇଁ ଅଦ୍ୟତିତ କରାଯାଇଛି।
ସ୍ଥାନୀୟ Linux କର୍ଣ୍ଣଲ ସମର୍ଥନ vmcoreinfo
ସ୍ୱୟଂଚାଳିତ ଭାବରେ, କିନ୍ତୁ, dom0 ଡ଼ମେନଗୁଡ଼ିକରେ kdump ସେଟ କରିବା ପାଇଁ, kernel-xen-debuginfo
ପ୍ୟାକେଜ ଆବଶ୍ୟକ ହୋଇଥିଲା। ଏହି ପ୍ରକାଶନ ସହିତ, କର୍ଣ୍ଣଲ ଏବଂ ହାଇପରଭାଇଜରକୁ ପରିବର୍ତ୍ତନ କରାସରିଛି ଏବଂ ବର୍ତ୍ତମାନ vmcoreinfo ପଠନକୁ ସମର୍ଥନ କରୁଅଛି ଏବଂ kdumpକୁ ସ୍ଥାନୀୟ ଭାବେ ଲେଖୁଅଛି। debuginfo
କିମ୍ବା debuginfo-common
ପ୍ୟାକେଜଗୁଡ଼ିକୁ ସ୍ଥାପନ ନକରି ଚାଳକମାନେ ତ୍ରୁଟିନିବାରଣ ପାଇଁ kdump କୁ ବ୍ୟବହାର କରୁଛନ୍ତି କିମ୍ବା dom0 ଡମେନରେ ଅନ୍ୟାନ୍ୟ ଅନୁସନ୍ଧାନ କରୁଛନ୍ତି।
ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ Red Hat Enterprise Linux 5 ଅତିଥି ଯେତେବେଳେ ଯାନ୍ତ୍ରାନୁକୃତ ଡ଼ିସ୍କ ଏବଂ ନେଟୱର୍କ ଉପକରଣଗୁଡ଼ିକୁ ବ୍ୟବହାର କରି ଅନୁକୂଳ କାର୍ଯ୍ୟକ୍ଷମତାର ସମ୍ମୁଖିନ ହୋଇଥିଲା। ଏହି ଅଦ୍ୟତନରେ, ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥିଗୁଡ଼ିକରେ ଆଂଶିକ ଆଭାସୀ ଡ଼ିସ୍କ ଏବଂ ନେଟୱର୍କଗୁଡ଼ିକର ବ୍ୟବହାରକୁ ସରଳିକୃତ କରିବା ପାଇଁ kmod-xenpv ପ୍ୟାକେଜକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରାଯାଇଛି।
ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥିରେ ଏହି ଡ୍ରାଇଭରଗୁଡ଼ିକୁ ବ୍ୟବହାର କରିବା ଦ୍ୱାରା ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥିରେ ମହତ୍ତ୍ୱପୂର୍ଣ୍ଣ ଭାବରେ କାର୍ଯ୍ୟକ୍ଷମତା ଏବଂ କାର୍ଯ୍ୟକାରୀତାରେ ଉନ୍ନତି ହୋଇଥାଏ। ନେଟଫ୍ରଣ୍ଟ ଏବଂ ବ୍ଲକ ଫ୍ରଣ୍ଟ ଡ୍ରାଇଭରଗୁଡ଼ିକ ପାଇଁ ତ୍ରୁଟିନିବାରଣକୁ ସଙ୍ଗେ ସଙ୍ଗେ ଲାଗୁକରାଯାଇଥାଏ ଏବଂ କର୍ଣ୍ଣଲ ପ୍ୟାକେଜ ସହିତ ସମତାଳ କରାଯାଇଥାଏ।
ଅତିଥି ମାନଙ୍କର ବର୍ତ୍ତମାନ 2MB ବ୍ୟାକିଙ୍ଗ ପୃଷ୍ଠା ବ୍ୟବହାର କରିବାର କ୍ଷମତା ଅଛି, ଯାହାକି ତନ୍ତ୍ର କାର୍ଯ୍ୟକ୍ଷମତାକୁ ବଢ଼ାଇ ଦେଇଥାଏ।
ଗୋଟିଏ ଆଂଶିକ ଆଭସୀ ଅତିଥିକୁ ବନ୍ଦକରିବା ସମୟରେ dom0 କିଛି ସମୟ ପାଇଁ ଉତ୍ତର ଦେବା ବନ୍ଦ କରିଦିଏ। ଅତିଥିରେ ଅଧିକ ପରିମାଣର ସ୍ମୃତିସ୍ଥାନ ସହିତ (12GBରୁ ଅଧିକ) କିଛି ସେକଣ୍ଡର ବିଳମ୍ବ ପରିଲକ୍ଷିତ ହୁଏ। ଏହି ଅଦ୍ୟତନରେ, ଆଭାସୀ କର୍ଣ୍ଣଲ ଆଂଶିକ ଆଭାସୀ ଅତିଥିର ବନ୍ଦକରିବା କ୍ରିୟାକୁ ଅନୁମତି ଦେଇଥାଏ, ଯାହାକି ଏହି ସମସ୍ୟାର ସମାଧାନ କରିଥାଏ।
କ୍ରାଶ
ଗୋଟିଏ vmcore ଫାଇଲରୁ ହାଇପରଭାଇଜରର ସ୍ଥାନାନ୍ତରିତ ଠିକଣାକୁ ପଢ଼ିବାରେ ଅସମର୍ଥ। ଏହି କାରଣରୁ, vmcore ଫାଇଲରୁ କ୍ରାଶ ସହିତ ଆଭାସୀ କର୍ଣ୍ଣଲକୁ ଖୋଲିବା ବିଫଳ ହୋଇଥିଲା, ଫଳସ୍ୱରୂପ ଏହି ତ୍ରୁଟି ପରିଲକ୍ଷିତ ହୋଇଥାଏ:
କ୍ରାଶ: ସମାଧାନ କରିପାରିବେ ନାହିଁ "idle_pg_table_4"ଏହି ଅଦ୍ୟତନରେ, ହାଇପରଭାଇଜର ବର୍ତ୍ତମାନ ସେହି ଠିକଣାକୁ ସଠିକ ଭାବରେ ସଂରକ୍ଷଣ କରିଥାଏ, ଯିଏକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
ପୂର୍ବରୁ, ଆଂଶିକ ଆଭସୀ ଅତିଥିମାନଙ୍କ ପାଖରେ କେବଳ ସର୍ବାଧିକ 16 ଡ଼ିସ୍କ ଯନ୍ତ୍ର ଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସୀମାକୁ ସର୍ବାଧିକ 256 ଡ଼ିସ୍କ ଯନ୍ତ୍ର ପର୍ଯ୍ଯନ୍ତ ବଢ଼ାଯାଇଥିଲା
kdump କର୍ଣ୍ଣଲ ପାଇଁ ସଂରକ୍ଷିତ ସ୍ମୃତି ସ୍ଥାନଟି ଠିକ ନୁହଁ, ଫଳସ୍ୱରୂପ ଅନୁପଯୋଗୀ କ୍ରାଶ ଡମ୍ପ ହୋଇଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ସଠିକ କ୍ରାଶ ଡମ୍ପ ସୃଷ୍ଟି କରିବାକୁ ଅନୁମତି ଦେଇ, ସ୍ମୃତି ସ୍ଥାନ ସଂରକ୍ଷଣଟି ବର୍ତ୍ତମାନ ଠିକ ଅଛି।
ଗୋଟିଏ ନିର୍ଦ୍ଦିଷ୍ଟ ନାମ ସହିତ (ie. /dev/xvdaa
, /dev/xvdab
, /dev/xvdbc
ଇତ୍ୟାଦି) ଗୋଟିଏ ଅତିଆଭାସୀ ଅତିଥିରେ ଗୋଟିଏ ଡ଼ିସ୍କ ଯୋଗକରିବା ଫଳରେ ଅତିଥି ଭିତରେ ତ୍ରୁଟିଯୁକ୍ତ /dev
ଉପକରଣ ଥାଏ। ଏହି ଅଦ୍ୟତନ ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ, ଯାହାଫଳରେ ଏହି ନାମ ସହିତ ଡିସ୍କ ଯୋଗ କରିବା ଦ୍ୱାରା ଅତିଆଭାସୀ ଅତିଥି ସଠିକ /dev
ଉପକରଣ ଅତିଥି ମଧ୍ଯରେ ସୃଷ୍ଟି କରିଥାଏ।
ପୂର୍ବରୁ, ଲୁପବେକ ଉପକରଣମାନଙ୍କର ସଂଖ୍ଯା 4ମଧ୍ଯରେ ସିମୀତ ଥାଏ। ଫଳସ୍ୱରୂପ, ଏହା 4ରୁ ଅଧିକ ନେଟୱର୍କ ଅନ୍ତରାପୃଷ୍ଠ ସହିତ ତନ୍ତ୍ରରେ ବ୍ରିଜ ନିର୍ମାଣ କରିବାର କ୍ଷମତାକୁ ସିମୀତ କରିଥାଏ। ଏହି ଅଦ୍ୟତନରେ, netloop
ଡ୍ରାଇଭର ବର୍ତ୍ତମାନ ଅତିରିକ୍ତ ଲୁପବେକ ଉପକରଣଗୁଡ଼ିକୁ ନିର୍ମାଣ କରିବା ଆବଶ୍ୟକ ହୋଇଥାଏ।
ଆଭାସୀ ନେଟୱର୍କ ଉପକରଣକୁ ନିର୍ମାଣ ଏବଂ ନଷ୍ଟ କରିବା ସମୟରେ ଗୋଟିଏ ଘଡ଼ିସନ୍ଧି ମୁହୂର୍ତ୍ତ ଆସିପାରେ। କିଛି କ୍ଷେତ୍ରରେ -- ବିଶେଷ କରି ଅଧିକ ଧାରଣ ପରିସ୍ଥିତିରେ -- ଏହି କାରଣରୁ ଆଭାସୀ ଉପକରଣ ଉତ୍ତର ଦେଇ ନଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଘଡ଼ିସନ୍ଧି ମୁହୁର୍ତ୍ତକୁ ଏଡ଼ାଇବା ପାଇଁ ଆଭାସୀ ଉପକରଣର ସ୍ଥିତିକୁ ଯାଞ୍ଚକରାଯାଇଥାଏ।
virt-manager
ରେ ସ୍ମୃତି ଚୋରିର ସମ୍ମୁଖିନ ହୋଇଥାଏ ଯଦି ସେହି ପ୍ରୟୋଗକୁ ଚାଲୁରଖି ଛାଡ଼ିଦେଇଥିବେ। ଫଳସ୍ୱରୂପ, ପ୍ରୟୋଗଟି ସ୍ଥିର ଭାବରେ ଅଧିକ ଉତ୍ସ ଖର୍ଚ୍ଚକରିବ, ଯାହାଫଳରେ ସ୍ମୃତିସ୍ଥାନର ଅଭାବ ପରିଲକ୍ଷିତ ହେବ। ଏହି ଅଦ୍ୟତନରେ, ସେହି ଚୋରିକୁ ସଂଶୋଧନ କରାଯାଇଛି, ଯାହାକି ସେହି ସମସ୍ୟାର ସମାଧାନ କରିଥାଏ।
crash
ଉପଯୋଗୀତା kernel-xen
ଚଲାଉଥିବା ତନ୍ତ୍ରରୁ x86_64
vmcoresକୁ ବିଶ୍ଳେଷଣ କରିପାରିଲା ନାହିଁ, କାରଣ Red Hat Enterprise Linux ହାଇପର୍ଭାଇଜର ସ୍ଥାନାନ୍ତର କରିବା ଯୋଗ୍ୟ ଏବଂ ସେହି ସ୍ଥାନାନ୍ତରିତ ଭୌତିକ ଆଧାର ଠିକଣାଟି vmcore ଫାଇଲର ELF ଶୀର୍ଷକରେ ପ୍ରବେଶ କରିନଥିଲା। କ୍ରାଶ ଉପଯୋଗୀତା ପାଇଁ ନୂତନ --xen_phys_start
ନିର୍ଦ୍ଦେଶନାମା ବିକଳ୍ପ ଚାଳକକୁ ସ୍ଥାନାନ୍ତରିତ ଆଧାର ଭୌତିକ ଠିକଣା କ୍ରାଶ ମଧ୍ଯକୁ ପ୍ରବେଶ କରିବାକୁ ଅନୁମତି ଦେଇଥାଏ।
ଆଂଶିକ ଆଭାସୀ ଫ୍ରେମ ବଫର (PVFB)
ଦ୍ୱାରା ସମସ୍ତ ମାଉସ ଘଟଣାଗୁଡ଼ିକୁ ଗ୍ରହଣ ଏବଂ କାର୍ଯ୍ୟକାରୀ କରାଯାଇନଥାଏ। ଏହା ଫଳରେ, ଆଂଶିକ ଆଭାସୀ ଅତିଥି ସହିତ ଯୋଗାଯାଗ କରିବା ସମୟରେ ଆଭାସୀ ଯନ୍ତ୍ର କୋନସୋଲ
ସହିତ ସ୍କ୍ରଲ ଚକ କାର୍ଯ୍ୟ କରିନଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ସ୍କ୍ରଲ ଚକ ମାଉସ ଘଚଣାଗୁଡ଼ିକୁ ସଠିକ ଭାବରେ ନିୟନ୍ତ୍ରଣ କରାଯାଇଥାଏ, ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
ଅଧିକ ସ୍ମୃତି ସ୍ଥାନ ବିଶିଷ୍ଟ ଗୋଟିଏ ତନ୍ତ୍ରରେ (256GBରୁ ଅଧିକ), dom0 ସେଟ କରିବା ଦ୍ୱାରା ହାଇପରଭାଇଜର ସ୍ମୃତି ସ୍ଥାନ ନିଷ୍କାସନ ହୋଇଥାଏ। ଏଥିରେ କାର୍ଯ୍ଯ କରିବାକୁ, xenheap ଏବଂ dom0_size ନିର୍ଦ୍ଦେଶ ସ୍ୱତନ୍ତ୍ରଚରକୁ ତନ୍ତ୍ର ପାଇଁ ବୈଧ ମୂଲ୍ୟ ପ୍ରଦାନ କରିବା ଉଚିତ। ଏହି ଅଦ୍ୟତନରେ, ହାଇପରଭାଇଜରକୁ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଏହି ମୂଲ୍ୟ ସେଟ କରିବା ପାଇଁ ଅଦ୍ୟତିତ କରାଯାଇଛି, ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
ଅଧିକ ସଂଖ୍ୟକ CPU ବିଶିଷ୍ଟ ଗୋଟିଏ ଯନ୍ତ୍ରରେ ଆଭାସୀକରଣ ବ୍ୟବହାର କରିବା ଦ୍ୱାରା ଅତିଥି ସ୍ଥାପନ ସମୟରେ ହାଇପରଭାଇଜର କ୍ରାଶ ହୋଇଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ସେହି ସମସ୍ୟାଟି ସମାଧାନ ହୋଇଛି।
ଅଧିକ ସ୍ମୃତି ସ୍ଥାନ ବିଶିଷ୍ଟ ଅତିଥି ନିର୍ମାଣ କରିବା ସମୟରେ ଗୋଟିଏ ସଫ୍ଟ ଲକଅପ ଘଟିଥାଏ। ଫଳସ୍ୱରୂପ, ତ୍ରୁଟିର ଗୋଟିଏ ବାର୍ତାଳାପକୁ ସନ୍ଧାନକୁ ଉଭୟ dom0 ଏବଂ ଅତିଥିରେ ଦର୍ଶାଯାଇଛି। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରାଯାଇଛି।
Intel ସଂଚାଳକରେ ଯାହାକି CPUID ପରିବାର ମୂଲ୍ୟ 6 ଦେଇଥାଏ, kernel-xen
ରେ କେବଳ ଗୋଟିଏ କାର୍ଯ୍ୟକ୍ଷମତା ମାପକ ସକ୍ରିୟ ହୋଇଥାଏ। ଫଳସ୍ନରୂପ, କେବଳ ଗଣକ 0 ନମୁନା ପ୍ରଦାନ କରିଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ୟାଟିକୁ ସମାଧାନ କରାଯାଇଛି।
ନୂତନ CPU ଗୁଡ଼ିକ ବିଶିଷ୍ଟ ତନ୍ତ୍ରରେ, CPU IDରୁ CPU APIC ID ଭିନ୍ନ ଥାଏ. ସେହିପରି, ଆଭାସୀ କର୍ଣ୍ଣଲ CPU ଆବୃତି ମାପକୁ ଆରମ୍ଭ କରିବାରେ ଅସମର୍ଥ. ଏହି ଅଦ୍ୟତନରେ,CPU ଆବୃତି ମାପକୁ ସଠିକଭାବରେ ଆରମ୍ଭକରି ଆଭାସୀ କର୍ଣ୍ଣଲ ବର୍ତ୍ତମାନ ହାଇପରଭାଇଜରରୁ CPU APIC ID କାଢ଼ିଥାଏ।
ଗୋଟିଏ x86 ଆଂଶିକ ଆଭାସୀ ଅତିଥିକୁ ଚଲାଇବା ସମୟରେ, ଯଦି ଗୋଟିଏ ପଦ୍ଧତି ଅବୈଧ ସ୍ମୃତି ସ୍ଥାନକୁ ବ୍ୟବହାର କରୁଥାଏ, ତେବେ SEGV ସଂକେତ ପାଇବା ପରିବର୍ତ୍ତେ ଏହା ଗୋଟିଏ ଚକ୍ରିଳ ପଥରେ ଚାଲୁଥାଏ। ଏହା ହାଇପରଭାଇଜର ଅନ୍ତର୍ଗତରେ execshield ଯାଞ୍ଚ ପଥରେ ଗୋଟିଏ ପ୍ରବାହ କରାଇଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରାଯାଇଛି।
ଅତିଥି ସ୍ଥାପନ ବିଫଳତା ଘଟାଉଥିବା xend
ର ଗୋଟିଏ ତୃଟିକୁ ସମାଧାନ କରିଦିଆଯାଇଛି।
evtchn
ଘଟଣା ଚ୍ୟାନେଲ ଉପକରଣରେ ତାଲା ଏବଂ ସ୍ମୃତି ସ୍ଥାନ ବନ୍ଧନର ଅଭାବ ପରିଲକ୍ଷିତ ହୋଇଥାଏ। ଏହା ଫଳରେ xenstore ଉତ୍ତର ଦେବାପାଇଁ ଅସମର୍ଥ ହୋଇଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ୟାର ସମାଧାନ କରାଯାଇଛି।
ଅସମାନସ୍ମୃତି ସ୍ଥାନ ବ୍ୟବହାର (NUMA) ସୂଚନାକୁ xm info
ନିର୍ଦ୍ଦେଶ ଦ୍ୱାରା ଦର୍ଶାଯାଇନାହିଁ। ଫଳସ୍ୱରୂପ, ପ୍ରତ୍ୟେକ ନୋଡ଼ ପାଇଁ node_to_cpu
ମୂଲ୍ୟ no cpus
ପରି ଭାବରେ ଭୁଲ ଭାବରେ ଦିଆଯାଇଅଛି। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ଯାକୁ ସମାଧାନ କରାଯାଇଛି।
ପୂର୍ବରୁ, ହାର୍ଡୱେର ଆଭାସୀ ଯନ୍ତ୍ର (HVM)ରେ ଅତିଥି ନିର୍ମାଣ କରିବା ଦ୍ୱାରା VT-i2 ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ଅନ୍ତର୍ଭୁକ୍ତ ସଞ୍ଚାଳକକୁ ବିଫଳ କରିଥାଏ। ଏହି ଅଦ୍ୟତନରେ, ଏହି ସମସ୍ୟାଟି ସମାଧାନ ହୋଇଛି।
ଯେତେବେଳେ ଅତିଥି ଆଭାସୀ ଯନ୍ତ୍ର ପାଇଁ ଉପଲବ୍ଧ ଗତିଜ IRQ ଗୁଡ଼ିକ ନିଷ୍କାସିତ ହୋଇଯାଆନ୍ତି, ସେତେବେଳେ dom0
କର୍ଣ୍ଣଲ କ୍ରାଶ ହୋଇପାରେ। ଏହି ଅଦ୍ୟତନରେ, କ୍ରାଶ ସ୍ଥିତିକୁ ଠିକ କରାଯାଇଥାଏ, ଏବଂ ଉପଲବ୍ଧ IRQଗୁଡ଼ିକର ସଂଖ୍ଯାକୁ ବୃଦ୍ଧି କରାଯାଇଥାଏ, ଯାହାକି ଏହି ସମସ୍ୟାର ସମାଧାନ କରିଥାଏ।
ନୂତନ CPU ଗୁଡ଼ିକ ବିଶିଷ୍ଟ ତନ୍ତ୍ରରେ, CPU IDରୁ CPU APIC ID ଭିନ୍ନ ଥାଏ. ସେହିପରି, ଆଭାସୀ କର୍ଣ୍ଣଲ CPU ଆବୃତି ମାପକୁ ଆରମ୍ଭ କରିବାରେ ଅସମର୍ଥ. ଏହି ଅଦ୍ୟତନରେ,CPU ଆବୃତି ମାପକୁ ସଠିକଭାବରେ ଆରମ୍ଭକରି ଆଭାସୀ କର୍ଣ୍ଣଲ ବର୍ତ୍ତମାନ ହାଇପରଭାଇଜରରୁ CPU APIC ID କାଢ଼ିଥାଏ।
ଆଭାସୀ କର୍ଣ୍ଣଲ ବ୍ୟବହାର କରି ଡ଼ିସ୍କେଟ ଡ୍ରାଇଭ ମେଡ଼ିଆ ମଧ୍ଯକୁ ପ୍ରବେଶ କରିହେବ ନାହିଁ. ଏହାର ସମାଧାନ ପାଇଁ, ଏହା ବଦଳରେ ଗୋଟିଏ USB-ସଂଲଗ୍ନ ଡିସ୍କେଟ ଡ୍ରାଇଭ ବ୍ୟବହାର କରନ୍ତୁ।
ମନେରଖନ୍ତୁ ଯେ ଡ଼ିସ୍କେଟ ଡ୍ରାଇଭ ମେଡ଼ିଆ ଅନ୍ୟାନ୍ୟ ଆଭାସୀକୃତ ହୋଇନଥିବା କର୍ଣ୍ଣଲଗୁଡ଼ିକ ସହିତ ଭଲ ଭାବରେ କାର୍ଯ୍ୟ କରିଥାଏ।
ଆଂଶିକ ଆଭାସୀ ଅତିଥିର ଜୀବନ୍ତ ସ୍ଥାନାନ୍ତରଣରେ, ସମୟ-ନିର୍ଭରଶୀଳ ଅତିଥି ଧାରାଗୁଡ଼ିକ ଭୁଲ ଭାବରେ କାର୍ଯ୍ୟ କରିପାରେ ଯଦି ଅନୁରୂପ ହୋଷ୍ଟର (dom0) ସମୟକୁ ସମତାଳ କରାଯାଇନଥାଏ। ସମସ୍ତ ଅନୁରୂପ ହୋଷ୍ଟକୁ ସ୍ଥାନାନ୍ତରିତ କରିବା ପୂର୍ବରୁ ତନ୍ତ୍ରକୁ ସମତାଳ କରିବା ପାଇଁ NTP କୁ ବ୍ୟବହାର କରନ୍ତୁ।
ଦୁଇଟି ଆଧାର ମଧ୍ଯରେ ବାରମ୍ବାର ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ମାନଙ୍କର ଚଳନ୍ତି ଉତ୍ପ୍ରବାସନ ଗୋଟିଏ ଆଧାରକୁ ଅକାମି କରି ଦେଇପାରେ। ଗୋଟିଏ ଅତିଥିକୁ ତନ୍ତ୍ରରୁ ବାହାରକୁ ଅତ୍ପ୍ରବାସିତ କରିସାରିବା ପରେ ଏବଂ ସେହି ସମାନ ଅତିଥିକୁ ପୁନର୍ବାର ନିଜ ସ୍ଥାନକୁ ପ୍ରତ୍ଯାବର୍ତ୍ତନ କରିବା ପୂର୍ବରୁ ତନ୍ତ୍ରକୁ ପୁନର୍ଚାଳନ କଲେ, ଆଧାରଟି ଅକାମି ହୋଇ ନ ଥାଏ।
Windows 2008 କିମ୍ବା Windows Vistaକୁ ଅତିଥି ଭାବରେ ଚଲାଇବା ସମୟରେ ଡ଼ିସ୍କକୁ ଫର୍ମାଟ କରିବା ଦ୍ୱାରା ନଷ୍ଟ ହୋଇଯାଇଥାଏ ଯେତେବେଳେ ଗୋଟିଏ ଅତିଥିକୁ ଏକାଧିକ CPUs ସହିତ ବୁଟ କରାଯାଇଥାଏ। ଏହାର ସମାଧାନ ପାଇଁ, ଫର୍ମାଟ କରିବା ସମୟରେ ଗୋଟିଏ ଏକୁଟିଆ ଆଭାସୀ CPU ସହିତ ଅତିଥିକୁ ବୁଟ କରନ୍ତୁ।
virt-manager
ମାଧ୍ୟମରେ ନିର୍ମିତ ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥି କେବେକେବେ ମାଉସକୁ ପରଦାରେ ମୁକ୍ତଭାବରେ ସଂଚରଣ କରିବାରେ ବାଧା ଦେଇପାରେ। ଏହାର ପ୍ରତିକାର ପାଇଁ, ଗୋଟିଏ USB ଟ୍ୟାବଲେଟ ଉପକରଣକୁ ଅତିଥି ପାଇଁ ବିନ୍ୟାସ କରିବାରେ virt-manager
କୁ ବ୍ୟବହାର କରନ୍ତୁ।
ଗୋଟିଏ 128 କିମ୍ବା ତଦୁର୍ଧ CPU ତନ୍ତ୍ର ଉପରେ ଥିବା ସମୟରେ ସର୍ବାଧିକ CPUକୁ 128 ତଳେ ସୀମିତ ରଖିବାକୁ ହେବ। ଏହି ସମୟରେ ସର୍ବାଧିକ 126 ସମର୍ଥିତ। ହାଇପରଭାଇଜରକୁ 126ରେ ସୀମିତ ରଖିବା ପାଇଁ ହାଇପରଭାଇଜର ସ୍ୱତନ୍ତ୍ରଚର maxcpus=126
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ
ଡମେନ ବିରତି ନେବା ଏବଂ ପୁନଃ ଚଳନ ହେବା ଯୋଗୁଁ ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ଅତିଥି ନଷ୍ଟ ହୋଇଥିବା ସମୟକୁ ଠିକ କରିପାରିବ ନାହିଁ। ବିରତି ନେବା ଏବଂ ପୁନଃ ଚଳନ ହେବା ମଧ୍ଯବର୍ତ୍ତି ସମୟକୁ ଠିକ ଭାବରେ ଜାଣିବାର ସାମର୍ଥ୍ୟ ଆଂଶିକ ଆଭାସୀ କର୍ଣ୍ଣଲର ଉପକାରୀତା। ଏହି ସମସ୍ୟାଟିକୁ ପରିବର୍ତ୍ତିତ ସମୟ ମାପକ ପାଇଁ ଅପଷ୍ଟ୍ରିମକୁ ପଠାଯାଇଛି, ତେଣୁ ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ ତନ୍ତ୍ରରେ ଆଂଶିକ ଆଭାସୀ କର୍ଣ୍ଣଲର ସମୟ ମାପକ ପାଇବ। ବର୍ତ୍ତମାନ, ଏହି ସଂକେତଟି ବିକାଶ ଅପଷ୍ଟ୍ରିମରେ ଅଛି ଏବଂ Red Hat Enterprise Linuxର ପରବର୍ତ୍ତି ସଂସ୍କରଣଗୁଡ଼ିକରେ ଉପଲବ୍ଧ ହେବ।
ଆଂଶିକ ଆଭସୀକରଣ ଅତିଥିମାନଙ୍କର ବାରମ୍ବାର ସ୍ଥାନାନ୍ତରଣ ଫଳରେ bad mpa
ସନ୍ଦେଶଗୁଡ଼ିକ dom0
କୋନସୋଲରେ ଦେଖାଦେଇଥାଏ। କିଛି କ୍ଷେତ୍ରରେ, ହାଇପରଭାଇଜର ମଧ୍ଯ ଆତଙ୍କିତ ହୋଇପାରେ।
ହାଇପରଭାଇଜର କର୍ଣ୍ଣଲ ଆତଙ୍କକୁ ପ୍ରତିରୋଧ କରିବା ପାଇଁ, ଖରାପ mpa ସନ୍ଦେଶ ଦେଖାଯିବା ମାତ୍ରେ ସ୍ଥାନାନ୍ତରିତ ଅତିଥିକୁ ପୁନର୍ଚାଳନ କରନ୍ତୁ।
dom0
ରେ ଅନ୍ତରାପୃଷ୍ଠ ବନ୍ଧନ ସେଟକରିବା ସମୟରେ, ପୂର୍ବନିର୍ଦ୍ଧାରିତନେଟୱର୍କ-ବ୍ରିଜ
ସ୍କ୍ରିପ୍ଟ ବାନ୍ଧିହୋଇଥିବା ନେଟୱର୍କ ଅନ୍ତରାପୃଷ୍ଠକୁ ବୈକଳ୍ପିକ ଭାବେ ଅନୁପଲବ୍ଧ
ଏବଂ ଉପଲବ୍ଧ
ମଧ୍ଯରେ ଅଦଳ ବଦଳ ହେବାକୁ ପଡ଼ିଥାଏ। ଏହା ସାଧାରଣତଃ flapping ନାମରେ ପରିଚିତ।
ଏହାକୁ ଅଟକାଇବା ପାଇଁ, ନିମ୍ନଲିଖିତ ଧାଡ଼ି ସହିତ /etc/xen/xend-config.sxp
ରେ ମାନକ ନେଟୱର୍କ-ସ୍କ୍ରିପ୍ଟ
ଧାଡ଼ିକୁ ପରିବର୍ତ୍ତନ କରନ୍ତୁ:
(ନେଟୱର୍କ-ସ୍କ୍ରିପ୍ଟ ନେଟୱର୍କ-ବ୍ରିଜ-ବନ୍ଧନ netdev=bond0)
ଏହା କରିବା ଦ୍ୱାରା netloop ଯନ୍ତ୍ର ନିଷ୍କ୍ରିୟ ହୋଇଯାଇଥାଏ, ଯାହାକି ଠିକଣା ସ୍ଥାନାନ୍ତରଣ ପଦ୍ଧତିରେ ଠିକଣା ସମାଧାନ ପ୍ରୋଟୋକଲ (ARP)କୁ ନିରିକ୍ଷଣ କରିବାରୁ ଅଟକାଇଥାଏ।
ଯେତେବେଳେ ଏକାଧିକ ଅତିଥି ଡମେନ ଚାଲୁଥାଏ, ଅତିଥି ନେଟୱର୍କିଙ୍ଗ ଅସ୍ଥାୟୀ ଭାବରେ କାର୍ଯ୍ୟ କରିବା ବନ୍ଦ କରିପାରେ, ଫଳସ୍ୱରୂପ dom0 ଲଗରେ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ଖବର ହୋଇଥାଏ:
Memory squeeze in netback driverଏହାର ସମାଧାନ ପାଇଁ,
dom0_mem
ହାଇପରଭାଇଜର ନିର୍ଦ୍ଦେଶ ନାମା ବିକଳ୍ପ ସହିତ ପାଇଁ ଉପଲବ୍ଧ ସ୍ମୃତି ସ୍ଥାନର ପରିମାଣକୁ ବଢ଼ାନ୍ତୁ।
xm migrate
ସହିତ ଅତିଆଭାସୀ ଅତିଥି କାମ କରି ନ ଥାଏ।
[domain]
[dom0 IP address]
Red Hat Enterprise Linux 5 କୁ ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀ SMP ଅତିଥି ରେ ସ୍ଥାପନ କରିବା ସମୟରେ ସ୍ଥାପନକ୍ରିୟାଟି ବନ୍ଦ ହୋଇ ଯାଇ ପାରେ। ପରିଚାରକ (dom0
) ଟି Red Hat Enterprise Linux 5.2ରେ ଚାଲୁଥିବା ସମୟରେ ଏହା ଘଟିଥାଏ।
ଏହାର ପ୍ରତିରୋଧ ପାଇଁ, ଅତିଥିକୁ ଗୋଟିଏ ପ୍ରସେସର ବିନିଯୋଗ କରି ବ୍ୟବହାର କରାନ୍ତୁ। --vcpus=1
ଏହି ବିକଳ୍ପକୁ virt-install
ରେ ବ୍ୟବହାର କରି ଆପଣ ଏହା କରି ପାରିବେ। ଥରେ ସ୍ଥାପନକ୍ରିୟା ସମାପ୍ତ ହୋଇଗଲା ପରେ, ଆପଣ ନିର୍ଦ୍ଦିଷ୍ଟିତ vcpus
କୁ virt-managerରେ ପରିବର୍ତ୍ତନ କରି ଅତିଥିକୁ SMPରେ ସଜାଡି ପାରିବେ।
xm migrate
ସହିତ ଅତିଆଭାସୀ ଅତିଥି କାମ କରି ନ ଥାଏ।
[domain]
[dom0 IP address]
HP ତନ୍ତ୍ରର xw9300 ଏବଂ xw9400 ନମୁନାରେ ଆଭାସୀକରଣ ଗୁଣକୁ ସ୍ଥାପନ କରିବା ଦ୍ବାରା ଏହା time went backwards
ଚେତାବନୀ ଦେଇଥାଏ।
xw9400 ମେସିନ ମାନଙ୍କ ପାଇଁ ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିବା ପାଇଁ, HPET କାଳ ମାପକକୁ ସକ୍ରିୟା କରିବା ପାଇଁ BIOS ସଂଯୋଜନାକୁ ବିନ୍ଯାସ କରନ୍ତୁ। ଏହା ମନେ ରଖନ୍ତୁ ଯେ ଏହି ବିକଳ୍ପଟି କେବଳ xw9300 ମେସିନ ମାନଙ୍କ ପାଇଁ ଉପଲବ୍ଧ।
Red Hat Enterprise Linux 3.9 କୁ ଗୋଟିଏ ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ ସ୍ଥାପନ କରିବା ଅତି ମନ୍ଥର ହୋଇପାରେ। ଏହା ବ୍ଯତିତ, ସ୍ଥାପନ ପରେ ବୁଟ କରିବା ଦ୍ବାରା ଏହା hda: lost interrupt
ତୃଟି ଦେଇପାରେ।
ବୁଟଅପ ତୃଟିକୁ ଆଗ୍ରହ୍ଯ କରିବା ପାଇଁ, SMP କର୍ଣ୍ଣଲକୁ ବ୍ଯବହାର କରିବାକୁ ଅତିଥିକୁ ବିନ୍ଯାସ କରନ୍ତୁ।
ଗୋଟିଏ ଆଧାର (dom0
) ତନ୍ତ୍ରକୁ Red Hat Enterprise Linux 5.2ରେ ଉନ୍ନୟନ କରିବା ସମୟରେ ଏହା ଅବସ୍ଥିତ Red Hat Enterprise Linux 4.5 SMP ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥିକୁ ବୁଟବିହୀନଯୋଗ୍ଯ କରିପାରେ। ତନ୍ତ୍ରରେ 4 GBରୁ ଅଧିକ RAM ଥିଲେ ସାଧାରଣତଃ ଏହା ହୋଇଥାଏ।
ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ପ୍ରତ୍ଯେକ Red Hat Enterprise Linux 4.5 ଅତିଥିକୁ ଗୋଟିଏ CPU ଧାରାରେ ବୁଟ କରନ୍ତୁ ଏବଂ ଏହାର କର୍ଣ୍ଣଲକୁ ନବୀନତମ ସଂସ୍କରଣକୁ ( Red Hat Enterprise Linux 4.5.z ପାଇଁ) ଉନ୍ନୟନ କରନ୍ତୁ।
xm migrate
ସହିତ ଅତିଆଭାସୀ ଅତିଥି କାମ କରି ନ ଥାଏ।
[domain]
[dom0 IP address]
VGA ର କୋନଶୋଲ ନିର୍ଗମ ପାଇଁ ବିନ୍ଯାସ କରାଯାଇଥିବା କିଛି Itanium ତନ୍ତ୍ର ମାନଙ୍କରେ, dom0
ଆଭାସୀକୃତ କର୍ଣ୍ଣଲ ବୁଟ କରିବାରେ ବିଫଳ ହୋଇପାରେ। ଏହା ଏଥିପାଇଁ ହୋଇଥାଏ ଯେ ଆଭାସୀକୃତ କର୍ଣ୍ଣଲ ବର୍ଦ୍ଧିତ ଫାର୍ମୱେର ଅନ୍ତରାପୃଷ୍ଠ (EFI) ବିନ୍ଯାସରୁ ପୂର୍ବନିର୍ଦ୍ଧାରିତ କୋନଶୋଲ ଉପକରଣକୁ ସଠିକ ଭାବରେ ଖୋଜିବାରେ ବିଫଳ ହୋଇଥାଏ।
ଏହା ଘଟିଲେ, ଆପଣ /boot/efi/elilo.conf
ରେ କର୍ଣ୍ଣଲ ବୁଟ ଧାଡି ସହିତ console=tty
ବୁଟ ପାରାମିଟରକୁ ଯୋଗ କରି ସମାଧାନ କରିପାରିବେ।
କିଛି Itanium ତନ୍ତ୍ରରେ (ଯେପରିକି Hitachi Cold Fusion 3e), କ୍ରମିକ ପୋର୍ଟ କୁ dom0
ରେ ଚିହ୍ନି ହେବ ନାହିଁ ଯେବେ VGA କୁ ସକ୍ରିୟ କରାଯାଇଥାଏ EFI ଅନୁରକ୍ଷଣ ପ୍ରବନ୍ଧକ ଦ୍ୱାରା। ଏହି ପ୍ରକାର, ଆପଣଙ୍କୁ ନିମ୍ନଲିଖିତ କ୍ରମିକ ପୋର୍ଟ ସୂଚନାକୁ dom0
କର୍ଣ୍ଣଲ ରେ ଭରଣ କରିବାକୁ ପଡିଥାଏ:
ବେଗ ବିଟସ/ସେକଣ୍ଡ ରେ
Number of data bits
Parity
io_base
ଠିକଣା
ଏହି ବିସ୍ତ୍ରୃତ ବିବରଣୀ ମାନଙ୍କୁ /boot/efi/elilo.conf
ରେ dom0
କର୍ଣ୍ଣଲର append=
ଧାଡିରେ ଉଲ୍ଳେଖ କରିବା ଉଚିତ। ଉଦାହରଣ ସ୍ବରୂପ:
append="com1=19200,8n1,0x3f8 -- quiet rhgb console=tty0 console=ttyS0,19200n8"
ଏହି ଉଦାହରଣରେ, com1
ଟି କ୍ରମିକ ପାର୍ଟ ଅଟେ, 19200
ଟି ଗତି(ବିଟ/ସେକଣ୍ଡ) ରେ, 8n1
ଡାଟା ବିଟ/ପେରିଟି ସେଟିଙ୍ଗର ସଂଖ୍ୟା କୁ ଦର୍ଶାଏ, ଏବଂ 0x3f8
ଟି io_base
ଠିକଣା।
ଆଭାସୀକରଣ ସେହି ବିନ୍ୟାସରେ କାମ କରି ନ ଥାଏ ଯିଏ ଅସମାନ ସ୍ମୃତି ସ୍ଥାନ ଅଭିଗମ୍ୟତା NUMA ର ପ୍ରୟୋଗ କରିଥାଏ। ଏହିପରି, ତନ୍ତ୍ରରେ ଆଭାସୀ କର୍ଣ୍ଣଲ ର ସ୍ଥାପନା ଯାହାକି NUMA ର ପ୍ରୟୋଗ କରିଥାଏ ବୁଟ ବିଫଳତାର ପରିଣାମ ଦେଖାଇ ଥାଏ।
କିଛି ସ୍ଥାପନ ସଂଖ୍ଯା ଆଭାସୀ କର୍ଣ୍ଣଲ କୁ ପୂର୍ବ ନିର୍ଧାରିତ ରୂପେ ସ୍ଥାପନ କରିଥାଏ. ଯଦି ଆପଣଙ୍କ ପାଖରେ ସେହି ସ୍ଥାପନ ସଂଖ୍ୟା ଅଛି ଏବଂ ତନ୍ତ୍ର NUMA ବ୍ୟବହାର କରୁଥାଏ ଏବଂ କର୍ଣ୍ଣଲ-Xen ସହିତ କାର୍ଯ୍ୟ କରିନଥାଏ, ସ୍ଥାପନ ସମୟରେ ଆଭାସୀ ପନ୍ଥାକୁ ନିଷ୍କ୍ରିୟ କରନ୍ତୁ।
ବର୍ତ୍ତମାନ, ଏହି ସଂରଚନାରେ ସଂପୂର୍ଣ ଆଭାସୀ ଅତିଥି ମାନଙ୍କର ଜୀବନ୍ତ ସ୍ଥାନାନ୍ତରଣ ସମର୍ଥିତ ନୁହେଁ। ଏହା ସହିତ, kexec
ଏବଂ kdump
ମଧ୍ଯ ଏହି ସଂରଚନାରେ ଆଭାସୀକରଣ ପାଇଁ ଅସମର୍ଥ।
ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ବିଶେଷ ଗୁଣ ଗୁଡିକ Red Hat Enterprise Linux ସଦସ୍ୟତା ସେବା ଅଧୀନରେ ବର୍ତ୍ତମାନ ସମର୍ଥିତ ନୁହଁ, ଏଗୁଡିକ ସମ୍ପୂର୍ଣ୍ଣ ଭାବରେ କାର୍ଯ୍ଯ କରି ନ ପାରନ୍ତି, ଏବଂ ସାଧାରଣତଃ ଉତ୍ପାଦନର ବ୍ଯବହାର ପାଇଁ ପ୍ରଯୁଜ୍ଯ ନୁହଁନ୍ତି। ତଥାପି, ଏହି ଗୁଣଗୁଡିକୁ ଗ୍ରାହକ ମାନଙ୍କର ସୁବିଧା ପାଇଁ ଅନ୍ତର୍ଭୂକ୍ତ କରାଯାଇଛି ଏବଂ ଗୁଣଗୁଡିକୁ ବିସ୍ତୃତ ବିବରଣୀ ସହିତ ପ୍ରଦାନ କରାଯାଇଛି।
ଗ୍ରାହକ ମାନେ ଏହି ଗୁଣ ମାନଙ୍କୁ ଗୋଟିଏ ଉତ୍ପାଦନ ବିହୀନ ପରିବେଶରେ ଉପଯୋଗୀ ପାଇପାରନ୍ତି। ପୂର୍ଣ୍ଣ ସମର୍ଥିତ ହେବା ପୂର୍ବରୁ ଗୋଟିଏ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ପାଇଁ ମଧ୍ଯ ଗ୍ରାହକ ମାନେ ନିଜର ପ୍ରତିକ୍ରିୟା ଏବଂ କାର୍ଯ୍ଯତ୍ମକତା ପ୍ରସ୍ତାବ ପ୍ରଦାନ କରିପାରିବେ। ଅଧିକ ଗୁରୁତର ସୁରକ୍ଷା ସମସ୍ଯା ମାନଙ୍କ ପାଇଁ ଇରେଟା ପ୍ରଦାନ କରାଯିବ।
ଗୋଟିଏ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ବିଶେଷ ଗୁଣର ବିକାଶ ସମୟରେ, ସର୍ବସାଧରଣ ମାନଙ୍କ ଉଦ୍ଦେଶ୍ଯରେ ଅତିରିକ୍ତ ଉପାଦାନ ପରୀକ୍ଷଣ ପାଇଁ ଉପଲବ୍ଧ ହେଇପାରେ। ଭବିଷ୍ଯତ ସଂସ୍କରଣରେ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଗୁଣ ମାନଙ୍କୁ ପୂର୍ଣ୍ଣ ସମର୍ଥନ ପ୍ରଦାନ କରିବା Red Hat ର ଲକ୍ଷ୍ଯ ଅଟେ।
ସୁସ୍ପଷ୍ଟ ସକ୍ରିୟ-ନିଷ୍କ୍ରିୟ ଫେଲ-ଅଭର (ALUA) ଧାରା ବ୍ଯବହାର କରି EMC Clariion ରେ dm-multipath
ଭଣ୍ଡାର ବର୍ତ୍ତମାନ ଉପଲବ୍ଧ। ଏହି ଧାରାକୁ T10 ବିଶେଷ ବିବରଣୀ ଅନୁଯାୟୀ ପ୍ରଦାନ କରିଯାଇଛି, କିନ୍ତୁ ଏହାକୁ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଭାବରେ ପ୍ରଦାନ କରାଯାଇଛି।
T10 ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇବା ପାଇଁ, http://www.t10.org କୁ ପଢନ୍ତୁ।
ext ଫାଇଲତନ୍ତ୍ରର ନୂତନ ନିର୍ମାଣ, ext4
, ଏହି ପ୍ରକାଶନରେ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପ୍ରାକଦର୍ଶନ ଭାବରେ ଉପଲବ୍ଧ ହୋଇଥାଏ। Ext4
ଟି Red Hat ଏବଂ Linux ସମ୍ପ୍ରଦାୟ ଦ୍ୱାରା ନିର୍ମିତ ext3
ଫାଇଲତନ୍ତ୍ରର ବର୍ଦ୍ଧିତ ଉନ୍ନତି। ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପ୍ରାକଦର୍ଶନ ପାଇଁ ଫାଇଲ ତନ୍ତ୍ରର ପ୍ରକାଶନ ନାମଟି ହେଉଛି ext4dev
।
ଫାଇଲ ତନ୍ତ୍ରଟି ext4dev.ko
କର୍ଣ୍ଣଲ ଏକକାଂଶ, ଏବଂ ଗୋଟିଏ ନୂତନ e4fsprogs
ପ୍ୟାକେଜ ଦ୍ୱାରା ପ୍ରଦତ୍ତ, ଯାହାକି ext4 ସହିତ ବ୍ୟବହାର କରିବା ପାଇଁ ପରିଚିତ e2fsprogs ପ୍ରଶାସକ ସାଧନର ଅଦ୍ୟତିତ ସଂସ୍କରଣକୁ ଧାରଣ କରିଥାଏ। ବ୍ୟବହାର କରିବା ପାଇଁ, e4fsprogs
କୁ ସ୍ଥାପନ କରନ୍ତୁ ଏବଂ ତାପରେ ext4-ଆଧାରିତ ଫାଇଲତନ୍ତ୍ର ନିର୍ମାଣ କରିବା ପାଇଁ e4fsprogs ପ୍ରଗ୍ରାମରୁ mkfs.ext4dev
ପରି ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ। ସ୍ଥାପିତ ନିର୍ଦ୍ଦେଶନାମା କିମ୍ବା fstab ଫାଇଲରେ ଯେତେବେଳେ ଫାଇଲତନ୍ତ୍ରକୁ ଅନୁସରଣ କରୁଛନ୍ତି, ଫାଇଲତନ୍ତ୍ର ନାମ ext4dev
କୁ ବ୍ୟବହାର କରନ୍ତୁ।
FreeIPMI କୁ ଏହି ସଂସ୍କରଣରେ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଭାବରେ ଅନ୍ତର୍ଭୂକ୍ତ କରାଯାଇଛି। FreeIPMI କୁଶଳ ପ୍ଲାଟଫର୍ମ ପରିଚାଳନା IPMI ତନ୍ତ୍ର ସଫ୍ଟୱେର ମାନଙ୍କର ଗୋଟିଏ ସଂଗ୍ରହ ଅଟେ। କୁଶଳ ପ୍ଲାଟଫର୍ମ ପରିଚାଳନା ଅନ୍ତରାପୃଷ୍ଠ (IPMI v 1.5 ଏବଂ v2.0) ମାନକକୁ ନିଶ୍ଚିତ କରୁଥିବା ଗୋଟିଏ ବିକାଶ ଲାଇବ୍ରେରୀ ସହିତ ଏହା ଇନ-ବ୍ଯାଣ୍ଡ ଏବଂ ଆଉଟ-ଆଫ-ବ୍ଯାଣ୍ଡ ସଫ୍ଟୱେର ପ୍ରଦାନ କରିଥାଏ।
FreeIPMI ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇବା ପାଇଁ, http://www.gnu.org/software/freeipmi/ କୁ ପଢନ୍ତୁ।
TrouSerS ଏବଂ tpm-tools
ଦ୍ୱୟ Trusted Platform Module (TPM) ହାର୍ଡୱେରର ବ୍ୟବହାରକୁ ସକ୍ରିୟ କରିବା ପାଇଁ ଏହି ସଂସ୍କରଣରେ ଅନ୍ତର୍ଗତ। TPM ହାର୍ଡୱେରର ବିଶେଷ ଗୁଣ ଗୁଡିକ ଅନ୍ତର୍ଗତ (ଅନ୍ୟ ମାନଙ୍କ ମଧ୍ଯରେ):
RSA ଚାବି ଗୁଡିକର ସୁରକ୍ଷିତ ଭାବରେ ସୃଷ୍ଟି, ସଂରକ୍ଷଣ ଏବଂ ବ୍ୟବହାର (ସ୍ମୃତି ରେ ବିନା ଖୋଲାରଖି)
ସଙ୍କେତ ଲିପିକ ହ୍ୟାସଗୁଡ଼ିକୁ ବ୍ୟବହାର କରି ଗୋଟିଏ ପ୍ଲାଟଫର୍ମ'ର ସଫ୍ଟୱେର କୁ ଯାଞ୍ଚ କରିବା
TrouSerS ବିଶ୍ବସ୍ତ କମ୍ପୁଟିଙ୍ଗ ସମୂହ'sର ସଫ୍ଟୱେର ଷ୍ଟାକ (TSS) ବିଶିଷ୍ଟତା ର ଗୋଟିଏ ପରିଚାଳନ। TPM ହାର୍ଡୱେରକୁ ବ୍ଯବହାର କରୁଥିବା ପ୍ରୟୋଗ ମାନଙ୍କୁ ଲେଖିବା ପାଇଁ ଆପଣ TrouSerS କୁ ବ୍ଯବହାର କରିପାରିବେ। tpm-tools
TPM ହାର୍ଡୱେରର ପରିଚାଳନା ଏବଂ ଉପଯୋଗୀତା ପାଇଁ ଉପକରଣ ମାନଙ୍କର ଗୋଟିଏ ସମୂହ ଅଟେ।
TrouSerS ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇବା ପାଇଁ, http://trousers.sourceforge.net/. କୁ ପଢନ୍ତୁ।
eCryptfs Linux ପାଇଁ ଗୋଟିଏ ଗୁଚ୍ଛିତ ସାଙ୍କେତିକ ଫାଇଲ ତନ୍ତ୍ର ଅଟେ। ଏହା EXT3 ପରି ଅବସ୍ଥିତ ନିମ୍ନ ବର୍ଗୀୟ ମାଉଣ୍ଟ କରାଯାଇଥିବା ଫାଇଲ ତନ୍ତ୍ରର ବ୍ଯକ୍ତିଗତ ଡିରେକ୍ଟୋରିରେ ମାଉଣ୍ଟ କରିଥାଏ; eCryptfs କୁ ବ୍ଯବହାର କରିବା ପାଇଁ ଅବସ୍ଥିତ ବିଭାଜନ କିମ୍ବା ଫାଇଲ ତନ୍ତ୍ର ମାନଙ୍କୁ ପରିବର୍ତ୍ତନ କରିବାର କୌଣସି ଆବଶ୍ଯକତା ନାହିଁ।
ଏହି ପ୍ରକାଶନ ସହିତ, eCryptfs ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 56ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଥାଏ, ଯାହାକି ଅନେକ ତ୍ରୁଟି ନିବାରଣ ଏବଂ ଉନ୍ନତି ପ୍ରଦାନ କରିଥାଏ। ଏହା ସହିତ, ଏହି ଅଦ୍ୟତନ eCryptfs (ecryptfs-mount-helper-gui
)ର ବିନ୍ୟାସରେ ସହାୟତା ପାଇଁ ଗୋଟିଏ ଆଲେଖୀ ପ୍ରଗ୍ରାମ ପ୍ରଦାନ କରିଥାଏ।
ଏହି ଅଦ୍ୟତନ କିଛି eCryptfs ସ୍ଥାପନ ବିକଳ୍ପଗୁଡ଼ିକର ବାକ୍ୟବିନ୍ୟାସକୁ ମଧ୍ଯ ପରିବର୍ତ୍ତନ କରିଥାଏ। ଯଦି ଆପଣ eCryptfsର ଏହି ସଂସ୍କରଣକୁ ଅଦ୍ୟତନ କରିବାକୁ ବାଛନ୍ତି, ତେବେ ଆପଣଙ୍କୁ ଯେକୌଣସି କ୍ଷତିଗ୍ରସ୍ତ ସ୍କ୍ରିପ୍ଟ ଏବଂ /etc/fstab
ନିବେଶଗୁଡ଼ିକୁ ଅଦ୍ୟତନ କରିବାକୁ ହେବ। ଏହି ପରିବର୍ତ୍ତନଗୁଡ଼ିକ ବିଷୟରେ ସୂଚନା ପାଇଁ, man ecryptfs
ଚଲାନ୍ତୁ।
ନିମ୍ନଲିଖିତ caveats eCryptfs ର ଏହି ପ୍ରକାଶନରେ ପ୍ରୟୋଗ ହୋଇଥାଏ :
ମନେରଖନ୍ତୁ ଯେ eCryptfs ଫାଇଲ ତନ୍ତ୍ର କେବଳ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିଥାଏ ଯଦି ସଂଗୁପ୍ତ ପାଇଲ ତନ୍ତ୍ର ଥରେ ସମାନ ନାମ ବିଶିଷ୍ଟ ଅନ୍ତର୍ନିହିତ ଡ଼ିରେକ୍ଟରୀରେ ସ୍ଥାପିତ ହୋଇଥାଏ। ଉଦାହରଣ ସ୍ୱରୂପ:
mount -t ecryptfs /mnt/secret /mnt/secret
ଏହି ଫାଇଲତନ୍ତ୍ରର ସୁରକ୍ଷିତ ଅଂଶକୁ ଖୋଲାରଖିବା ଉଚିତନୁହଁ, ଯେପରି କି, ଏହାକୁ ଅନ୍ୟ ସ୍ଥାପନ କ୍ଷେତ୍ର, ବନ୍ଧନ ସ୍ଥାପନ, ଏବଂ ସେହିପରି କ୍ଷେତ୍ରରେ ସ୍ଥାପନ କରିବା ଉଚିତନୁହଁ।
ନେଟୱର୍କ ଫାଇଲ ତନ୍ତ୍ରରେ ସ୍ଥାପିତ ହୋଇଥିବା eCryptfs (ଯେପରି NFS, Samba) ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିନପାରେ।
eCryptfs କର୍ଣ୍ଣଲ ଡ୍ରାଇଭରର ଏହି ସଂସ୍କରଣ ଅଦ୍ୟତିତ ଚାଳକ ସ୍ଥାନ ଆବଶ୍ୟକ କରିଥାଏ, ଯାହାକି ecryptfs-utils-56-4.el5
କିମ୍ବା ନୂତନତମ ଦ୍ୱାରା ପ୍ରଦତ୍ତ।
eCryptfs ବିଷୟରେ ଅଧିକ ସୂଚନା ପାଇଁ, http://ecryptfs.sf.net କୁ ଅନୁସରଣ କରନ୍ତୁ। ଆପଣ ମୌଳିକ ବ୍ୟବସ୍ଥାର ସୂଚନା ପାଇଁ http://ecryptfs.sourceforge.net/README ଏବଂ http://ecryptfs.sourceforge.net/ecryptfs-faq.html କୁ ମଧ୍ଯ ପଢିପାରିବେ।
ଅବସ୍ଥା ବିହୀନ Linux ଗୋଟିଏ ତନ୍ତ୍ରର ଚାଳନ ଏବଂ ପରିଚାଳନ ପାଇଁ ଏକ ନୂତନ ପ୍ରକାର ଚିନ୍ତନ, ସାଧାରଣ ଭାବରେ ଉଦ୍ଦିଷ୍ଟ ଏବଂ ପରିଚାଳିତ ବହୁଳ ସଂଖ୍ଯକ ତନ୍ତ୍ରର ସମ୍ମିଳନରେ ଏହାକୁ ପ୍ରସ୍ତୁତ କରାଯାଇଛି ଯେପରିକି ଏହାକୁ ସହଜରେ ବଦଳାଇ ହେବ। ଏହାକୁ ପ୍ରାରମ୍ଭିକ ସ୍ତରରେ ଉପସ୍ଥିତ ତନ୍ତ୍ରର ପ୍ରତିଛବିକୁ ସ୍ଥାପନ କରି ସମ୍ପନ୍ନ କରାଯାଇଛି ଯାହାକି ଏକାଧିକ ଅବସ୍ଥା ବିହୀନ ତନ୍ତ୍ର ଦ୍ବାରା ପରିଚାଳିତ ଏବଂ ଅନୁକୃତ। ଏହା କେବଳ ପାଠ୍ଯ ଧାରାରେ ପ୍ରଚାଳନ ତନ୍ତ୍ରକୁ ଚଳାଉଛି (ଅଧିକ ସୂଚନା ଜାଣିବା ପାଇଁ ଦୟାକରି /etc/sysconfig/readonly-root
କୁ ପଢନ୍ତୁ)।
ଏହାର ପ୍ରଚଳିତ ବିକାଶ ଅବସ୍ଥାରେ, ଅବସ୍ଥା ବିହୀନ ଗୁଣ ଗୁଡିକ ଉଦ୍ଦେଶ୍ଯ ମୂଳକ ଲକ୍ଷ୍ଯର ଉପସେଟ ଅଟନ୍ତି। ଉଦାହରଣ ସ୍ବରୂପ, ଦକ୍ଷତାକୁ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଅବସ୍ଥା ରୂପରେ ସୂଚୀତ କରାଯାଇଛି।
ଏହା Red Hat ଦ୍ୱାରା ବିଶେଷ ଭାବରେ ପରାମର୍ଶିତ ଯେ, ଯେଉଁମାନେ ଅବସ୍ଥା ବିହୀନ ସଙ୍କେତକୁ ପରୀକ୍ଷଣ କରିବାକୁ ଇଚ୍ଛୁକ, ସେମାନେ HOWTO କୁ ଏଠାରେ http://fedoraproject.org/wiki/StatelessLinuxHOWTO ପଢନ୍ତୁ ଏବଂ ଏହି ସମୂହରେ stateless-list@redhat.com ନିଜକୁ ପଞ୍ଜୀକୃତ କରନ୍ତୁ।
ଅବସ୍ଥାବିହୀନ Linux ପାଇଁ ଅବସଂରଚନା ଅଂଶ ମାନଙ୍କୁ ସକ୍ରିୟଣକୁ ମୂଳ ରୂପରେ Red Hat Enterprise Linux 5 ରେ ପରିଚିତ କରାଯାଇଥିଲା।
AIGLX ପୂର୍ଣ୍ଣ ସମର୍ଥିତ X ସେବକର ଗୋଟିଏ ପ୍ରଯୁକ୍ତଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଗୁଣ ଅଟେ। ଗୋଟିଏ ସାଧାରଣ ଡେସ୍କଟପରେ GL-ତ୍ବରିତ ପ୍ରଭାବ ମାନଙ୍କୁ ସକ୍ରିୟ କରିବା ପାଇଁ ଏହା ଲକ୍ଷ୍ଯ କରିଅଛି। ଏହି ଯୋଜନାଟି ନିମ୍ନଲିଖିତ ଉପାଦାନ ମାନଙ୍କୁ ଧାରଣ କରିଅଛି:
ସରଳତାର ସହିତ ରୂପାନ୍ତରିତ ଗୋଟିଏ X ସେବକ।
ଗୋଟିଏ ଅଦ୍ଯତିତ ମେସା ପ୍ଯାକେଜ ଯାହାକି ନୂତନ ପ୍ରଟୋକଲ ସହାୟତା ଯୋଗ କରିଥାଏ
ଏହି ଉପାଦାନ ମାନଙ୍କୁ ସ୍ଥାପନ କରି, ଅତି କମ ପରିବର୍ତ୍ତନ ମାନଙ୍କ ସହିତ ଆପଣ ଆପଣଙ୍କ ଡେସ୍କଟପରେ GL-ତ୍ବରିତ ପ୍ରଭାବ ପାଇପାରିବେ, ଆହୁରି ମଧ୍ଯ ଆପଣଙ୍କ X ସେବକକୁ ନ ବଦଳାଇ ଇଚ୍ଛାନୁସାରେ ସେମାନଙ୍କୁ ସକ୍ରିୟ ଏବଂ ନିଷ୍କ୍ରିୟ କରିବାର ଦକ୍ଷତା ହାସଲ କରିପାରିବେ। ହାର୍ଡୱେର GLX ତ୍ବରଣର ସୁବିଧା ପାଇବା ପାଇଁ AIGLX ଦୂର GLX ପ୍ରୟୋଗ ମାନଙ୍କୁ ମଧ୍ଯ ସକ୍ରିୟ କରିଥାଏ।
Linux ଲକ୍ଷ୍ଯ (tgt) ଢାଞ୍ଚା ଗୋଟିଏ ତନ୍ତ୍ରକୁ ଗୋଟିଏ SCSI ପ୍ରାରମ୍ଭକ ଥିବା ଅନ୍ଯ ତନ୍ତ୍ର ପାଇଁ ଖଣ୍ଡ-ସ୍ତରୀୟ SCSI ସଂରକ୍ଷଣ କରିବାର ସେବା ଦେବାକୁ ଅନୁମତି ପ୍ରଦାନ କରିଥାଏ। ଏହି କ୍ଷମତାକୁ ପ୍ରାରମ୍ଭିକ ରୂପରେ ଯେ କୌଣସି iSCSI ପ୍ରାରମ୍ଭକ ପାଇଁ ନେଟୱାର୍କ ଦେଇ ସଂରକ୍ଷଣ ପ୍ରଦାନ କରିବା ସହିତ ଗୋଟିଏ Linux iSCSI ଲକ୍ଷ୍ଯ ଭାବରେ ପରିନିୟୋଜନ କରାଯାଇଛି।
iSCSI ଲକ୍ଷ୍ଯକୁ ବ୍ଯବସ୍ଥାପନ କରିବା ପାଇଁ, scsi-target-utils
RPM କୁ ସ୍ଥାପନ କରନ୍ତୁ ଏବଂ ଏଠାରେ ଅନୁଦେଶକୁ ପଢନ୍ତୁ:
/usr/share/doc/scsi-target-utils-
[version]
/README
/usr/share/doc/scsi-target-utils-
[version]
/README.iscsi
କୁ ସ୍ଥାପିତ ପ୍ଯାକେଜର ଆପେକ୍ଷିକ ସଂସ୍କରଣ ସହିତ ବଦଳାନ୍ତୁ।
[version]
ଅଧିକ ସୂଚନା ପାଇଁ, man tgtadm
କୁ ପଢନ୍ତୁ।
firewire-sbp2
ଏକକାଂଶକୁ ଏହି ଅଦ୍ଯତନରେ ଗୋଟିଏ ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ ଭାବରେ ଅନ୍ତର୍ଭୂକ୍ତ କରାଯାଇଛି। ଏହି ଏକକାଂଶ ଫାୟାରୱେର ଭଣ୍ଡାର ଉପକରଣ ଏବଂ କ୍ରମବୀକ୍ଷକ ସହିତ ସଂଯୋଜକତା ସକ୍ରିୟ କରିଥାଏ।
ବର୍ତ୍ତମାନ, FireWire ନିମ୍ନଲିଖିତ ସେବାକୁ ସମର୍ଥନ କରେନାହିଁ:
IPv4
pcilynx ଆଧାର ନିୟନ୍ତ୍ରକ
ବହୁଳ-LUN ଭଣ୍ଡାର ଉପକରଣ
ଭଣ୍ଡାର ଉପକରଣକୁ ଅସ୍ପଷ୍ଟ ଅଭିଗମ
ଏହା ସହିତ, ନିମ୍ନଲିଖିତ ସମସ୍ଯା ଗୁଡିକ ଫାୟାରୱେରରେ ତଥାପି ରହିଛି:
SBP2
ଡ୍ରାଇଭରରେ ଗୋଟିଏ ସ୍ମୃତି ହାନୀ ମେସିନ ଉତ୍ତର ନ ଦେବାର କାରଣ ହୋଇପାରେ।
ବିଗ-ଇଣ୍ଡିୟାନ ମେସିନରେ ଏହି ସଂସ୍କରଣରେ ଥିବା ଗୋଟିଏ ସଙ୍କେତ ସଠିକ ଭାବରେ କାର୍ଯ୍ଯ କରି ନ ଥାଏ। ଏହା PowerPC ରେ ଅପ୍ରତ୍ଯାଶିତ ବ୍ଯବହାର ସୃଷ୍ଟି କରିପାରେ।
ଏହି ପ୍ରକାଶନରେ ktune
(ktune
ପ୍ୟାକେଜରୁ) ଅନ୍ତର୍ଭୁକ୍ତ। ଏହା ଗୋଟିଏ ସର୍ଭିସ ଯାହାକି ଅନେକ କର୍ଣ୍ଣଲ ଟ୍ୟୁନିଙ୍ଗ ପ୍ରାଚଳଗୁଡ଼ିକୁ ତନ୍ତ୍ର ରୂପରେଖା ନିର୍ଦ୍ଦିଷ୍ଟ ଉପଯୁକ୍ତ ମୂଲ୍ୟକୁ ବିନ୍ୟାସ କରିଥାଏ। ବର୍ତ୍ତମାନ, ktune
କେବଳ ବୃହତ ସ୍ମୃତିସ୍ଥାନ ତନ୍ତ୍ର ଚାଳିତ ଡ଼ିସ୍କ-ବୃଦ୍ଧିକର ଏବଂ ନେଟୱର୍କ-ବୃଦ୍ଧିକର ପ୍ରୟୋଗମାନଙ୍କ ପାଇଁ ରୂପରେଖା ପ୍ରଦାନ କରିଥାଏ।
ktune
ଦ୍ୱାରା ପ୍ରଦତ୍ତ ବିନ୍ୟାସ /etc/sysctl.conf
କିମ୍ବା କର୍ଣ୍ଣଲ ନିର୍ଦ୍ଦେଶନାମାରେ ବିନ୍ୟାସିତ ଉପରେ ନବଲିଖନ କରେନାହିଁ। ktune
କିଛି ତନ୍ତ୍ର ଏବଂ କାର୍ଯ୍ୟଭାରରେ ଉପଯୁକ୍ତ ହୋଇନଥାଇପାରେ; ସେହିପରି, ଆପଣ ଏହାକୁ ଉତ୍ପାଦନରେ ଦେବା ପୂର୍ବରୁ ବିସ୍ତୃତ ଭାବରେ ପରୀକ୍ଷା କରିବା ଉଚିତ।
ଆପଣ ktune
ଦ୍ୱାରା ସେଟ ହୋଇଥିବା କୌଣସି ବିନ୍ୟାସକୁ ନିଷ୍କ୍ରିୟ କରି ପାରିବେ ଏବଂ (ପ୍ରମୁଖ ଚାଳକ ଭାବରେ) service ktune stop
ବ୍ୟବହାର କରି ktune
କୁ ବନ୍ଦ କରି ଆପଣଙ୍କର ସାଧାରଣ ବିନ୍ୟାସକୁ ପ୍ରତ୍ୟାବୃତ କରିପାରିବେ।
କ୍ରମିକ ସାଧାରଣ ଉଦ୍ଦେଶ୍ୟ ନିବେଶ ନିର୍ଗମ (SGPIO) ଟି ମୂଖ୍ୟ ବୋର୍ଡ ଏବଂ ବିଭିନ୍ନ ପ୍ରକାର ଆଭ୍ୟନ୍ତରିଣ ଏବଂ ବାହ୍ୟ ହାର୍ଡ ଡିସ୍କ ଡ୍ରାଇଭ ସଂଲଗ୍ନ ମଧ୍ଯରେ ଗୋଟିଏ ଉଦ୍ୟୋଗ ମାନକ ସଞ୍ଚାର ମାଧ୍ଯମ। ଏହି ପଦ୍ଧତିକୁ AHCI ଡ୍ରାଇଭର ଅନ୍ତରାପୃଷ୍ଠରେ LED ଆଲୋକକୁ ନିୟନ୍ତ୍ରଣ କରିବା ପାଇଁ ବ୍ୟବହାର କରାଯାଇପାରିବ।
ଏହି ପ୍ରକାଶନରେ, dmraid ରେ SGPIO ସମର୍ଥନକୁ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପ୍ରାକଦର୍ଶନ ଭାବରେ ଅନ୍ତର୍ଭୁକ୍ତ କରାଯାଇଛି. ଏହା dmraid କୁ ଡିସ୍କ ସଂଲଗ୍ନ ସହିତ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିବାକୁ ଅନୁମତି ଦେଇଥାଏ।
Gnu ସଂକଳକ ସଂଗ୍ରହ ସଂସ୍କରଣ 4.3 (GCC4.3) ଟି ବର୍ତ୍ତମାନ ଏହି ପ୍ରକାଶନରେ ପ୍ରଯୁକ୍ତି ଜ୍ଞାନ ପୂର୍ବାଲୋକନ ଭାବରେ ଅନ୍ତର୍ଭୁକ୍ତ କରାଯାଇଛି। ଏହି ସଂକଳକଗୁଡ଼ିକର ସଂଗ୍ରହରେ C, C++, ଏବଂ Fortran 95 ସଂକଳକ ସମର୍ଥନ ଲାଇବ୍ରେରୀ ସହିତ ଅନ୍ତର୍ଭୁକ୍ତ।
ମନେରଖନ୍ତୁ ଯେ gcc43
ପ୍ୟାକେଜଗୁଡ଼ିକରେ, gnu89-inline
ବିକଳ୍ପ ପାଇଁ ପୂର୍ବନିର୍ଦ୍ଧାରିତକୁ -fgnu89-inline
ରେ ପରିବର୍ତ୍ତନ କରାଯାଇଛି, ଯେଉଁଠି ଅପଷ୍ଟ୍ରିମ ଏବଂ Red Hat Enterprise Linux 5 ର ଭବିଷ୍ୟତ ଅଦ୍ୟତନଗୁଡ଼ିକରେ -fno-gnu89-inline
ପୂର୍ବନିର୍ଦ୍ଧାରିତ ହୋଇଥାଏ। ଏହା ଆବଶ୍ୟକ କାରଣ ଅନେକ ଶୀର୍ଷକଗୁଡ଼ିକ Red Hat Enterprise Linux 5ର ଅଂଶ ପରି ସିପ ହୋଇଥାଏ। ISO C99 ଅର୍ଥ ବିନ୍ଯାସର GNU ଲାଇନ-ବିଶିଷ୍ଟ ଅର୍ଥ ବିଜ୍ଞାନ ପରିବର୍ତ୍ତେ ଆବଶ୍ୟକ ହୋଇଥାଏ। ଏହି ଶୀର୍ଷକଗୁଡ଼ିକ ଗୁଣ ମାଧ୍ଯମରେ GNU ଧାଡ଼ି-ବିଶିଷ୍ଟ ଅର୍ଥ ବିଜ୍ଞାନରେ ମେଳାଇଥାଏ।
ଏହି ଅଦ୍ୟତନରେ, ଗୋଟିଏ ନୂତନ କର୍ଣ୍ଣଲ ଚିହ୍ନକ/ଚିହ୍ନିତ ସ୍ଥାନ ସୁବିଧାକୁ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନ ଭାବରେ କାର୍ଯ୍ୟକାରୀ କରାଯାଇଥାଏ। ଏହି ଅନ୍ତରାପୃଷ୍ଠ ସ୍ଥିର ସନ୍ଧାନ ସ୍ଥାନଗୁଡ଼ିକୁ କର୍ଣ୍ଣଲରେ SystemTap ପରି ସାଧନଗୁଡ଼ିକରେ ବ୍ୟବହାର କରିବା ପାଇଁ ଯୋଗ କରିଥାଏ।
ଇଥରନେଟ ଉପରେ ଫାଇବର ଚ୍ୟାନେଲ (FCoE) ଡ୍ରାଇଭର, libfc ସହିତ, FCoE କୁ ମାନକ ଇଥରନେଟ କାର୍ଡ ଉପରେ ଚାଲିବାର କ୍ଷମତା ପ୍ରଦାନ କରିଥାଏ। ଏହି କ୍ଷମତାକୁ Red Hat Enterprise Linux 5.3ରେ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନ ଭାବରେ ପ୍ରଦାନ କରାଯାଇଥାଏ।
Red Hat Enterprise Linux 5.3 ତିନୋଟି ଉପଯୁକ୍ତ ହାର୍ଡୱେର ପ୍ରୟୋଗରେ FCoE ପାଇଁ ସମ୍ପୂର୍ଣ୍ଣ ସମର୍ଥନ ପ୍ରଦାନ କରିଥାଏ। ସେଗୁଡ଼ିକ ହେଲେ: Cisco fnic
ଡ୍ରାଇଭର, Emulex lpfc
ଡ୍ରାଇଭର, ଏବଂQlogic qla2xx
ଡ୍ରାଇଭର।
ଉପକରଣ ବିଫଳତା ନିରିକ୍ଷଣ, dmraid ସାଧନ ଏବଂ dmevent_ସାଧନକୁ ବ୍ୟବହାର କରି,Red Hat Enterprise Linux 5.3 ରେ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନ ଭାବରେ ଅନ୍ତର୍ଭୁକ୍ତ କରାଯାଇଛି। ଏହା RAID ସେଟରେ ଥିବା ଉପାଦାନ ଉପକରଣରେ ଉପକରଣ ବିଫଳତାକୁ ଦେଖିବା ଏବଂ ଖବର କରିବାର କ୍ଷମତା ପ୍ରଦାନ କରିଥାଏ।
TTY ଉପକରଣର କାର୍ଯ୍ୟକଳାପ ବିବରଣୀଗୁଡ଼ିକ ପାଇଁ ଥିବା ତଥ୍ୟ ସଠିକ ଭାବରେ ସୃଷ୍ଟି କରାଯାଇନଥିଲା। ଫଳସ୍ୱରୂପ, ନିମ୍ନଲିଖିତ ତ୍ରୁଟିକୁ ଦର୍ଶାଇକରି, sar -y
ନିର୍ଦ୍ଦେଶ ବିଫଳ ହୋଇଥାଏ:
ଅନୁରୋଧ କରାଯାଇଥିବା କାର୍ଯ୍ୟକଳାପ ଫାଇଲରେ ଉପଲବ୍ଧ ନାହିଁ
ଏହି ଅଦ୍ୟତିତ ପ୍ୟାକେଜରେ, sar କୁ ଠିକ କରାଯାଇଛି, ତେଣୁ -y ବିକଳ୍ପ TTY ଉପକରଣ କାର୍ଯ୍ୟକଳାପକୁ ଦର୍ଶାଇଥାଏ।
ପୂର୍ବରୁ, max_fds
କୁ /etc/multipath.conf
ରେ ଥିବା unlimited
ରେ ବିନ୍ୟାସ କରିବା ଦ୍ୱାରା multipathd ଡ଼େମନକୁ ଆରମ୍ଭ ହେବାରୁ ପ୍ରତିରୋଧ କରିଥାଏ। ଯଦି ଖୋଲା ଫାଇଲ ବର୍ଣ୍ଣନାକାରୀର ସଂଖ୍ଯା ତନ୍ତ୍ରର ସର୍ବାଧିକ ସଂଖ୍ୟାଆକାରରେ ସେଟ କରାଯାଏ, ତେବେ max_fds
କୁ max
ସେଟ କରାଯିବା ଆବଶ୍ୟକ।
mod_perl ବର୍ତ୍ତମାନ ସଂସ୍କରଣ 2.0.4, ନୂତନତମ ଅପଷ୍ଟ୍ରିମ ପ୍ରକାଶନରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଯାଇଛି। ଏହି ଅଦ୍ୟତନ ଅନେକ ଅଦ୍ୟତନଗୁଡ଼ିକୁ ପ୍ରୟୋଗ କରିଥାଏ, ଯାହାକି ଗୋଟିଏ ତ୍ରୁଟି ନିବାରଣକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ ଯାହାକି ବର୍ତ୍ତମାନ mod_perlକୁ Bugzilla 3.0 ସହିତ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିବାକୁ ଅନୁମତି ଦେଇଥାଏ।
cups ସଂସ୍କରଣ 1.3.7 ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ଅନେକ ତ୍ରୁଟିନିବାରଣ ଏବଂଉନ୍ନତିକୁ ପ୍ରୟୋଗ କରିଥାଏ, (ଅନ୍ୟ ମାନଙ୍କ ମଧ୍ୟରେ):
କର୍ବୋରସ ପ୍ରାଧିକରଣଟି ବର୍ତ୍ତମାନ ସମର୍ଥିତ।
ଚାଳକ-ନିର୍ଦ୍ଦିଷ୍ଟ ମୁଦ୍ରଣୀ ଏବଂ କାର୍ଯ୍ୟ ନିତୀଗୁଡ଼ିକ ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ ଧାରଣ କରାଯାଇଛି।
ବ୍ରାଉଜିଙ୍ଗ ନିଷ୍କ୍ରିୟ ହେବା ପରେ ସୁଦୂର କ୍ରମ କ୍ୟାଶେଗୁଡ଼ିକୁ ଆଉ ଧାରଣ କରାଯାଉନାହିଁ।
classes.conf
ବିନ୍ୟାସ ଫାଇଲରେ ବର୍ତ୍ତମାନ ସଠିକ ଫାଇଲ ଅନୁମତି ଅଛି।
lm_sensors
ସଂସ୍କରଣ 2.10.7ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ଅନେକ ଅପଷ୍ଟ୍ରିମ ଉନ୍ନତି ଏବଂ ତ୍ରୁଟି ନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ। ଏହା ଗୋଟିଏ ତ୍ରୁଟିନିବାରଣକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ ଯାହାକି libsensorsକୁ General parse error
ସନ୍ଦେଶ ସହିତ ଖରାପ ହେବାରୁ ଅଟକାଇଥାଏ ଯେତେବେଳେk8temp
ମଧ୍ଯ ଧାରଣ କରାଯାଉଥାଏ।
ନିମ୍ନଲିଖିତ ତ୍ରୁଟିଗୁଡ଼ିକୁ ଦର୍ଶାଇବା ପାଇଁ elfutils ଏହି ପ୍ରକାଶନରେ ଅଦ୍ୟତିତ ହୋଇସାରିଛି:
eu-readelf ଉପଯୋଗୀତା ନଷ୍ଟ ହୋଇପାରେ ଯେତେବେଳେ କିଛି ନିବେଶ ଫାଇଲଗୁଡ଼ିକୁ ପଢାଯାଉଥାଏ।
eu-strip ଉପଯୋଗୀତା rpmbuild
ପ୍ରଣାଳୀରେ ବ୍ୟବହାର ହୋଇଥାଏ ଯାହାକି ନୂତନ ବାଇନାରି ପ୍ୟାକେଜ ନିର୍ମାଣ କରିଥାଏ। -debuginfo
ପ୍ୟାକେଜ ନିର୍ମାଣ କରିବା ପାଇଁଏହା ତ୍ରୁଟି ନିବାରଣ ସୂଚନାକୁ ନିଷ୍ପାଦ୍ୟ ସଂକେତରୁ ପୃଥକ କରିଥାଏ। ଫଳସ୍ୱରୂପ s390 ପ୍ଲାଟଫର୍ମ ଉପରେ ET_REL ଫାଇଲରେ ଏହି ଉପଯୋଗୀତାର ଗୋଟିଏ ତ୍ରୁଟି ଅବ୍ୟବହୃତ ତ୍ରୁଟି ନିବାରଣ ସୂଚନା ମିଳିଥାଏ; ଏହା Linux କର୍ଣ୍ଣଲ ଏକକାଂଶ ଫାଇଲଗୁଡ଼ିକ (.ko.debug
) ଉପରେ ପ୍ରଭାବ ପକାଇଥାଏ, ଏବଂ ନିର୍ମିତ kernel-debuginfo
ପ୍ୟାକେଜଗୁଡ଼ିକ s390 ଉପରେ Systemtapରେ କାର୍ଯ୍ୟକରିନଥାଏ।
vnc-server ସଂସ୍କରଣ 4.1.2-14.el5 କୁ ଅଦତିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ନିମ୍ନଲିଖିତ ନିବାରଣଗୁଡ଼ିକୁ ପ୍ରୟୋଗ କରିଥାଏ:
ଗୋଟିଏ ତ୍ରୁଟି ଯିଏ vncserver କୁ Xvnc ଆରମ୍ଭ କରିବାରେ ବିଫଳ ହେବା ସମୟରେ ବାରଣ କରିଥାଏ ତାହା ବର୍ତ୍ତମାନ ଠିକ ହୋଇସାରିଛି।
Xvnc ଏବେ ଆଉ ଭୁଲ ମୂଳ ୱିଣ୍ଡୋ ଗଭୀରତାକୁ ବ୍ୟବହାର କରିନଥାଏ; ଏହା ବର୍ତ୍ତମାନ -depth
ବିକଳ୍ପ ଦ୍ୱାରା ନିର୍ଦ୍ଦିଷ୍ଟ ସଠିକ ୱିଣ୍ଡୋ ଗଭୀରତାକୁ ବ୍ୟବହାର କରିଥାଏ।
ଗୋଟିଏ ତ୍ରୁଟି ଯିଏକି libvnc.so
ଏକକାଂଶକୁ X ସର୍ଭରରେ ନଷ୍ଟକରିଥାଏ ତାହା ବର୍ତ୍ତମାନ ଠିକ ହୋଇସାରିଛି।
Xvnc ବର୍ତ୍ତମାନ GLX ଏବଂ RENDER ଅନୁଲଗ୍ନଗୁଡ଼ିକୁ ସମସ୍ତ ସଂରଚନାରେ ସମର୍ଥନ କରିଥାଏ।
smartmontools ସଂସ୍କରଣ 5.38ର୍ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ହାର୍ଡୱେର ଉପକରଣଗୁଡ଼ିକର ସ୍ୱୟଂଚାଳିତ ଚିହ୍ନଟକୁ ଉନ୍ନତତର କରିଥାଏ, CCISS RAID ଆରେ ପାଇଁ ସମର୍ଥନକୁ ଉନ୍ନତ କରିଥାଏ, ଏବଂ ସମର୍ଥିତ ଉପକରଣଗୁଡ଼ିକର ଗୋଟିଏ ବୃହତ ତଥ୍ୟାବଳୀକୁ ଦର୍ଶାଇଥାଏ।
ଏହି ଅଦ୍ୟତନ ଗୋଟିଏ ତ୍ରୁଟିକୁ ମଧ୍ଯ ଠିକ କରିଥାଏ ଯେଉଁଠି SELinux smartmontoolsକୁ 3ware RAID ଉପକରଣଗୁଡ଼ିକୁ ନିରିକ୍ଷଣ କରିବାରୁ ପ୍ରତିରକ୍ଷା କରିଥାଏ। smartmontools ବର୍ତ୍ତମାନ ଏହି ପରି ଉପକରଣଗୁଡ଼ିକୁ ସଠିକ ଭାବରେ ନିରିକ୍ଷଣ କରିପାରିବ।
python-urlgrabber ସଂସ୍କରଣ 3.1.0-5ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହା ଅପଷ୍ଟ୍ରିମରୁ ଅନେକ ତ୍ରୁଟି ନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ, ଅନ୍ୟ ମାନଙ୍କ ମଧ୍ୟରେ:
yum
ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ yum
ସଂଗ୍ରହାଳୟରୁ ପୁନଃ-ଆହୋରଣ କରିଥାଏ ଯାହାକି ଆଂଶିକ ଆହୋରଣକୁ ସମର୍ଥନ କରିଥାଏ।
yum
ବର୍ତ୍ତମାନ ବ୍ୟାହତପୂର୍ଣ୍ଣ ଆହୋରଣକୁ ପୁନର୍ଚାଳନ କରିପାରିବ, ଯଦିଚ yum
ସଂଗ୍ରହାଳୟଟି ଗୋଟିଏ FTP-ନିର୍ଦ୍ଦିଷ୍ଟ ସଂଯୋଗିକି ସହିତ ଆଧାରିତ।
ଉନ୍ନତି ଦଣ୍ଡଗୁଡ଼ିକର ଆକାର ବର୍ତ୍ତମାନ ଟର୍ମିନାଲ ଓସାର ପ୍ରତି ଗତିଶିଳ। ଏହା ସହିତ, ଉନ୍ନତି ଦଣ୍ଡଗୁଡ଼ିକ ବର୍ତ୍ତମାନ ଅପେକ୍ଷାକୃତ ସଫା, ଏବଂ ଆହରଣ କରାଯାଇଥିବା ସମସ୍ତ ତଥ୍ୟର କିଛି ପ୍ରତିଶତ ଦର୍ଶାଇଥାଏ।
python-urlgrabberର keepalive
ସଙ୍କେତ ବର୍ତ୍ତମାନ ସ୍ଥିର ହୋଇଯାଇଛି।ପୂର୍ବରୁ, ଆହରଣ ସମୟରେ ଏହି ସଙ୍କେତରେ ଗୋଟିଏ ତ୍ରୁଟି ଭୁଲ ଭାବରେ ସ୍ମୃତି ସ୍ଥାନ ବ୍ୟବହାରକୁ ବଢାଇଦେଇଥାଏ; ଏହା ସହିତ, ଏହି ତ୍ରୁଟିଟି ମଧ୍ଯ reposync ଏବଂ yumdownloaderକୁ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିବାରୁ ଅଟକାଇଥାଏ, ଯେତେବେଳେ ଅଧିକ ସଂଖ୍ଯକ ପ୍ୟାକେଜ ଆହରଣ କରୁଥାଏ।
yum-utils ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 1.1.16 କୁ ଅଦତନ ହୋଇଯାଇଛି। ଏହା ନିମ୍ନଲିଖିତ ବିଶେଷ ଗୁଣଗୁଡିକୁ ପ୍ରୟୋଗ କରେ (ଅନ୍ୟ ମାନଙ୍କ ମଧ୍ୟରେ):
yum update --security
ବର୍ତ୍ତମାନ ସଠିକ ଭାବରେ ସମସ୍ତ ସୁରକ୍ଷା ଅଦ୍ୟତନଗୁଡ଼ିକୁ ଚିହ୍ନିହେଉନାହିଁ
yum-versionlock
ବର୍ତ୍ତମାନ ପ୍ୟାକେଜ ଅଚଳ ପାଇଁ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିଥାଏ।
ଏହି ଅଦ୍ୟତନରେ yum-fastestmirror
ପ୍ଲଗଇନ ଅନ୍ତର୍ଭୁକ୍ତ, ଯାହାକି ପ୍ରତିବିମ୍ବ ତାଲିକାରେ ତୀବ୍ରତମ ସଂଗ୍ରହାଳୟକୁ yum ବାଛିଥାଏ।
Samba ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 3.2.0କୁ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହା ଅନେକ ତ୍ରୁଟିକୁ ଠିକ କରିଥାଏ, Windows 2003 କୁ ସେମାନଙ୍କର ନାମ ସର୍ଭର ଭାବରେ ବ୍ୟବହାର କରୁଥିବା ଡ଼ମେନକୁ ସଂଯୋଗ କରି ଚାଳକକୁ ଅଟକାଉଥିବା ତ୍ରୁଟିକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି। ଏହି ଅଦ୍ୟତନ samba ଡ଼ମେନ ସଦସ୍ୟତାକୁ net rpc changetrustpw
କୁ ବ୍ୟବହାର କରି ତନ୍ତ୍ର ପ୍ରବେଶ ସଂକେତକୁ ପରିବର୍ତ୍ତନ କରିସାରିବା ପରେ ଭାଙ୍ଗିଥାଏ।
ଅପଷ୍ଟ୍ରିମ samba ଅଦ୍ୟତନର ଏହି ପ୍ରକାଶନରେ ଅନ୍ତର୍ଭୁକ୍ତ କରାଯାଇଥିବା ଅଧିକ ବିସ୍ତୃତ ତାଲିକା ପାଇଁ, http://www.samba.org/samba/history/samba-3.0.32.htmlକୁ ଅନୁସରଣ କରନ୍ତୁ
OpenLDAP ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 2.3.43ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ନିମ୍ନଲିଖିତମାନଙ୍କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି ଏହା ଅନେକ ଅପଷ୍ଟ୍ରିମ ତ୍ରୁଟିନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ:
init
ସ୍କ୍ରିପ୍ଟ ବର୍ତ୍ତମାନ ଗୋଟିଏ ଚେତାବନୀ ଦେଇଥାଏ ଯଦିslapd
ଡେମନ TLS ପ୍ରମାଣପତ୍ର ଫାଇଲକୁ ପଢ଼ିନପାରେ।
openldap-debuginfo
ପ୍ୟାକେଜରେ ଥିବା ସମସ୍ତ ଲାଇବ୍ରେରୀ ବର୍ତ୍ତମାନ ଘୋଡ଼ାହୋଇନଥାଏ।
openldap-devel
ପ୍ୟାକେଜକୁ ବିସ୍ଥାପନ କରିବା ଦ୍ୱାରା ଏବେ ଆଉ OpenLDAP ଲାଇବ୍ରେରୀଗୁଡ଼ିକୁ ଭାଙ୍ଗିନଥାଏ।
Red Hat ବର୍ତ୍ତମାନ OpenLDAP ସର୍ଭର ପାଇଁ ଅତିରିକ୍ତ ଆଚ୍ଛାଦନ ବଣ୍ଟନ କରିଥାଏ। syncprov
ବ୍ୟତିତ, ସମସ୍ତ ଆଚ୍ଛାଦନଗୁଡ଼ିକୁ ପୃଥକ ପୃଥକ openldap-servers-overlays
ପ୍ୟାକେଜଗୁଡ଼ିକରେ ମିଳିଥିଲା, ଗତିଶିଳ ଭାବରେ ଧାରଣ କରିବା ଯୋଗ୍ୟ। syncprov
ଆଚ୍ଛାଦନ OpenLDAP ସର୍ଭର ପୁରୁଣା OpenLDAP ପ୍ରକାଶନଗୁଡ଼ିକ ସହିତ ସୁସଂଗତି ପରିଚାଳନା କରିବା ପାଇଁ ସଂଯୋଗ ହୋଇଥାଏ।
କାରଣ xterm
ବାଇନାରିରେ ସମୂହ ପରିଚୟ(setgid
) ବିଟ ବିନ୍ୟାସିତ ଥାଏ, କିଛି ପାରିବେଶିକ ପ୍ରାଚଳ(ଯେପରି କି LD_LIBRARY_PATH
ଏବଂ TMPDIR
) ଗୁଡ଼ିକ ସେଟ ହୋଇନଥାଏ। ଏହି ପ୍ରକାଶନରେ, xterm
ବାଇନାରି ବର୍ତ୍ତମାନ ଧାରା 0755
ଅନୁମତି ବିନ୍ୟାସିତ, ଯାହାକି ଏହି ସମସ୍ଯାକୁ ସମାଧାନ କରିଥାଏ।
NIS ସର୍ଭରରେ ଧାରଣକୁ ସମତୁଲ କରିବା ପାଇଁ ପରାମର୍ଶିତ ପଦ୍ଧତି ଯେତେବେଳେ ypbind ସହିତ ସଂଯୋଗ ହୋଇଥିବା ଏକାଧିକ ଯନ୍ତ୍ରଗୁଡ଼ିକ ଏହି ପ୍ରକାଶନରେ ପରିବର୍ତ୍ତିତ ହୋଇଥାଏ। ସେତେବେଳେypbind ଡ଼େମନର ଆଚରଣ ପରିବର୍ତ୍ତିତ ହୋଇନଥାଏ: ଏହା ଏବେବି /etc/ypbind
ବିନ୍ୟାସ ଫାଇଲରେ ତାଲିକାଭୁକ୍ତ ସମସ୍ତ NIS ସର୍ଭରକୁ ପିଙ୍ଗ କରିଥାଏ ଏବଂ ତାପରେ ଏକୁଟିଆ ତୀବ୍ରତମ-ଉତ୍ତର ଦେଉଥିବା ସର୍ଭର ସହିତ ବାନ୍ଧି ହୋଇଥାଏ। ପୂର୍ବରୁ, ସମସ୍ତ ଉପଲବ୍ଧ NIS ସର୍ଭରଗୁଡ଼ିକୁ ପ୍ରତ୍ୟେକ ଯନ୍ତ୍ରର /etc/ypbind.conf
ବିନ୍ୟାସ ଫାଇଲରେ ତାଲିକାଭୁକ୍ତ କରିବା ପାଇଁ ପରାମର୍ଶ ଦିଆଯାଇଥିଲା। ତଥାପି, ଅଧିକ ଭାର ଅନ୍ତର୍ଗତ ସର୍ଭରରେ ପିଙ୍ଗକୁ ଏହା ଅତିଶିଘ୍ର ଉତ୍ତର ଦେଇଥାଏ, ତେଣୁ ଅସାବଧାନତାରେ ସେମାନଙ୍କର ଭାର ବଢ଼ିଥାଏ, ଏହା ବର୍ତ୍ତମାନ ପ୍ରଶାସକଙ୍କୁ କ୍ଷୁଦ୍ରତର ସଂଖ୍ୟକ ଉପଲବ୍ଧ NIS ସର୍ଭରଗୁଡ଼ିକୁ ଗୋଟିଏ ଯନ୍ତ୍ରର ypbind.confରେ ତାଲିକାଭୁକ୍ତ କରିବାକୁ ପରାମର୍ଶ ଦେଇଥାଏ, ଏବଂ ଏହି ତାଲିକାକୁ ଯନ୍ତ୍ରଗୁଡ଼ିକ ମଧ୍ଯରେ ବଦଳାଇବା ପାଇଁ ପରାମର୍ଶ ଦେଇଥାଏ। ଏହି ପରି ଭାବରେ, NIS ସର୍ଭରଗୁଡ଼ିକ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଭାର ସମତୁଲ କରିଥାଆନ୍ତି ଯେହେତୁ ପ୍ରତ୍ଯେକ NIS ସର୍ଭର ସମସ୍ତ ଯନ୍ତ୍ର ପାଇଁ ଉପଲବ୍ଧ ବୋଲି ତାଲିକାଭୁକ୍ତ କରାଯାଇଛି।
OpenMotif ଅପଷ୍ଟ୍ରିମ ସଂସ୍କରଣ 2.3.1ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇସାରିଛି। ଏହି ଅଦ୍ୟତନ ଅନେକ ତ୍ରୁଟି ନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ, ଅନ୍ୟ ମାନଙ୍କ ମଧ୍ୟରେ:
OpenMotif ପଥରେ ଥିବା ଗୋଟିଏ ତ୍ରୁଟି Grab
ଏବଂUngrab
ଘଟଣାଗୁଡ଼ିକ ବର୍ତ୍ତମାନ ଠିକ ହୋଇସାରିଛି।ପୂର୍ବ ପ୍ରକାଶନଗୁଡ଼ିକରେ, ଏହି ତ୍ରୁଟି ପ୍ରଦର୍ଶକକୁ ଅପରିବର୍ତ୍ତିତ କରିଦେଇପାରେ।
nedit ରେ ଥିବା ଗୋଟିଏ ତ୍ରୁଟି nedit ଆଲେଖି ଚାଳକ ଅନ୍ତରାପୃଷ୍ଠକୁ ବ୍ୟବହାର କରୁଥିବା ସମୟରେ ଏହାକୁ ଖରାପ କରିଦେଇପାରେ। ଏହା ସଙ୍କେତରେ ଥିବା ଗୋଟିଏ ଫଳନ ଦ୍ୱାରା ଘଟିଥାଏ ଯାହାକି ବସ୍ତୁ ଚୟନର କିଛି କ୍ଷେତ୍ରରେ ବିଖଣ୍ଡନ ତ୍ରୁଟି ଘଟାଇଥାଏ, ଯାହାକି ବର୍ତ୍ତମାନ ସଂଶୋଧିତ ହୋଇସାରିଛି।
dbus ସଂସ୍କରଣ 1.1.2ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ଗୋଟିଏ ତ୍ରୁଟିକୁ ସଂଶୋଧନ କରିଥାଏ ଯେଉଁଠି ମଲ୍ଟି-ଥ୍ରେଡ଼େଡ଼ ପ୍ରଗ୍ରାମଗୁଡ଼ିକ dbusରେ ଗୋଟିଏ ଡ଼େଡ଼ଲକ ପକାଇଥାଏ। ପୂର୍ବ ପ୍ରକାଶନରେ, ଯେପରି ଗୋଟିଏ ଥ୍ରେଡ଼ dbusକୁ ଉତ୍ତର ଦେଇଥାଏ ଏବଂ ସନ୍ଦେଶ ସଞ୍ଚାଳନ କରିଥାଏ, ଦ୍ୱିତୀୟ ଥ୍ରେଡ଼ଟି dbusକୁ ସନ୍ଦେଶ ପଠାଇଥାଏ।
strace ସଂସ୍କରଣ 4.5.18ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଥାଏ। ନିମ୍ନଲିଖିତମାନଙ୍କୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି ଏହା ଅନେକ ତ୍ରୁଟିଗୁଡ଼ିକୁ ଠିକ କରିଥାଏ:
ଯେତେବେଳେ -f
ବିକଳ୍ପକୁ କିଛି ମଲ୍ଟି-ଥ୍ରେଡ଼େଡ଼ ପ୍ରଗ୍ରାମରେ ବ୍ୟବହାର କରାଯାଇଥାଏ ସେତେବେଳେ strace କୁ ଖରାପ କରୁଥିବା ଗୋଟିଏ ତ୍ରୁଟିକୁ ବର୍ତ୍ତମାନ ସଂଶୋଧନ କରାଯାଇଛି (ବିଶେଷ କରି 64-ବିଟ ତନ୍ତ୍ରରେ)।
32-ବିଟ ପ୍ରଣାଳୀ vfork()
ଫଳନକୁ ନିଷ୍ପାଦନ କରିବା ଦ୍ୱାରା strace 64-ବିଟ ସଂସ୍କରଣକୁ ପ୍ରତିରୋଧ କରୁଥିବା ଗୋଟିଏ ତ୍ରୁଟିକୁ ବର୍ତ୍ତମାନ ସଂଶୋଧନ କରାସରିଛି।
cpuspeed କୁ ସଂସ୍କରଣ 1.2.1-5କୁ ଅଦ୍ଯତିତ କରାଯାଇଛି। ଏହି ଅଦ୍ୟତନ ସହିତ, cpuspeed init
ସ୍କ୍ରିପ୍ଟ ବର୍ତ୍ତମାନ speedstep-centrino
ଏକକାଂଶକୁ ଧାରଣ କରିଥାଏ ଯଦି ସମସ୍ତ ଏକକାଂଶ ଧାରଣ ବିଫଳ ହୋଇଥାଏ। ଏହା ସହିତ, ଗୋଟିଏ ଚାଳକ-ସ୍ଥାନ ତ୍ରୁଟି ଯାହାକି Powernow-k8
ଏକକାଂଶକୁ ଧାରଣ କରିବାରୁ ପ୍ରତିରୋଧ କରିଥାଏ, ତାହା ବର୍ତ୍ତମାନ ସଂଶୋଧନ ହୋଇସାରିଛି।
frysk ରୂପକ ସାଧନଗୁଡ଼ିକୁ ଏହି ପ୍ରକାଶନରୁ ସମ୍ପୂର୍ଣ୍ଣ ଭାବରେ କଢ଼ାସରିଛି। frysk ପ୍ରକୃତରେ Red Hat Enterprise Linux 5.0ରେ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନ ଭାବରେ ପରିଚିତ ହୋଇଥାଏ।
ପୂର୍ବରୁ, iostat -x
ନିର୍ଦ୍ଦେଶ ଦ୍ୱାରା ପ୍ରଦତ୍ତ I/O ପରିସଂଖ୍ୟାନ ବିଭଜନଗୁଡ଼ିକ ଅସମ୍ପୂର୍ଣ୍ଣ ଅଛି। ଏହି ଅଦ୍ୟତନରେ, ବିଭାଜନ ସ୍ତରରେ ବିସ୍ତୃତ ଅନୁକୂଳ I/O ପରିସଂଖ୍ଯାନ ଏବଂ ବିସ୍ତୃତ ବିଭାଜନ ପରିସଂଖ୍ଯାନଗୁଡ଼ିକ ବର୍ତ୍ତମାନ ଡ଼ିସ୍କ ପରିସଂଖ୍ଯାନ ପରି ସମାନ ଉପାୟରେ ହିସାବ କରାଯାଇଥାଏ।
Dovecot ମେଲ ସର୍ଭର ପାଇଁ ବିନ୍ୟାସ ଫାଇଲ ସହିତ ଗୋଟିଏ ପ୍ରବେଶ ସଂକେତ ପ୍ରକାଶ ପ୍ରବାହ ମିଳିଥାଏ। ଯଦି ଗୋଟିଏ ତନ୍ତ୍ରରେ ssl_key_password
ବିକଳ୍ପ ବ୍ୟାଖ୍ଯା କରାଯାଇଥାଏ, ତେବେ ଯେକୌଣସି ସ୍ଥାନୀୟ ଚାଳକ SSL କି ପ୍ରବେଶ ସଂକେତକୁ ଦେଖିପାରିବେ (CVE-2008-4870)
ଏହି ପ୍ରବାହ ଆକ୍ରମଣକାରୀକୁ SSLକି ର ବିଷୟବସ୍ତୁ ଧାରଣ କରିବାର ଅନୁମତି ଦେଇନଥାଏ। ଏହି କି ବିନା ପ୍ରବେଶ ସଂକେତର କୌଣସି ମୂଲ୍ୟ ନଥାଏ ଯାହାକି ଆଜଣା ଚାଳକଙ୍କୁ ପ୍ରବେଶାନୁମତି ଦେଇଥାଏ।
ଏହି ମୂଲ୍ୟକୁ ସୁରକ୍ଷିତ କରି ମଧ୍ଯ, ଯଦି, dovecot.conf
ଫାଇଲ ବର୍ତ୍ତମାନ "!include_try" ଡ଼ିରେକ୍ଟିଭକୁ ସମର୍ଥନ କରିଥାଏ। ssl_key_password
ବିକଳ୍ପ dovecot.conf
ରୁ ଗୋଟିଏ ନୂତନ ଫାଇଲକୁ ପଠାଇଦେବା ଉଚିତ, ଏବଂ କେବଳ ମୂଖ୍ୟ ଚାଳକ (ଯେପରି କି 0600) ଦ୍ୱାରା ପଠନଯୋଗ୍ୟ ଏବଂ ଲିଖନଯୋଗ୍ୟ ହୋଇଥାଏ। ଏହି ଫାଇଲ dovecot.conf
ରୁ !include_try
ବିକଳ୍ପର ସନ୍ଦର୍ଭ ନେଇଥାଏ।
/path/to/password/file
ksh ସଂସ୍କରଣ 2008-02-02ରେ ପୁନଃ-ସ୍ଥାପିତ ହୋଇଛି। ଏହି ଅଦ୍ୟତନ ଏକାଧିକ ବାଇଟ ଅକ୍ଷର ନିୟନ୍ତ୍ରଣ, ଅନେକ କାର୍ଯ୍ୟ ନିୟନ୍ତ୍ରଣ ସମସ୍ୟାକୁ ଦର୍ଶାଇଥାଏ ଏବଂ ଅପଷ୍ଟ୍ରିମରୁ ଅନେକ ତ୍ରୁଟି ନିବାରଣକୁ ପ୍ରୟୋଗ କରିଥାଏ। ମନେରଖନ୍ତୁ ଯେ ଏହି ଅଦ୍ୟତନ ksh ସ୍ଥିତବାନ ସ୍କ୍ରିପ୍ଟଗୁଡ଼ିକ ପାଇଁ ସୁସଂଗତିକୁ ସଂରକ୍ଷଣ କରିଥାଏ।
ଗୋଟିଏ vmconvert
ତ୍ରୁଟି ଏହାକୁ vmur
ଉପକରଣ ନୋଡ (/dev/0.0.000c
)ରୁ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟକରିବାରୁ ଅଟକାଇଥାଏ। ଏହା vmconvert
କୁ vmur
ଉପକରଣରେ vmconvert: Open dump file failed! (Permission denied)
ତ୍ରୁଟି ସହିତ ଡମ୍ପଗୁଡ଼ିକ ମଧ୍ୟରେ ଅଭିଗମନ କରିବାକୁ ଚେଷ୍ଟାକରିବା ସମୟରେ ବିଫଳ ହୋଇଥାଏ। ଏହି ପ୍ରକାଶନରେ s390utils
ପାଇଁ ଗୋଟିଏ ଅଦ୍ୟତନ ଏହି ସମସ୍ୟାର ସମାଧାନ କରିଥାଏ।
mon_procd
ଡେମନ ଏବଂ mon_fsstatd
ଡେମନ ପାଇଁ init
ସ୍କ୍ରିପ୍ଟ ଏବଂ config
ଫାଇଲ s390utils
ପ୍ୟାକେଜରୁ ହଜିଯାଇଛି। ଫଳସ୍ୱରୂପ ଏହି ଡ଼େମନଗୁଡ଼ିକୁ ନିର୍ମାଣ ଏବଂ ବ୍ୟବହାର କରିହେବ ନାହିଁ। ହଜିଯାଇଥିବା ଫାଇଲଗୁଡ଼ିକୁ ଏହି ଅଦ୍ୟତନରେ ଯୋଗ କରାଯାଇଛି ଯାହାକି ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିଥାଏ।
ehci_hcd
ଏକକାଂଶକୁ ଏହି ସଂରଚନାରେ ଧାରଣ ହେବାରୁ ଅଟକାଉଥିବା ଗୋଟିଏ ତ୍ରୁଟିକୁ ବର୍ତ୍ତମାନ ଠିକ କରାସରିଛି। ଏହା ନିଶ୍ଚିତ ଯେ Belkin 4-port PCI-Express USB Lily ଏଡପଟର (ଏବଂ ଅନ୍ୟାନ୍ୟ ସମାନ ଉପକରଣଗୁଡ଼ିକୁ) ବର୍ତ୍ତମାନସଠିକ ଭାବରେ Red Hat Enterprise Linux 5 କାର୍ଯ୍ୟକରୁଅଛି ଯେତେବେଳେ ehci_hcd
ଏକକାଂଶକୁ ବ୍ୟବହାର କରନ୍ତି।
libhugetlbfs ଲାଇବ୍ରେରୀ ବର୍ତ୍ତମାନ ସଂସ୍କରଣ 1.3ରେ ପୁନଃ-ସ୍ଥାପିତ। ଏହି ଅଦ୍ୟତନ ଲାଇବ୍ରେରୀରେ ଅନେକ ଅପଷ୍ଟ୍ରିମ ଉନ୍ନତି ପ୍ରୟୋଗ କରିଥାଏ, ତାହାଦ୍ୱାରା ବହୁତ ପୃଷ୍ଠା ବ୍ୟବହାର କରୁଥିବା ପ୍ରୟୋଗର କ୍ଷମତାରେ ଉନ୍ନତି ହୋଇଥାଏ।
libhugetlbfs ପାଇଁ ଅଦ୍ୟତନର ଗୋଟିଏ ସମ୍ପୂର୍ଣ୍ଣ ତାଲିକା ପାଇବାକୁ, ନିମ୍ନଲିଖିତ ସଂଯୋଗକୁ ଅନୁସରଣ କରନ୍ତୁ:
http://sourceforge.net/mailarchive/message.php?msg_name=20080515170754.GA1830%40us.ibm.com
Red Hat Enterprise Linux 5.2ରେ, httpdର ଗୋଟିଏ 64-ବିଟ ସଂସ୍କରଣକୁ ଏହି ସଂରଚନାର 32-ବିଟ httpdରେ ଅନ୍ତର୍ଭୁକ୍ତ କରିଥାଏ। ଯଦି କୌଣସି ଚାଳକ ଉଭୟ ସଂସ୍କରଣକୁ ସ୍ଥାପନ କରିଥାଏ, ତେବେ httpdକୁ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟ କରିବାରୁ ପ୍ରତିରୋଧ କରି ଗୋଟିଏ httpd ଦ୍ୱନ୍ଦ ଘଟାଇଥାଏ।
ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିବା ପାଇଁ, httpdର 64-ବିଟ ସଂସ୍କରଣକୁ ଏହି ପ୍ରକାଶନରୁ କାଢ଼ିଦିଆଯାଇଛି। httpdକୁ ଏହି ପ୍ରକାଶନ ପାଇଁ ଉନ୍ନତତର କରିବା ଦ୍ୱାରା ସ୍ୱୟଂଚାଳିତ ଭାବରେ httpdର 64-ବିଟ ସଂସ୍କରଣକୁ ମଧ୍ଯ କାଢ଼ିଦେଇଥାଏ।
ମୂଖ୍ୟ ଚାଳକ ଫାଇଲତନ୍ତ୍ରକୁ ସଂଗୁପ୍ତ କରିବା ପାଇଁ ନୂତନ ଡ଼ିସ୍କ ସଂଗୁପ୍ତ ବିଶେଷଗୁଣ ବ୍ୟବହାର କରିବା ସମୟରେ, ତନ୍ତ୍ରକୁ ବନ୍ଦ କରିବା ସମୟରେ କୋନସୋଲରେ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ସନ୍ଦେଶଖବର କରାଯାଇଥାଏ:
ଡ଼ିସ୍କ ସଂଗୁପ୍ତକୁ ବନ୍ଦ କରୁଅଛି [ବିଫଳ]
ଏହି ସନ୍ଦେଶକୁ ସଫଳତାର ସହିତ ଅଗ୍ରାହ୍ୟ କରାଯାଇଛି, ବନ୍ଦ କରିବା ପଦ୍ଧତିଟି ସଫଳତାର ସହିତ ସମ୍ପୂର୍ଣ୍ଣ ହେବ।
ଗୋଟିଏ ସଂଗୁପ୍ତ ଉପକରଣ ବ୍ୟବହାର କରିବା ସମୟରେ, ବୁଟକରିବା ସମୟରେ ନିମ୍ନଲିଖିତତ୍ରୁଟି ସନ୍ଦେଶ ପରିଲକ୍ଷିତ ହୋଇଥାଏ:
insmod: ଭର୍ତ୍ତି କରିବା ସମୟରେ ତ୍ରୁଟି '/lib/aes_generic.ko': -1 ଫାଇଲ ଅବସ୍ଥିତଏହି ସନ୍ଦେଶକୁ ସୁରକ୍ଷିତ ଭାବରେ ଅଗ୍ରାହ୍ୟ କରାଯାଇପାରିବ।
ଏକାଧିକ ପଥ ଉପରେ ଏକାଧିକ ଉପକରଣ (MD) RAID ବ୍ୟବହାର କରି ସ୍ଥାପନା କରିବା ଫଳରେ ମେସିନ ବୁଟ ହୋଇନଥାଏ। ଭଣ୍ଡାର ଅଞ୍ଚଳ ନେଟୱର୍କ (SAN) ଉପକରଣକୁ ଏକାଧିକ ପଥ ଯାହାକି ଆଭ୍ୟନ୍ତରୀଣ ଭାବେ RAID ପ୍ରଦାନ କରିଥାଏ ତାହା କ୍ଷତିଗ୍ରସ୍ତ ହୋଇନଥାଏ।
ଯେତେବେଳେ ଗୋଟିଏ ବଡ଼ ସଂଖ୍ୟକ LUNକୁ ନୋଡରେ ଯୋଗ କରାଯାଇଥାଏ, ଏକାଧିକ ପଥ ମହତ୍ତ୍ୱପୂର୍ଣ୍ଣ ଭାବରେ udev ପାଇଁ ଉପକରଣ ନୋଡ ନିର୍ମାଣ କରିବା ପାଇଁ ଆବଶ୍ୟକ ସମୟକୁ ବଢାଇଥାଏ। ଯଦି ଆପଣ ଏହି ସମସ୍ୟାର ସମ୍ମୁଖିନ ହୁଅନ୍ତି, ତେବେ ଆପଣ ନିମ୍ନଲିଖିତ ଧାଡ଼ିକୁ ଅପସାରଣ କରି ଠିକ କରି ପାରିବେ/etc/udev/rules.d/40-multipath.rules
:
KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod | /bin/grep ^dm_multipath'", RUN+="/sbin/multipath -v0 %M:%m"ଏହି ଧାଡ଼ି udev କୁ ପ୍ରତ୍ୟେକ ଥରଉପକରଣ ଯୋଗ ହେବା ସମୟରେ multipathକୁ ବ୍ୟବହାର କରାଇଥାଏ। ଯଦିଚ ଏହି ଧାଡ଼ିକୁ ଅପସାରଣ କରିବା ସହିତ, multipathd ଏପର୍ଯ୍ୟନ୍ତ ସ୍ୱୟଂଚାଳିତ ଭାବରେ multipath ଉପକରଣ ନିର୍ମାଣ କରିନଥାଏ, ଏବଂ multipathକୁ ଏବେ ମଧ୍ୟ ଏକାଧିକ ପଥବିଶିଷ୍ଟ ମୂଖ୍ୟଚାଳକ ଫାଇଲତନ୍ତ୍ର ପାଇଁ ବୁଟ ପଦ୍ଧତି ସମୟରେ ଡକାଯାଇଥାଏ।
Red Hat Enterprise Linux 5.2 ର ବିଟା ପ୍ରକାଶନରୁ ଏହି GA ପ୍ରକାଶନକୁ ଉନ୍ନତତର କରିବା ସମୟରେ ଆପଣ ନିମ୍ନଲିଖିତ ତ୍ରୁଟିର ସମ୍ମୁଖିନ ହୋଇପାରନ୍ତି:
ଅଦ୍ୟତିତ କରୁଅଛି : mypackage ################### [ 472/1655] rpmdb: mutexକୁ ତାଲା ପକାଇବାରେ ଅସମର୍ଥ: ଅବୈଧ ସ୍ୱତନ୍ତ୍ରଚର
ତାଲା ପକାଇବା ସମସ୍ୟାଟି ହେଉଛି glibcରେ ତାଲା ପଡ଼ିଥିବା ସହଭାଗୀ futex ପ୍ରତି ପଦ୍ଧତିରେ 5.2 ରୁ 5.3କୁ ଉନ୍ନତତର ହୋଇଥିଲା। ଫଳସ୍ୱରୂପ, 5.2 glibc ବିପକ୍ଷରେ ଚାଲୁଥିବା ପ୍ରଗ୍ରାମ ସହଭାଗୀ futex ତାଲାକୁ 5.3 glibc ବିପକ୍ଷରେ ଚାଲୁଥିବା ପ୍ରଗ୍ରାମ ସହିତ ସଠିକ ଭାବରେ କାର୍ଯ୍ୟକାରୀ କରିପାରି ନଥାଏ।
ଏହି ନିର୍ଦ୍ଦିଷ୍ଟ ତ୍ରୁଟି ସନ୍ଦେଶଟି ହେଉଛି ସ୍ଥାପନ ସ୍କ୍ରିପ୍ଟଗୁଡ଼ିକର ଅଂଶ ଭାବରେ rpm ଡାକୁଥିବା ପ୍ୟାକେଜର ଗୋଟିଏ ପାର୍ଶ୍ୱ ପ୍ରଭାବ। ପୂର୍ବ glibcକୁ ସମଗ୍ର ଉନ୍ନୟନରେ ବ୍ୟବହାର କରି ଉନ୍ନୟନ କ୍ରିୟା କରୁଥିବା rpmର ସ୍ଥିତି, କିନ୍ତୁ ନୂତନ glibc ବ୍ୟବହାର କରି ସ୍କ୍ରିପ୍ଟରୁ ଆରମ୍ଭ ହୋଇଥିବା rpm ସ୍ଥିତି।
ଏହି ତ୍ରୁଟିକୁ ଏଡ଼ାଇବା ପାଇଁ, glibc କୁ ପ୍ରଥମେ ଗୋଟିଏ ଭିନ୍ନ ପ୍ରକ୍ରିୟାରେ ଉନ୍ନୟନ କରନ୍ତୁ:
# yum update glibc # yum updateଆପଣ ମଧ୍ଯ ଏହି ତ୍ରୁଟିକୁ ଦେଖିବେ ଯଦି ଆପଣ ସ୍ଥାପିତ 5.3 ତନ୍ତ୍ରର ପୂର୍ବ ସଂସ୍କରଣରେ glibcର ପଦନ୍ନତି କରନ୍ତି।
Red Hat Enterprise Linux 5ରେ mvapich
ଏବଂ mvapich2
କେବଳ InfiniBand/iWARP ଆଭ୍ୟନ୍ତରୀଣ ସଂଯୋଗକୁ ସମର୍ଥନ କରିବା ପାଇଁ ସଙ୍କଳନ କରାଯାଇଥାଏ। ଏହା ଫଳରେ, ସେମାନେ ଇଥରନେଟ କିମ୍ବା ଅନ୍ୟାନ୍ୟ ନେଟୱର୍କ ଆଭ୍ୟନ୍ତରୀଣ ସଂଯୋଗ ଉପରେ ଚାଲିନଥାନ୍ତି।
ଦୁଇରୁ ଅଧିକ ସଂଗୁପ୍ତ ବ୍ଲକ ଉପକରଣଗୁଡ଼ିକ ବିଶିଷ୍ଟ ତନ୍ତ୍ର ପାଇଁ, ଆନାକୋଣ୍ଡା ପାଖରେ ଗୋଟିଏ ଜାଗତିକ ପ୍ରବେଶ ସଂକେତ ପ୍ରଦାନ କରିବାର ବିକଳ୍ପ ଅଛି। init ସ୍କ୍ରିପ୍ଟ, ଯଦିଚ, ଏହି ବିଶେଷଗୁଣକୁ ସମର୍ଥନ କରିନଥାଏ। ତନ୍ତ୍ରକୁ ବୁଟ କରିବା ସମୟରେ, ସମସ୍ତ ସଂଗୁପ୍ତ ଉପକରଣ ପାଇଁ ପ୍ରତ୍ୟେକ ବ୍ୟକ୍ତିଗତ ପ୍ରବେଶ ସଂକେତ ଭରଣ କରିବା ଆବଶ୍ୟକ ହୋଇଥାଏ।
yum ବ୍ୟବହାର କରି openmpi କୁ ଉନ୍ନୟନ କରିବା ସମୟରେ, ନିମ୍ନଲିଖିତ ଚେତାବନୀ ଦେଖାଇପାରେ:
ପଢ଼ିବା ପାଇଁ `/tmp/openmpi-upgrade-version.*' କୁ ଖୋଲି ପାରିବ ନାହିଁ: ଏପରି କୌଣସି ଫାଇଲ କିମ୍ବା ଡ଼ିରେକ୍ଟୋରି ନାହିଁଏହି ସନ୍ଦେଶଟି କ୍ଷତିକାରକ ନୁହଁ ଏବଂ ସୁରକ୍ଷିତ ଭାବରେ ଅଗ୍ରାହ୍ୟ କରାଯାଇପାରିବ।
IRQ SMP ସାଦୃଶ୍ୟ ବିନ୍ୟାସ କରିବା ଦ୍ୱାରା କିଛି ଉପକରଣ ଉପରେ କୌଣସି ପ୍ରଭାବ ପଡ଼ିନଥାଏ, ଯେଉଁମାନେ MSI ପ୍ରତି-ଭେକ୍ଟର ମାସ୍କିଙ୍ଗ କ୍ଷମତା ବିନା ସନ୍ଦେଶ ସାଙ୍କେତିକ ବାଧା (MSI) ବ୍ୟବହାର କରିଥାନ୍ତି। ଏହି ଉପକରଣର ଉଦାହରଣରେ Broadcom NetXtreme ଇଥରନେଟ ଉପକରଣ ଅନ୍ତର୍ଭୁକ୍ତ ଯାହାକି bnx2
ଡ୍ରାଇଭର ବ୍ୟବହାର କରିଥାଏ।
ଯଦି ଆପଣ ଏହି ଉପକରଣ ପାଇଁ IRQ ସାଦୃଶ୍ୟକୁ ବିନ୍ୟାସ କରିବା ପାଇଁ ଚାହୁଁଛନ୍ତି, ତେବେ /etc/modprobe.d/
ରେ ନିମ୍ନଲିଖିତ ଧାଡ଼ି ଧାରଣ କରିଥିବା ଗୋଟିଏ ଫାଇଲ ନିର୍ମାଣ କରି MSI କୁ ନିଷ୍କ୍ରିୟ କରନ୍ତୁ:
ବିକଳ୍ପ bnx2 disable_msi=1
ବୈକଳ୍ପିକ ରୂପେ, ଆପଣ କର୍ଣ୍ଣଲ ବୁଟ ପ୍ରାଚଳ pci=nomsi
କୁ ବ୍ୟବହାର କରି MSI କୁ ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ ନିଷ୍କ୍ରିୟ କରିପାରିବେ।
Dell PowerEdge R905 ସର୍ଭରରେ ଥିବା CD-ROM/DVD-ROM ଏକକ Red Hat Enterprise Linux 5 ସହିତ କାର୍ଯ୍ୟ କରିନଥାଏ। ଅଧିକ ସୂଚନା ପାଇଁ ଦୟାକରି ଜ୍ଞାନ ଆଧାର #13121କୁ ଦେଖନ୍ତୁ: http://kbase.redhat.com/faq/FAQ_103_13121.
ଜ୍ଞାନ ଆଧାର ନିବନ୍ଧରେ ଉଲ୍ଲେଖ କରାଯାଇଥିବା ନିମ୍ନଲିଖିତ ପଦ୍ଧତି ଅନ୍ୟନ୍ୟ ସମସ୍ୟା ସୃଷ୍ଟି କରିପାରେ ଯାହାକି GSS ଦ୍ୱାରା ସମର୍ଥିତ ନୁହଁ।
ଅଦ୍ଯତନୀକୃତ /etc/udev/rules.d/50-udev.rules
ଫାଇଲରେ ଥିବା ତ୍ରୁଟି ୯ରୁ ଅଧିକ ସଂଖ୍ୟକ ନାମ ସହିତ ଟେପ ଯନ୍ତ୍ରଗୁଡିକ ନିମିତ୍ତ ସ୍ଥର ନାମ ଗୁଡିକର ସୃଷ୍ଟିକୁ ଅବରୋଧ କରେ। ଉଦାହରଣ ସ୍ୱରୂପ nst12
ସ୍ଥିର ନାମ ବିଶିଷ୍ଟ ଟେପ ଯନ୍ତ୍ର ସୃଷ୍ଟି ହେବ ନାହିଁ।
ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, /etc/udev/rules.d/50-udev.rules
ରେ ପ୍ରତ୍ଯେକ ଥର nst[0-9]
ର ଆବୃତି ପରେ ଗୋଟିଏ ତାରକା ଚିହ୍ନ (*) ଯୋଗ କରନ୍ତୁ।
smartctl
ସାଧନଟି ସଠିକଭାବରେ SMART ପ୍ରାଚଳ ଗୁଡିକୁ SATA ଯନ୍ତ୍ର ମାନଙ୍କରୁ ପଢିପାରେ ନାହିଁ।
openmpi
ଏବଂ lam
ର ପୂର୍ବ ସଂସ୍କରଣରେ ଥିବା ତ୍ରୁଟି ଏହି ପ୍ଯାକେଜ ଗୁଡିକର ଉନ୍ନୟନରେ ବାଧା ସୃଷ୍ଟି କରିପାରେ। ଏହି ତ୍ରୁଟି ନିମ୍ନଲିଖିତ ଭୁଲ ଗୁଡିକରେ ସ୍ପଷ୍ଟ ହୋଇଥାଏ (openmpi
କିମ୍ୱା lam
କୁ ଉନ୍ନତତର କରିବାକୁ ପ୍ରୟାସ କରିବା ସମୟରେ:
ତୃଟି: %preun(openmpi-[version]
) scriptlet failed, exit status 2
ଏହି ପ୍ରକାର, ଆପଣଙ୍କୁ ତାର ନୂତନ ସଂସ୍କରଣକୁ ସ୍ଥାପନ କରିବାକୁ ହେଲେ openmpi
ଏବଂ lam
ର ପୁରୁଣା ସଂସ୍କରଣକୁ ହାତରେ ହଟାଇବାକୁ ପଡିଥାଏ। ଏହା କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ rpm
ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରନ୍ତୁ:
rpm -qa | grep '^openmpi-\|^lam-' | xargs rpm -e --noscripts --allmatches
dm-multipath
କୁ ପ୍ରୟୋଗ କଲାବେଳେ, ଯଦି features "1 queue_if_no_path"
ଟି /etc/multipath.conf
ଦର୍ଶାଯାଇଥାଏ ତେବେ କୌଣସି ପ୍ରକ୍ରିୟା ଯିଏ I/O କୁ ନିର୍ଗତ କରୁଥାଏ ଅଟକି ଯାଇଥାଏ ଯେତେପର୍ଯ୍ୟନ୍ତ କି ଏକ ବା ଅଧିକ ପଥଗୁଡିକ ପୁଣିଥରେଜମାକରା ନ ଯାଇଛି।
ଏଥିରୁ ଦୁରେଇ ରହିବାପାଇଁ, no_path_retry
କୁ [N]
/etc/multipath.conf
(ଯେଉଁଠି
ଟି ତନ୍ତ୍ରର ଗୋଟିଏ ପଥରେ ବାରମ୍ୱାର ଭ୍ରମଣର ସଂଖ୍ୟାକୁ ବୁଝାଇଥାଏ) ରେ ସଜାଡନ୍ତୁ। ଯେତେବେଳେ ଆପଣ ଏହା କରୁଛନ୍ତି, [N]
/etc/multipath.conf
ରୁ features "1 queue_if_no_path"
ବିକଳ୍ପକୁ ହଟାଇ ଦିଅନ୍ତୁ।
ଆପଣଙ୍କୁ "1 queue_if_no_path"
ବ୍ୟବହାର କରିବା ଆବଶ୍ୟକ ଏବଂ ଏଠାରେ ଲେଖାଯାଇଥିବା ସମସ୍ୟାକୁ ଜାଣିବା ଦରକାର, ଗୋଟିଏ ନିର୍ଦ୍ଦିଷ୍ଟ LUN ପାଇଁ (ଯାହାପାଇଁ କୌଣସି ପଥ ଉପଲବ୍ଧ ନଥାଏ) ଚାଲୁଥିବା ସମୟରେ ନିତୀକୁ ସମ୍ପାଦନ କରିବାକୁ dmsetup
କୁ ବ୍ୟବହାର କରନ୍ତୁ।
ବ୍ୟାଖ୍ୟା କରିବା ପାଇଁ: dmsetup message
କୁ ଚଲାନ୍ତୁ, ଯେଉଁଠି [device]
0 "fail_if_no_path"
ଟି ହେଉଛି ଏକାଧିକ ଉପକରଣ ନାମ (ଉଦାହରଣ ସ୍ୱରୂପ [device]
mpath2
; ପଥ ଉଲ୍ଲେଖ କରନ୍ତୁ ନାହିଁ) ଯାହା ପାଇଁ ଆପଣ ନିତୀକୁ "queue_if_no_path"
ରୁ "fail_if_no_path"
କୁ ପରିବର୍ତ୍ତନ କରିବାକୁ ଚାହୁଁଛନ୍ତି।
ସମାନ କର୍ଣ୍ଣଲର ଏକାଧିକ ସ୍ଥାପିତ ସଂସ୍କରଣକୁ ସକ୍ରିୟ କରିବା ସମର୍ଥିତ ନୁହେଁ। ଅଧିକନ୍ତୁ, କର୍ଣ୍ଣଲ ଏକକାଂଶ ଗୁଡିକୁ ବିଶ୍ଳେଷଣ କରିଯାଉଥିବା ଉପୟରେ ଗୋଟିଏ ତୃଟି ସମୟ ସମୟରେ ଗୋଟିଏ ସମାନ କର୍ଣ୍ଣଲର ଏକାକାଂଶର ଗୋଟିଏ ପୂର୍ବ ସଂସ୍କରଣକୁ ସକ୍ରିୟ କରିଥାଏ।
Red Hat ପରାମର୍ଶିତ ଯେ ଆପଣ ଗୋଟିଏ ସ୍ଥାପିତ କର୍ଣ୍ଣଲ ଏକକାଂଶର ନୂତନ ସଂସ୍କରଣକୁ ସ୍ଥାପନ କରିବା ପୂର୍ବରୁ , ପୁରୁଣା ସଂସ୍କରଣଟିକୁ ପ୍ରଥମେ ଲିଭାଇଦେବା ଉଚିତ।
NFS ମୂଳ ଦ୍ବାରା ବିନ୍ଯାସିତ ଗୋଟିଏ IBM Bladecenter QS21 କିମ୍ବା QS22 ରେ kdump
କୁ ନିଷ୍ପାଦନ କଲେ, ଏହା ବିଫଳ ହୋଇଯିବ। ଏହାକୁ ଏଡାଇବା ପାଇଁ, /etc/kdump.conf
ରେ ଗୋଟିଏ NFS ଡମ୍ପ ଲକ୍ଷ୍ଯକୁ ଉଲ୍ଲେଖ କରନ୍ତୁ।
ଗୋଟିଏ ଡକିଙ୍ଗ ଷ୍ଟେସନକୁ ନିବୃତ କିମ୍ବା ପ୍ଲଗ-ଇନ କରିବା ସମୟରେ IBM T60 ସମ୍ପୂର୍ଣ୍ଣ ରୂପେ ବନ୍ଦ ହୋଇଯିବ। ଏହାକୁ ଏଡାଇବା ପାଇଁ, ଏହି ତନ୍ତ୍ରକୁ acpi_sleep=s3_bios
ସ୍ବତନ୍ତ୍ରଚର ଦ୍ବାରା ବୁଟ କରନ୍ତୁ।
IBM Bladecenter ପାଇଁ QLogic iSCSI Expansion Card ଇଥରନେଟ ଏବଂ iSCSI ଫଳକଗୁଡିକୁ ଦେଇଥାଏ। କାର୍ଡରେ କିଛି ଅଂଶ ଫଳନ ଦ୍ୱୟ ଦ୍ୱାରା ବଣ୍ଟା ଯାଏ। ଯଦିଚ, ପ୍ରଚଳିତ qla3xxx
ଏବଂ qla4xxx
ଡ୍ରାଇଭର ଇଥରନେଟ ଏବଂ iSCSI ଫଳନ କୁ ସମର୍ଥନ ଦେଇଥାଏ। ଉଭୟ ଡ୍ରାଇଭର ଇଥରନେଟ ଏବଂ iSCSI କୁ ଏକସଙ୍ଗେ ସମର୍ଥନ କରନ୍ତି ନାହିଁ।
ଏହି ସାମର୍ଥ ସୀମା କାରଣରୁ, ଲଗାତାର ରିସେଟ (କ୍ରମାନ୍ୱିତ ifdown
/ifup
ନିର୍ଦ୍ଦେଶ ଦ୍ୱାରା) ଯନ୍ତ୍ରକୁ ଅଟକାଇ ଦେଇପାରେ। ଏଥିରୁ ନିବୃତ୍ତି ପାଇବାକୁ ହେଲେ, ifup
ପରେ ଏବଂ ifdown
ପୂର୍ବରୁ ୧୦ ସେକଣ୍ଡର ବିରାମର ଅନୁମତି ଦିଅନ୍ତୁ। ପୁଣି, ifdown
ପରେ ଏବଂ ifup
ନିର୍ଗତ ପୂର୍ବରୁ ସେହି ସମାନ ୧୦ ସେକଣ୍ଡର ବିରାମ ନିଅନ୍ତୁ। ଏହି ଅନ୍ତରାଳ ଯେତେବେଳେ ଏକ ifup
ନିର୍ଗତ କରାଯାଏ ସେତେବେଳେ ସମସ୍ତ ଫଳନକୁ ସ୍ଥିର ଏବଂ ପୁଣି ଆରମ୍ଭ କରିବାକୁ ଯଥେଷ୍ଟ ସମୟ ଦେଇଥାଏ।
Cisco Aironet MPI-350 ବେତାର କାର୍ଡ ଥିବା ଲାପଟପ ଗୁଡିକ ତାର ସଂଯୋଜିତ ଇଥରନେଟ ସଂଯୋଗିକୀ ବ୍ଯବହାର କରି ଯେ କୌଣସି ନେଟୱାର୍କ ଆଧାରିତ ସ୍ଥାପନ ସମୟରେ ଗୋଟିଏ DHCP ଠିକଣା ପାଇବାକୁ ପ୍ରଚେଷ୍ଟା କରୁଥିବା ସମୟରେ ଅଟକି ଯାଇପାରନ୍ତି।
ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ଆପଣଙ୍କ ସ୍ଥାପନ ପାଇଁ ସ୍ଥାନୀୟ ମାଧ୍ଯମକୁ ବ୍ଯବହାର କରନ୍ତୁ। ପର୍ଯ୍ଯାୟକ୍ରମିକ ଭାବରେ, ସ୍ଥାପନ ପୂର୍ବରୁ ଲାପଟପର BIOS ରେ ଆପଣ ବେତାର କାର୍ଡକୁ ନିଷ୍କ୍ରିୟ କରିପାରିବେ (ସ୍ଥାପନ ସମାପ୍ତ ହେବା ପରେ ଆପଣ ବେତାର କାର୍ଡକୁ ପୁନଃ ସକ୍ରିୟ କରିପାରିବେ)।
Red Hat Enterprise Linux 5.3 ର ଏହି ସଂସ୍କରଣରେ /var/log/boot.log
କୁ ଲଗ କରୁଥିବା ବୁଟ ସମୟ ଉପଲବ୍ଧ ନାହିଁ।
ଯଦି X ଚାଲୁଅଛି ଏବଂ vesa ବ୍ଯତୀଥ ଅନ୍ଯ ଗୋଟିଏ ଡ୍ରାଇଭର ବ୍ଯବହାର କରୁଅଛି, ତାହାହେଲେ ତନ୍ତ୍ରଟି ସଫଳତାର ସହିତ ଗୋଟିଏ kexec
/kdump
କର୍ଣ୍ଣଲ ସହିତ ପୁନର୍ଚାଳିତ ହୋଇପାରିବ ନାହିଁ। ଏହି ସମସ୍ଯା କେବଳ ATI Rage XL ଆଲେଖୀକ ଚିପ-ସେଟରେ ଦେଖା ଯାଇଥାଏ।
ଯଦି X ଗୋଟିଏ ATI Rage XL ଦ୍ବାରା ସୁସଜ୍ଜିତ ତନ୍ତ୍ରରେ ଚାଲୁଅଛି, ତାହାହେଲେ ଗୋଟିଏ kexec
/kdump
କର୍ଣ୍ଣଲ ସହିତ ପୁନର୍ଚାଳନ କରିବା ପାଇଁ ଏହା vesa ଡ୍ରାଇଭର ବ୍ଯବହାର କରୁଅଛି ବୋଲି ନିଶ୍ଚିତ କରନ୍ତୁ।
nVidia CK804 ଚିପସେଟ ସ୍ଥାପିତ ଥିବା ଗୋଟିଏ ତନ୍ତ୍ରରେ Red Hat Enterprise Linux 5.2 ବ୍ଯବହାର କରିବା ସମୟରେ, ଆପଣ ନିମ୍ନଲିଖିତ କର୍ଣ୍ଣଲ ସନ୍ଦେଶ ମାନ ପାଇପାରନ୍ତି।
kernel: assign_interrupt_mode Found MSI capability kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
ଏହି ସନ୍ଦେଶଟି ଏହା ସୂଚୀତ କରୁଛି ଯେ କିଛି PCI-E ସଂଯୋଗିକୀ ଗୁଡିକ IRQ ମାନଙ୍କୁ ନିବେଦନ କରୁ ନାହାଁନ୍ତି। ଆହୁରି ମଧ୍ଯ, କୌଣସି ପରିସ୍ଥିତିରେ, ଏହି ସନ୍ଦେଶ ଗୁଡିକ ମେସିନର କାର୍ଯ୍ଯକଳାପକୁ ପ୍ରଭାବିତ କରନ୍ତି ନାହିଁ।
ଆପଣ ରୁଟ ଭାବରେ ଲଗଇନ ହୋଇଥିବା ସମୟରେ ଅପସାରଣ ଯୋଗ୍ଯ ଭଣ୍ଡାର ଉପକରଣ (ସି.ଡି. ଏବଂ ଡି.ଭି.ଡି. ପରି) ଗୁଡିକ ସ୍ବତଃ ମାଉଣ୍ଡ ହୁଅନ୍ତି ନାହିଁ। ତେଣୁ, ଆପଣଙ୍କୁ ଆଲେଖୀକ ଫାଇଲ ପରିଚାଳକ ଦ୍ବାରା ଉପକରଣ ମାନଙ୍କୁ ହସ୍ତକୃତ ଭାବରେ ମାଉଣ୍ଟ କରିବାକୁ ପଡିବ।
ବୈକଳ୍ପିକ ଭାବରେ, ଆପଣ ଗୋଟିଏ ଉପକରଣକୁ /media
ରେ ମାଉଣ୍ଟ କରିବା ପାଇଁ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ଚଳାଇ ପାରିବେ:
mount /dev/[device name]
/media
ଗୋଟିଏ ବିନ୍ଯାସ କରାଯାଇଥିବା ଫିଲଟରରୁ ଗୋଟିଏ LUN କୁ ଅପସାରଣ କରିବା ସମୟରେ, ପରିବର୍ତ୍ତନଟି ଆଧାରରେ ଦେଖାଯାଏ ନାହିଁ। ଏପରି ପରିସ୍ଥିତିରେ, dm-multipath
ବ୍ଯବହାର କରାଗଲେ lvm
ଅନନ୍ତକାଳ ପାଇଁ ଲଟକିଯିବ, କାରଣ LUN ବର୍ତ୍ତମାନ stale ହୋଇଯାଇଛି।
ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ସମସ୍ତ ଉପକରଣକୁ ଏବଂ ଅଟକିଥିବା LUN ନିର୍ଦ୍ଦିଷ୍ଟ /etc/lvm/.cache
ରେ ଥିବା mpath
ସଂଯୋଗ ପ୍ରବିଷ୍ଟି ମାନଙ୍କୁ ଅପସାରଣ କରନ୍ତୁ।
ଏହି ପ୍ରବିଷ୍ଟି ଗୁଡିକ କ'ଣ ବୋଲି ଜାଣିବା ପାଇଁ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ଚଳାନ୍ତୁ:
ls -l /dev/mpath | grep
[stale LUN]
ଉଦାହରଣ ସ୍ବରୂପ, ଯଦି
ଟି 3600d0230003414f30000203a7bc41a00 ଅଟେ, ତାହାହେଲେ ନିମ୍ନଲିଖିତ ପରିଣାମ ମିଳିପାରେ:
[stale LUN]
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
multipath
ନିର୍ଦ୍ଦେଶକୁ -ll
ବିକଳ୍ପ ସହିତ ଚାଳାଇବା ଦ୍ବାରା ଗୋଟିଏ ତାଳକିତ ଉପକରଣରେ ଗୋଟିଏ ପଥ ଥିଲେ, ଏହା ନିର୍ଦ୍ଦେଶକୁ ଅଟାକାଇ ଦେଇପାରେ। ଏହା ମନେ ରଖନ୍ତୁ ଯେ କିଛି ସମୟ ପରେ ଉପକରଣଟି ଉତ୍ତର ନ ଦେଲେ ଡ୍ରାଇଭର ଗୋଟିଏ ନିବେଦନକୁ ବିଫଳ କରେନାହିଁ।
ଏହା ସାଜ୍ଜିକରଣ ସଙ୍କେତ ଦ୍ବାରା ସୃଷ୍ଟି ହୋଇଛି, ଯାହାକି ପଥ ପରୀକ୍ଷକ ନିବେଦନ ସମ୍ପୂର୍ଣ୍ଣ କିମ୍ବା ବିଫଳ ହେବା ପର୍ଯ୍ଯନ୍ତ ଅପେକ୍ଷା କରିଥାଏ। ଏହା ପରିବର୍ତ୍ତେ ବର୍ତ୍ତମାନ ଉପସ୍ଥିତ ଥିବା multipath
ଅବସ୍ଥାକୁ ନିର୍ଦ୍ଦେଶକୁ ନ ଅଟକାଇ ପ୍ରଦର୍ଶନ କରିବା ପାଇଁ, multipath -l
ନିର୍ଦ୍ଦେଶକୁ ବ୍ଯବହାର କରନ୍ତୁ।
Red Hat Enterprise Linux 5.2 ବିଟା ସଂସ୍କରଣରୁ pm-utils
କୁ ଉନ୍ନୟନ କରିବା ସମୟରେ pm-utils
ବିଫଳ ହୋଇଯିବ, ଫଳସ୍ୱରୂପ ନିମ୍ନଲିଖିତ ତୃଟି ହୋଇଥାଏ:
ତୃଟି: ଫାଇଲ /etc/pm/sleep.d: cpio: rename ରେ ଅଭିଲେଖନକୁ ଖୋଲିବା ବିଫଳ
ଏପରି ହେବାରୁ ଅଟକାଇବା ପାଇଁ, ଉନ୍ନୟନ କରିବା ପୂର୍ବରୁ /etc/pm/sleep.d/
ଡିରେକ୍ଟୋରିକୁ ଅପସାରଣ କରନ୍ତୁ। /etc/pm/sleep.d/
କୌଣସି ଫାଇଲ ଧାରଣ କରିଥିଲେ, ଏହି ଫାଇଲକୁ /etc/pm/hooks/
କୁ ପଠାନ୍ତୁ।
Mellanox MT25204 ପାଇଁ ହାର୍ଡୱେର ପରିକ୍ଷାରୁ ଜଣାପଡିଛି ଯେ ଗୋଟିଏ ଆନ୍ତରିକ ତ୍ରୁଟି କିଛି ହାଇ-ଲୋଡ ସ୍ଥିତିର ଅନ୍ତର୍ଗତ ହୋଇଥାଏ। ଯେତେବେଳେ ib_mthca
ଚାଳକ ଗୋଟିଏ ବଡ ତ୍ରୁଟିକୁ ଏହି ହାର୍ଡୱେର ରେ ରିପଟ କରିଥାଏ, ଏହା ପ୍ରାୟ: ଉପଯୁକ୍ତ ଅନୁପ୍ରୟୋଗ ଦ୍ୱାରା ଉତ୍ପନ୍ନ ଶେଷ କାର୍ଯ୍ୟ ଆଗ୍ରହ ସଂଖ୍ୟାରେ ଉପର୍ୟାପ୍ତ ହୋଇଥାଏ।
ଯଦିଚ ଡ୍ରାଇଭରଟି ହାର୍ଡୱେରକୁ ରିସେଟ କରିବ ଏବଂ ଏପରି ଏକ ଘଟଣାରୁ ନିବୃତ୍ତି ପାଇବାକୁ ଚେଷ୍ଟା କରିବ, ତଥାପି ତ୍ରୁଟି ସମୟରେ ସମସ୍ତ ଅବସ୍ତତ ସଂଯୋଗ ନଷ୍ଟ ହୋଇଯିବ। ପରିଣାମ ସ୍ୱରୂପ ଏହା ସାଧାରଣତ ଚାଳକର ପ୍ରୟୋଗରେ ବିଖଣ୍ଡନ ତ୍ରୁଟି ଘଟାଇଥାଏ। ପୁନର୍ବାର ଯଦି ତ୍ରୁଟି ସମୟରେ opensm
ଚାଲୁଥାଏ ସେତେବେଳେ ଆପଣଙ୍କୁ ବିଧିବଦ୍ଧ ପ୍ରକ୍ରିୟା ପୁନଃ ଚାଳନ କରିବା ପାଇଁ ଏହାକୁ ହାତରେ ପୁନଃ ଆରମ୍ଭ କରନ୍ତୁ।
Red Hat Enterprise Linux 5କୁ ଅତିଥିରେ ସ୍ଥାପନ କରିବା ସମୟରେ, ଅତିଥି dom0
ଦ୍ୱାରା ଦିଆଯାଇଥିବା ଅସ୍ଥାୟୀ ସ୍ଥାପନ କର୍ଣ୍ଣଲକୁ ବ୍ୟବହାର କରିବା ପାଇଁ ବିନ୍ୟାସିତ ହୋଇଥାଏ। ଥରେ ସ୍ଥାପନ କ୍ରିୟା ସମାପ୍ତ ହେବା ପରେ, ଏହା ନିଜର ବୁଟଲୋଡର ବ୍ୟବହାର କରିପାରିବ। ଯଦିଚ, ଏହା କେବଳ ଅତିଥି'sର ପ୍ରଥମ ପୁନର୍ଚଳନକୁ ବାଧ୍ୟତାମୁଳକ ବନ୍ଦ କରିବା ଦ୍ୱାରା ହାସଲ ହୋଇପାରେ।
ସେହିପରି, ଯେତେବେଳେ ପୁନର୍ଚଳନ ବଟନ ଅତିଥି ସ୍ଥାପନ ଶେଷରେ ଦେଖାଯାଇଥାଏ, ସେତେବେଳେ ଏହାକୁ କ୍ଲିକ କରିବା ଦ୍ୱାରା ଅତିଥି ବନ୍ଦ ହୋଇଯାଏ, କିନ୍ତୁ ଏହାକୁ ପୁନର୍ଚଳନ କରିନଥାଏ। ଏହା ଗୋଟିଏ ଆଶାକରାଯାଇଥିବା ଆଚରଣ।
ମନେରଖନ୍ତୁ ଏହାପରେ ଯେତେବେଳେ ଆପଣ ଅତିଥିକୁ ବୁଟକରନ୍ତି ସେତେବେଳେ ଏହା ନିଜର ବୁଟଲୋଡରକୁ ବ୍ୟବହାର କରିଥାଏ।
rpmbuild
କୁ compiz
ରେ ଚଲାଇବା ଫଳରେ ଉତ୍ସ RPM ବିଫଳ ହୋଇଥାଏ ଯଦି କୌଣସି KDE କିମ୍ବା qt
ବିକାଶମୂଳକ ପ୍ୟାକେଜ (ଉଦାହରଣ ସ୍ୱରୂପ, qt-devel
) ସ୍ଥାପିତ ହୋଇଥାଏ। ଏହାcompiz
ବିନ୍ୟାସ ସ୍କ୍ରିପ୍ଟରେ ଥିବା ଗୋଟିଏ ତ୍ରୁଟି ଯୋଗୁଁ ହୋଇଥାଏ।
ଏହାର ସମାଧାନ ପାଇଁ, ଉତ୍ସ RPMରୁ compiz
ପ୍ୟାକେଜ ନିର୍ମାଣ କରିବାକୁ ଚେଷ୍ଟାକରିବା ପୂର୍ବରୁ ସେଥିରେ ଥିବା କୌଣସି KDE କିମ୍ବା qt
ବିକାଶମୂଳକ ପ୍ୟାକେଜକୁ କାଢ଼ି ଦିଅନ୍ତୁ।
ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ରରେ ATI Radeon R500 କିମ୍ବା R600 ଆଲେଖି କାର୍ଡ ଅଛି, ତେବେ ସ୍ଥାପନ ପରେ firstboot
ଚାଲିବ ନାହିଁ. ତନ୍ତ୍ର ସିଧାସଳଖ ଭାବରେ ଆଲେଖିକ ଲଗଇନ ପରଦାକୁ ଯାଇଥାଏ ଏବଂ ସମସ୍ତଙ୍କ ସହିତ firstboot
କୁ ଏଡ଼ାଇଯାଇଥାଏ। ଯଦି ଆପଣ firstboot
କୁ ହସ୍ତକୃତ ଭାବରେ ଚଲାଇବାକୁ ଚେଷ୍ଟାକରନ୍ତି (ଯେପରି, ଗୋଟିଏ ଫେଲସେଫ ଟର୍ମିନାଲରୁ), ତେବେ X ଅଧିବେଶନଟି ନଷ୍ଟ ହୋଇଯିବ।
ଏହି ସମସ୍ୟାଟି ATI Radeon R500/R600 ହାର୍ଡୱେର ଦ୍ୱାରା ବ୍ୟବହୃତ ଡ୍ରାଇଭର ଦ୍ୱାରା ଘଟିଥାଏ। ଏହି ଆଲେଖି କାର୍ଡ ଦ୍ୱାରା ବ୍ୟବହୃତ ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଡ୍ରାଇଭର ଏପର୍ଯ୍ୟନ୍ତ ପ୍ରଯୁକ୍ତି ବିଜ୍ଞାନ ପୂର୍ବାଲୋକନରେ ଅଛି। ଏହାର ସମାଧାନ ପାଇଁ, /etc/X11/xorg.conf
ଫାଇଲର ନକଳ ସଂରକ୍ଷଣ କରନ୍ତୁ; ତାପରେ ସମର୍ଥିତ vesa
ଡ୍ରାଇଭରକୁ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ବ୍ୟବହାର କରିବା ପରିବର୍ତ୍ତେ X କୁ ବିନ୍ୟାସ କରନ୍ତୁ:
system-config-display --reconfig --set-driver=vesa
ଆପଣ ବର୍ତ୍ତମାନ firstboot
କୁ ଚଲାଇ ପାରିବେ। ଆପଣଙ୍କର ପୂର୍ବ ବିନ୍ୟାସକୁ ପରିବର୍ତ୍ତିତ ହୋଇ ଯିବା ପାଇଁ, ଆପଣଙ୍କର ପ୍ରକୃତ /etc/X11/xorg.conf
କୁ ପୁନଃସ୍ଥାପନ କରନ୍ତୁ।
ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ର TSC ସମୟ ମାପକ ବ୍ୟବହାର କରୁଥାଏ, ତେବେ gettimeofday
ତନ୍ତ୍ର ଡ଼ାକରା ପଛକୁ ଯାଇଥାଏ। ଏହା ଅତିପ୍ରବାହ ସମସ୍ୟା ଦ୍ୱାରା ହୋଇଥାଏ ଯାହାଫଳରେ କିଛି କ୍ଷେତ୍ରରେ TSC ସମୟ ମାପକକୁ ଆଗକୁ ଡ଼େଇଁବାକୁ ପଡ଼ିଥାଏ, ଯେତେବେଳେ ଏହା ଘଟିଥାଏ, TSC ସମୟ ମାପକ ନିଜକୁ ଠିକ କରିନିଏ, କିନ୍ତୁ ଶେଷରେ ଗତିକୁ ପଛ ସମୟରେ ପଞ୍ଜୀକୃତ କରିଥାଏ।
ଏହି ସମସ୍ୟାଟି ନିର୍ଦ୍ଦିଷ୍ଟ ଭାବେ ସମୟ-ସମ୍ବେଦନଶୀଳ ତନ୍ତ୍ର ପାଇଁ ଗୁରୁତ୍ତ୍ୱପୂର୍ଣ୍ଣ, ଯେପରି କି, ଯେଉଁମାନଙ୍କୁ କାରବାର ତନ୍ତ୍ର ଏବଂ ତଥ୍ୟାଧାରରେ ବ୍ୟବହାର କରାଯାଉଥାଏ। ସେହିପରି, ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ର ସଠିକ ସମୟ ଆବଶ୍ୟକ କରୁଥାଏ, ତେବେ ଅନ୍ୟ ଏକ ସମୟ ମାପକ ବ୍ୟବହାର କରିବା ପାଇଁ କର୍ଣ୍ଣଲକୁ ବିନ୍ୟାସ କରିବା ପାଇଁ Red Hat ଆପଣଙ୍କୁ ଗୁରୁତ୍ତ୍ୱପୂର୍ଣ୍ଣ ଭାବରେ ସୁପାରିଶକରିଥାଏ (ଉଦାହରଣ ସ୍ୱରୂପ, HPET)।
sniff
କୁ ଚଲାଇବା ପାଇଁ ଚେଷ୍ଟାକଲେ ଫଳସ୍ୱରୂପ ତ୍ରୁଟି ଆସିବ। କାରଣ କିଛି ଆବଶ୍ୟକୀୟ ପ୍ୟାକେଜ ଗୁଡିକ dogtail
ସହିତ ସ୍ଥାପନ କରାଯାଇ ନଥିଲା।
ଏହାକୁ ଘଟିବାରୁ ଅଟକାଇବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପ୍ୟାକେଜ ଗୁଡିକୁ ହାତରେ ସ୍ଥାପନ କରନ୍ତୁ:
librsvg2
ghostscript-fonts
pygtk2-libglade
Thin Provisioning ("virtual provisioning" ନାମରେ ପରିଚିତ) ପ୍ରଥମେ EMC Symmetrix DMX3 ଏବଂ DMX4 ସହିତ ପ୍ରକାଶିତ ହେବ। ଅଧିକ ସୂଚନା ପାଇଁ ଦୟାକରି EMC Support Matrix ଏବଂ Symmetrix Enginuity ସଙ୍କେତ ପ୍ରକାଶନ ଟିପ୍ପଣୀକୁ ଅନୁସରଣ କରନ୍ତୁ।
/etc/multipath.conf
ରେ, max_fds
ରୁ unlimited
କୁ ବିନ୍ୟାସ multipathd
ଡେମନକୁ ଆରମ୍ଭ ହେବାରୁ ଅଟକାଇଥାଏ। ସେହିପରି, ଆପଣଙ୍କୁ ଏହି ବିନ୍ୟାସ ପରିବର୍ତ୍ତେ ଯଥେଷ୍ଟ ଉଚ୍ଚ ମୂଲ୍ୟର ବିନ୍ୟାସ ବ୍ୟବହାର କରିବା ଉଚିତ।
ଚାଳକ-ସ୍ଥାନ ଘଟଣାଗୁଡ଼ିକୁ ଅନୁସନ୍ଧାନ କରିବା ପାଇଁ SystemTap ବର୍ତ୍ତମାନ GCCକୁ ବ୍ୟବହାର କରିଥାଏ। ତଥାପି, ପ୍ରାଚଳଗୁଡ଼ିକ ପାଇଁ ନିର୍ଦ୍ଦିଷ୍ଟ ସ୍ଥାନ ତାଲିକା ସୂଚନା ସହିତ ତ୍ରୁଟି ନିବାରକମାନଙ୍କୁ ଯୋଗାଇବାରେ ଅସମର୍ଥ ହୋଇଥାଏ। କିଛି କ୍ଷେତ୍ରରେ, GCC ମଧ୍ଯ କିଛି ପ୍ରାଚଳରେ ଦୃଶ୍ୟମାନ୍ୟତା ଯୋଗାଇବାରେ ବିଫଳ ହୋଇଥାଏ। ଏହି କାରଣରୁ, SystemTap ସ୍କ୍ରିପ୍ଟ ଯାହାକି ଚାଳକ-ସ୍ଥାନ ଅନୁସନ୍ଧାନରେ ଭୁଲ ତଥ୍ୟ ପ୍ରଦାନ କରିଥାଏ।
IBM T41 ଲାପଟପ ମଡେଲ Suspend Mode କୁ ସଠିକ ଭାବରେ ଭରଣ କରେନାହିଁ; ସେହିପରି, Suspend Mode ଏପର୍ଯ୍ଯନ୍ତ ସାଧାରଣ ଭାବରେ ବ୍ୟାଟେରୀ ଜୀବନ ବ୍ୟବହାର କରୁଅଛି। Red Hat Enterprise Linux 5 ଏପର୍ଯ୍ୟନ୍ତ radeonfb
ଏକକାଂଶକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରିନଥିବାରୁ ଏହା ହୋଇଥାଏ।
ଏହାର ସମାଧାନ ପାଇଁ, hal-system-power-suspend
ନାମକ ଗୋଟିଏ ସ୍କ୍ରିପ୍ଚକୁ ନିମ୍ନଲିଖିତ ଧାଡ଼ି ଧାରଣ କରି/usr/share/hal/scripts/
ରେ ଯୋଗ କରନ୍ତୁ:
chvt 1 radeontool light off radeontool dac off
ଏହି ସ୍କ୍ରିପ୍ଟଟି ନିଶ୍ଚିତ କରେ ଯେ IBM T41 ଲାପଟପ ସଠିକ ଭାବରେନିଲମ୍ବନ ଅବସ୍ଥାକୁ ପ୍ରବେଶ କରିଥାଏ। ତନ୍ତ୍ରଟି ସାଧାରଣ ପ୍ରୟୋଗଗୁଡ଼ିକୁ ସଠିକ ଭାବରେ ପୁନଃ ଚଳନ କରୁଅଛି କି ନାହିଁ ନିଶ୍ଚିତ କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ଧାଡ଼ି ଧାରଣ କରି restore-after-standby
ସ୍କ୍ରିପ୍ଟକୁ ସେହି ଡ଼ିରେକ୍ଟୋରୀରେ ଯୋଗକରନ୍ତୁ:
radeontool dac on radeontool light on chvt 7
ଯଦି edac
ଏକକାଂଶକୁ ଧାରଣ କରାଯାଇଛି, BIOS ସ୍ମୃତି ସ୍ଥାନ ଖବରକରିବା କାର୍ଯ୍ୟ କରିନଥାଏ। edac
ଏକକାଂଶ ସ୍ମୃତି ସ୍ଥାନ ତ୍ରୁଟି ଖବର କରିବା ପାଇଁ BIOS ବ୍ୟବହାର କରୁଥିବା ବିବରଣ ପୁସ୍ତକକୁ ଲିଭାଇଦେବା କାରଣରୁ ହୋଇଥାଏ।
ପ୍ରଚଳିତ Red Hat Enterprise Linux ଡ୍ରାଇଭର ଅଦ୍ୟତନ ମଡେଲ କର୍ଣ୍ଣଲକୁ ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଭାବରେ ସମସ୍ତ ଉପଲବ୍ଧ ଏକକାଂଶଗୁଡ଼ିକୁ ଧାରଣ କରିବା ପାଇଁ ନିର୍ଦ୍ଦେଶ ଦେଇଥାଏ (edac
ଏକକାଂଶକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି)। ଯଦି ଆପଣ BIOS ସ୍ମୃତି ସ୍ଥାନ ଖବର କରିବାକୁ ଆପଣଙ୍କ ତନ୍ତ୍ରରେ ନିଶ୍ଚିତ କରିବାକୁ ଚାହୁଁଛନ୍ତି, ତେବେ ଆପଣଙ୍କୁ ହସ୍ତକୃତ ଭାବରେ edac
ଏକକାଂଶକୁ ବ୍ଲାକଲିଷ୍ଟ କରିବାକୁ ହେବ। ଏହା କରିବା ପାଇଁ, /etc/modprobe.conf
ରେ ନିମ୍ନଲିଖିତ ଧାଡ଼ିକୁ ଯୋଗ କରିବାକୁ ହେବ:
edac_mcକୁ ବ୍ଲାକଲିଷ୍ଟ କରନ୍ତୁ i5000_edacକୁ ବ୍ଲାକଲିଷ୍ଟ କରନ୍ତୁ i3000_edacକୁ ବ୍ଲାକଲିଷ୍ଟ କରନ୍ତୁ e752x_edacକୁ ବ୍ଲାକଲିଷ୍ଟ କରନ୍ତୁ
Red Hat Enterprise Linux 5.3 ନିମ୍ନରେ ଥିବା ବ୍ଲକ ଉପକରଣର ପ୍ରସାରଣ କିମ୍ବା ସଂକୋଚନକୁ ଅନଲାଇନ ନିରିକ୍ଷଣ କରିପାରିବ। ତଥାପି, ଗୋଟିଏ ଉପକରଣର ଆକାର ପରିବର୍ତ୍ତନକୁ ନିରିକ୍ଷଣ କରିବା ପାଇଁ କୌଣସି ସ୍ୱୟଂଚାଳିତ ପଦ୍ଧତି ନାହିଁ, ତେଣୁଁ ଏହାକୁ ଚିହ୍ନିବା ଏବଂ କୌଣସି ଫାଇଲତନ୍ତ୍ରର ଆକାର ପରିବର୍ତ୍ତନ ପାଇଁ ହସ୍ତକୃତ ପଦକ୍ଷେପଗୁଡ଼ିକ ଆବଶ୍ୟକ ଯାହାକି ପ୍ରଦତ୍ତ ଉପକରଣ(ଗୁଡ଼ିକ)ରେ ରହିଅଛି। ଯେତେବେଳେ ଗୋଟିଏ ପରିବର୍ତ୍ତିତ ବ୍ଲକ ଉପକରଣ ଚିହ୍ନା ପଡ଼ିଥାଏ, ସେତେବେଳେ ନିମ୍ନଲିଖିତ ପରି ଗୋଟିଏ ସନ୍ଦେଶ ତନ୍ତ୍ର ଲଗରେ ଦୃଶ୍ୟମାନ ହୋଇଥାଏ:
VFS: ପରିବର୍ତ୍ତିତ ମେଡ଼ିଆ କିମ୍ବା ପରିବର୍ତ୍ତିତ ଆକାର ଡ଼ିସ୍କ sdi ଉପରେ ବ୍ୟସ୍ତ inodeଗୁଡ଼ିକ
ଯଦି ବ୍ଲକ ଉପକରଣଗୁଡ଼ିକ ବଢ଼ିଯାଇଛି, ତେବେ ଏହି ସନ୍ଦେଶକୁ ନିରାପଦରେ ଅଗ୍ରାହ୍ୟ କରାଯାଇପାରିବ। ତଥାପି, ଯଦି ବ୍ଲକ ଉପକରଣରେ ସେଟକରାଯାଇଥିବା ତଥ୍ୟଗୁଡ଼ିକୁ ପ୍ରଥମେ ସଂକୋଚନ କରିବା ପରିବର୍ତ୍ତେ ନିଜେ ସଂକୁଚିତ ହୋଇଯାଏ, ତେବେ ସେଥିରେ ରହିଥିବା ତଥ୍ୟ ତ୍ରୁଟିଯୁକ୍ତ ହୋଇପାରନ୍ତି।
ଏହା କେବଳ ଫାଇଲତନ୍ତ୍ରର ଅନଲାଇନ ଆକାର ପରିବର୍ତ୍ତନ କରିବା ଦ୍ୱାରା ସମ୍ଭବ ଯାହାକି ସମଗ୍ର LUN (କିମ୍ବା ବ୍ଲକ ଉପକରଣ) ରେ ନିର୍ମିତ। ଯଦି ସେଠାରେ ଗୋଟିଏ ବିଭାଜନ ସାରଣୀ ଅଛି, ତେବେ ବିଭାଜନ ସାରଣୀକୁ ଅଦ୍ୟତିତ କରିବା ପାଇଁ ଫାଇଲତନ୍ତ୍ରକୁ ବିସ୍ଥାପନ କରିବାକୁ ହେବ।
ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ରରେ GFS2 ଫାଇଲ ତନ୍ତ୍ର ସ୍ଥାପିତ, ତେବେ ଗୋଟିଏ ନୋଡ ଅଟକି ଯାଇପାରେ ଯଦି ଗୋଟିଏ କ୍ୟାଶେ ବିଶିଷ୍ଟ inode କୁ ଗୋଟିଏ ନୋଡରେ ବ୍ୟବହାର କରିହୁଏ ଏବଂ ଭିନ୍ନ ଏକ ନୋଡରୁ ସଂଯୋଗ ବିଚ୍ଛିନ୍ନ ହୋଇଥାଏ। ଯେତେବେଳେ ଏହା ଘଟିଥାଏ, ସେତେବେଳ ବଳକା ନୋଡଟି ଉପଲବ୍ଧ ହୋଇନଥାଏ ଯେପର୍ଯ୍ୟନ୍ତ ଆପଣ ସାଧାରଣ କ୍ଲଷ୍ଟର ପୁନରୁଦ୍ଧାର ମେସିନ ମାଧ୍ୟମରେ ଏହାର ପୁନରୁଦ୍ଧାର ନକରିଛନ୍ତି। ଫଳନ ଡ଼ାକରା gfs2_dinode_dealloc
ଏବଂ shrink_dcache_memory
ମଧ୍ଯ ବଳକା ନୋଡରେ ଥିବା ପଦ୍ଧତି ଥାକରେ ଦୃଶ୍ୟମାନ ହୋଇଥାଏ।
ଏହି ସମସ୍ୟାଟି ଏକକ-ନୋଡ GFS2 ଫାଇଲତନ୍ତ୍ର ଉପରେ ପ୍ରଭାବ ପକାଇନଥାଏ।
ନିମ୍ନଲିଖିତ ସନ୍ଦେଶ ତନ୍ତ୍ର ବୁଟ ସମୟରେ ସମ୍ମୁଖିନ ହୋଇପାରେ:
10 ସେକଣ୍ଡ ଅପେକ୍ଷା କରି,ସ୍ଥିରତା ନିର୍ଦ୍ଧାରଣ କରିହେବ ନାହିଁ। ସମସ୍ତ ଭୌତିକ ଆକାରକୁ ପଢ଼ୁଅଛି। ଏହା ପାଇଁ କିଛି ସମୟ ଲାଗିପାରେ...ଏହି ବିଳମ୍ବ (ଯାହାକି 10 ସେକଣ୍ଡ ପର୍ଯ୍ୟନ୍ତ, ହାର୍ଡୱେର ବିନ୍ୟାସ ଉପରେ ନିର୍ଭର କରିଥାଏ) ତାହା କର୍ଣ୍ଣଲ ଡ଼ିସ୍କ ନିରିକ୍ଷଣ ସମ୍ପନ୍ନ କରିସାରିଛି ବୋଲି ନିଶ୍ଚିତ କରିବା ଆବଶ୍ୟକ ହୋଇଥାଏ।
ipmitoolରେ User Payload Accessର ସାମ୍ପ୍ରତିକ ପ୍ରୟୋଗ ଆପଣଙ୍କୁ ଉପକରଣ ବିନ୍ୟାସ କରିବାରେ ଅନୁମତି ଦେଇଥାଏ, କିନ୍ତୁ ଆପଣଙ୍କୁ ସେହି ଉପକରଣ ପାଇଁ ସାମ୍ପ୍ରତିକ ସଂରଚନା କାଢ଼ିବାକୁ ଅନୁମତି ଦିଏନାହିଁ।
swap --grow
ପ୍ରାଚଳକୁ କିକଷ୍ଟାର୍ଟ ଫାଇଲରେ --maxsize
ପ୍ରାଚଳକୁ ବିନ୍ୟାସ ନକରି ବ୍ୟବହାର କରିବା ଦ୍ୱାରା ସେହି ସମୟରେ ଆନାକୋଣ୍ଡାକୁ swap ବିଭାଜନର ସର୍ବାଧିକ ଆକାରକୁ ସିମୀତ ରଖିବାକୁ ବାଧ୍ଯ କରିଥାଏ। ଏହା ଉପକରଣକୁ ପୁରଣ କରିବା ପାଇଁ ବଢ଼ିବା ପାଇଁ ଅନୁମତି ଦେଇନଥାଏ।
2GBରୁ କମ ସ୍ମୃତି ସ୍ଥାନ ବିଶିଷ୍ଟ ତନ୍ତ୍ର ପାଇଁ, ପ୍ରଦତ୍ତ ସୀମା ହେଉଛି ଭୌତିକ ସ୍ମତି ସ୍ଥାନର ଦୁଇଗୁଣା। 2GBରୁ ଅଧିକ ତନ୍ତ୍ର ପାଇଁ, ପ୍ରଦତ୍ତ ସୀମା ହେଉଛି ଭୌତିକ ସ୍ମତି ସ୍ଥାନର ଆକାର ଯୁକ୍ତ 2GB।
gfs2_convert
ପ୍ରଗ୍ରାମ GFS ଅଧିତଥ୍ୟରୁ ସମସ୍ତ ବ୍ଲକକୁ ମୁକ୍ତ କରିନପାରେ ଯାହାକି ଏବେ ଆଉ GFS2 ଅନ୍ତର୍ଗତରେ ବ୍ୟବହାର ହେଉନାହିଁ। ଏହି ଅବ୍ୟବହୃତ ଅଧିତଥ୍ୟ ବ୍ଲକଗୁଡ଼ିକୁ ଆବିଷ୍କାର କରାଯିବ ଏବଂ ପରବର୍ତ୍ତି ଥର ଫାଇଲ ତନ୍ତ୍ରରେ gfs2_fsck ଚାଲୁଥିବା ସମୟରେ ମୁକ୍ତ କରିଦିଆଯିବ। ଏହା ପରାମର୍ଶିତ ଯେgfs2_fsck
ଫାଇଲତନ୍ତ୍ର ପଛରେ ଚାଲୁଥିବା ଦ୍ୱାରା ଅବ୍ୟବହୃତ ବ୍ଲକଗୁଡ଼ିକ ମୁକ୍ତ ହୋଇଥାଏ।ଏହି ଅବ୍ୟବହୃତ ବ୍ଲକଗୁଡ଼ିକ ନିମ୍ନଲିଖିତ ସନ୍ଦେଶ ପରି gfs2_fsck ଦ୍ୱାରା ଚିହ୍ନିତ ହୋଇଥାଏ:
Ondisk ଏବଂ fsck bitmaps ବ୍ଲକ 137 (0x89)ରେ ପୃଥକ ହୋଇଥାଏ Ondisk ସ୍ଥିତ 1 ଅଟେ(ତଥ୍ୟ) କିନ୍ତୁ FSCK ଭାବେ ଏହା 0 ହେବା ଉଚିତ(ମୁକ୍ତ) ଅଧିତଥ୍ୟ ପ୍ରକାର 0 ଅଟେ(ମୁକ୍ତ)ଏହି ସନ୍ଦେଶଗୁଡ଼ିକ GFS2 ଫାଇଲ ତନ୍ତ୍ରରେ ଥିବା ତ୍ରୁଟିକୁ ଇଙ୍ଗିତ କରେନାହିଁ, ସେମାନେ ମୁକ୍ତି ପାଇବା ଯୋଗ୍ୟ ବ୍ଲକକୁ ଇଙ୍ଗିତ କରୁଥାଏ, କିନ୍ତୁ କରୁନଥାଏ। ମୁକ୍ତି ଆବଶ୍ୟକ କରୁଥିବା ବ୍ଲକ ସଂଖ୍ୟା ଫାଇଲତନ୍ତ୍ର ଏବଂ ବ୍ଲକ ଆକାର ଉପରେ ନିର୍ଭରଶୀଳ। ଅନେକ ଫାଇଲତନ୍ତ୍ର କଦାପି ଏହି ସମସ୍ୟାର ସମ୍ମୁଖିନ ହୋଇନାହାନ୍ତି। ବୃହତ ଫାଇଲତନ୍ତ୍ରରେ ଛୋଟ ସଂଖ୍ୟକ ବ୍ଲକଗୁଡ଼ିକ ଥାଇପାରେ (ପାରମ୍ପରିକ ଭାବେ 100ରୁ କମ)।
ଖାଲି ଧାତୁ ବିଶିଷ୍ଟ (ଆଭାସୀକୃତ ବିହୀନ) କର୍ଣ୍ଣଲ ଚଳାଉଥିବା ସମୟରେ, X ସେବକ ପ୍ରଦର୍ଶିକାରୁ EDID
ସୂଚନା ପୁନରୁଦ୍ଧାର କରି ନ ପାରେ। ଏହା ଘଟିବା ସମୟରେ, ଆଲେଖୀ ଡ୍ରାଇଭର 800x600 ରୁ ଅଧିକ ବିଭେଦନକୁ ପ୍ରଦର୍ଶନ କରିବାରେ ଅସମର୍ଥ ହେବ।
ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, /etc/X11/xorg.conf
ର ServerLayout
ବିଭାଗରେ ନିମ୍ନଲିଖିତ ଧାଡିକୁ ଯୋଗକରନ୍ତୁ:
Option "Int10Backend" "x86emu"
ଲିପିବଦ୍ଧ କରିବା ପଦ୍ଧତିକୁ Dell M4300 ଏବଂ M6300 ରେ ହାତରେ ସକ୍ରିୟ କରିବାକୁ ପଡ଼ିଥାଏ। ଏହାକୁ କାର୍ଯ୍ୟକାରୀ କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପଗୁଡ଼ିକୁ ପାଳନ କରନ୍ତୁ:
alsamixer
କୁ ଖୋଲନ୍ତୁ।
[Capture] କୁ View କ୍ଷେତ୍ରରେ (ତାଲିକାର ଉପର ବାମପଟ ଅଂଶରେ ଦୃଶ୍ୟମାନ)ଆଗପଛ କରିବା ପାଇଁ Tab ଦବାନ୍ତୁ।
Space ଦଣ୍ଡକୁ ଦବାନ୍ତୁ।
ଅନୁଲିପିଟି ସକ୍ରିୟ ଅଛି ବୋଲି ଯାଞ୍ଚକରିବା ପାଇଁ, ADCMux
କ୍ଷେତ୍ର ଉପରେ ଥିବା ପାଠ୍ୟ L R CAPTUR
ଦର୍ଶାଉଥିବା ଉଚିତ।
ତନ୍ତ୍ର ସ୍ଥାପନା ସମୟରେ ଯଦି ବୁଟ ଉପକରଣରେ ସଂଗୁପ୍ତକୁ ସକ୍ରିୟ କରାଯାଇଛି, ତେବେ ତନ୍ତ୍ରବୁଟ ସମୟରେ ନିମ୍ନଲିଖିତ ସନ୍ଦେଶଗୁଡ଼ିକୁ ଲଗ କରାଯାଇପାରିବ:
padlock: VIA PadLock ଚିହ୍ନା ପଡ଼ିନଥାଏ।ଏହି ସନ୍ଦେଶକୁ ସୁରକ୍ଷିତ ଭାବରେ ଅଗ୍ରାହ୍ୟ କରାଯାଇପାରିବ।
NVIDIA ଆଲେଖୀ କାର୍ଡ ବ୍ଯବହାର କରୁଥିବା କିଛି ମେସିନ ଗୋଟିଏ ଆଲେଖୀକ ଲଗଇନ ବ୍ଯବହାର କରିବା ସମୟରେ ବିକୃତ ଆଲେଖୀ କିମ୍ବା ଅକ୍ଷର ରୂପ ପ୍ରଦର୍ଶନ କରିପାରନ୍ତି। ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ଗୋଟିଏ ଆଲେଖୀକ କୋନଶୋଲକୁ ସୁଇଚ କରନ୍ତୁ ଏବଂ ତାପରେ ପୁନର୍ବାର ସ୍ବାଭାବିକ X ଆଧାରକୁ ପ୍ରତ୍ଯାବର୍ତ୍ତନ କରନ୍ତୁ।
ଗୋଟିଏ IBM T61 ଲାପଟପରେ, glxgears
ୱିଣ୍ଡୋକୁ କ୍ଲିକ କରି କାର୍ଯ୍ୟରୁ ନିବୃତ ହେବା ପାଇଁ (ଯେତେବେଳେ glxgears
ଚାଲେ) Red Hat ସୁପାରିଶ କରିଥାଏ। ଏହା କରିବା ଦ୍ୱାରା ତନ୍ତ୍ରକୁ ଅପରିବର୍ତ୍ତନୀୟ କରାଯାଇପାରେ।
ଏହାକୁ ଘଟିବାରୁ ଅଟକାଇବା ପାଇଁ, tilling ବିଶେଷ ଗୁଣକୁ ନିଷ୍କ୍ରିୟ କରନ୍ତୁ। ଏହା କରିବା ପାଇଁ, /etc/X11/xorg.conf
ର Device
ବିଭାଗରେ ନିମ୍ନଲିଖିତ ଧାଡ଼ିକୁ ଯୋଗ କରନ୍ତୁ:
ବିକଳ୍ପ "Tiling" "0"
ଲିପିବଦ୍ଧ କରିବା ପଦ୍ଧତିକୁ Dell M4300 ଏବଂ M6300 ରେ ହାତରେ ସକ୍ରିୟ କରିବାକୁ ପଡ଼ିଥାଏ। ଏହାକୁ କାର୍ଯ୍ୟକାରୀ କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପଗୁଡ଼ିକୁ ପାଳନ କରନ୍ତୁ:
alsamixer
କୁ ଖୋଲନ୍ତୁ।
[Capture] କୁ View କ୍ଷେତ୍ରରେ (ତାଲିକାର ଉପର ବାମପଟ ଅଂଶରେ ଦୃଶ୍ୟମାନ)ଆଗପଛ କରିବା ପାଇଁ Tab ଦବାନ୍ତୁ।
Space ଦଣ୍ଡକୁ ଦବାନ୍ତୁ।
ଅନୁଲିପିଟି ସକ୍ରିୟ ଅଛି ବୋଲି ଯାଞ୍ଚକରିବା ପାଇଁ, ADCMux
କ୍ଷେତ୍ର ଉପରେ ଥିବା ପାଠ୍ୟ L R CAPTUR
ଦର୍ଶାଉଥିବା ଉଚିତ।
ଯଦି ଆପଣଙ୍କର ତନ୍ତ୍ର Intel 945GM ଆଲେଖୀ କାର୍ଡ ବ୍ୟବହାର କରୁଥାଏ, ତେବେ i810
ଡ୍ରାଇଭର ବ୍ୟବହାର କରନ୍ତୁ ନାହିଁ। ଆପଣଙ୍କୁ ଏହା ବ୍ୟତିତ ପୂର୍ବନିର୍ଦ୍ଧାରିତ intel
ଡ୍ରାଇଭର ବ୍ୟବହାର କରିବା ଉଚିତ।
dual-GPU ଲାପଟପଗୁଡ଼ିକରେ, ଯଦି ଗୋଟିଏ ଆଲେଖୀ ଚିପ Intel-ଆଧାରିତ ହୋଇଥାଏ, ତେବେ Intel ଆଲେଖୀ ଧାରା କୌଣସି ବାହ୍ୟ ଡିଜିଟାଲ ସଂଯୋଗକୁ ଚଲାଇପାରି ନଥାଏ (HDMI, DVI, ଏବଂ DisplayPortକୁ ଅନ୍ତର୍ଭୁକ୍ତ କରି)। ଏହି Intel GPUର ଗୋଟିଏ ହାର୍ଡ଼ୱେର ସୀମା। ଯଦି ଆପଣ ବାହ୍ୟ ଡିଜିଟାଲ ସଂଯୋଗଗୁଡ଼ିକୁ ଆବଶ୍ୟକ କରନ୍ତି, ତେବେ (BIOSରେ) ବିବିକ୍ତ ଆଲେଖୀ ଚିପ ବ୍ୟବହାର କରିବା ପାଇଁ ତନ୍ତ୍ରକୁ ବିନ୍ୟାସ କରନ୍ତୁ।
ତୃଟିମୁକ୍ତ କରିବା ପାଇଁ Alt-SysRq-W ବ୍ଯବହାର କରିବା ସମୟରେ, ନିମ୍ନଲିଖିତ ଚେତାବନୀ ସନ୍ଦେଶ ମିଳିବ:
arch/powerpc/kernel/smp.c:223 ରେ ଥିବା smp_call_function ରେ ତୃଟି
ପରବର୍ତ୍ତୀ ସମୟରେ, ତନ୍ତ୍ରଟି ଲଟକିଯିବ ବୋଲି ମଧ୍ଯ ଚେତାବନୀ ଦେବ। ଏହି ସନ୍ଦେଶକୁ ଏଡାଇ ଦେବା ଉଚିତ କାରଣ ଏହା ତନ୍ତ୍ରକୁ ଲଟକାଇବ ନାହିଁ।
ଲିପିବଦ୍ଧ କରିବା ପଦ୍ଧତିକୁ Dell M4300 ଏବଂ M6300 ରେ ହାତରେ ସକ୍ରିୟ କରିବାକୁ ପଡ଼ିଥାଏ। ଏହାକୁ କାର୍ଯ୍ୟକାରୀ କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପଗୁଡ଼ିକୁ ପାଳନ କରନ୍ତୁ:
alsamixer
କୁ ଖୋଲନ୍ତୁ।
[Capture] କୁ View କ୍ଷେତ୍ରରେ (ତାଲିକାର ଉପର ବାମପଟ ଅଂଶରେ ଦୃଶ୍ୟମାନ)ଆଗପଛ କରିବା ପାଇଁ Tab ଦବାନ୍ତୁ।
Space ଦଣ୍ଡକୁ ଦବାନ୍ତୁ।
ଅନୁଲିପିଟି ସକ୍ରିୟ ଅଛି ବୋଲି ଯାଞ୍ଚକରିବା ପାଇଁ, ADCMux
କ୍ଷେତ୍ର ଉପରେ ଥିବା ପାଠ୍ୟ L R CAPTUR
ଦର୍ଶାଉଥିବା ଉଚିତ।
PPC କର୍ଣ୍ଣଲ ପ୍ରତିଛବିର ଆକାର OpenFirmware କୁ ସମର୍ଥନ ଦେବା ପାଇଁ ଅତ୍ୟଧିକ ବଡ଼। ଫଳସ୍ୱରୂପ, ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ସନ୍ଦେଶ ପ୍ରଦାନ କରି, ନେଟୱର୍କ ବୁଟିଙ୍ଗ ବିଫଳ ହୋଇଥାଏ:
ଦୟାକରି ଅପେକ୍ଷା କରନ୍ତୁ, କର୍ଣ୍ଣଲ ଧାରଣ କରୁଅଛି... /pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: ଏହିପରି କୌଣସି ଫାଇଲ କିମ୍ବା ଡ଼ିରେକ୍ଟୋରୀ ନାହିଁ boot:ଏହାର ସମାଧାନ ପାଇଁ:
'8' କି କୁ ଦବାଇ OpenFirmware ପ୍ରମ୍ପଟକୁ ବୁଟ କରନ୍ତୁ,ଯେତେବେଳେ IBM splash ପରଦାକୁ ଦର୍ଶାଯାଇଥାଏ।
ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ଚଲାନ୍ତୁ:
setenv real-base 2000000
ନିର୍ଦ୍ଦେଶ ସହାୟତାରେ ତନ୍ତ୍ର ପରିଚାଳନା ସର୍ଭିସ (SMS)ରେ ବୁଟ କରନ୍ତୁ:
0 > dev /packages/gui obe
Red Hat Enterprise Linux 5.2 କୁ z/VM ରେ ଚଲାଇବା ସମୟରେ ଯାହାକି 2GB ଅତିଥି ଭଣ୍ଡାର ପରିଭାସିତରୁ ଅଧିକ ଥାଏ, ଅବୈଧ ତଥ୍ୟକୁ ପଢିପାରେ ଏବଂ ଏଥିରୁ QDIO ଆଧାରିତ ଧାଡିରେ ଥିବା I/O ସହାୟକ (QIOASSIST) ବିକଳ୍ପ ସକ୍ରିୟ ସହିତ ସଂଲଗ୍ନ ଯେକୌଣସି FCP ଏବଂ OSA ଯନ୍ତ୍ରରେ ଲେଖିପାରେ। ଯଦି ଆପଣଙ୍କ ତନ୍ତ୍ର ଏପରି କୌଣସି ଯନ୍ତ୍ର ସହିତ ସଂଲଗ୍ନ ହୋଇଥାଏ, ତେବେ Red Hat ପରାମର୍ଶ ଦିଏ ଯେ ଆପଣ ନିମ୍ନଲିଖିତ ସଂଯୋଗରୁ ଅନୁରୁପ z/VM ପ୍ରଗ୍ରାମ ଟେମ୍ପରାରି ଫିକ୍ସ (PTF) କୁ ଆହରଣ ଏବଂ ସ୍ଥାପନ କରନ୍ତୁ:
ଗୋଟିଏ z/VM ଡମ୍ପକୁ ଗୋଟିଏ ଫାଇଲରେ ସିଧାସଳଖ ପଢିବା କିମ୍ବା ରୂପାନ୍ତରିତ କରିବା ସମ୍ବବ ନୁହେଁ। ଏହା ପରିବର୍ତ୍ତେ, ଆପଣ ପ୍ରଥମେ vmur
ନିର୍ଦ୍ଦେଶ ବ୍ଯବହାର କରି z/VM ପାଠକରୁ ଡମ୍ପକୁ ଗୋଟିଏ Linux ଫାଇଲ ତନ୍ତ୍ରକୁ ନକଲ କରନ୍ତୁ ଏବଂ vmconvert
ନିର୍ଦ୍ଦେଶ ବ୍ଯବହାର କରି ଡମ୍ପକୁ ଗୋଟିଏ Linux ପଠନୀୟ ଫାଇଲରେ ରୂପାନ୍ତରିତ କରନ୍ତୁ।
IBM System z ଗୋଟିଏ ପାରମ୍ପରିକ Unix ଶୈଳୀର ଭୌତିକ କୋନଶୋଲ ପ୍ରଦାନ କରେ ନାହିଁ। ଯେପରିକି, ପ୍ରାରମ୍ଭିକ ପ୍ରୋଗ୍ରାମ ଧାରଣ ସମୟରେ Red Hat Enterprise Linux 5.2 IBM System z ପାଇଁ firstboot କୁ ସମର୍ଥନ କରେ ନାହିଁ।
IBM System z, ତନ୍ତ୍ରରେ Red Hat Enterprise Linux 5.2 ର ବ୍ଯବସ୍ଥାପନ ପ୍ରକ୍ରିୟାକୁ ସଠିକ ଭାବରେ ପ୍ରାରମ୍ଭିକରଣ କରିବା ପାଇଁ, ସ୍ଥାପନ ପରେ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶ ମାନଙ୍କୁ ଚଳାନ୍ତୁ:
/usr/bin/setup
-- setuptool
ପ୍ଯାକେଜ ଦ୍ବାରା ପ୍ରଦାନ କରାଯାଇଛି।
/usr/bin/rhn_register
-- rhn-setup
ପ୍ଯାକେଜ ଦ୍ବାରା ପ୍ରଦାନ କରାଯାଇଛି।
କିଛି Itanium ତନ୍ତ୍ର ଗୁଡିତ kexec
purgatory
ସଙ୍କେତରୁ ସଠିକ ଭାବରେ କୋନଶୋଲ ଆଉଟପୁଟ ସୃଷ୍ଟି କରିପାରିବ ନାହିଁ। ଏହି ସଙ୍କେତ ଗୋଟିଏ ସମସ୍ଯା ପରେ ପ୍ରଥମ ୬୪୦ କିଲୋ-ବାଇଟ ସ୍ମୃତିକୁ ପୂନରୁଦ୍ଧାର କରିବା ପାଇଁ ଅନୁଦେଶ ଧାରଣ କରିଥାଏ।
purgatory
କୋନଶୋଲ ଆଉଟପୁଟ ତୃଟି ସମାଧାନ କରିବା ପାଇଁ ଉପଯୋଗୀ ହେଉଥିବା ବେଳେ, kdump
ର ସଠିକ ଚାଳନା ପାଇଁ ଏହା ପରାମର୍ଶିତ ନୁହେଁ। ଉଦାହରଣ ସୂରୂପ, ଗୋଟିଏ kdump
ପ୍ରକ୍ରିୟା ସମୟରେ ଆପଣଙ୍କର Itanium ତନ୍ତ୍ର ପୁନଃସ୍ଥାପିତ ହେଲେ, purgatory
ରେ /etc/sysconfig/kdump
ରେ ଥିବା KEXEC_ARGS
ରେ --noio
ଯୋଗ କରି କୋନଶୋଲ ଆଉଟପୁଟକୁ ନିଷ୍କ୍ରିୟ କରନ୍ତୁ।
perftest
କୁ ଚଲାଇବା ବିଫଳ ହୋଇଥାଏ ଯଦି ପୃଥକ CPU ଗତି ଜଣାପଡ଼େ। ସେହିପରି, perftest
କୁ ଚଲାଇବା ପୂର୍ବରୁ ଆପଣଙ୍କୁ CPU ଗତି ମାପକୁ ନିଷ୍କ୍ରିୟ କରିବାକୁ ପଡ଼ିବ।
ଯେତେବେଳେ kdump
କର୍ଣ୍ଣଲକୁ ବୁଟକରାଯାଏ, ସେତେବେଳେ ବୁଟ ଲଗରେ ନିମ୍ନଲିଖିତ ତ୍ରୁଟି ଦେଖାଦେଇଥାଏ:
mknod: /tmp/initrd.[numbers]
/dev/efirtc: ଏପରି କୌଣସି ଫାଇଲ କିମ୍ବା ଡ଼ିରେକ୍ଟୋରି ନାହିଁ
ଗୋଟିଏ ଭୁଲ ପଥରେ efirtc
କୁ ନିର୍ମାଣ କରିବା ପାଇଁ ପଠାଯାଇଥିବା ତ୍ରୁଟିଯୁକ୍ତ ଅନୁରୋଧ ଫଳରେ ଏହି ତ୍ରୁଟି ଦେଖାଦେଇଛି। ତଥାପି, ପ୍ରଶ୍ନରେ ଥିବା ଉପକରଣ ପଥ initramfs
ରେ ମଧ୍ଯ ନିର୍ମାଣ ହୋଇଥାଏ ଯେତେବେଳେ kdump
ସର୍ଭିସ ଆରମ୍ଭ ହୋଇଥାଏ। ସେହିପରି, ଚାଲୁଥିବା ସମୟରେ ସୃଷ୍ଟି ହେଉଥିବା ଉପକରଣ ନୋଡଟି ହେଉଛି ଅନାବଶ୍ୟକ, କ୍ଷତିହୀନ, ଏବଂ kdump
ର କାର୍ଯ୍ୟକ୍ଷମତା ଉପରେ ପ୍ରବାବ ପକାଇନଥାଏ।
କିଛି ତନ୍ତ୍ର kdump
କର୍ଣ୍ଣଲକୁ ସଠିକ ଭାବରେ ବୁଟ କରିବାରେ ଅସମର୍ଥ ହୋଇପାରନ୍ତି। ଏହିପରି ପରିସ୍ଥିତିରେ, machvec=dig
କର୍ଣ୍ଣଲ ପ୍ରାଚଳ ବ୍ୟବହାର କରନ୍ତୁ।
ଲିପିବଦ୍ଧ କରିବା ପଦ୍ଧତିକୁ Dell M4300 ଏବଂ M6300 ରେ ହାତରେ ସକ୍ରିୟ କରିବାକୁ ପଡ଼ିଥାଏ। ଏହାକୁ କାର୍ଯ୍ୟକାରୀ କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପଗୁଡ଼ିକୁ ପାଳନ କରନ୍ତୁ:
alsamixer
କୁ ଖୋଲନ୍ତୁ।
[Capture] କୁ View କ୍ଷେତ୍ରରେ (ତାଲିକାର ଉପର ବାମପଟ ଅଂଶରେ ଦୃଶ୍ୟମାନ)ଆଗପଛ କରିବା ପାଇଁ Tab ଦବାନ୍ତୁ।
Space ଦଣ୍ଡକୁ ଦବାନ୍ତୁ।
ଅନୁଲିପିଟି ସକ୍ରିୟ ଅଛି ବୋଲି ଯାଞ୍ଚକରିବା ପାଇଁ, ADCMux
କ୍ଷେତ୍ର ଉପରେ ଥିବା ପାଠ୍ୟ L R CAPTUR
ଦର୍ଶାଉଥିବା ଉଚିତ।
Intel Itanium-ଆଧାରିତ ତନ୍ତ୍ରରେ SELinuxକୁ ବାଧ୍ୟତାମୂଳକ ଧାରାରେ ଚଲାଇବା ଦ୍ୱାରା, ହୁଏତ allow_unconfined_execmem_dyntrans
କିମ୍ବା allow_execmem
ବୁଲିଆନ IA-32 ନିଷ୍ପାଦ୍ୟ ସ୍ତର (ia32el
ସର୍ଭିସ)କୁ ସଠିକ ଭାବରେ ଚଲାଇବା ପାଇଁ ଅନୁମତି ଦେବା ପାଇଁ ନିଶ୍ଚିତ ଭାବରେ ଅନ ହୋଇଥାଏ। ଯଦି allow_unconfined_execmem_dyntrans
ବୁଲିଆନଟି ଅଫ ହୋଇଥାଏ, କିନ୍ତୁ allow_execmem
ବୁଲିଆନ ଅନ ହୋଇଥାଏ, ଯାହାକି Red Hat Enterprise Linux 5ରେ ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଭାବରେ, 32-ବିଟ ଯାନ୍ତ୍ରନୁକରଣ ia32el ସର୍ଭିସକୁ ସମର୍ଥନ କରିଥାଏ; ତଥାପି, ଯଦି ଉଭୟ ବୁଲିଆନଗୁଡ଼ିକ ଅଫ ହୋଇଥାଏ, ଯାନ୍ତ୍ରନୁକରଣ ବିଫଳ ହୋଇଥାଏ।
ସଂଶୋଧନ ଇତିହାସ | |||
---|---|---|---|
ସଂଶୋଧନ 1.0 | 16th October 2008 | ||
|