IC SunsetThe developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this blog will no longer be available. More details available on our FAQ.

Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (4)

cggibbo commented Dec 19 2012 Comment Permalink

Hi Somesh, If you recorded the bootlist output prior to rebooting then you can use this information to determine which disk to boot from in the openfirmware prompt. For example: # bootlist -m normal -ov 'ibm,max-boot-devices' = 0x5 NVRAM variable: (boot-device=/vdevice/v-scsi@30000002/disk@8100000000000000:2 /vdevice/v-scsi@30000003/disk@8100000000000000:2) Path name: (/vdevice/v-scsi@30000002/disk@8100000000000000:2) match_specific_info: ut=disk/vscsi/vdisk hdisk0 blv=hd5 pathid=0 Path name: (/vdevice/v-scsi@30000003/disk@8100000000000000:2) match_specific_info: ut=disk/vscsi/vdisk hdisk0 blv=hd5 pathid=1 At the openfirmware prompt: 0> boot /vdevice/v scsi@30000002/disk@8100000000000000:2 | Where: /vdevice - Virtual I/O Bus /v-scsi@30000004 - Virtual I/O SCSI Adapter /disk@8100000000000000:4 - Virtual I/O SCSI Disk Device This is documented in the following article: http://www.ibmsystemsmag.com/aix/trends/aix/AIX-Updates-With-Multibos/ Or you could simply boot into SMS and select the alternate boot disk partition. Good luck! Cheers. Chris

SomeshChourey commented Dec 19 2012 Comment Permalink

Hi Thanks for the document I tried this way and when i rebooted with multibos boot device its not booting up Can you please how can i boot the server with an old boot device . Error code :e14d led code Can you please help This is what the error when i tried to boot from raritan console : boot Unable to use memory at load-base Data stack pointer = c10ff8 000000c10ff0: 00 00 00 00 00 00 00 10 ff ff ff ff ff ff ff fe :................: 000000c11000: 00 00 00 00 de ad be ef 00 00 00 00 00 00 00 00 :................: 000000c11010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: 000000c11020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: Call History ------------ throw - c3ba04 $abort - c47c80 map-load-addr - c8a648 $load - c8a748 (poplocals) - c3d040 (load) - c8ab08 boot|load - c8ba18 boot - c8c1f0 evaluate - c4d1c0 ^c17100 - c17100 invalid pointer - 4 invalid pointer - 4 quit - c4dadc quit - c4d698 My Fix Pt Regs: 00 0000011000000000 9000000000003002 00000000deadbeef 0000000000c47c7c 04 0000000000000021 0000000000c8a621 0000000000c11f58 0000000000c03008 08 0000000100000000 00000000fd677f5f 0000000000c8a744 0000000000000000 0c 0000000000009ec8 0000000000000000 0000000000000000 0000000000000000 10 0000000000ee5170 0000000000ee5120 0000000000c47c74 0000000000c47c80 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c43338 0000000000c11f90 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 48808044 %XER: 20000000 %DSISR: 00000000 %SRR0: 0000000000c43160 %SRR1: 900000000000b002 %LR: 0000000000c3f73c %CTR: 0000000000000000 %DAR: 0000000000000000 Note: SRR0, SRR1, R0-R2 may have been altered by a dec-int. ok 0 > boot Unable to use memory at load-base Data stack pointer = c10ff8 000000c10ff0: 00 00 00 00 00 00 00 10 ff ff ff ff ff ff ff fe :................: 000000c11000: 00 00 00 00 de ad be ef 00 00 00 00 00 00 00 00 :................: 000000c11010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: 000000c11020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 :................: Call History ------------ throw - c3ba04 $abort - c47c80 map-load-addr - c8a648 $load - c8a748 (poplocals) - c3d040 (load) - c8ab08 boot|load - c8ba18 boot - c8c1f0 evaluate - c4d1c0 ^c17100 - c17100 invalid pointer - 4 invalid pointer - 4 quit - c4dadc quit - c4d698 My Fix Pt Regs: 00 0000011000000000 9000000000003002 00000000deadbeef 0000000000c47c7c 04 0000000000000021 0000000000c8a621 0000000000c11f58 0000000000c03008 08 0000000100000000 00000000fd677f5f 0000000000c8a744 0000000000000000 0c 0000000000009ec8 0000000000000000 0000000000000000 0000000000000000 10 0000000000ee51c0 0000000000ee5170 0000000000c47c74 0000000000c47c80 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c43338 0000000000c11f90 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 48808044 %XER: 20000000 %DSISR: 00000000 %SRR0: 0000000000c3cf44 %SRR1: 900000000000b002 %LR: 0000000000c3f73c %CTR: 0000000000000000 %DAR: 0000000000000000 Note: SRR0, SRR1, R0-R2 may have been altered by a dec-int. ok Thanks Somesh Chourey

cggibbo commented Feb 25 2011 Comment Permalink

Fraser, Yes that would be a logical way to use it. Although I can't help but feel like I've just jumped through several hoops to do something I could have done with NIM alone, in a lot less steps. Perhaps this would be useful if you did not have access to a NIM server at a remote site but you had one at your local site. You could do the nimadm mksysb migrate at the local site, then ftp the mksysb image over to the remote site and use multibos to "migrate" the remote LPAR to the higher-level of AIX. I guess one advantage is you don't need a spare disk with the multibos method as opposed to nimadm. Food for thought either way.

fjw999 commented Feb 24 2011 Comment Permalink

Do you think it would work if you took a mksysb image of your 6.1 system then used nimadm to upgrade it to 7.1 and use that image to restore to your multibos standby image. This way you would keep all your users etc. howerver the -M flag might prevent that. Fraser