Thursday, October 27, 2005

What are Solaris 10 Updates made of: Patches and scripts and packages, too.

There seems to be some confusion about what a Solaris Update release is, both in and outside of the company, so I'd like to take an opportunity to explain how we are currently generating Solaris update releases.

First of all, a reminder, I am the technical lead for just the ON Consolidation for Solaris 10 Update 1. All of Solaris, aka the WOS, is made up of various consolidations. ON, the Operating System and Networking Consolidation, is just one of them. I can speak about how we handle things in ON land, but cannot promise that the same things apply across all consolidations. Most of ON is now available in OpenSolaris, to give you an idea of what code base I'm talking about. Mike Kupfer gives a good background on the ON consolidation.

The other caveat: there are exceptions. I will lay out first the basic structures of an update. Later entries will talk more about the exceptions and more fancy things, like features.

My mantra throughout this release has been "the patch gate is the update gate is the patch gate is the update gate...". I even included that in the gate's README file.

Put another way, update releases are made up almost entirely of patches, most of which are released early on SunSolve to provide binary relief to customers.

The most basic things that an update release contains are bug fixes, which I'll cover in this entry. These bugs may have been found internally or may have been reported by an external customer who escalated the issue. When a bug is fixed, it is first integrated in the release under development, in this case Nevada, where it undergoes significant testing and gains exposure on our internal servers and desktops. We call that "soaking".

After soak has completed, the fix comes back to the sustaining gate, on10-patch, where we do milestone builds every two weeks. At the end of a build, we will cut at least one patch for each integration we took for each applicable architecture and deliver those for further testing. The final patches will typically end up on SunSolve and are also used to create what is known as a Freshbit image of Solaris. Essentially, we start with an GA version of Solaris 10 and install patches on top of that image, to create an update build. That is, if the fix was not included in a patch, it will not be part of the update release.

Patches are cumulative so if patch A-01 contains a fix for bug X, patch A-02 will also contain a fix for bug X + some other bug fixes. Therefor, update builds are also cumulative. If something was fixed in a patch applied to the freshbit image of s10u1_01 it will still be fixed in s10u1_02 and so on.

In theory, you can take a base Solaris 10 03/05 system and patch up to an update release. In fact, you may remember when Sun used to release MUs (Maintenance Updates) which would basicly install the base OS then spend a couple of hours automatically patching it. Those where the bad ol' days - now we do the patching for you, and you can just upgrade or do a fresh install, getting essentially Solaris 10 03/05 and all relevant patches for your hardware.

Of course, there are exceptions, but most of those are not relevant for existing install base for Solaris 10 03/05.

I hope this helps to explain things a bit. I will have more entries, soon, to explain how features and new packages are handled and tested. let me know if any of this does not make sense, or if you have any specific questions on the interaction of patches and updates.


  1. I have a couple questions around this process. Perhaps some of it lies more on the shoulders of the group that handles installation/upgrade tools...
    Is there a simpler way to get support for updated hardware.
    The most common reason that I choose the latest update over a fresh patch set is to get support for newer hardware. This is for a couple reasons: to support newer components in the same server (15k getting US-IV, then US-IV+ boards) or to update standard flash archives for deployment across all new or redeployed servers.
    Unfortunately, the only supported way of getting this ON support seems to be to either install fresh or perform an upgrade. I have always been leary of upgrades and my most recent try explains why: I had the Sun SAN packages and relevant patches applied to a SUNWCall flar (misbuilt, long story). I wanted to get the SUNWCXall cluster on there so that I could reliably deploy it on everything from 220's - 25k's. However, on the first boot after the upgrade, sanity checks on files that were supposed to be patched indicated they were not the ones that were supposed to be there (checksums didn't match checksums from before upgrade). The patches were still installed and not superceded. Yikes. What else did it mess up?
    I would feel a lot better about adding new hardware support to an OS if I could get a set of packages and patches that would add that support. This would help greatly in the promise of being able to easily upgrade high end servers like marketing says you can do.
    Why can't newboot be delivered by patches?
    I hear from many people that it is impossible to deliver newboot via anything other than a fresh install. I have a hard time believing that. It certainly could be a risky patch, but I haven't heard the argument for why it could not be delivered as the appropriate packages and/or patches. Grub can live in cylinder 0, just as the current boot code does. Any ramdisk boot images could be in a patch/package or generated from a script using the files on the system.
    FWIW, way back when I had relatively little difficulty switching from LILO to GRUB with Linux. I installed the grub package, ran a few commands, and it worked better than its predecessor.
    Thanks for any light you can shed,

  2. Hi Mike -
    For your first question: most of our new hardware support comes in the form of packages.
    Patches can only patch existing software, so currently the only way to delivery new packages is through upgrade or fresh install. Since for the most part, new hardware is going to have those bits preinstalled, it's not an issue.
    We are investigating new ways of delivering software and issues like yours are being kept in mind. I'm not sure what happened in your upgrade, as I've not heard of anything quite like that before.
    As for NewBoot: NewBoot also comes with new packages. I will get clarification from the NewBoot team specificly.

  3. Hi,

    Why can't newboot be delivered by patches?

    The quick answer is that it can, and will.

    New packages are needed, and these will be delivered in a patch. It's not the normal way of doing things but this is exceptional circumstance.

    Patching to newboot is not as trivial as you might think. Just getting it to work on a simple system isn't too hard, but we also need to make sure that customers using live upgrade can upgrade to newboot smoothly, which takes more effort.

    Best Wishes,

  4. Valerie,
    Is there a resource that lists which patches and revs are included in a Solaris Update?

  5. Hi Mark-
    The release notes for every update should contain a list of all patches (including revs) included in that release. (that's why the release notes are so long! :-)