ସ୍ଥାପନ ସମ୍ବନ୍ଧିତ ଟିପ୍ପଣୀ

ବିଶେଷତା ଅଦ୍ଯତନ

ଡ୍ରାଇଭର ଅଦ୍ଯତନ

କର୍ଣ୍ଣଲ ସମ୍ବନ୍ଧିତ ଅଦ୍ଯତନ

ଅନ୍ଯାନ୍ଯ ଅଦ୍ଯତନ

ପ୍ରଯୁକ୍ତିଜ୍ଞାନ ପୂର୍ବାବଲୋକନ

ସମାଧାନ କରାଯାଇଥିବା ସମସ୍ଯା

ଜ୍ଞାତ ସମସ୍ଯା

ଯଦି ଆପଣ Red Hat Enterprise Linux 5 ସି.ଡି.-ରମର ସାମଗ୍ରୀକୁ ନକଲ କରୁଛନ୍ତି (ଉଦାହରଣ ସ୍ବରୂପ, ନେଟୱାର୍କ ଆଧାରିତ ସ୍ଥାପନର ପ୍ରସ୍ତୁତି ପାଇଁ), ତାହାହେଲେ କେବଳ ପ୍ରଚାଳନ ତନ୍ତ୍ର ପାଇଁ ସି.ଡି.-ରମକୁ ନକଲ କରିବା ପାଇଁ ଚୟନ କରନ୍ତୁ। ଅତିରିକ୍ତ ସି.ଡି.-ରମକୁ କିମ୍ବା ସ୍ତରୀଭୂତ କୌଣସି ସି.ଡି.-ରମ ଉତ୍ପାଦକୁ ନକଲ କରନ୍ତୁ ନାହିଁ, କାରଣ ଏହା ଆନାକୋଣ୍ଡାର ସଠିକ ଚାଳନ ପାଇଁ ଆବ୍ଯଶ୍ଯକ ହେଉଥିବା ଫାଇଲ ମାନଙ୍କୁ ନବଲିଖନ କରିଦେବ।

ଅତିରିକ୍ତ ସି.ଡି.-ରମ ଏବଂ ଅନ୍ଯାନ୍ଯ ସ୍ତରୀଭୂତ ଉତ୍ପାଦ ସି.ଡି.-ରମ ମାନଙ୍କର ବିଷୟବସ୍ତୁ ମାନଙ୍କୁ Red Hat Enterprise Linux 5.1 ସ୍ଥାପିତ ହୋଇସାରିବା ପରେ ସ୍ଥାପନ କରିବା ଉଚିତ।

ଗୋଟିଏ ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ Red Hat Enterprise Linux 5.1 କୁ ସ୍ଥାପନ କରିବା ସମୟରେ, kernel-xen କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରନ୍ତୁ ନାହିଁ। ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ ଏହି କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରିବା ଦ୍ବାରା ଏହା ଆପଣଙ୍କ ତନ୍ତ୍ରକୁ ଅଟକାଇଦେବ।

ଆପଣ ଗୋଟିଏ ଆଭାସୀକୃତ ଅତିଥିରେ Red Hat Enterprise Linux 5.1 କୁ ସ୍ଥାପନ କରିବା ସମୟରେ ଗୋଟିଏ ସ୍ଥାପନ ସଂଖ୍ଯା ବ୍ଯବହାର କରୁଥିଲେ, ସ୍ଥାପନ ସମୟରେ ଆଭାସୀକରଣ ପ୍ଯାକେଜ ସମୂହକୁ ବିଚୟନ କରିବା ପାଇଁ ନିଶ୍ଚିତ ହୁଅନ୍ତୁ। ଆଭାସୀକରଣ ପ୍ଯାକେଜ ସମୂହ ବିକଳ୍ପ kernel-xen କର୍ଣ୍ଣଲକୁ ସ୍ଥାପନ କରିଥାଏ।

ଏହା ମନେ ରଖନ୍ତୁ ଯେ ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ଗୁଡିକ ଏହି ସମସ୍ଯା ଦ୍ବାରା ପ୍ରଭାବିତ ହୁଅନ୍ତି ନାହିଁ। ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ଗୁଡିକ ସର୍ବଦା kernel-xen କର୍ଣ୍ଣଲକୁ ବ୍ଯବହାର କରିଥାଆନ୍ତି।

Red Hat Enterprise Linux 5 ରୁ 5.1 କୁ ଉନ୍ନୟନ କରିବା ସମୟରେ ଆପଣ ଆଭାସୀକୃତ କର୍ଣ୍ଣଲ ବ୍ଯବହାର କରୁଥିଲେ, ଉନ୍ନୟନ ସମାପ୍ତ ହେବା ପରେ ଆପଣ ପୁନର୍ଚାଳନ କରିବା ଉଚିତ।

Red Hat Enterprise Linux 5 ଏବଂ 5.1 ର ହାଇପରଭାଇଜର ଗୁଡିକ ABI ସୁସଂଗତି ନୁହଁନ୍ତି। ଉନ୍ନୟନ ମାନଙ୍କ ମଧ୍ଯରେ ଆପଣ ପୁନର୍ଚାଳନ ନ କଲେ, ଉନ୍ନୟନ କରାଯାଇଥିବା ଆଭାସୀକରଣ RPM ଗୁଡିକ ଚଳନ୍ତି କର୍ଣ୍ଣଲ ସହିତ ମିଶିବ ନାହିଁ।

CIFS ଗ୍ରାହକକୁ 1.48aRH ସଂସ୍କରଣକୁ ଅଦ୍ଯତନ କରାଯାଇଛି। ଏହା 1.48a ପ୍ରକାଶନ ଉପରେ ଆଧାରିତ, ପ୍ଯାଚ ସହିତ ଯାହାକି ନିମ୍ନଲିଖିତ ପରିବର୍ତ୍ତନ ମାନଙ୍କୁ ଲାଗୁ କରିଥାଏ:

