Live Upgrade works like this:
- Create a "boot environment" (BE) representing your current system
- Create an "alternate boot environment" (ABE) which is a clone of your BE
- Run a Solaris upgrate against the ABE
- Switch the active "boot environment" to the ABE
This whole procedure is also easier if you separate your system partitions from your data ones. Yes, I know this is normally a good practice. However, I've grown to just use a huge "/" and smaller "/var" on most of my machines these days. It's just easier, and I still have "/home" on an external file server.
So what was I to do? The Solaris 10 6/06 DVD set was here, and I wanted to upgrade. (my server was running the original Solaris 10 release) I needed something large to make my ABE on, but also needed it to be somewhere I was comfortable using as my long-term boot drive. I also wanted to avoid involving anything beyond that server itself. Then it occured to me... the "system disk" of my server was actually an SVM mirror set!
In short form, here was my plan of action:
- Make a backup (thankfully this machine has a DDS3 drive installed in it)
- Remove the second disk from the mirror and unconfigure its meta devices
- Run live upgrade, using that second disk as the ABE
- Switch the default BE to the one on the second disk
- Boot off the second disk, into the new version of Solaris
- Make sure the server is still working correctly
- Unconfigure the mirror devices in SVM
- Recreate the meta devices on the second disk, mirrors containing them, run metaroot, etc.
- Reboot again
- Add the first drive back into the mirrors
While I should now show a complete walkthrough of what I did, a full post-mortem reconstruction would be rather tedious. Besides, if you're familar with SVM and can read through Sun's LU docs, following my strategy should be straightforward and simple. (yes, it does work) Just remember to install the recommended patches before using LU, or it'll fail.
Also, I strongly recommend mounting the upgraded ABE before that first reboot. You should then check the "/var/sadm/system/data/upgrade_cleanup" file for any changes of interest that it made. I failed to do this myself, and wound up having sendmail misconfigured for several hours. On the bright side, it does make backup copies of any configuration files that it changes.