09:34:43 <warden> yes, in FreeBSD you can reference disks by their SN by using the path /dev/diskid/DISK-${SN}, if the sysctl 'kern.geom.label.disk_ident.enable' is set to 1 (as by default).
18:49:36 <szilard> Hi. I am facing a strange issue here with my OmniOS install. I have a pkgsrc zone running znc & irssi. I have set up both program. It used to work for a long time this way. Then, some days ago I have modified the configuration of ZNC and I have used that way for some days. But yesterday I had to reboot the machine, and while the zone started, the config change I did some days ago is missing.
18:50:28 <szilard> I suspect this can be a boot-environment thing.
18:50:36 <sommerfeld> is it possible that a package update created and activated a new BE, and then you didn't reboot immediately but instead made a config change to the running BE?
18:51:10 <sommerfeld> beadm list and beadm mount the previous BE and see if it has the missing config change..
18:51:26 <szilard> yes, that can be possible. If I run "zfs list" in the zone I see 13 different boot environment.
18:54:05 <sommerfeld> or, well, one of the previous be's if there are that many...
18:54:08 <szilard> this is what I see: https://pastebin.com/raw/Uqc8A4yQ
18:55:12 <sommerfeld> "beadm list" shows creation dates and is generally more compact than "zfs list"
18:56:08 <sommerfeld> I generally prune old BE's fairly ruthlessly if the running system is stable.
18:57:57 <szilard> here is the "beadm list" output: https://pastebin.com/raw/CNZ4mN5x
18:58:14 <szilard> Strange, but zbe-12 is active, not the last one.
18:58:36 <szilard> I have attempted to mount zbe-13, but it doesn't contain the changes I miss.
18:59:03 <sommerfeld> I'd recommend pruning BE's in the global zone.
19:00:02 <sommerfeld> see the beadm manpage; the 'xb' indicates that the BE would be active on boot in a different global BE
19:01:09 <sommerfeld> you likely had some pending updates in the global zone as well..
19:02:01 <sommerfeld> generally a bad idea to do any sysadmin ops in a non-global zone in between a pkg update and a reboot in the GZ for this reason.
19:03:30 <sommerfeld> pkg update in GZ with or without -r; then reboot without doing any other admin to NGZs.   Then mess with NGZs after rebooting the GZ.
19:04:34 <sommerfeld> the lost change is likely in an older BE in the IRC zone.
19:06:05 <szilard> No, it is actually in the zbe-12
19:07:43 <szilard> I have reverted to an earlier BE in the global zone, I think this is the reason why the BE's marked as xb now. Is my logic sane here?
19:14:00 <szilard> lets check my theory