Live Upgrade ate my system
By tdw on Oct 04, 2006
Since I already upgraded my system from Solaris 9 to Solaris 10 using Live Upgrade, I thought this would be a doddle, and indeed it was.
First, delete the old Solaris 9 boot environment:
# ludelete solaris_9
Next, create the new boot environment on the same partition as the old Solaris 9 partition:
# lucreate -m /:/dev/dsk/c0t1d0s0:ufs -n solaris10_u2 -f /tmp/excludesNote that here I tried to exclude some file systems which I would rather not be part of the new BE. Sadly, this failed, for some reason (maybe because they are part of the current boot env).
Now, do the upgrade from the Solaris 10 6/06 DVD:
# luupgrade -u -n solaris10_u2 -s /cdrom/sol_10_305_sparc/s0
And finally, activate the new boot environment and reboot:
# luactivate solaris10_u2 ... # shutdown -y -i6 -g0
Those of you already familiar with Live Upgrade will no doubt know that the luactivate command spouts out some information about what to do if your new boot environment fails. It turns out that this was a life-saver for me - especially as I was rather rash in attempting to fix the mess which followed the reboot.
So, the system rebooted and it was immediately apparent that something had gone badly wrong with the live upgrade. A number of modules could not be loaded because of missing symbols: aggr and zfs to name but two. Then, when X-windows tried to start up, it failed and I see I have a core file from 'dtgreet' left in the root directory.
Unfortunately, here's where I panic'ed (no pun intended). Instead of thinking rationally about the problem, I thought it must be a kernel issue, so I rather rashly copied over /platform/sun4u/kernel/sparcv9/unix from the original boot environment into the same place on the current boot environment (without making a backup!!!!!!). Surprise, surprise, ... on attempting to reboot, the kernel panic'ed early in the boot and that was game over.
After some faffing around booting from DVD and trying to correct the fault, I finally recalled the sage words spouted by luactivate, so I managed to pull these from the handy-dandy typescript file I cunningly made whilst performing the upgrade.
luactivate says to "Mount the Current boot environment root slice". However, what you really need to do is to mount the old boot environment root slice, because it is that you need to activate. That's worth remembering!
Now comes another tricky bit: for some bizarre reason, when booting from DVD, the device tree for the disks is set up with the disks hanging off controller 1 instead of controller 0 as they are in the disk boots. So, you happily mount the old boot environment root slice and try to run the luactivate command to reactivate that BE. Needless to say, this fails with a complaint about it being on the wrong disk partition.
The fix for this is to do the following (assuming c0t1d0s4 is the old BE and c0t1d0s0 is the currently active BE):
# cd /dev/dsk # ln -s c1t1d0s4 c0t1d0s4 # ln -s c1t1d0s0 c0t1d0s0 # cd ../rdsk # ln -s c1t1d0s2 c0t1d0s2Then, mount the correct device and run luactivate. This should run through successfully.
Finally reboot and we're back to where we were before we started.
I'm not sure if I should re-attempt the live upgrade or just give it up as a bad job for the moment, but I thought I'd share my experience (and stupidity) in case it is helpful to anyone else.