Upgrading your AIX environment using multibos
If you haven’t clued on by now, AIX is my operating system of choice. I’m sure there are many arguments for and against, but looking at it from a systems administrator view point, it’s second to none. Anyway, that’s a story for another time. What I’m writing about today is patching your AIX installations using multibos. Now before I get started, I’ll stress two points:
1) Chris Gibson has already written two great (and far more in depth) articles on multibos, which I recommend reading before going any further (Links: here and here).
2) This blog of mine serves two purposes; To share some of the things I come about during my sysadmin activities and secondly also a dumping ground for documents I write for myself. This post is the latter, as multibos isn’t something that I use daily (maybe a few times a year), and really, who’s going to remember all those syntax switches
2) This blog of mine serves two purposes; To share some of the things I come about during my sysadmin activities and secondly also a dumping ground for documents I write for myself. This post is the latter, as multibos isn’t something that I use daily (maybe a few times a year), and really, who’s going to remember all those syntax switches
Now, assuming you’ve read both articles, I don’t need to go into the benefits of multibos and I’ll dive straight into the how. I’ll be working on upgrading an AIX instance running 6100-05-01-1016 to the latest ML which at the time of writing is 6100-06-04-1112
PREREQUISITES
First things first, we need to make sure the current environment is ready to be copied. The two main things that I look for are:
PREREQUISITES
First things first, we need to make sure the current environment is ready to be copied. The two main things that I look for are:
1. Make sure the current environment doesn’t have any missing filesets.
**Note: If a particular ML doesn’t return positive (e.g. 6100-05_AIX_ML), use instfix -ciqk 6100-05_AIX_ML | grep “:-:” to see the fileset causing issues and rectify it.
2. Make sure all filesets have been committed. Now I’m not entirely sure if this is a requirement, but I prefer to work with an as clean environment as possible.
**Note: If you have software which is in an applied state, commit it.
Now that we’re happy with the state of the environment, you need to verify that there is enough room in rootvg to make copies of the following logical volumes [/ (hd4), /usr (hd2), /var (hd9var), /opt (hd10opt) and the boot logical volume (hd5)].
Once we’ve satisfied the above requirement, we can get started with the multibos work. I’m not going to dissect each command, so I suggest reading the multibos man pages to know what each switch does. The only one that I’ll explain is -p, which does a preview of the multibos command executed.
MULTIBOS
1. Remove any previous standby multibos environments. The below command will return a FAILURE status if you don’t have a standby multibos environment. If you’re using multibos for the first time, this will be the case.
1. Remove any previous standby multibos environments. The below command will return a FAILURE status if you don’t have a standby multibos environment. If you’re using multibos for the first time, this will be the case.
2. Create the standby BOS. New logical volumes and filesystems will be created prefixed and with bos_. This can take a while to complete.
This will preview the creation of the multibos environment and list all the logical volumes that will be copied.
You can also view the log file using the alog command.
If everything completed successfully, run the command again without the preview.
Once complete, you’ll notice that the new logical volumes will be prefixed with bos_
3. Once complete, you can drop into a multibos shell and check oslevel, it should be the same as the host OS.
The below command will mount all the filesystems required and drop you in a MULTIBOS> prompt
To umount all the filesystems and break out of the multibos environment.
4. Apply the TL/ML to the multibos environment.
The below command will tell multibos to apply the updates from the specified location (which is the location that your new ML resides).
Drop into the multibos shell again and check that the ML has been successfully applied.
5. Verify that the bootlist now contains blv=bos_hd5. bos_hd5 is the location of the new boot logical volume. It will be at the top of the list when you run the bootlist command.
You can now reboot into the new environment and verify that all went to plan.
6. If you need to back out of the change for any reason, just change the bootlist order back to blv=hd5 and reboot. Now, while this doesn’t bother me, it may bother others. You’ll notice after the reboot that your environment is now using the bos_ logical volumes. The only way to get your environment back to how it was using the original logical volume names is to create another multibos environment, and reboot into it. Since your current boot environment is using the bos_ logical volumes, it will create it using the original logical volume names (i.e. without the bos_). For those that want to do that, redo step 2 and reboot. However, I suggest not doing this for a week or so to be sure you’re happy with the new changes, as creating a new multibos environment will remove the backup environment with the previous ML.
As always, post comments/questions below.
Thanks to http://www.kristijan.org