ଏହା ମନେ ରଖନ୍ତୁ ଯେ EMC Celerra ଉତ୍ପାଦର ଚାଳକ ମାନଙ୍କ ପାଇଁ (NAS Code 5.5.26.x ଏବଂ ନିମ୍ନତମ), EMC NAS ରେ ସହଭାଗ ମାନଙ୍କୁ ଅଭିଗମ କରିବା ସମୟରେ CIFS ଗ୍ରାହକ ଲଟକିଯାଏ। ଏହି ସମସ୍ଯାକୁ ନିମ୍ନଲିଖିତ କର୍ଣ୍ଣଲ ସନ୍ଦେଶ ମାନଙ୍କ ପାଇଁ ବିଶେଷତା ପ୍ରଦାନ କରାଯାଇଛି:

kernel:  CIFS VFS: server not responding
kernel:  CIFS VFS: No response for cmd 162 mid 380
kernel:  CIFS VFS: RFC1001 size 135 bigger than SMB for Mid=384

CIFS ମାଉଣ୍ଟ ପରେ, ଏଥିରେ ଥିବା ଯେକୌଣସି ଫାଇଲକୁ ପଢିବା/ଲେଖିବା ଅସମ୍ଭବ ଅଟେ ଏବଂ ମାଉଣ୍ଟ ବିନ୍ଦୁରେ ଗୋଟିଏ I/O ପ୍ରଚେଷ୍ଟା କରୁଥିବା ସମସ୍ତ ପ୍ରୟୋଗ ଲଟକିଯିବେ। ଏହି ସମସ୍ଯାକୁ ସମାଧାନ କରିବା ପାଇଁ, NAS Code 5.5.27.5 କିମ୍ବା ପରିବର୍ତ୍ତୀ ସଂସ୍କରଣ (EMC Primus ସ୍ଥିତି ସଂଖ୍ଯା emc165978) କୁ ଉନ୍ନୟନ କରନ୍ତୁ।

MODULE_FIRMWARE ସୂଚକ ଗୁଡିକ ବର୍ତ୍ତମାନ ସମର୍ଥିତ ଅଟନ୍ତି।

ICH9 ନିୟନ୍ତ୍ରକ ବର୍ତ୍ତମାନ ସମର୍ଥିତ ଅଟେ।

Greyhound ସଂସାଧକ ଗୁଡିକ ବର୍ତ୍ତମାନ CPUID କୋଲରେ ସମର୍ଥିତ ଅଟନ୍ତି।

Oprofile ବର୍ତ୍ତମାନ ନୂତନ Greyhound ପ୍ରଦର୍ଶନ ଗଣକ ଘଟଣାକୁ ସମର୍ଥନ କରିଥାଏ।

ନିର୍ଦ୍ଦେଶିତ DIAG ବର୍ତ୍ତମାନ z/VM ଉପଯୋଗୀତାକୁ ବଢାଇବା ପାଇଁ ସମର୍ଥନ କରାଯାଇଛି।

Intel ଆଲେଖୀ ଚିପସେଟ ବର୍ତ୍ତମାନ DRM କର୍ଣ୍ଣଲ ଏକକାଂଶ ଦ୍ବାରା ସମର୍ଥିତ ଅଟେ। ଆହୁରି ମଧ୍ଯ, ପ୍ରତ୍ଯେକ୍ଷ ଚିତ୍ରଣ ପ୍ରକ୍ରିୟାକୁ ସମର୍ଥନ କରିବା ପାଇଁ DRM API କୁ 1.3 ସଂସ୍କରଣକୁ ଉନ୍ନୟନ କରାଯାଇଛି।

ACPI ଶକ୍ତି ପରିଚଳନାର ଅଦ୍ଯତନ ଗୁଡିକ S3 ସସପେଣ୍ଡ-ଟୁ-RAM ଏବଂ S4 ନିଲମ୍ବନ ପ୍ରକ୍ରିୟାକୁ ଉନ୍ନତ କରିଅଛି।

gaim ବର୍ତ୍ତମାନ pidgin ଭାବରେ ପରିଚିତ।

Intel microcode କୁ 1.17 ସଂସ୍କରଣକୁ ଅଦ୍ଯତନ କରାଯାଇଛି। ଏହା ନୂତନ Intel ସଂସାଧକ ମାନଙ୍କ ପାଇଁ ସମର୍ଥନ ଯୋଗ କରିଅଛି।

dm-multipath କୁ ବ୍ଯବହାର କରି EMC Clariion ଭଣ୍ଡାରରେ ଅନ୍ତଃର୍ନିହିତ ଏକ୍ଟିଭ-ଏକ୍ଟିଭ ଫେଲଅଭର ବର୍ତ୍ତମାନ ସମର୍ଥିତ ଅଟେ।

ଚିନୀ ଫୋଣ୍ଟ Zysong କୁ ବର୍ତ୍ତମାନ fonts-chinese ପ୍ଯାକେଜର ଗୋଟିଏ ଅଂଶ ଭାବରେ ସ୍ଥାପନ କରାଯାଉ ନାହିଁ। Zysong କୁ ବର୍ତ୍ତମାନ ଅଲଗା fonts-chinese-zysong ଭାବରେ ସ୍ଥାପନ କରାଯାଉଛି। fonts-chinese-zysong ପ୍ଯାକେଜ ଅତିରିକ୍ତ ସି.ଡି. ରେ ଅବସ୍ଥିତ ଅଛି।

ଏହା ମନେ ରଖନ୍ତୁ ଯେ fonts-chinese-zysong ପ୍ଯାକେଜ ଚିନୀ ରାଷ୍ଟ୍ରୀୟ ମାନକ GB18030 କୁ ସମର୍ଥନ କରିବା ପାଇଁ ଆବଶ୍ଯକୀୟ।

ଚ୍ଯାଲେଞ୍ଜ ହେଣ୍ଡସେକ ଅଥେଣ୍ଟିକେସନ ପ୍ରୋଟୋକଲ (CHAP) ଚାଳକ ନାମ ଏବଂ ପ୍ରବେଶ ସଙ୍କେତ ପ୍ରତ୍ଯେକର ସର୍ବାଧିକ ଅକ୍ଷର ସୀମା ୨୫୬ ଅଟେ।

pump କୁ ଏହି ଅଦ୍ଯତନରେ ନାପସନ୍ଦ କରଯାଇଛି। ତେଣୁ, ଆପଣଙ୍କ ନେଟୱାର୍କ ଅନ୍ତରାପୃଷ୍ଠକୁ netconfig ଦ୍ବାରା ବିନ୍ଯାସ କରିବା ଦ୍ବାରା ଏହା ifcfg ସ୍କ୍ରିପ୍ଟକୁ ଭୂଲ ଭାବରେ ସମ୍ପାଦନ କରିପାରେ।

