To complete the report, I have at last solved the "upgrade-the-zones" puzzle by
rebooting back to snv_77, detaching the zones, booting back to snv_93 and
attaching them in upgrade mode (zoneadm -z zonename attach -u). (NOTE: fix
/etc/zones/index on the new rootfs to mark all these zones as "configured" with
no UUID; more tweaks below).
I don't think this was a really good behavior on behalf of Solaris: when I
first tried to detach zones in snv_93, it generated the manifest files with
package versions from snv_93, disregarding the package info available inside
the zones. But I don't think this is any issue for the ZFS team to fix ;)
However, global OS reboots work weirdly, especially if I select the old snv_77
BE in GRUB and/or have the system reboot with generation of a boot-archive
(after the upgrade there's not much free space on rootpool). Every once in a
while GRUB refuses to boot (Error 16: inconsistent filesystem structure).
Working through command-line mode of GRUB I found that usually kernels can be
booted, but module commands pointing to boot-archives fail. Sometimes not all
of them, i.e. I can use trial-and-error to pick a currently-working
boot_archive. In command-line mode TAB-completion of ZFS paths doesn't work
(often giving something like "Error 15: not found"), but direct manually-typed
paths are resolved.
This situation can be worked around by some or all of the following magic
incantations:
1) Boot to failsafe mode (snv_93 failsafe also finds the rootfs and suggests to
mount it; still refuses to automount the older SVM mirrored UFS root).
2) Try setting mountpoint to "legacy", "none" or some reasonable value ("/")
for rootpool/rootfs_snv93 (luactivate seems to set it to a space character or
something like that)
3) Clean up free space on rootpool (kill experimental snapshots, etc)
4) Regenerate boot-archives, even if those on disk do seem valid
5) Try installgrub (use new grub!) on all disks' s0 slices
6) Try leaving the rootpool "imported" or "exported" before rebooting from
failsafe
A few rounds of such magic breathes life into GRUB again ;)
I'd be interested to know why such issues exist in the first place, and what is
a *correct* method of fixing them?
Can it be connected to ZFS cloning used to create several rootfs'es? Can
possibly boot-archives of different versions collide (including those in
snapshots)? Can it be due to lack of much free space (about 200M-500M are
available, that's not much given the 200-250M eaten by a couple of boot-archive
files).
To shake off some common problems I've seen in the forums, the rootfs is a
single-tree one (/usr, /var, /opt are part of rootfs, not separate FSes); it is
not compressed whatsoever...
Root and user zpool versions are so far "9", and the new Solars release
supports version "10". I don't want to upgrade yet as I might need to boot back
to snv_77 for fixups...
--
There were also a number of zone upgrade issues, including:
1) Sendmail tries to listen with MTA-v6 daemon, and our zones have no IPv6
addresses, not even localhost. A dirty hack to solve the issue is to comment
away this line in /etc/mail/sendmail.cf :
#O DaemonPortOptions=Name=MTA-v6, Family=inet6
2) TZ definition in /etc/default/init changed to PDT, had to fix a dozen of
these files ;)
3) Some services, so far notably the webconsole, started acting in SBD mode
(listening on localhost only), fixed as per documentation:
# svccfg -s svc:/system/webconsole setprop options/tcp_listen = true
# svcadm refresh svc:/system/webconsole
# /usr/sbin/smcwebserver restart
This message posted from opensolaris.org
_______________________________________________
sysadmin-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
