2012-06-25 18:18, Aneurin Price wrote:> Hi folks, > > I have a basic newbie question: can somebody help me to understand how > exactly the boot environments created by 'pkg image-update' work?
Hello, I might make a few mistakes (and welcome corrections then), but here's the way I see it (and in short - your understanding matches mine): There are some packages which are marked as requiring (suggesting) creation of either a backup BE or a new BE; you can also enforce or disable creation of these via "pkg(5)" command-line options. There are also many packages which do not dictate creation of BEs (backup or new) during their installation, leaving that to chance (the user's choice and/or what other co-installed packages might dictate). Backup BEs are snapshots taken just before the installation, and in my practice they seemed to stay snapshots (not directly easily bootable - but you can make a ZFS clone filesystem based on the snapshot, in order to boot into the backup BE). Modifications are applied to the current BE; this is a mode for changes which are not expected (by package authors or sysadmins) to cause troubles. New BEs are just that - a snapshot is created of your current BE, a clone is made from this snapshot, and the modifications are applied to this clone. Your currently active BE remains intact, and if you apply any changes to it (manually) after creating a new cloned BE - these changes will be unseen in the new BE and its descendants. As you say, in this case a reboot should be scheduled and done soon, to avoid surprises. I think that the "new BE" upgrade mode is more geared towards lower-level upgrades, such as the kernel, drivers and system tools; (re-)enabling many of these would either require a reboot or equivalent shutdown of services and reloading of drivers at least, and a fast-reboot is cleaner to test everything. That said, if you're installing some userland application software which wants a new BE but you know it doesn't really require that, *I think* it is safe to optionally backup/clone your current BE, and install the package into the current BE requesting that a new one should not be made by pkg(5). > Lets say I start with the BE 'mysystem'. My initial expectation -
obviously incorrect - was that performing the update would take a snapshot (call it 'mysystem-1'), and create a corresponding BE, then apply the relevant updates to the *currently active* BE. Then I would immediately have access to updates that don't require a restart (new application software versions etc.); I can reboot to get the new kernel version, or I can reboot and choose the mysystem-1 BE if anything went wrong. In short, I was expecting the operation to be roughly equivalent to snapshot creation, followed by 'apt-get dist-upgrade'. That obviously isn't the case, but I can't find a clear explanation anywhere of how the process actually works. From observation it appears to be the following: a snapshot and corresponding BE are created, and the update process is applied to that *new* BE. Thus newly installed updates aren't available until rebooting into that new BE. The current BE effectively acts as the 'backup' snapshot, so any other changes to the system (applied to the running environment) not only won't apply to the new BE, but are basically modifying the backup. Hence, updating should be the *very last* thing to do before a reboot, and rebooting ASAP after performing the update is *extremely* important. Is that understanding correct? Assuming so, is it possible to make pkg behave more like my initial expectation? I suppose I could create a snapshot myself using beadm, then tell pkg not to create a new environment, but is that likely to bite me in some nasty way? I'd like a better understanding of why the system works the way it does before trying to fight it :P. Thanks for your time. (PS: Apologies if this list is inappropriate for basic questions like this; let me know if that's the case.)
HTH, //Jim Klimov _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss