[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: booting btrfs

From: Michael Chang
Subject: Re: booting btrfs
Date: Thu, 9 Jan 2014 18:03:45 +0800

2014/1/9 Chris Murphy <address@hidden>:
> 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.

Isn't search --fs-uuid sufficient for this task? Or I'm afraid that I
didn't understand your problem enough.

  cat <<EOF > /boot/efi/EFI/<DISTRIBUTION>/grub.cfg
  search --fs-uuid --set=root `grub-probe --target=fs_uuid /boot/grub`
  set prefix=(\$root)/boot/grub
  configfile \$prefix/grub.cfg

  grub-mkconfig -o /boot/grub/grub.cfg

This way we can avoid calling "grub-mkconfig -o
/boot/efi/EFI/<DISTRIBUTION>/grub.cfg" and hopefully can get rid of
the problem you have.


> What do you think? Total edge case?
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]