bosboot after exchanging all rootvg PVs?!

[tboege]

Hi all,

I often excountered a problem after migrating the whole rootvg from some disks to other disks. The problem occurs when running the bosboot -a command w/o the device flag set to a specific disk device. If one omits the device parameter, bosboot calls the bootinfo command to determine the correct disk device to put the BLV content on (bootinfo -b). As we migrated the whole rootvg, bootinfo gives back an old hdisk device which WAS the boot device, but either is no longer bootable or non-existant anymore (if you already deleted the disk).
In either case there is an error message (hd5 not found on the disk specified OR missing disk parameter as bootinfo returns an empty string).


DOES ANYBODY IN THIS UNIVERSE KNOW HOW TO FIX THIS?
I've googled, I've searched IBM, I can't find any solution... Maybe I'm missing just a simple command to tell the kernel which disk is now holding the BLV?

Thanks a lot!!!

 

[hirschaj]

The bosboot command relies upon the /dev/ipldevice file when running it without specifying a device. /dev/ipldevice is a hard link to the device you booted off of. You can change it to point at your new OS disk by running this command.....

ln -f /dev/hdiskX /dev/ipldevice

Hopefully it is obvious that you would replace hdiskX with whatever disk you migrated your OS to. Give it a shot and let me know if it worked.

Jim Hirschauer

http://www.aixexpert.com

 

[tboege]

Well, if of all thank you very much fpr the reply. But this does NOT solve it. See my output (I've done this before posting):

root@aix005:/dev>rm ipldevice
root@aix005:/dev>ln -f rhdisk0 ipldevice
root@aix005:/dev>ls -la | grep 14,\ \ [01]
brw------- 1 root system 14, 0 Mar 20 12:55 hdisk0
brw------- 1 root system 14, 1 Mar 20 12:55 hdisk1
crw------- 2 root system 14, 0 Mar 20 11:48 ipldevice
crw------- 2 root system 14, 0 Mar 20 11:48 rhdisk0
crw------- 1 root system 14, 1 Mar 20 11:48 rhdisk1

root@aix005:/dev>lspv -l hdisk0 | grep hd5
hd5 1 1 01..00..00..00..00 N/A
root@aix005:/dev>lspv -l hdisk1 | grep hd5
hd5 1 1 01..00..00..00..00 N/A
root@aix005:/dev>bootinfo -b
root@aix005:/dev>bosboot -a
0301-150 bosboot: Invalid or no boot device specified!
usage: bosboot {-a | -v} [-d device] [-p proto] [-k kernel] [-l lvdev]
[-b file] [-M serv|norm|both] [-D|-I] [-LTq]
Where:
-a Create boot image and write to device or file.
-v Verify, but do not build boot image.
-d device Device for which to create the boot image.
-p proto Use given proto file for RAM disk file system.
-k kernel Use given kernel file for boot image.
-l lvdev Target boot logical volume for boot image.
-b file Use given file name for boot image name.
-D Load kernel debugger.
-I Load and Invoke kernel debugger.
-M norm|serv|both Boot mode - normal or service.
-T platform Specifies the hardware platform type.
-q Query disk space required to create boot image.
-L Enable MP locks instrumentation.

root@aix005:/dev>

THANKS!

 

[kHz]

Have you tried 'bosboot -ad /dev/hdisk0' ?

 

[tboege]

Yes, this is working. But it is not only a matter of convenience NOT to type -ad /dev/hdiskX but smitty/installp is often running it, too. There MUST be any fix for this, otherwise one would have to reboot the server just to fix it...

 

[hirschaj]

You could try the procedure list here.....

http://publib16.boulder.ibm.com/pse...base/43_docs/aixprob/prbslvgd/reintrootvg.htm

Jim Hirschauer

http://www.aixexpert.com

 

[kHz]

Have you cleared the BLV from the old disk(s)?

 

[tboege]

Thanks Jim, ut I don't think that this is the correct way to solve it (but have to confess that I did not read it entirely yet). Seems to recover more then I need as my problem is only a small one (in fact everything's working beside the smitty-complains-when-installing-software-problem)... ;-)

No, I haven't done so. Do you think that this will produce any difference here? Thought that chpv -c only whipe's out the "master boot record" ;-) But probably it's doing something more, will try... hang on, tomorrow I'll give it a try.

BTW: Thanks for your idea and help, guys!

 

[tboege]

@Jim: This looks like cleaning up all ODM entries for the rootvg, but I don't think that the "last boot device" is in the ODM at all: I did some odmgets on CuAt and CuDv but couldn't locate any entry that might cause my problem. I think that the running kernel maintains this information in memory. As I said: If you simply reboot the server the problem's fixed. But anyway, thanks a lot for that reply!

 

[hirschaj]

I ran a trace on the "bootinfo -b" command and after reding through the 9000+ lines of output I am convinced that the info about what device you booted the system from resides in nvram or possible gets embedded in the Kernel. There are many entries in the trace report where the system is accessing /dev/nvram. Here is a list of files that my system tried to access to complete the "bootinfo -b" command (sorted in alphabetical order)...

/../etc/bootdev_type_1
/../etc/bootdev_type_2
/../etc/bootdev_type_3
/../etc/bootdev_type_4
/../etc/bootdev_type_5
/dev/nvram
/dev/systrctl
/etc/bootdev_type_1
/etc/bootdev_type_2
/etc/bootdev_type_3
/etc/bootdev_type_4
/etc/bootdev_type_5
/etc/bootinfo
/etc/objrepos/CuDv
/etc/objrepos/CuPath
/etc/objrepos/CuPath.vc
/etc/objrepos/PdAt
/etc/objrepos/PdAt.vc
/etc/objrepos/PdDv
/etc/objrepos/PdDv.vc
/etc/objrepos/SWservAt
/etc/objrepos/SWservAt.vc
/unix
/usr/bin/bootinfo
/usr/bin/trcstop
/usr/lib
/usr/lib/boot/bin/bootinfo_chrp
/usr/lib/boot/bin/libcfg_chrp
/usr/lib/libC.a
/usr/lib/libc.a
/usr/lib/libc_r.a
/usr/lib/libcfg.a
/usr/lib/libcrypt.a
/usr/lib/libodm.a
/usr/lib/libpthreads.a
/usr/lib/libtrace.a
/usr/sbin/bootinfo

So I think you are correct that only a reboot will fix your issue. Hope this info helps.

Jim Hirschauer

http://www.aixexpert.com

 

[kHz]

Actually you should reboot after running a bosboot. In your case run the bosboot -ad and reboot. Your problem would be solved.

 

[tboege]

Thanks to all!
I tried to answer yesterday but this site has had problems... The solution is to either boot or replace bosboot with a wrapper script that does not call bootinfo but searches the bootdisk by calling lslv -m hd5 and awk.
There seems to be no other possibility or workaround.

If some IBM'er is reading this: HINT HINT HINT, please fix this behaviour as migrating the rootvg ONLINE to other disks and wanting to stay up and running (w/o loosing the chance to "smitty install" software is not that unusual, or is it?

Again, thanks for your replies...!!!!