[OpenIndiana-discuss] 'pkg image-update' and BEs

[Jim Klimov]

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