In part 2 of this series, Anthony English covers a few of the surprises you can face when you reboot your AIX OS, including using the correct boot device, retaining device attributes, performance tuning settings, and partition profiles.
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:
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:
Method error (/usr/lib/methods/chggen):
0514-029 Cannot perform the requested function because a
child device of the specified device is not in a correct state.
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.
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.
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. (And you can find a lot of handy tips and tricks in my eBook, "AIX Logical Volume Manager First Aid Kit.")
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.