В Mon, 20 Jul 2015 10:52:15 -0600 Chris Murphy <lists@colorremedies.com> пишет:
On Sun, Jul 19, 2015 at 11:58 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
I understand the rationalization, it's easier to get to bootable snapshots and rollbacks this way. I just disagree with a.) taking the user's feature and control away from them, b.) making the boot process essentially invisible when it comes to what subvolume is being used.
You also need to a) somehow designate snapshot to be booted by default
That should be something the bootloader configuration understands. Snapshot doesn't change the need to define the bootloader's need to know what root is, to find the specific kernel + initramfs + root fs to pass off to the kernel.
When you have multiple specifications for kernel+initramfs+root you need to select which one to use. Be these specifications on subvolumes, filesystems or in $BOOT/loader/entries.
Now what's being done is to say, no we're giving up on all such specifics and we're going to hide it in fs metadata that is Btrfs specific. So the entire boot process has now changed, and only on Btrfs.
As snapper (rollbacks) are specific to btrfs this is rather logical.
and b) handle path changes when snapshot is created (snapshot is different subvolume so any path inside grub.cfg needs adjustment).
This is no different than an LVM thinp snapshot where now it's a different device mapper path for boot and root. If you don't like things modifying grub.cfg,
I CAN NOT modify grub.cfg because it is on read-only snapshot. At least that was absolute requirement when SUSE created this code.
then we need to get serious about fixing whatever problems GRUB upstream has with the bootloaderspec. Either the original or mjg59's variant. And then whatever wants to change the boot process needs to add a new drop in script, rather than modifying bootloader files.
Again - one of the original requirements that lead to current design was booting snapshot without any preparations. I am not sure current code fulfills it, but it was attempted. ...
change it.
I actually have design draft (from grub side) that requires minimal code changes (and some changes are what I believe should be included for other reasons) and solves all these issues. But it also means changes to installer, yast, snapper ... if anyone is willing to cooperate on fixing those, let's setup OBS project and try to implement it. Then it can be present as alternative solution; and I am pretty confident that GRUB changes that are required will be suitable for inclusion upstream.
Do you have a basic outline for this draft? I'm fairly dense when it comes to reading code.
Default bootloader in fixed subvolume, e.g. /mboot. "Local bootloader" in root subvolume, e.g in $subvol/boot Master bootloader multiboots local bootloader from $subvol/boot/xxx/core.img, passing it subvolume as parameter. Default subvolume to boot from either as subvolume property (preferable if btrfs developers agree) or as environment block in fixed location, e.g. /mboot/bootconfig. In this scheme /mboot is installed just once and can be left alone. It has static grub.cfg that looks for available subvolumes and presents them in menu. Switching root environment means just setting variable in /mboot/bootconfig. Required changes on grub side are - make grub-mkconfig scripts generate btrfs paths relative to run-time subvolumes (current SUSE patches effectively do this already). - make grub accept parameters passed via multiboot/EFI (everyone agrees it is needed, the question is mostly semantic). On EFI it may not even be needed because grub already knows where it was booted from, so likely can extract subvolume (with some help from btrfs). Downside is, the more run-time magic is added to grub.cfg the more incompatible with os-prober idea it becomes. OTOH nothing prevents os-prober from probing for /mboot ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org