How do I set a fallback root filesystem?

[leyvi]

I have full system backups that can be booted off of on a separate drive, in case my primary root filesystem has issues. How do I tell my system to try booting off of that if the primary root fails?

[zen_desu]

the simplest way would be additional boot entries with a different root= arg

a more elegant system could possibly be added into an initramfs but it seems simpler to just have different boot entries for different cases.

if you were to use ugrd and force it to build in the "backup" root info, but the bootloader generally passes the "main" root info, it will failover using the built in info, but i don't think this is a reasonable scheme to generally use

[Hu]

More generally, what does it mean that "the primary root fails"? Does that mean the primary root block device was not found, and so could not be mounted? Is it a failure if the root block device is found, but contains a filesystem that cannot be mounted? Is it a failure if the root filesystem mounts, but then init crashes, resulting in a kernel panic? What if init works fine, but critical programs from the boot runlevel are broken, causing the system to be effectively unusable? Some failure modes require considerably more state tracking than others to detect that a failure has happened and that a recovery is needed.

[leyvi]

the simplest way would be additional boot entries with a different root= arg

a more elegant system could possibly be added into an initramfs but it seems simpler to just have different boot entries for different cases.

if you were to use ugrd and force it to build in the "backup" root info, but the bootloader generally passes the "main" root info, it will failover using the built in info, but i don't think this is a reasonable scheme to generally use

Thanks. I don't know if that works so well in my use case though, which is EFIStub with LUKS.

I love µGRD by the way, I keep meaning to try and contribute, but I haven't gotten the chance.

[leyvi]

More generally, what does it mean that "the primary root fails"? Does that mean the primary root block device was not found, and so could not be mounted? Is it a failure if the root block device is found, but contains a filesystem that cannot be mounted? Is it a failure if the root filesystem mounts, but then init crashes, resulting in a kernel panic? What if init works fine, but critical programs from the boot runlevel are broken, causing the system to be effectively unusable? Some failure modes require considerably more state tracking than others to detect that a failure has happened and that a recovery is needed.

Basically any of the problems you've just named.

The reason I set up these backups is because I do a lot of unhinged tinkering with my software, which sometimes results in an unbootable machine, in which case a backup of the last functioning installation is nice to have. Some problems I have encountered include (but are not limited to):

• /sbin/init is gone.
• Messed-up PAM configuration.

All of these were my fault, and I'd rather not have to panic next time I mess with something I don't entirely understand and urgently need to use my computer.

You're right that this would require a lot of state tracking. Maybe EFI variables? The only problem with those is that they work different on every system, and if you mess something up, you may brick your motherboard.

[Hu]

I called out the case of broken user programs because that is so hard to handle with a wrapper that can automatically recognize that the next boot needs to use fallback mode. Since you want to handle that case, my advice is to keep two bootloader entries for each working kernel, one with root=maindrive and one with root=backupdrive. Then the user can pick whichever is appropriate, based on whether the user (you) is aware that a prior boot failed badly.

[leyvi]

I called out the case of broken user programs because that is so hard to handle with a wrapper that can automatically recognize that the next boot needs to use fallback mode. Since you want to handle that case, my advice is to keep two bootloader entries for each working kernel, one with root=maindrive and one with root=backupdrive. Then the user can pick whichever is appropriate, based on whether the user (you) is aware that a prior boot failed badly.

This could obviously be done with grub. Can it be done with efibootmgr? It doesn't seem to have as much configurability (obviously, it's not a full bootloader).

EDIT I
Obviously yes, with the kernel parameter. But I have my root(s) on LUKS, so it isn't so simple. I just let µGRD handle that stuff.

[Hu]

If root=/dev/mapper/crypt-root is always used, then you need to vary which raw block device is passed to cryptsetup open.

[leyvi]

Found something interesting, check it out: https://wiki.archlinux.org/title/Truste ... _registers.

See registers 3, 4, 5, 13, and 23.

[leyvi]

Some of those registers are for general use. Some others keep track of recent boot attempts.