ଆପଣଙ୍କ ନେଟୱାର୍କ ଅନ୍ତରାପୃଷ୍ଠକୁ ସଠିକ ଭାବରେ ବିନ୍ଯାସ କରିବା ପାଇଁ, system-config-network କୁ ଏହା ପରିବର୍ତ୍ତେ ବ୍ଯବହାର କରନ୍ତୁ। ଅଦ୍ଯତିତ system-config-network ପ୍ଯାକେଜକୁ ସ୍ଥାପନ କରିବା ଦ୍ବାରା ତାହା netconfig କୁ ଅପସାରଣ କରିଥାଏ।

rpm --aid କୁ ଆଉ ଏବେ ସମର୍ଥନ କରାଯାଉ ନାହିଁ। ପ୍ଯାକେଜ ମାନଙ୍କୁ ଅଦ୍ଯତନ ଏବଂ ସ୍ଥାପନ କରିବା ସମୟରେ yum ବ୍ଯବହାର କରିବା ପାଇଁ ଆପଣଙ୍କୁ ପରାମର୍ଶ କରାଯାଏ।

SATA-ସନ୍ନିହିତ ତନ୍ତ୍ରକୁ ବୁଟ ସମୟରେ ଅଟକାଉଥିବା ଏବଂ ପୁନର୍ଚାଳନ କରିବା ପୂର୍ବରୁ ଗୋଟିଏ ତୃଟି ପ୍ରଦର୍ଶନ କରୁଥିବା ଦୋଷକୁ ବର୍ତ୍ତମାନ ସମାଧାନ କରି ଦିଆଯାଇଛି।

ମଲ୍ଟିବୁଟ ତନ୍ତ୍ରରେ, parted ବର୍ତ୍ତମାନ ପ୍ରଥମ ମୌଳିକ ବିଭାଜନର ପ୍ରାରମ୍ଭିକ ଖଣ୍ଡକୁ ସଂରକ୍ଷିତ କରିଥାଏ ଯେଉଁଠାରେ Windows Vista™ କୁ ସ୍ଥାପନ କରାଯାଇଛି। ତେଣୁ, ଉଭୟ Red Hat Enterprise Linux 5.1 ଏବଂ Windows Vista™ ସହିତ ମଲ୍ଟିବୁଟ ତନ୍ତ୍ରକୁ ବ୍ଯବସ୍ଥାପିତ କରିବା ସମୟରେ, ପଶ୍ଚାତ ତନ୍ତ୍ରକୁ ଆଉ ବୁଟବିହୀନଯୋଗ୍ଯ ଭାବରେ ଚିତ୍ରଣ କରାଯାଉ ନାହିଁ।

rmmod xennet ଆଉ domU କୁ ଅକାମି କରୁନାହିଁ।

node 0 ରେ ବିନ୍ଯାସ କରାଯାଇ ନ ଥିବା ସ୍ମୃତି ବିଶିଷ୍ଟ 4-socket AMD Sun Blade X8400 ସେବକ ଏକକାଂଶ ତନ୍ତ୍ର ଗୁଡିକ ବୁଟ ସମୟରେ ଆଉ ଖରାପ ହେବେ ନାହିଁ।

conga ଏବଂ luci କୁ ବର୍ତ୍ତମାନ ଫେଲଅଭର ପରିସର ମାନଙ୍କୁ ସୃଷ୍ଟି ଏବଂ ବିନ୍ଯାସ କରିବା ପାଇଁ ବ୍ଯବହାର କରିହେବ।

ଏକତ୍ରିକରଣ ଭଣ୍ଡାର ସମୂହକୁ yum ଦ୍ବାରା ସ୍ଥାପନ କରିବା ସମୟରେ, ଆଦାନ ପ୍ରଦାନ ଆଉ ବିଫଳ ହୁଏନାହିଁ।

ସ୍ଥାପନ ସମୟରେ, ଭୂଲ SELinux ପ୍ରସଙ୍ଗକୁ ବର୍ତ୍ତମାନ /var/log/faillog ଏବଂ /var/log/tallylog ରେ ନ୍ଯସ୍ତ କରାଯାଏ ନାହିଁ।

ପୃଥକ ସ୍ଥାପନ ମାଧ୍ଯମ (ଉଦାହରଣ ସ୍ବରୂପ, ସି.ଡି. କିମ୍ବା NFSISO) କୁ ବ୍ଯବହାର କରି Red Hat Enterprise Linux 5.1 କୁ ସ୍ଥାପନ କରିବା ସମୟରେ, amanda-server ର ସ୍ଥାପନ ଆଉ ତୃଟି ଘଟାଏ ନାହିଁ।

EDAC ବର୍ତ୍ତମାନ ନବୀନତମ k8 ସଂସାଧକ ମାନଙ୍କରେ ସଠିକ ପରିମାଣର ସ୍ମୃତି ବିବରଣୀ ପ୍ରଦାନ କରିଥାଏ।

ଦୂରରୁ gdm ଦ୍ବାରା ନୋମ ଡେସ୍କଟପକୁ ଲଗଇନ କରିବା ଦ୍ବାରା ଆଉ ଏବେ ଲଗଇନ ପରଦା ଲଟକୁ ନାହିଁ।

ଏକାଧିକ ଆରୋହଣ (ମଲ୍ଟି-ମାଉଣ୍ଟ) ପ୍ରକ୍ରିୟାକୁ ସଠିକ ଭାବରେ କାର୍ଯ୍ଯ କରିବାରୁ ଅଟକାଉଥିବା autofs ର ଗୋଟିଏ ତୃଟିକୁ ସମାଧାନ କରିଦିଆଯାଇଛି।

tvtime ଏବଂ xawtv ନିର୍ଦ୍ଦେଶକୁ bttv କର୍ଣ୍ଣଲ ଏକକାଂଶ ସହିତ ଚଳାଇଲେ ଏହା ତନ୍ତ୍ରକୁ ଆଉ ଅଟକାଏ ନାହିଁ।

