On Jan 9, 2014, at 3:03 AM, Michael Chang <mch...@suse.com> wrote: > 2014/1/9 Chris Murphy <li...@colorremedies.com>: >> >> On Jan 7, 2014, at 10:55 AM, Chris Murphy <li...@colorremedies.com> wrote: >> >>> >>> On Jan 1, 2014, at 10:17 PM, Michael Chang <mch...@suse.com> 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 > EOF > > 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.
Yes I think that will work. Do you agree that a GUI installer permitting, e.g. /boot on Btrfs raid1, should implement this? Or should it be a future feature of grub-mkconfig to figure out, that two grub.cfgs are needed? Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
