How does BE temporary activation work?

B

bob2112

When people advocate the use of "bectl activate -t", they are usually either vague about the benefit or they mention getting back to a BE with working remote access. I'm wondering about how well it protect against an early lockup or spontaneous reboot.

Ideally the fallback BE would start first, clear the setting, and then chain the temporary BE. If that doesn't happen then it's a matter of how early the activation is cleared - before loader.conf is read would be a major benefit.
 
/boot/loader.conf is part of a BE, it lives in zroot/ROOT/default (which is mounted as /) normally. That entire dataset is the BE.
 
bob2112 said:
I don't understand the relevance of that. The question is about how the temporary activation is cleared.
Click to expand...
According to the man page for bectl, bectl activate -t just applies to the next boot. Bectl itself, from what I can tell, just mounts that related snapshot rather than what the normal files would be there.

Of is that not what you're getting at?
 
Apologies may be longer than you want to read.

N flag is "active on next boot"
R flag is "currently running"

bectl activate -t I think adds a "bootonce" property and moves the N flag to that BE, leaving the "bootfs" property on the currently running BE.
You reboot, loader things see the bootonce and boot into the BE that was activate -t.
If you reboot again, the bootonce is ignored and the BE with the bootfs property set is used.

bectl is not utilized during the boot process; it is used to modify flags on existing BEs (activate), create/destroy, check, mount existing BEs. A BE is technically a zfs clone (basically a read/writable snapshot because snapshots are not writable).

The default BE layout has /boot as part of a BE, so /boot/loader.conf is part of each BE (may not differ from a previous one given the way ZFS snapshots/clones work).

So "why" use bectl activate -t? Safety, paranoia.
Your system is running fine on 14.x-RELEASE-pY but you want to upgrade to 15.A-RELEASE-pB but you don't know if your graphics subsystems will work or if you need to muck with network config.
So upgrade into a new BE (15.x-RELEASE-pY), bectl activate -t 15.x-RELEASE-pY and reboot.
It reboots and if there is a problem that causes the system to reboot, it will reboot into your 14.X-RELEASE-pY BE. Then you can do bectl mount 15.x-RELEASE-pY /mnt, cd /mnt and start poking around in config to fix it.
Once you are satisfied 15.x-RELEASE-pY is working correctly, you do bectl activate -T 15.X-RELEASE-pY to clear the bootonce, then bectl activate 15.X-RELEASE-pY to set it's bootfs property.
 
scottro said:
This stuff confused me too. I wound up making a little page on it, which might help. (also works with beadm). https://srobb.net/fbsdbe.html
Click to expand...
Good stuff. Thanks for it.

BE: has a specific definition within the entire ZFS ecosystem. beadm was the original tool from Sun, I think scripted, bectl is roughly a reimplementation in I think C (maybe Rust? That was a joke).
To my knowledge commands and arguments are pretty much one to one between beadm and bectl so the biggest difference is "3 letters and one is in base the other in ports".

One thing to keep in mind with BEs: I think there is a difference between a "shallow" (the default) and "deep". The distinction is in how datasets are laid out and what gets included into a BE. And BE's are clones which are "writable snapshots of a snapshot".

One can learn a lot about BEs by mucking around with creating a new one, do bectl list to see the flags in the Active column, the mount point, then go and look at properties on the different BEs (bootfs, bootonce, etc).

You don't have to actually reboot or anything, but see what happens to flags and properties when you bectl activate, bectl activate -t, bectl activate -T. The flags under "Active" always feel backwards to me: I want N to me "Now" R to mean "Reboot" but it's really "Next boot" and "Running right now". This is a little backwards from say freebsd-update -kru where k is "kernel for next boot" r is "currently running" and u is "userland"

Sometimes with BEs my head hurts if I try to overthink them but if one accepts the base premise, they become almost easy to understand.
 
What I'm referring to is the situation in which you boot into an upgraded system and it fails before the boot menu/prompt is usable, leaving you with no easy way to switch to a backup BE. Potentially temporary activation gives you a simple way out of this, but only if the temporary activation is cleared and committed to non-volatile storage in good time.

