14:54:25 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? 14:55:22 Welcome! It will only force a new BE if necessary - that is, if something being updated is flagged as 'reboot-required' 14:55:47 So standard updates like `pkg update openssl` or for weekly releases that don't require a reboot, you shouldn't need one 14:56:00 `pkg` will still create a backup BE unless you disable that 14:56:38 We try and avoid updates that require a reboot, but if they affect the kernel or things like CPU microcode, then they will. 14:57:13 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 14:58:13 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! 14:59:43 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! :) 15:00:18 It does. It also creates some if people miss the 'you need to reboot' message. 15:03:07 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 16:32:36 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 16:34:22 "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 16:35:07 but I read "xb" in the "ACTIVE" field of "beadm list" output... I gues I'm still missing something 16:51:37 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. 16:52:58 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. 16:54:40 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? 17:36:54 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! :) 17:43:23 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!)