utrace ପାଇଁ ଅନେକ ପ୍ଯାଚ ଗୁଡିକ ନିମ୍ନଲିଖିତ ସମାଧାନ ମାନଙ୍କୁ ଲାଗୁ କରିଅଛି:

ସତର୍କ ସଙ୍କେତକୁ ଏବଂ ସାମୟିକ RTC ହସ୍ତକ୍ଷେପ ମାନଙ୍କୁ ସଠିକ ଭାବରେ ଚାଲିବାରୁ ପ୍ରତିରୋଧ କରିଥିବା ଗୋଟିଏ ବାସ୍ତବିକ ସମୟ ଘଡି (RTC) ତୃଟିକୁ ବର୍ତ୍ତମାନ ସମାଧାନ କରାଯାଇଛି।

ପ୍ରଥମ ଥର ଆନାକୋଣ୍ଡାରେ ପ୍ରକାଶନ ଟିପ୍ପଣୀ ବଟନକୁ ଦବାଇଲେ, ଏହା କିଛି ସମୟ ନେଇଥାଏ କାରଣ ୱିଣ୍ଡୋ ପ୍ରକାଶନ ଟିପ୍ପଣୀକୁ ଚିତ୍ରଣ କରୁଥାଏ। ଏହି ବିଳମ୍ବତା ସମୟରେ, ୱିଣ୍ଡୋରେ ଗୋଟିଏ ଖାଲି ତାଲିକା ଦେଖାଦେବା ପରି ଜଣାପଡେ। ଚିତ୍ରଣ ସାଧାରଣତଃ ଶୀଘ୍ର ସମାପ୍ତ ହୋଇଯାଏ, ତେଣୁ ଅଧିକାଂଶ ଚାଳକ ଏହାକୁ ଦେଖି ନ ପାରନ୍ତି।

ଏହି ବିଳମ୍ବତା ସାଧାରଣତଃ ଏହି କାରଣରୁ ହୋଇଥାଏ ଯେ ପ୍ଯାକେଜ ସ୍ଥାପନ ପ୍ରକ୍ରିୟା ସ୍ଥାପନ ପର୍ଯ୍ଯାୟର ସବୁଠାକୁ ଅଧିକ CPU ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରକ୍ରିୟା ଅଟେ।

NVIDIA ଆଲେଖୀ କାର୍ଡ ବ୍ଯବହାର କରୁଥିବା କିଛି ମେସିନ ଗୋଟିଏ ଆଲେଖୀକ ଲଗଇନ ବ୍ଯବହାର କରିବା ସମୟରେ ବିକୃତ ଆଲେଖୀ କିମ୍ବା ଅକ୍ଷର ରୂପ ପ୍ରଦର୍ଶନ କରିପାରନ୍ତି। ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ଗୋଟିଏ ଆଲେଖୀକ କୋନଶୋଲକୁ ସୁଇଚ କରନ୍ତୁ ଏବଂ ତାପରେ ପୁନର୍ବାର ସ୍ବାଭାବିକ X ଆଧାରକୁ ପ୍ରତ୍ଯାବର୍ତ୍ତନ କରନ୍ତୁ।

ଆଧାର ବସ ଏଡେପ୍ଟର ଯାହାକି MegaRAID ଡ୍ରାଇଭରକୁ ବ୍ଯବହାର କରିଥାଏ, ତାହାକୁ "I2O" ପରିବର୍ତ୍ତେ "ବହୁଳ ଭଣ୍ଡାର" ଯନ୍ତ୍ରାନୁକରଣ ଧାରାରେ ଚଳାଇବା ପାଇଁ ବିନ୍ଯାସ କରିବା ଉଚିତ। ଏପରି କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ପଦକ୍ଷେପ ମାନଙ୍କୁ ଅନୁସରଣ କରନ୍ତୁ:

ଯଦି ଏଡେପ୍ଟରକୁ ଭୂଲବଶତଃ "I2O" ଯନ୍ତ୍ରାନୁକରଣ ଧାରାରେ ବିନ୍ଯାସ କରାଯାଇଛି, ତାହାହେଲେ ତନ୍ତ୍ରଟି i2o ଡ୍ରାଇଭରକୁ ଧାରଣ କରିବା ପାଇଁ ପ୍ରଚେଷ୍ଟା କରିବ। ଏହା ବିଫଳ ହେବ, ଏବଂ ଠିକ ଡ୍ରାଇଭରକୁ ଲୋଡ କରିବାରୁ ଅଟକାଇବ।

ପୂର୍ବ Red Hat Enterprise Linux ପ୍ରକାଶନ ସାଧାରଣତଃ MegaRAID ଡ୍ରାଇଭର ପୂର୍ବରୁ I20 ଡ୍ରାଇଭରକୁ ଧାରଣ କରିବା ପାଇଁ ପ୍ରଚେଷ୍ଟା କରି ନ ଥାଏ। ଏହା ଉପରେ ଦୃଷ୍ଟିପାତ ନ କରି, Linux ବ୍ଯବହାର କରୁଥିବା ସମୟରେ ହାର୍ଡୱେରକୁ ସର୍ବଦା "ବହୁଳ ଭଣ୍ଡାର" ଯନ୍ତ୍ରାନୁକରଣ ଧାରାରେ ବିନ୍ଯାସ କରାଯିବା ଉଚିତ।

Cisco Aironet MPI-350 ବେତାର କାର୍ଡ ଥିବା ଲାପଟପ ଗୁଡିକ ତାର ସଂଯୋଜିତ ଇଥରନେଟ ସଂଯୋଗିକୀ ବ୍ଯବହାର କରି ଯେ କୌଣସି ନେଟୱାର୍କ ଆଧାରିତ ସ୍ଥାପନ ସମୟରେ ଗୋଟିଏ DHCP ଠିକଣା ପାଇବାକୁ ପ୍ରଚେଷ୍ଟା କରୁଥିବା ସମୟରେ ଅଟକି ଯାଇପାରନ୍ତି।

ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ଆପଣଙ୍କ ସ୍ଥାପନ ପାଇଁ ସ୍ଥାନୀୟ ମାଧ୍ଯମକୁ ବ୍ଯବହାର କରନ୍ତୁ। ପର୍ଯ୍ଯାୟକ୍ରମିକ ଭାବରେ, ସ୍ଥାପନ ପୂର୍ବରୁ ଲାପଟପର BIOS ରେ ଆପଣ ବେତାର କାର୍ଡକୁ ନିଷ୍କ୍ରିୟ କରିପାରିବେ (ସ୍ଥାପନ ସମାପ୍ତ ହେବା ପରେ ଆପଣ ବେତାର କାର୍ଡକୁ ପୁନଃ ସକ୍ରିୟ କରିପାରିବେ)।

