Is this true for OpenSolaris? My experience: 

I was trying to upgrade from "SunOS 5.11 snv_28" to "SunOS 5.11 snv_54" where 
my NGZ zone roots were set to a zfs mount point like below:

zpool               93.8G  40.1G    26K  /zpool
zpool/zones         3.50G  40.1G  1.68G  /zpool/zones

Upgrading to SNV_54 did not work for me (CD|DVD|Live-Upgrade). The install 
procedure was cancelled after it came to the NGZ ZFS setup part. However - I 
was enforced to to a full re-install of the whole OS. By this time, I decided 
to have an OS independent application setup: I decided to leave all my 
Non-Solaris apps within the following structure:

zpool               93.8G  40.1G    26K  /zpool
zpool/applic        2.40G  40.1G  2.40G  /zpool/applic
zpool/bin            108M  40.1G   108M  /zpool/bin
zpool/data           644M  40.1G   644M  /zpool/data
zpool/logs          1.03G  40.1G  1.03G  /zpool/logs

This means, Apache, Tomcat, Bind DNS, Postfix, MySQL, Berkeley-DB, ... was 
installed using a prefix (e.g. ./configure --prefix=/zpool/applic/named)

This gives me some independencies to the core OS located 
in /sbin; /usr/bin, ...

After I moved all my apps into my own prefix path (ZFS mount poing), I did 
another full reinstall of the OS, where I found out that I should have backed 
up some files from the core OS before. Especially I should have backed up the 
following files from the GZ and all NGZ. 

a) /etc/hosts, /etc/passwd, /etc/shadow, /etc/nsswitch.conf, /etc/resolv.conf
b) /etc/hostname.XX, 
c) /etc/init.d/startup-scripts (my own releases)

After I did another full setup (not upgrading), I created the zones using the 
famous zonemgr script and brought back all applications by just mounting 
the /zpool/applic/path into the NGZ path. 

This way, I was pretty fast in upgrading the whole system to a new Nevada 
build, even upgrading would be the preferred solution to me. 

I do not know if I with SNV_54, another upgrade from SNV_54 to SNV_55 is 
supported by OpenSolaris. That is why this thread is of interest to me. 

My 2 cents


On Wednesday 07 February 2007 22:39, Rich Teer wrote:
> On Wed, 7 Feb 2007, Jerry Jelinek wrote:
> > This is incorrect.  All S10 updates have supported upgrading systems
> > with zones.  I believe what you are thinking of is that live-upgrade
> > does not support upgrading systems with zones.  This is being
> > fixed in the next S10 update.  It is already fixed in nevada.
> Gotcha; thanks for the clarification.
> > That is the only real reason.  The only other reason I know of
> > is fairly obscure.  The patch tools don't know about zfs so they
> > can miscalculate space when you have a set of zones, each on
> > their own zfs dataset, but in the same zpool.  If you were really
> > tight on space, the patch process might fail partway through as a
> > result.  This is probably not an issue for most people but is
> > the only other one I know of.
> Excellent; disk space won't be an issue for me, nor will the
> non-live-upgradability, so I'll be putting my zone roots on
> ZFS.
> Much obliged!

zones-discuss mailing list

Reply via email to