Mirrored root and kernel rebuild

[VINCENT SPURGEON]

Once upon a time, a couple weeks back, I had all my filesystems mirrored on two internal drives, (HPUX 11.0, N-Class, 18GB drives).

I could boot off the second drive (hpux -lq) with no problem. And as far as I was concerned things worked great.

Then I decided to rebuild the kernel via SAM... (installing MQ-Series) and it would not boot properly. GSP complained of software problems or failures.

I had to boot with "hpux -lq"; then I went in and removed all the mirrors; and re-created the mirrors. It boots with the correct kernel and is back to normal.

A couple of things:

Should I not use SAM to rebuild the kernel when the drives are mirrored? This worked on a duplicate system that does not have mirrored filesystems, but is running LVM.

If I do use SAM to rebuild the kernel, should I reduce the mirrors first, rebuild the kernel, run "mkboot", then increase the mirrors?

[John Palmer · Accepted solution]

Hi,

SAM is fine for reconfiguring the kernel (it's about the only thing that I do use it for). Mirrored disks do not make any difference to the kernel rebuild.

No you shouldn't reduce the mirrors first. I don't know what your original problem was, maybe you could give some more information...

hpux -lq causes the system to boot even if the boot volume group's disk quota is not met. So if you had two disks in vg00 then hpux -lq allows you to boot with one of them missing.

Regards,
John

[James R. Ferguson]

Vincent:

1. There is no need to rebuild a kernel when mirroring is turned on or off.

2. It is always best to use SAM to tune kernel parameters or to add or subtract drivers from the kernel. SAM "knows" of the proper relationships among various parameters. Thus, using SAM will generate a well-balanced kernel. The risk of creating an unbootable system (because of a grossly misconfigured kernel) are greatly reduced with SAM.

SAM automates the kernel generation steps so nicely that its a "no-brainer". With SAM's builtin help for viewing what each kernel parameters allowable values are, along with a brief description of their purpose, how can you lose?! :-))

3. I personally don't see a need to reduce your mirrors before a kernel rebuild and reboot only to add them back afterwards. SAM always preserves the current kernel as /stand/vmunix.prev and in a crisis, you can always boot from this as viable kernel code.

...JRF...

[Alan Riggs]

Mirrors should cause no problem for a kernel rebuild. I do not know why SAM failed, but I think it unlikely to have been caused by the LVM mirroring.

As to the question of splitting mirrors, it is by no means necessary. However, it might not be a bad idea. Not to solve the problem you had this time, but simply as a fast means of backing out an install that fails. Obviously, if all you have done is a kernel change then you can simply put the saved vmunix file back in place and reboot. If you have installed multiple patches or a large patch bundle, though, backing out a change can be cumbersome and time consuming. If you have split mirrors beforehand, you can simply boot off of the split mirror, and then resync "backwards" to restore your original root drive configuration.

As I say, this is not necessary, and I do not do it for every, or even most, patching. However, I keep the procedure around for large updates that I feel might be troublesome/complicated to back out.

[Joel Shank]

Be careful about splitting mirrors and thinking you can merge them back after a reboot. I do not think LVM remembers the split after a reboot, so it won't merge it. You can split the mirror and save it as a separate logical volume, however, and use it that way.

As for breaking mirrors when rebuilding the kernel, you should not have to. All my servers have always used mirrors and I have never had a problem with kernel builds, except once, but that was a bug in SAM.

JLS

[Tim Nelson]

Never trust an application to do what you can do for yourselve. I have had enough problems with SAM's mistakes with 9.04, 10.20 and 11.0. I use SAMto check descriptions and limits for kernel tunables and that is it. I prefer to have more control over what I am doing. Edit the system file run mk_kernel then kmupdate if you are using 11.0.
Leave the menu driven admin utilities to those who do not wish to understand.

[VINCENT SPURGEON]

Today, regen'd the kernel and rebooted w/o incident. I suspect the problem the last time around was my mirrors and since then I was a bit gun shy with this production server. Thanks for the help.