Live Upgrage feature in Solaris OS, refer to live_upgrade(5), no doubt, is extremely convinient way of doing not only an operating system upgrade, but also a single product installation or the other various experiments - all of these in a very very safe manner.

The basic idea is to maintain several operating system images - "boot environments" on a single machine at the same time. Besides, boot environments may share partitions. So, the current environment can be smartly cloned to the other spare partitions, then modified as it is required - starting with sevral files replacement, and ending with the whole OS level upgrade. After that, a newly created alternative environment can be used as a working one.

If something is screwed up, you can fall back to your previous stable boot environment any time.

Continuing with Live Upgrade, you may clone boot environment 1 to 2, upgrade 2, reboot into 2, thus 2 becomes your current environment, and so you may clone 2 back to 1, do upgrade, switch to 1 and so forth - i.e. you'll get a non-stop safe upgrade process.

Everything starts with a planning, so let's consider some example.
Assume we want to play with two environments, well ... in general let's have the current root filesystem on slice 0, slice 1 is basically swap, slice 2 as we know always points to the whole disk (or to a whole Solaris fdisk(1M) partition if we're on x86), slice 3 we plan to use as root for an alternative boot environment, and slice 4 we plan to share between both environments.

# format
AVAILABLE DISK SELECTIONS:
    0. c0d0 <DEFAULT cyl 5220 alt 2 hd 255 sec 63>
Specify disk (enter its number): 0
format> verify

Part      Tag    Flag     Cylinders        Size  
  0       root    wm    1570 - 2875       10.00GB
  1       swap    wu       3 -  263        2.00GB
  2     backup    wm       0 - 5219       39.99GB
  3 unassigned    wm     264 - 1569       10.00GB
  4 unassigned    wm    2876 - 5219       17.96GB
  

