Three Hilarious Things

Last updated: Thu, 07 Dec 2006 11:01:00 GMT

About patching a Solaris 10 zone host.

We'll start with the only one that actually made me laugh:

README.118344-14:6377690 Patch 118344-06 and greater revs should not have "rebootafter" property.
---
README.118344-14:NOTE 1:  Reboot system after patch installation is complete.

Next up, showrev -p returns its list of applied patches in a deterministic order, but not an order I can determine. I had thought it probably the order in which they were applied, but the order that it returns the patches in a sparse nonglobal zone differs from the order that they're returned in the global zone. Furthermore, if you look at the content of each one-line patch summary, the content is ordered deterministically, but differently in global and nonglobal zones. For example:

10c10
< Patch: 118344-14 Obsoletes: 122397-01 Requires:  Incompatibles:
Packages: SUNWcsu, SUNWcsl, SUNWckr, SUNWfmd, SUNWhea, SUNWarc
---
> Patch: 118344-14 Obsoletes: 122397-01 Requires:  Incompatibles:
Packages: SUNWckr, SUNWcsl, SUNWfmd, SUNWhea, SUNWarc, SUNWcsu

Mmm, handy.

So, to compare two machines using showrev -p, one must sort and cut the output, and then refer back to other documentation to see what the differing patches actually are. Sweet. Ten years later, and they're still less useful than IRIX5. Okay, IRIX5 made me put a CD in with the patches on it, whereas smpatch mostly sometimes downloads the patches for me, as long as seconds since epoch isn't divisible by 256 and they haven't changed the patch signing certificate again.

Last up, a real doozy. If you take a fresh, full OEM plus bundled Solaris 10u1 x86 server, create a bog-standard sparse zone on it, patch it (I went to kernel 118855-19, which is pretty fresh, but this particular behaviour is not new) and then create a second sparse zone, the two will be different. In fact, the first zone will be about 100MB in size, and the second about 250MB. Where's the difference? It's in /var/sadm/pkg. The difference is the backout data from all those patches you applied -- 150MB of archived up files that were "replaced" when the patches were applied. But, wait, if the zone's a regular sparse one, my whole OS is just a read-only mount of the host's OS, right? Well, almost -- you've got package-managed files in /etc, don't forget, and under /var, so the ability to back out of those patches might come in handy. Oh, yeah, I forgot -- you can't back out of those patches, because the likelihood is that they include one or more files in /usr, which is read-only. Right. So, why the difference, again, have the patches not been applied to the first zone? Well, showrev -p reckons they have, so I guess all the metadata's there, just not the backout archives.

Why the difference?

You tell me. Maybe it'll be clearer in the morning.

This may be one of the many, many things that Sun claim to have fixed with regards to zones and patching, but I keep hearing about these improvements and Sun just keep on suckin'.

Did I tell you about the zone administration tools that, when they fail, honk on stderr but exit 0? Or the horrible leak in the resource capping daemon? Or the service management framework that disables services that exit immediately after startup because any daemon that starts, establishes that it has sufficient configuration and resource to continue, forks a child to serve, and then cleanly exits the parent with a good healthy 0 has got to be failing, right?

Thanks, Sun.