-
warden
Hi to all! OmniOS newbie here (coming from *BSD)... there is a way to 'pkg update' without creating a new BE? It looks like unuseful to force reboot if only a couple of packages will be updated... or I'm missing something and it's right to always reboot the host?
-
andyf
Welcome! It will only force a new BE if necessary - that is, if something being updated is flagged as 'reboot-required'
-
andyf
So standard updates like `pkg update openssl` or for weekly releases that don't require a reboot, you shouldn't need one
-
andyf
`pkg` will still create a backup BE unless you disable that
-
andyf
We try and avoid updates that require a reboot, but if they affect the kernel or things like CPU microcode, then they will.
-
andyf
You can still always be selective - this week's update, for example, contains an AMD CPU microcode update - if you're on an Intel processor you don't need that
-
warden
in fact at this very time a CPU microcoda package has to be updated... so I can assume that if it tells me that a new BE it has to be created, it's always right to do that. Thanks!
-
warden
in FreeBSD that's a choice I has to make myself... I'm not used to this approach, but I guess that saves a lot oh headcaches to sysadmins! :)
-
andyf
It does. It also creates some if people miss the 'you need to reboot' message.
-
warden
Thanks @andyf. I'm slowly approaching to Illumos (by now, testing only SmartOS and OmniOS) because I always had a crush on Solaris. Let's see if we'll fall in love/production! :D
-
warden
Just updated both pysical host and one lipkg NGZ with 'pkg update', and I found a new active BE (named "zbe-1") inside the NGZ
-
warden
"beadm destroy zbe" fails insize the NGZ, saying "destroying active zone root dataset from non-active global BE is not supported", but that BE is not active: in fact only the new "zbe-1" is mounted
-
warden
but I read "xb" in the "ACTIVE" field of "beadm list" output... I gues I'm still missing something
-
andyf
In a linked zone some BEs are tied to BEs in the global zone, so they will go away when you destroy the corresponding GZ BE.
-
andyf
It so that if you select and boot from a different BE, the zone rolls back too since it's important that certain files are consistent between the zone and the GZ.
-
warden
thanks, I was guessing somethig like this. But I cannot understand how they are tied: the "zbe" dataset is not a clone of the host's BE root dataset. Somethign is written in the zone configuration files?
-
warden
aha I found that: the NGZ root dataset has a couple of properties in the namespace "org.opensolaris.libbe", which "link" that dataset to the GZ's inactive BE's dataset! :)
-
warden
boot environment management is pretty "heavier" here than in FreeBSD. That's another strong point for sysadmins who aren't used to understand too deeply the OS they're using (actually FreeBSD induced me to go deep, eheh!)