The bulletproof way of handling this is for the boot to start in the tried and tested R BE allowing it clear the setting and chain the T BE.

The relevance of loader.conf is that it's read before the boot menu comes up, so has some scope for causing the type of failure I mentioned.
 
bob2112 said:
When people advocate the use of "bectl activate -t", they are usually either vague about the benefit or they mention getting back to a BE with working remote access.
Click to expand...
With a system only accessable via remote access, very often comes without access to the (boot) console where the user can select an option where a BE of choice can be selected. Because very often a remote (virtual) system that does not provide console access and where operators/VM managers do not care much or are not allowed to fix boot option in such a matter, there are often only two options available:
  • A complete reinstall/restore from backup
  • An operator (perhaps even user) initiated power cycle
With #2 in combination with the boot once feauture ( the -t option ), the system automatically boots into its previous state (= previous BE).

Some info & links I wrote down: Boot Environment & snapshot - important ZFS features
 
Erichans said:
With a system only accessable via remote access, very often comes without access to the (boot) console where the user can select an option where a BE of choice can be selected. Because very often a remote (virtual) system that does not provide console access and where operators/VM managers do not care much or are not allowed to fix boot option in such a matter, there are often only two options available:
  • A complete reinstall/restore from backup
  • An operator (perhaps even user) initiated power cycle
With #2 in combination with the boot once feauture ( the -t option ), the system automatically boots into its previous state (= previous BE).

Some info & links I wrote down: Boot Environment & snapshot - important ZFS features
Click to expand...
This is the obvious use of temporary activation that I mentioned in the OP and excluded.
 
bob2112 said:
Bootonce applies to UFS, I doubt its relevance to ZFS BEs.
Click to expand...
ZFS properties, why could it not also apply to ZFS? Obviously something is telling loader "boot me this time".

bob2112 said:
What I'm referring to is the situation in which you boot into an upgraded system and it fails before the boot menu/prompt is usable, leaving you with no easy way to switch to a backup BE. Potentially temporary activation gives you a simple way out of this, but only if the temporary activation is cleared and committed to non-volatile storage in good time.
Click to expand...
If the system fails to boot and falls back to the loader, the temporary/bootonce is recognized as in "I've tried to boot that BE, it failed so I'm rebooting and looking for the bootfs property.

Simple enough to test.
Take what ever you have now. Do bectl create blahblah, bectl activate -t bectl blahblah, reboot.
See what BE you are in (probably blahblah)
Now do bectl list pay attention to NR flags and do shutdown -r now
Wait for it to come up and do bectl list pay attention to flags and see what BE you are in.

Temporary/bootonce activation I think is designed to cover "I got a panic or something that caused a reboot so don't keep rebooting into the same failing BE. Only boot into it once, if it fails boot into failsafe. If it works USER MUST understand they need to clear temporary/bootonce and activate permanently".

Temporary activation: assume it set's a property (made up names), lets call it "bootmenexttime" and flag is set to true. You reboot, you get into the BE marked temporary, and as soon as possible set the bootmenextime flag to false. IF there is a problem that causes a reboot, you wind up back at the loader loader looks for bootmenextime == true, finds nothing so looks for bootfs == true property and goes there.

If a problem occurs between pmbr and initial gptzfsboot/loader one is pretty much screwed.
One can keep on trying to count how many angels will fit on the head of a pin, but at some point you need to accept that during boot, there are always going to be theoretical holes that need manual intervention.
 
I wasn't aware of this feature. It doesn't exist in sysutils/beadm.

Reading the code it sinks into sys/contrib/openzfs/lib/libzfsbootenv/lzbe_device.c, function lzbe_set_boot_device().

I didn't really understand the thing, but it uses the bootenv of the zpool and add a var named OS_BOOTONCE. This var is read by the loaders (efi or BIOS) and if used, a new var is added OS_BOOTONCE_USED (hum...). It seems that OS_BOOTONCE is removed at the same time it is read with the function zfs_get_bootonce_spa(). The kernel isn't loaded at this time, so the chance it crashes before to remove this var in close to zero.

That should work on the paper or at least, as my tired eyes see it.
 
You must log in or register to reply here.
Back
Top