ବର୍ତ୍ତମାନ, system-config-kickstart ପ୍ଯାକେଜ ଚୟନ କିମ୍ବା ବିଚୟନ ବିକଳ୍ପକୁ ସମର୍ଥନ କରୁ ନାହିଁ। system-config-kickstart ବ୍ଯବହାର କରିବା ସମୟରେ, ପ୍ଯାକେଜ ଚୟନ ବିକଳ୍ପ ଏହା ନିଷ୍କ୍ରିୟ ଅଛି ବୋଲି ସୂଚାଇଥାଏ। କାରଣ system-config-kickstart ସାମୂହିକ ସୂଚନା ସଂଗ୍ରହ କରିବା ପାଇଁ yum ବ୍ଯବହାର କରିଥାଏ, କିନ୍ତୁ Red Hat Network ସହିତ ସଂଯୋଗ କରିବା ପାଇଁ yum କୁ ବିନ୍ଯାସ କରିବାରେ ଅସମର୍ଥ ଅଟେ।

ବର୍ତ୍ତମାନ, ଆପଣ ଆପଣଙ୍କ କିକ-ଷ୍ଟାର୍ଟ ଫାଇଲ ମାନଙ୍କରେ ହସ୍ତକୃତ ଭାବରେ ପ୍ଯାକେଜ ବିଭାଗ ମାନଙ୍କୁ ଅଦ୍ଯତନ କରିବା ଉଚିତ। ଗୋଟିଏ କିକ-ଷ୍ଟାର୍ଟ ଫାଇଲକୁ ଖୋଲିବା ପାଇଁ system-config-kickstart ପ୍ରୟୋଗ କରିବା ସମୟରେ, ଏହା ସମସ୍ତ ପ୍ଯାକେଜ ସୂଚନାକୁ ଏଠାରେ ସଂଗ୍ରହ କରିବ ଏବଂ ଏହାକୁ ଆପଣ ସଂରକ୍ଷଣ କରିବା ସମୟରେ ସେହି ସ୍ଥାନରେ ଲେଖିଦେବ।

Red Hat Enterprise Linux 5 ର ଏହି ସଂସ୍କରଣରେ /var/log/boot.log କୁ ଲଗ କରୁଥିବା ବୁଟ ସମୟ ଅନୁପଲବ୍ଧ। ଭବିଷ୍ଯତ ଅଦ୍ଯତନରେ ଗୋଟିଏ ଅନୁରୂପ କାର୍ଯ୍ଯତ୍ମକତା ଯୋଗ କରାଯିବ।

Red Hat Enterprise Linux 4 ରୁ Red Hat Enterprise Linux 5 କୁ ଉନ୍ନୟନ କରିବା ସମୟରେ, ପରିନିୟୋଜନ ଗାଇଡଟି ସ୍ବତଃ ପ୍ରାରମ୍ଭ ହୋଇଥାଏ। ଉନ୍ନୟନ ସମାପ୍ତ ହେବା ପରେ ହସ୍ତକୃତ ଭାବରେ ଏହାକୁ ସ୍ଥାପନ କରିବା ପାଇଁ ଆପଣ pirut କୁ ବ୍ଯବହାର କରିବା ଉଚିତ।

ଯଦି X ଚାଲୁଅଛି ଏବଂ vesa ବ୍ଯତୀଥ ଅନ୍ଯ ଗୋଟିଏ ଡ୍ରାଇଭର ବ୍ଯବହାର କରୁଅଛି, ତାହାହେଲେ ତନ୍ତ୍ରଟି ସଫଳତାର ସହିତ ଗୋଟିଏ kexec/kdump କର୍ଣ୍ଣଲ ସହିତ ପୁନର୍ଚାଳିତ ହୋଇପାରିବ ନାହିଁ। ଏହି ସମସ୍ଯା କେବଳ ATI Rage XL ଆଲେଖୀକ ଚିପ-ସେଟରେ ଦେଖା ଯାଇଥାଏ।

ଯଦି X ଗୋଟିଏ ATI Rage XL ଦ୍ବାରା ସୁସଜ୍ଜିତ ତନ୍ତ୍ରରେ ଚାଲୁଅଛି, ତାହାହେଲେ ଗୋଟିଏ kexec/kdump କର୍ଣ୍ଣଲ ସହିତ ପୁନର୍ଚାଳନ କରିବା ପାଇଁ ଏହା vesa ଡ୍ରାଇଭର ବ୍ଯବହାର କରୁଅଛି ବୋଲି ନିଶ୍ଚିତ କରନ୍ତୁ।

HP ତନ୍ତ୍ରର xw9300 ଏବଂ xw9400 ନମୁନାରେ ଆଭାସୀକରଣ ଗୁଣକୁ ସ୍ଥାପନ କରିବା ଦ୍ବାରା ଏହା time went backwards ଚେତାବନୀ ଦେଇଥାଏ।

xw9400 ମେସିନ ମାନଙ୍କ ପାଇଁ ଏହି ସମସ୍ୟାକୁ ସମାଧାନ କରିବା ପାଇଁ, HPET କାଳ ମାପକକୁ ସକ୍ରିୟା କରିବା ପାଇଁ BIOS ସଂଯୋଜନାକୁ ବିନ୍ଯାସ କରନ୍ତୁ। ଏହା ମନେ ରଖନ୍ତୁ ଯେ ଏହି ବିକଳ୍ପଟି କେବଳ xw9300 ମେସିନ ମାନଙ୍କ ପାଇଁ ଉପଲବ୍ଧ।

ଏହା HP ଦ୍ବାରା ଆଗନ୍ତୁକ BIOS ଅଦ୍ଯତନରେ ସମାଧାନ କରିଦିଆଯିବ।

