by The process of installing and configuring Live Upgrade on Solaris is pretty well covered at this stage but, as ever with Solaris, there is always something that is not covered in the many existing documents and blog postings on the subject. So, here is an overview of what I did, what worked, what did not work and how I overcame the bits that did not work.
Setup
I wanted to use Live Upgrade to ease the painful patching process on Solaris (not to upgrade the operating system). I tried this on a SunFire T1000 and a SunFire T2000 both running Solaris 2.10 U3 (06/06). In both cases, the systems contained 2 existing 10GB UFS file systems (/ on c0t0d0s0 and /opt on c0t0d0s3) as well as a swap partition (c0t0d0s1).
What Did Work
Following the Live Upgrade documentation from the Sun website, I narrowed the commands down to the following steps:
Create a new partition to accommodate the Alternative Boot Environment
# format
Created a Live Upgrade configuration:
# lucreate -c solaris_env_1 -n solaris_env_2 -m /:/dev/dsk/c0t0d0s4:ufs
Verified the successful creation using
# lustatus
# lucurr
Downloaded any available patches for this system
# smpatch download
Install the downloaded patches in the alternative boot environment
# smpatch update -b solaris_env_2
Reboot the system in the recommended manner
# init 6
What Did Not Work
No matter how many times I retried to reboot the system (in full accordance with the instructions in the documentation), the system simply refused to boot from the new/alternative boot environment. Each time, the lustatus command showed that both boot environment were correctly configured and that the alternative environment (solaris_env_2) was scheduled to boot at the next reboot. However, it never did boot from the alternative environment.
Apparently, when the patch process completes successfully (or whenever you use the luactivate command), the system should automatically update the boot-device EEPROM environment variable (see eeprom command from Solaris).
Workaround
I found that the only way around this problem was to manually adjust the boot-device environment variable from the system console each time you need to boot an alternative boot environment. This was done (from the system console) as follows:
Shut down the system
# init 0
Determine the appropriate setting for the boot-device variable
ok setenv auto-boot? false
ok reset-all
ok probe-scsi-all
ok show-disks
Using the output from the above commands, determine a new value for the boot-device variable. For example:
ok setenv boot-device /pci@7c0/pci@0/pci@8/scsi@2/disk@0,0:a
Verify that the system still boots from the old/existing environment
ok boot
If so, you should now be able to drop back to the boot prompt and set the boot-device variable to a new value in accordance to the Live Upgrade partition you created earlier (in my case, c0t0d0s4 or disk@0,0:e)
ok setenv boot-device /pci@7c0/pci@0/pci@8/scsi@2/disk@0,0:e
Also, you might like to return auto-boot setting to its normal value before booting the system again
ok setenv auto-boot? true
ok boot
Best of luck!
I’ve seen this problem too — there is no way to get luactivate to work. I have a ticket open with Sun — did you do the same?
No, I meant to do this but it turns out that I did not. Which is the best site to log such issues with Sun?
Do you have a support contract? If not, I’m not sure what the best way is — I will mention this link to them at least, however.
Just to follow up, Sun support says that luuactivate will not work if in eeprom diag-switch?=true, which my system had. I haven’t tried booting the machine yet (not allowed), but at least they have pointed to a solution.
Thanks for the tip Ryan.
I will take a look at the diag-switch setting on one of my test systems and see if it makes any difference.
Ryan,
I finally managed to get around to testing this today and I’m delighted to report that it worked a treat. Here is what I did:
You must change the diag-switch setting before you use the luactivate command.
I also found another article which includes the above eeprom command before an luactivate command although it doesn’t make any specific reference to it.
Thank you for your input.
I hadn’t tried it the other way, since I did the eeprom command immediately and didn’t boot for awhile after. Does seem to have cured the problem.
Glad I could help!
Thanks so much! Between this and the cpio bug in zones I have been going nuts this week. All better now!
Damian,
Thanks for your positive feedback, it’s always good to know you’re not alone!
Can you post some details about the cpio bug in zones that you refer to? I’d be interested in finding out more about this as we use zones quite a bit here.