Re: booting btrfs

[Chris Murphy]

On Jan 7, 2014, at 10:55 AM, Chris Murphy <address@hidden> wrote:

> 
> On Jan 1, 2014, at 10:17 PM, Michael Chang <address@hidden> wrote:
>> 
>> We snapshot /boot for kernel and initrd, otherwise the rollback would
>> encounter problem of incompatible userland and kernel/kernel modules.
>> And we need the ability to rollback them in terms of usefulness.
> 
> Of course, understood.
> 
> core.img is only going to point to one /boot, which may not be the /boot 
> snapshot needed for the kernel and initrd. This will be really confusing for 
> mortal users. They'd be unlikely to figure it out and understand it, without 
> documentation.
> 
> If core.img points to the "current" /boot, which it should, that boot has the 
> accumulated knowledge of all snapshots, and any recently updated grub 
> modules. Choosing to boot a snapshot means using a different /boot for 
> kernel/initramfs than what grub is using for its root. I don't off hand see a 
> problem with this because it's literally just two files that grub loads from 
> a different boot subvolume, found with an absolute path to that snapshot. And 
> it also uses rootflags=subvol= to use the matching root snapshot.
> 
> A separate issue that's not grub's problem is how to deal with the (now 
> wrong) fstab entries. systemd looks at fstab and generates mount jobs from 
> that; if taught to understand it's booting a snapshot it could second guess 
> parts of the fstab. Based on the name of the currently booting root snapshot, 
> which systemd definitely knows, it could mount that subvol= instead of what's 
> in fstab. It can use name substitution to do the same thing with the other 
> subvolume-snapshots that match the root one. Meaning all of the snapshots for 
> a system have the same base (re)naming convention.

Another hiccup. Maybe it's a silly use case. Consider /boot on Btrfs, 
multiple-device, raid1 data/metadata profile, UEFI Secure Boot. A drive dies, 
and the system needs to be rebooted before a rebuild occurs.

This works today with /boot on raid1/10 Btrfs. Yes, I manually have to add a 
degraded mount option as this isn't automatically done by Btrfs yet. But the 
GRUB boot part works. Even degraded, the path to grub.cfg is valid. And the 
file system itself keeps multiple copies so there's no work keeping it current.

With Secure Boot it's a problem. The signed grubx64.efi has a fixed prefix 
location, valid on any computer, to search for grub.cfg, which is on the ESP. 
So now we need to have multiple copies of grub.cfg, somehow synced, on each 
ESP. Or another solution. If we had a Btrfs subvolumetypeGUID, analogous to the 
GPT partitiontypeGUID, and specify that as the baked in partuuid for a signed 
grubx64.efi to search for /boot/grub/grub.cfg.

What do you think? Total edge case?


Chris Murphy