nVidia CK804 ଚିପସେଟ ସ୍ଥାପିତ ଥିବା ଗୋଟିଏ ତନ୍ତ୍ରରେ Red Hat Enterprise Linux 5 ବ୍ଯବହାର କରିବା ସମୟରେ, ଆପଣ ନିମ୍ନଲିଖିତ କର୍ଣ୍ଣଲ ସନ୍ଦେଶ ମାନ ପାଇପାରନ୍ତି।

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

ଏହି ସନ୍ଦେଶଟି ଏହା ସୂଚୀତ କରୁଛି ଯେ କିଛି PCI-E ସଂଯୋଗିକୀ ଗୁଡିକ ICQ ମାନଙ୍କୁ ନିବେଦନ କରୁ ନାହାଁନ୍ତି। ଆହୁରି ମଧ୍ଯ, କୌଣସି ପରିସ୍ଥିତିରେ, ଏହି ସନ୍ଦେଶ ଗୁଡିକ ମେସିନର କାର୍ଯ୍ଯକଳାପକୁ ପ୍ରଭାବିତ କରନ୍ତି ନାହିଁ।

ଆପଣ ରୁଟ ଭାବରେ ଲଗଇନ ହୋଇଥିବା ସମୟରେ ଅପସାରଣ ଯୋଗ୍ଯ ଭଣ୍ଡାର ଉପକରଣ (ସି.ଡି. ଏବଂ ଡି.ଭି.ଡି. ପରି) ଗୁଡିକ ସ୍ବତଃ ମାଉଣ୍ଡ ହୁଅନ୍ତି ନାହିଁ। ତେଣୁ, ଆପଣଙ୍କୁ ଆଲେଖୀକ ଫାଇଲ ପରିଚାଳକ ଦ୍ବାରା ଉପକରଣ ମାନଙ୍କୁ ହସ୍ତକୃତ ଭାବରେ ମାଉଣ୍ଟ କରିବାକୁ ପଡିବ।

ବୈକଳ୍ପିକ ଭାବରେ, ଆପଣ ଗୋଟିଏ ଉପକରଣକୁ /media ରେ ମାଉଣ୍ଟ କରିବା ପାଇଁ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ଚଳାଇ ପାରିବେ:

mount /dev/<device name> /media

Calgary IOMMU ଚିପ ପୂର୍ବନିର୍ଦ୍ଧାରିତ ଭାବରେ ଏହି ଅଦ୍ଯତନରେ ସମର୍ଥିତ ନୁହେଁ। ଏହି ଚିପ ପାଇଁ ସମର୍ଥନକୁ ସକ୍ରିୟ କରିବା ପାଇଁ, iommu=calgary କର୍ଣ୍ଣଲ ପାଠ୍ଯ ନିର୍ଦ୍ଦେଶ ବିକଳ୍ପକୁ ବ୍ଯବହାର କରନ୍ତୁ।

IBM System z ଗୋଟିଏ ପାରମ୍ପରିକ Unix ଶୈଳୀର ଭୌତିକ କୋନଶୋଲ ପ୍ରଦାନ କରେ ନାହିଁ। ଯେପରିକି, ପ୍ରାରମ୍ଭିକ ପ୍ରୋଗ୍ରାମ ଧାରଣ ସମୟରେ Red Hat Enterprise Linux 5 IBM System z ପାଇଁ firstboot କୁ ସମର୍ଥନ କରେ ନାହିଁ।

IBM System z, ତନ୍ତ୍ରରେ Red Hat Enterprise Linux 5 ର ବ୍ଯବସ୍ଥାପନ ପ୍ରକ୍ରିୟାକୁ ସଠିକ ଭାବରେ ପ୍ରାରମ୍ଭିକରଣ କରିବା ପାଇଁ, ସ୍ଥାପନ ପରେ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶ ମାନଙ୍କୁ ଚଳାନ୍ତୁ:

Red Hat Enterprise Linux 5 ରୁ Red Hat Enterprise Linux 5.1 କୁ Red Hat Network ଦ୍ବାରା ଉନ୍ନୟନ କରିବା ସମୟରେ, yum ଆପଣଙ୍କୁ redhat-beta ଚାବି ଆୟତ କରିବା ପାଇଁ ନ କହିପାରେ। ତେଣୁ, ଏହା ପରାମର୍ଶିତ ଯେ ଉନ୍ନୟନ କରିବା ପୂର୍ବରୁ ଆପଣ ହସ୍ତକୃତ ଭାବରେ redhat-beta ଚାବିକୁ ଆୟତ କରିନ୍ତୁ। ଏହା କରିବା ପାଇଁ, ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶ ଚଳାନ୍ତୁ:

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

ଗୋଟିଏ ବିନ୍ଯାସ କରାଯାଇଥିବା ଫିଲଟରରୁ ଗୋଟିଏ LUN କୁ ଅପସାରଣ କରିବା ସମୟରେ, ପରିବର୍ତ୍ତନଟି ଆଧାରରେ ଦେଖାଯାଏ ନାହିଁ। ଏପରି ପରିସ୍ଥିତିରେ, dm-multipath ବ୍ଯବହାର କରାଗଲେ lvm ଅନନ୍ତକାଳ ପାଇଁ ଲଟକିଯିବ, କାରଣ LUN ବର୍ତ୍ତମାନ stale ହୋଇଯାଇଛି।

ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ସମସ୍ତ ଉପକରଣକୁ ଏବଂ ଅଟକିଥିବା LUN ନିର୍ଦ୍ଦିଷ୍ଟ /etc/lvm/.cache ରେ ଥିବା mpath ସଂଯୋଗ ପ୍ରବିଷ୍ଟି ମାନଙ୍କୁ ଅପସାରଣ କରନ୍ତୁ।

ଏହି ପ୍ରବିଷ୍ଟି ଗୁଡିକ କ'ଣ ବୋଲି ଜାଣିବା ପାଇଁ ନିମ୍ନଲିଖିତ ନିର୍ଦ୍ଦେଶକୁ ଚଳାନ୍ତୁ:

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

ଉଦାହରଣ ସ୍ବରୂପ, ଯଦି <stale LUN> 3600d0230003414f30000203a7bc41a00 ଅଟେ, ତାହାହେଲେ ନିମ୍ନଲିଖିତ ପରିଣାମ ମିଳିପାରେ:

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

