Patching the boot miniroot

Assume that the setup is according to Custom JumpStart framework setup.
Consider that no operations have happened yet from /install/Solaris_10/Tools.
The booting miniroot should be unpacked to a subdirectory, not a ZFS dataset.
  
IMPORTANT
It can be considered best practice to patch the boot miniroot as soon as possible.
It's known to be necessary when performing a flash install of an updated ZFS-root image.
/install/Solaris_10/Tools should already exist as per the previous assumptions.
For correct patchadd behavior patch 119255-86 / 119254-86 must be installed.
  
The whole operation is as follows:
  
# mkdir /patch/miniroot
# /boot/solaris/bin/root_archive
    unpackmedia /install /patch/miniroot 

# cp -p /patch/miniroot/sbin/rc2{,.0}
# cp -p /patch/miniroot/sbin/sulogin{,.0}
  
# smpatch download -d /tmp -f -i 147441
147441-23 has been validated.
  

# patchadd -C /patch/miniroot /tmp/147441-23 

Patch 147441-23 has been successfully installed.
See /patch/miniroot/var/sadm/patch/147441-23/log for details
Executing postpatch script...
Patch packages installed:
  SUNWbtool
  SUNWcakr
  SUNWckr
  SUNWcsl
  SUNWcslr
  SUNWcsr
  SUNWcsu
  SUNWesu
  SUNWgss
  SUNWmdb
  SUNWmdbr
  SUNWmptsas
  SUNWnfsckr
  SUNWnfscr
  SUNWnfscu
  SUNWnfsskr
  SUNWnfssu
  SUNWos86r
  SUNWxvmpv
  SUNWzfskr
  SUNWzfsr
  SUNWzfsu
  SUNWzoneu
  

# export SVCCFG_REPOSITORY=/patch/miniroot/etc/svc/repository.db
  
# svccfg -s system/manifest-import setprop start/exec = :true
# svccfg -s system/filesystem/usr setprop start/exec = :true
# svccfg -s system/identity:node setprop start/exec = :true
# svccfg -s system/device/local setprop start/exec = :true
# svccfg -s network/loopback:default setprop start/exec = :true
# svccfg -s network/physical:default setprop start/exec = :true
# svccfg -s milestone/multi-user setprop start/exec = :true
  
# mv /patch/miniroot/sbin/rc2{.0,}
# mv /patch/miniroot/sbin/sulogin{.0,}

# /boot/solaris/bin/root_archive
    packmedia /install /patch/miniroot

Now, other boot and/or JumpStart servers can be more easily updated.
Assuming that the updated server js-01 can (rw) mount js-02:/install:
  

js-01 # cd /install
js-01 # find boot Solaris_10/Tools/Boot |
          cpio -pdum /net/js-02/install

   

Custom JumpStart flash install

Assume that the setup is according to Custom JumpStart framework setup.
Consider 192.168.0.12 as the IP address of the js-01 X86 Custom JumpStart server.
 
Solaris have always addressed the enterprise needs.
Automated installation is just another example of that.
All that's needed is already included built-in.
 
Solaris is continuously evolving and since Solaris 10 U9, support for Flash Archives have been incorporated to ZFS-root-based Custom JumpStart installations.
 
Compared to the conventional process, the flash install option is simpler.
The main benefit is that a fully updated system can be deployed in one step.
The conventional process requires a time-consuming post-installation update.
Since Solaris has many updates, currently U10 for Solaris 10, the catch-up is long.
Nonetheless, the conventional process is still invaluable to get to consistent images.
 
Another benefit is that it can be part of a disaster recovery procedure for a global zone (GZ).
This assumes, of course, that the non-global zones are backed up by other means.
My preferred NGZ backup option is through ZFS snapshots and streams.

The initial step is, of course, to create a Flash Archive base installation image.
As mentioned, the conventional Custom JumpStart can be used as a starting point.
In fact, I'd say that, for consistency, it's the preferred way to start creating an image.
  
Don't create NGZs for applications yet as they'll be carried out on a later phase.
  
Next, fully update the system.
Begin by applying the most recent patchset for the bulk part.
Wrap up by taking advantage of smpatch for a more fine grained control. 
Use no alternate BEs (ABE) as they aren't supported in the image.
   
Perform some clean-up before creating the image. 
Verify /var/tmp and possibly delete /var/run and inactive BEs (boot environments).
  
Finally, archive the image to where it can be used by Custom JumpStart.
 

js-01:~ # zfs create
            -o mountpoint=/images
            -o sharenfs='rw=base-01,ro=...' ...

js-01:~ # chmod 1777 /images 
 
base-01:~ # mount -F lofs -o nosub / /mnt
base-01:~ # [ -d /mnt/var/run ] && rm -r /mnt/var/run
base-01:~ # ls -la /mnt/var
base-01:~ # umount /mnt
base-01:~ # rm -r /var/tmp/...
base-01:~ # ludelete -R
 
base-01:~ # flarcreate
              -S -n base-01 /net/js-01/images/base-01.flar
 

js-01:~ # chown root:root /images/base-01.flar
  
If not going to use a Flash Archive file anytime soon, consider compressing it.
To achieve the highest compression ratio 7za is the answer.
 

# 7za a base-01{,.flar}

# [ -f base-01.7z ] && rm base-01.flar
  
A few adjustments to the Custom JumpStart profile and rules are needed as follows:
  

# cat rules

# 
# keyword value   begin-script  profile          finish-script
# ------- ------- ------------- ---------------- ---------------
  karch   i86pc   -             profile_x86_flar finish_x86_flar

# cat profile_x86_flar
#
# keyword               value
# --------------------  -------------------------------------
  install_type          flash_install
  archive_location      nfs 192.168.0.12:/images/base-01.flar
  partitioning          explicit
  pool                  rpool auto auto auto mirror any any

# cat finish_x86_flar
#!/bin/sh
  
BASE=/a
BIN=$BASE/usr/bin
SBIN=$BASE/usr/sbin

#................................................................
# X86 fix - The boot device isn't where Solaris was installed
  
$BIN/sync
$SBIN/reboot
   
There's still one important problem: patching the boot miniroot.
Due to the natural evolution of ZFS, the miniroot must be updated accordingly.
The original booting miniroot can't handle the recent ZFS updates on a fully updated image.