Watch the AIX Reboot Gotchas, Part 2: Bootlist and Devices

In part one of this series, I looked at some of the gotchas that can occur when you reboot your AIX OS and find that file systems don't come up or the application startup scripts let you down. In this article, I'll cover a few of the other surprises you can face when you reboot. Here are four big-ticket items that need attention:

• using the correct boot device
• retaining device attributes
• performance tuning settings
• partition profiles

Let's face it: Reboots ain't what they used to be. I remember the days when we rebooted every week just to clear out the cobwebs. These days, reboots are so rare that they're almost illegal, so you might not be ready for what happens to your environment after that magic reboot. Here's how to prevent yourself from getting caught out.

Check Your Bootlist

First, it's important to ensure that when you reboot, you use the correct boot image. Some commands will, by default, create a new boot device and point to that as the image to boot from (multibos, for instance). Multibos lets you create a second Base Operating System (BOS) image within the same root volume group (rootvg). By default, multibos changes the bootlist to use the alternate BOS image. That can be a problem, especially if your standby instance was created a long time before the reboot. Think of it: you might be using the primary BOS image, changing passwords, and installing software, only to discover when you reboot that you're now pointing to the AIX OS created when the multibos standby instance was set up—and all because multibos changes the bootlist.

You can stop that bootlist change by using the-t flag when you run multibos to create the standby image.

Cloning the rootvg

It's always worth checking the bootlist before you reboot. If you clone a root volume group to another disk using alt_disk_copy, then the bootlist (unlike multibos) doesn't get changed to the alternate disk. If you do want to boot off the alternate disk, you'll need to run the bootlist command.

Also, if you're using software mirroring to mirror a volume group—or to unmirror it—you'll be prompted to update the list of boot devices using the bootlist command. This is another time when it makes sense to check your bootlist.

If the boot image isn't the one you expect to be booting from, you might find yourself booting off an image that has a password you don't know, or is running an old version of the OS. So when the boot image gets updated, make sure that the bootlist contains the boot images you want, in the order you expect them to be.

You can check the list of boot devices for normal (multi-user) mode using the bootlist command:

Device Attributes

You should also be aware of changes to device attributes (e.g., for disks and adapters). If you attempt to change a device attribute, you might get an error if the device is in use. For example, if you try change the fast_fail attribute on a virtual SCSI (VSCSI) adapter but it has open paths to a disk, you'll get a message similar to this:

To prevent this, you could temporarily disable or remove the child devices, make the change to the attribute, and then reinstate the original device, which in this case is a VSCSI adapter. Alternatively, you could make the change by setting the permanent flag (-P). This makes the change in the Customized Attributes object class, but it will only take effect at the next reboot.

Incidentally, if you were able to make the change without the -P flag, the change should survive the reboot.

Performance Tuning

When you change tunable parameters using commands such as vmo for the virtual memory manager, you can apply the change immediately or as part of the next reboot process. If you make the change just for now, it won't survive the reboot. However, you do have the option to set the change as part of the next reboot. If you do that, the changes will be written to a text file called /etc/tunables/nextboot, which is read as part of the boot process.

You can find more details by selecting the performance tuning options in SMIT, or looking up the AIX performance tuning documentation.

Partition Profile/DLPAR

This last gotcha has to do with making dynamic changes using Dynamic LPAR (DLPAR). As the AIX 7.1 Documentation Center explains:

"Dynamic Logical Partitioning (DLPAR) allows you to dynamically allocate additional resources (such as memory and CPUs) to each logical partition, if needed, without stopping the application."

In other words, the change is only for the current, running OS. If you do a soft reboot, such as with the reboot command or shutdown -r, the resources allocated won't be changed from what they were before the reboot. But if you do a hard shutdown (that's a shutdown without the -r to reboot), you need to activate the partition profile to get the logical partition started again. That will use the resource configuration you have in the partition profile, which might be different from the one you changed dynamically using DLPAR.

That means is that if you make a change using DLPAR, and you want to make it permanent, you’ll need to make the corresponding resource changes in the partition profile. Fortunately, if you’re using a Hardware Management Console (HMC) to connect to your Power System, you should be able to save the current configuration (including any resource changes made via DLPAR) and use that the next time you need to activate your partition after a cold shutdown. My article “Mastering Soft and Hard Shutdowns” has more information on this topic.

Reboot Ready

There’s no reason for a reboot to be more dramatic than necessary. If you’re aware of changes that will (or won't) take effect after the reboot, you'll be ready to beat the reboot gotchas.

 

Learning Path

"Mastering Soft and Hard Shutdowns"

AIX Boot Path Enablement

AIX multibos command

Clone a rootvg using alt_disk_copy command

View or change your bootlist

Performance management – Reboot Tuning Procedure