But what is it good for?

Posts tagged with: live-upgrade

Upgrading VxVM and/or Solaris using Live Upgrade

Did you know you can now upgrade both VxVM AND Solaris using Live Upgrade without reverting to underlying devices? I didn't, until today when I discovered a document on exactly this topic from Symantec: Upgrading VxVM and/or Solaris using Live Upgrade. From what I can see in this document, it appears VxVM now comes with it's own wrapper scripts for the standard Live Upgrade called vxlustart and vxlufinish respectively. BOTH commands are supplied on the VxVM 5.0 (and later media) and they both require and expect the native Live Upgrade pkgs and patches to be already applied to the system... Continue reading ►

Free Solaris 10 Patching Best Practices Training

If you think Solaris patching is a complete nightmare, have a bit of spare time on your hands (don't worry, you can still check emails etc) and really want to get up speed on Sun's best practices for patching on Solaris 10, then check out the FREE Solaris 10 Patching Best Practices (WS-2700-S10) training course. It's a little on the cheesy side and uses some pretty poor Second Life like images, but it provides some useful information on how to make your patching experience considerably easier. The main emphasis is on using Live Upgrade for all your patching and maintenance ... Continue reading ►

The Key to Live Upgrade Success

I think one of the best features of Solaris is the Live Upgrade mechanism. This really useful feature can be used for upgrading and patching with very little impact on the server. This means you can patch or upgrade your production system, whilst it's still in production, and only schedule a short outage for the reboot needed to activate the new patched/upgraded environment. Live upgrade also has the added benefit that you can roll back to a known good boot environment in the event something goes wrong. Sadly, it's not always a bed of roses when it comes to using live upgrade as things change with patches and new bugs are discovered and fixed, however most problems can be easily avoided with a little bit of pre-planning. Continue reading ►

ludelete of BE Holding GRUB on Solaris x86 Fixed

My little Ultra 20 under my desk runs with two boot environments and flip-flop between them as I upgrade using Live Upgrade. The basic procedure is: rename the old inactive BE (lurename), update it with the contents of the currently running BE (lumake), upgrade it to the latest and greatest (luupgrade), activate it (luactivate) and reboot. This is quite a pain free experience and has worked well for me. I never actually delete the alternate BE as I don't need the space. However, other people need to and ever since GRUB was introduced into Solaris 10 (x86 only) they encounter the following error when attempting to delete the BE that contains the GRUB menu: # ludelete -n snv_22 ERROR: The boot environment contains the GRUB menu. ERROR: You are not allowed to delete this BE. Unable to delete boot environment. # This is a long standing issue (I've got a workaround if you want it) that has plagued many a sysadmin using Live Upgrade on Solaris 10 x86 and Nevada. Well, not any more. Continue reading ►

Solaris Live Upgrade and Patches

I encountered a bit of a challenging question today... Suppose I have Solaris 10 1/06 (update 1) installed and I've patched it with various patches that are actually provided as part of a much later release, for example Solaris 10 11/06 (update 3). Will I have to reapply those patches if I perform a live upgrade to and intermediate version, eg Solaris 10 6/06 (update 2)? At first I thought: "No. The patches have been applied, the pkgs updated to reflect these patches and the upgrade tool should be able to workout that a later version of the pkg has already been applied". Patches are essentially partial pkgs after all, and there is version detection within the patching and packaging. But the more I thought about it, the more I thought it couldn't be that simple, especially considering that the Solaris patch, packaging, installation and upgrade systems are a bit of a mess under the hood (it's being sorted in Nevada/OpenSolaris). So I did some investigating. Continue reading ►
Top