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:
NAME USED AVAIL REFER MOUNTPOINT 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: NAME USED AVAIL REFER MOUNTPOINT 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 Ivan 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 [email protected]