ଗୋଟିଏ ସି.ଡି. / ଡି.ଭି.ଡି ରୁ ଗୋଟିଏ ସମ୍ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ Windows™ ଅତିଥିକୁ ସୃଷ୍ଟି କରିବାକୁ ପ୍ରଚେଷ୍ଟା କରିବା ସମୟରେ, ଅତିଥି ସ୍ଥାପନର ଦ୍ବିତୀୟ ଅବସ୍ଥା ପୁନର୍ଚାଳନ ପରେ ଜାରି ହୋଇ ନ ପାରେ।

ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, /etc/xen/<name of guest machine> ରେ ସଠିକ ଭାବରେ ଗୋଟିଏ ପ୍ରବିଷ୍ଟିକୁ ଯୋଗ କରି ସି.ଡି. / ଡି.ଭି.ଡି. ଉପକରଣ ମାନଙ୍କ ପାଇଁ ସମ୍ପାଦନ କରନ୍ତୁ।

ଯଦି ଗୋଟିଏ ସାଧରଣ ଫାଇଲରେ କରାଯାଇଥିବା ସ୍ଥାପନକୁ ଗୋଟିଏ ଆଭାସୀ ତନ୍ତ୍ର ଭାବରେ ବ୍ଯବହାର କରାଯାଏ, /etc/xen/<name of guest machine> ର disk ଧାଡି ନିମ୍ନଲିଖିତ ଭାବରେ ପଢିବ:

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

ଆଧାରରେ /dev/dvd ଭାବରେ ଅବସ୍ଥିତ ଗୋଟିଏ ଡି.ଭି.ଡି.-ରମ ଉପକରଣକୁ ସ୍ଥାପନର ଦ୍ବିତୀୟ ସୋପାନରେ 'phy:/dev/dvd,hdc:cdrom,r' ପରି ଏକ ପ୍ରବିଷ୍ଟି ଯୋଗ କରି hdc ଭାବରେ ଉପଲବ୍ଧ କରାଯାଇ ପାରିବ। ଉଦାହରଣ ସ୍ବରୂପ, ଡିସ୍କ ଧାଡିକୁ ନିମ୍ନଲିଖିତ ଶୈଳୀରେ ପଢାଯିବା ଉଚିତ:

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

ପୂର୍ବ ନିଶ୍ଚିତ ଉପକରଣ ପଥ ଆପଣଙ୍କ ହାର୍ଡୱେର ଉପରେ ନିର୍ଭର କରି ବଦଳିପାରେ।

ଯଦି sctp ଏକକାଂଶକୁ କର୍ଣ୍ଣଲରେ ଯୋଗ କରାଯାଇ ନାହିଁ, ତାହାହେଲେ netstat କୁ -A inet କିମ୍ବା -A inet6 ବିକଳ୍ପ ସହିତ ଚଲାଇଲେ ଏହା ଅପ୍ରତ୍ଯାଶିତ ଭାବରେ ନିମ୍ନଲିଖିତ ସନ୍ଦେଶ ସହିତ ବନ୍ଦ ହୋଇଯାଏ:

