News, tips, partners, and perspectives for the Oracle Solaris operating system
-
Technologies /
Oracle Solaris 11
September 19, 2019
What is Automatic Boot Environment Naming and why is it important?
Ever since the initial delivery of the Image Packaging System (IPS) during the development of Oracle Solaris 11 it has been tightly integrated with Boot Environments; this provides a safe, reliable upgrade/rollback facility.
Naming of the boot environments was left to the administrator.
How do you choose a "good" name for your BE ?
If you are following the Oracle Solaris 11 SRU train then using the release and SRU number as part of the BE is a good start.
The name of a BE created during a 'pkg update' can be chosen in advance by using the --be-name option. However if you either don't upgrade to every SRU, or something in your pkg image configuration means it can't do an upgrade to the SRU but can do some update, then you need to predict in advance what the BE name should be and you might get it wrong.
You can always rename the BE after the package operation. Doing that turns out to less easy than it ideally should be, because beadm won't allow you to rename the current or active on next-boot BE. So you would have to reactivate the current BE, rename the new BE and then reactivate the new BE again. I had been using exactly that sequence of operations for a few years on our internal development builds, and selecting the BE name based on knowing what uname -v would produce. The value of uname -v now comes from a protected file in /etc/versions that is delivered by pkg:/release/name. For some background on how uname is set see Pete's "What's in a uname?" blog post.
Surely we can do better than that ? After all when pkg is the one creating the BE it already knows it has an upgrade solution and knows exactly what it will be delivering!
The first obvious answer is just have package do the same BE rename as it finishes. While that would work it is a little messy and it means we don't know the name of the BE until the very end of the 'pkg update', which is fine in most cases but not when you run 'pkg update -nv' to find out what it would do, because in that case we won't see the /etc/versions/uts_version file.
So what we need is a way of having a suggested BE name stored in package metadata, this is exactly what I choose to do.
As of Oracle Solaris 11.4.13 we have delivered the metadata in pkg:/release/name and changes to the pkg command so that it will automatically use a BE name that matches what 'uname -v' will return. If you wish you can still choose your on boot environment names.
Since this needs the new pkg command support that is delivered in 11.4.13 you won't see this activate until you upgrade from 11.4.13 to a later SRU.
When you do it will look a bit like this:
root@S11-4-SRU:~# pkg update entire@latest
Packages to install: 27
Packages to update: 298
Mediators to change: 1
Create boot environment: Yes
Create backup boot environment: No
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 325/325 8001/8001 903.6/903.6 4.2M/s
PHASE ITEMS
Removing old actions 1850/1850
Installing new actions 7181/7181
Updating modified actions 3883/3883
Updating package state database Done
Updating package cache 298/298
Updating image state Done
Creating fast lookup database Done
Updating package cache 5/5
A clone of 11.4.13.4.0 exists and has been updated and activated.
On the next boot the Boot Environment be://rpool/11.4.14.4.0 will be
mounted on '/'. Reboot when ready to switch to this updated BE.
Updating package cache 5/5
Now what if the OS would just do the update for you ? Would that be useful ?
-- Darren