Note: the slice we plan for cloning current root (our case it's slice 3) must be "unassigned", i.e. not mounted, otherwise Live Upgrade won't see it as a spare slice.

For better flexibility, we put this shared slice 4 to a ZFS storage pool, refer to zpool(1M). It allows, for instance, each boot environment to have own copy of /opt, but at the same time, /opt/csw (community software from www.blastwave.org), /opt/soffice8 and similar can be shared as a separate filesystems.

# zpool status
NAME        STATE     READ WRITE CKSUM
zp1         ONLINE       0     0     0
  c0d0s4    ONLINE       0     0     0

# zfs list
NAME           USED  AVAIL  REFER  MOUNTPOINT
zp1           7.49G  10.1G  2.64G  /mnt/zp1
zp1/csw       1.02G  10.1G  1.02G  /opt/csw
zp1/soffice8   385M  10.1G   385M  /opt/soffice8
  

Good, our current environment looks stable, and now we want to create an alternative boot environment, so do lucreate(1M) new environment named be2, assuming we do that first time, therefore we need to give a name to the current environment, let's call it be1, and finally mapping tells that we clone only root filesystem to spare slice 3, all the rest (swap and ZFS pool) keep shared.

# lucreate -n be2 -c be1 -m /:/dev/dsk/c0d0s3:ufs
Analyzing system configuration.
Populating file systems on boot environment <be2>.
Creation of boot environment <be2> successful.
  

Note: lucreate(1M) immediately starts copy data, rather then just configure boot environment and leave it unpopulated, so if you don't have half an hour time for a data copy, better not to start the process. The other thins is preserve flag looks quite confusing - it doesn't mean "leave partition unpopulated", it does mean "expect the target partition to be already populated and configured for LU usage".

Another catch is the lucreate(1M) process termination in the middle of execution. After that an invalid / incomplete environment neither can be recreated due to it's already exists, nor can be deleted due to the ACTIVE value of Copy Status.

# lustatus
Boot Environment           Is       Active Active    Can    Copy      
Name                       Complete Now    On Reboot Delete Status    
-------------------------- -------- ------ --------- ------ ----------
be1                        yes      yes    yes       no     -         
be2                        no       no     no        no     ACTIVE
    
# lucreate -n be2 -c be1 -m /:/dev/dsk/c0d0s3:ufs
ERROR: new boot environment <be2> already exists

# ludelete be2
ERROR: Cannot determine root device for BE <be2>.
Unable to delete boot environment.
  

Even if you delete /etc/lu/COPY_LOCK making a Copy Status non ACTIVE, it won't help.
The way out is manual editing of /etc/lutab file, refer to lutab(4).

Next time you need to populate an already configured alternative boot environment, you may use lumake(1M) rather then lucreate(1M).
For instance, you've done lucreate(1M) and then install something on your current environment, so you probably want to get your alternative environment up to date ... Or, you've clonned environment 1 to 2, upgrade 2, switch to it and want to synchronize environment 2 back to 1. In these cases:

# lumake -n be2
Populating file systems on boot environment <be2>
  

Hint: On some old releases, lucreate(1M) was NOT aware of ZFS, and eventually it copies shared data from ZFS filesystems over. As a result, an alternative environment can't boot correctly, because it can't mount shared ZFS filesystems, due to they're non empty.
However, lumake(1M) fortunately handles ZFS stuff. Well, if you're working on old release, you can do lucreate(1M) and lumake(1M) after, which will remove wrongly copied data.

Now you can manage an alternative be2 environment, particularly:

• you can upgrade OS on it:
  
  

  # luupgrade -u -n be2 -s <OS image path> 
      

• or install/remove individual packages, refer to luupgrade(1M).
• or mount necessary partitions and do whatever is needed:
  
  

  # lumount be2
  /.alt.be2
  
  # df -h
  /dev/dsk/c0d0s3 9.9G 3.7G 6.0G 39% /.alt.be2
  swap            2.4G   0K 2.4G  0% /.alt.be2/var/run
  swap            2.4G   0K 2.4G  0% /.alt.be2/tmp
      

The next step is to activate your alternative environment, and make it bootable.
That basically means:

• An alternative environment must to know that after its first boot it needs to synchronize certain system files from last active environment.
• On x86 platforms, an alternative environment must have proper root partition ID, not the one it has just after a copy process.
  Otherwise, continuing with our example, where be2 is not active yet and its root filesystem is /dev/dsk/c0d0s3, even if you do set root to this slice in the GRUB, i.e.
  
  

  grub> root (hd0,0,d)
  grub> kernel /platform/i86pc/multiboot
  grub> module /platform/i86pc/boot_archive
  grub> boot
      

  you'll still start booting be1 instead.

Ok, so luactivate(1M) our alternative environment:

# luactivate be2

**********************************************************************

The target boot environment has been activated. It will be used when you 
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You 
MUST USE either the init or the shutdown command when you reboot. If you 
do not use either init or shutdown, the system will not boot using the 
target BE.

**********************************************************************

Modifying boot archive service
GRUB menu is on device: </dev/dsk/c0d0s0>.
Filesystem type for menu device: <ufs>.
Activation of boot environment <be2> successful.
  

From the program output above, we see that reboot(1M) is not quite suitable, looks like LU service's stop script (/etc/init.d/lu stop) execution is mandatory, then

# init 6
  

If you're on x86 and want to edit GRUB menu file, take into consideration it's physical location, i.e. you may have several boot environments, but only one contains active GRUB stuff:

# bootadm list-menu
The location for the active GRUB menu is: /dev/dsk/c0d0s0 (not mounted)

# lumount be1
/.alt.be1

# bootadm list-menu
The location for the active GRUB menu is: /.alt.be1/boot/grub/menu.lst
  

One more thing, LU updates the Master Boot Record, in particular resets it to a default one for Solaris OS ... no idea why LU touches MBR, anyway ... so if you're using specific MBR program, I'd recomment to backup it before and restore it after using LU, e.g.:

# dd if=/dev/dsk/c0d0p0 count=1 of=mbr-backup

... LU stuff ...

# dd if=mbr-backup count=1 of=/dev/dsk/c0d0p0
  

If your alternative environment has problems during the boot, most probably that's because of some services can't start. If that's the case, compare /var/svc/manifest directories of previous and new environments to figure out which services are gone (exec_method points to non-exising path) and which are added. That'll give you a clue which services should be disabled and which in opposite - enabled.

Finally, here is an output from ludelete(1M) - boot environment delete program:

# ludelete be1
The boot environment <be1> contains the GRUB menu.
Attempting to relocate the GRUB menu.
Updating GRUB state.
Moving GRUB menu.
Installing GRUB loader.
Updating all boot environment configuration databases.
Boot environment <be1> deleted.
  

The point I want to emphasize here is that if you delete boot environment, which contains GRUB stuff, LU automatically relocates it to the current environment.

If you want to relocate GRUB manually, as an example you have it on slice 0 and want all of the GRUB related stuff to be on slice 3, you can use installgrub(1M) utility:

# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0d0s3
stage1 written to partition 2 sector 0
stage2 written to partition 2, 235 sectors starting at 50
  

So, installgrub(1M) above writes the actual GRUB program to a corresponding location (basically to the fdisk(1M) partition, on which the Solaris OS slices reside), by the way configuring it to work with menu.lst file (and other GRUB related files) on a target slice (our case it's slice 3).

And after a reboot, an MBR program will find an active partition (presumably it's one with Solaris OS), then load its 1-st sector, where the GRUB stage 1 code is, which in turn will load stage 2 code, which will use the rest of a GRUB stuff, including menu.lst, from the 3-rd slice, as we've planned.

However after a reboot, the bootadm(1M) still shows the old "menu file" location, which is basically not correct any more ...

# bootadm list-menu
The location for the active GRUB menu is: /dev/dsk/c0d0s0 (not mounted)
  

That's because of LU configuration still points to that location ...
Adjust /etc/lu/GRUB_slice, make them pointing to a proper slice, i.e. let Live Upgrade know where you've relocated GRUB to.

# cat /etc/lu/GRUB_slice
PHYS_SLICE=/dev/rdsk/c0d0s3
LOG_SLICE=/dev/dsk/c0d0s3
LOG_FSTYP=ufs

# bootadm list-menu
The location for the active GRUB menu is: /boot/grub/menu.lst
  

Now everything should be consistent.
Good luck.

bash-3.00# lucreate -m /:/dev/dsk/c0t0d0s5:ufs -m /usr:merged:ufs -n be1
Discovering physical storage devices
Discovering logical storage devices
Cross referencing storage devices with boot environment configurations
Determining types of file systems supported
Validating file system requests
ERROR: cannot check device name <merged> for device path abbreviation
ERROR: cannot determine if device name <merged> is abbreviated device path
ERROR: cannot create new boot environment using file systems as configured
ERROR: please review all file system configuration options
ERROR: cannot create new boot environment using options provided