netstat: no support for `AF INET (sctp)' on this system.        

ଏହାକୁ ଆଗ୍ରହ୍ଯ କରିବା ପାଇଁ, sctp କର୍ଣ୍ଣଲ ଏକକାଂଶକୁ ସ୍ଥାପନ କରନ୍ତୁ।

Red Hat Enterprise Linux 3.9 କୁ ଗୋଟିଏ ପୂର୍ଣ୍ଣ ଆଭାସୀକୃତ ଅତିଥିରେ ସ୍ଥାପନ କରିବା ଅତି ମନ୍ଥର ହୋଇପାରେ। ଏହା ବ୍ଯତୀଥ, ସ୍ଥାପନ ପରେ ବୁଟ କରିବା ଦ୍ବାରା ଏହା hda: lost interrupt ତୃଟି ମାନ ଦେଇପାରେ।

ବୁଟଅପ ତୃଟିକୁ ଆଗ୍ରହ୍ଯ କରିବା ପାଇଁ, SMP କର୍ଣ୍ଣଲକୁ ବ୍ଯବହାର କରିବାକୁ ଅତିଥିକୁ ବିନ୍ଯାସ କରନ୍ତୁ।

ଉପସ୍ଥିତ କର୍ଣ୍ଣଲ ବୁଟ ସମୟରେ ଅନୁକ୍ରମ ସଂଯୋଗିକୀ ମାନଙ୍କୁ ପ୍ରଦର୍ଶନ କରିବା ପୂର୍ବରୁ ଡାଟା ଟର୍ମିନାଲ ରେଡି (DTR) ସଙ୍କେତକୁ ନିଶ୍ଚିତ କରି ନ ଥାଏ। DTR ନିଶ୍ଚିତନ କିଛି ଉପକରଣ ମାନଙ୍କ ଦ୍ବାରା ଆବଶ୍ଯକ, ଫଳସ୍ବରୂପ, ସେହି ଉପକରଣ ମାନଙ୍କରେ ଅନୁକ୍ରମ କୋନଶୋଲରେ କର୍ଣ୍ଣଲ ବୁଟ ସନ୍ଦେଶ ମାନଙ୍କୁ ପ୍ରଦର୍ଶନ କରାଯାଏ ନାହିଁ।

ଗୋଟିଏ ଆଧାର (dom0) ତନ୍ତ୍ରକୁ Red Hat Enterprise Linux 5.1 ରେ ଉନ୍ନୟନ କରିବା ସମୟରେ ଏହା ଅବସ୍ଥିତ Red Hat Enterprise Linux 4.5 SMP ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥିକୁ ବୁଟବିହୀନଯୋଗ୍ଯ କରିପାରେ। ତନ୍ତ୍ରରେ ୪ ଗିଗା-ବାଇଟରୁ ଅଧିକ RAM ଥିଲେ ସାଧାରଣତଃ ଏହା ହୋଇଥାଏ।

ଏହାକୁ ସମାଧାନ କରିବା ପାଇଁ, ପ୍ରତ୍ଯେକ Red Hat Enterprise Linux 4.5 ଅତିଥିକୁ ଗୋଟିଏ CPU ଧାରାରେ ବୁଟ କରନ୍ତୁ ଏବଂ ଏହାର କର୍ଣ୍ଣଲକୁ ନବୀନତମ ସଂସ୍କରଣକୁ (Red Hat Enterprise Linux 4.5.z ପାଇଁ) ଉନ୍ନୟନ କରନ୍ତୁ।

ସମାନ ପ୍ଲାଟଫର୍ମରେ ବ୍ଯବହୃତ AMD 8132 ଏବଂ HP BroadCom HT100 (ଯେପରିକି HP dc7700) MMCONFIG ଆବର୍ତ୍ତନକୁ ସମର୍ଥନ କରେନାହିଁ। ଆପଣଙ୍କ ତନ୍ତ୍ର ଚିପସେଟ ବ୍ଯବହାର କରୁଥିଲେ, ଆପଣଙ୍କର PCI ବିନ୍ଯାସ ଅଧିକୃତ PortIO CF8/CFC କାର୍ଯ୍ଯାବଳୀକୁ ବ୍ଯବହାର କରିବା ଉଚିତ। ଏହାକୁ ବିନ୍ୟାସ କରିବା ପାଇଁ, ସ୍ଥାପନ ସମୟରେ ତନ୍ତ୍ରକୁ -pci nommconfig କର୍ଣ୍ଣଲ ପାରାମିଟର ସହିତ ବୁଟ କରନ୍ତୁ ଏବଂ ପୁନର୍ଚାଳନ କରିସାରିବା ପରେ GRUB ରେ pci=nommconf କୁ ଯୋଗକରନ୍ତୁ।

ଅଧିକନ୍ତୁ,, AMD 8132 ଚିପସେଟ ସନ୍ଦେଶ ସାଙ୍କେତିକ ହସ୍ତକ୍ଷେପ (MSI) କୁ ସମର୍ଥନ କରେ ନାହିଁ। ଆପଣଙ୍କ ତନ୍ତ୍ର ଏହି ଚିପସେଟ ବ୍ଯବହାର କରୁଥିଲେ, ଆପଣ ମଧ୍ଯ MSI କୁ ନିଷ୍କ୍ରିୟ କରିବା ଉଚିତ। ଏପରି କରିବା ପାଇଁ, ସ୍ଥାପନ ସମୟରେ -pci nomsi କର୍ଣ୍ଣଲ ପାରାମିଟରକୁ ବ୍ଯବହାର କରନ୍ତୁ ଏବଂ ପୁନର୍ଚାଳନ କରିସାରିବା ପରେ GRUB ରେ pci=nomsi କୁ ଯୋଗ କରନ୍ତୁ।

ତଥାପି, , ଆପଣଙ୍କର ନିର୍ଦ୍ଦିଷ୍ଟ ସମସ୍ଯା କର୍ଣ୍ଣଲ ଦ୍ବାରା ସନ୍ଦେହ ଭାଜନ ତାଲିକା ଅନ୍ତର୍ଭୂକ୍ତ ହୋଇଥିଲେ, ଆପଣଙ୍କ ତନ୍ତ୍ର ପୂର୍ବୋକ୍ତ pci କର୍ଣ୍ଣଲ ପାରାମିଟର ଆବଶ୍ଯକ କରି ନ ଥାଏ। ନିମ୍ନଲିଖିତ HP ପ୍ଲାଟଫର୍ମ ଗୁଡିକ ପୂର୍ବରୁ କର୍ଣ୍ଣଲ ଦ୍ବାରା ସନ୍ଦେହ ଭାଜନ ତାଲିକାରେ ଅନ୍ତର୍ଭୂକ୍ତ କରାଯାଇଛି:

ଏହି ପ୍ରକାଶନରେ ଅନ୍ତର୍ଭୂକ୍ତ କରାଯାଇଥିବା ଆଭାସୀ ମେସିନ ପରିଚାଳକ (virt-manager) ଚାଳକକୁ ଆଂଶିକ ଅତିଥି ସ୍ଥାପକ ପାଇଁ ଅତିରିକ୍ତ ବୁଟ ସ୍ବତନ୍ତ୍ରଚରକୁ ନିର୍ଦ୍ଦିଷ୍ଟ କରିବାର ଅନୁମତି ଦେଇ ନ ଥାଏ। ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରକାରର ହାର୍ଡୱେରରେ କିଛି ବିଶେଷ ଧରଣର ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ମାନଙ୍କୁ ସ୍ଥାପନ କରିବା ପାଇଁ ଏପରି ସ୍ବତନ୍ତ୍ରଚର ଗୁଡିକ ଆବଶ୍ଯକ ହେଉଥିବା ସମୟରେ ମଧ୍ଯ ଏହା ସତ ଅଟେ।

ଏହି ସମସ୍ଯାକେ virt-manager ର ପରବର୍ତ୍ତୀ ସଂସ୍କରଣରେ ଆଲୋଚନା କରାଯିବ। ପାଠ୍ଯ ନିର୍ଦ୍ଦେଶରୁ ଆଂଶିକ ଆଭାସୀକୃତ ଅତିଥି ମାନଙ୍କୁ ସ୍ଥାପନ କରିବା ପାଇଁ ଏକପକ୍ଷୀୟ କର୍ଣ୍ଣଲ ସ୍ବତନ୍ତ୍ରଚର ପ୍ରଦାନ କରିବା ପାଇଁ, virt-install ନିର୍ଦ୍ଦେଶକୁ ବ୍ଯବହାର କରନ୍ତୁ।

ଗୋଟିଏ ପୂର୍ବବର୍ତ୍ତୀ ବିଫଳ ପଥ ପୁନଃସ୍ଥାପିତ ହୋଇସାରିବା ପରେ, ପୂର୍ବନିର୍ଦ୍ଧାରିତ dm-multipath ବିନ୍ଯାସ ସହିତ, Netapp ଉପକରଣ ଗୁଡିକ ଫେଲବେକକୁ ସମ୍ପନ୍ନ କରିବା ପାଇଁ କିଛି ସମୟ ନେଇପାରନ୍ତି। ଏହି ସମସ୍ଯାକୁ ସମାଧାନ କରିବା ପାଇଁ, multipath.conf ଫାଇଲର devices ବିଭାଗରେ ନିମ୍ନଲିଖିତ Netapp ଉପକରଣ ବିନ୍ଯାସକୁ ଯୋଗକରନ୍ତୁ:

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