On Di, 14.07.20 04:35, Neal Gompa (ngompa13@xxxxxxxxx) wrote: > > Nah, this kind of selection you do in the initrd, not in the boot loader. > > Yes. SUSE does this at the bootloader time. A *huge* part of the code > they added to GRUB is to automatically discover all this and populate > the menu and boot selection. None of this code exists in the upstream > GRUB codebase. This is done so that when snapper automatically creates > snapshots, it's created and stored in a structure that GRUB knows to > traverse and enumerate for the menu. It *is* GRUB dependent, but in > practice, this is fine since they only use GRUB. And for that matter, > that's mostly true for us too... Oh, christ. So they have to replicate their whole frickin storage stack in Grub, with LUKS, iscsi, DM, MD, LVM and whatnot to make this work. This sounds like a maintainance nightmare. I am pretty sure we shouldn't try to replicate that. Boot loaders should be simple, and we should leave the initrd do such logic using our usual Linux storage stacks. > I am growing to understand that this is increasingly fundamentally > incompatible with the way Red Hat has been going with this. In the Red > Hat world with the Bootloader Spec, this *has* to be managed at the > initramfs/OS level and explicitly generated and configured. Things > like Boom (remember that?) are supposed to generate bootloader entry > configuration snippets when OS snapshots are made. Given that boot loader spec entries are just single drop-in files it should be reasonably safe and simple to add them and remove them atomically. > > The current GPT partition types for the root fs are defined for each > > arch separately, so that you can have a single GPT disk image with one > > root fs partition for each arch, but that doesn't fit anymore if > > suddenly one of the root fs can hold the data for multiple archs, > > because its btrfs with multiple subvols. > > It would be good to develop a scheme for this sort of thing and see if > we can also get openSUSE on board too, especially in time for SLE > 16. Do they document how they name stuff for this snapper thing anywhere? > > By doing that correctly now, you can easily extend things later > > incrementally without breaking stuff, just by *adding* stuff. And you > > gain immediate compat with "systemd-nspawn --image=" right-away as the > > basic minimum, which already is great. > > I would love to do that now, but right now I want to make sure > everything *works* before we jumble up the scheme we use to set up the > subvolumes. Maybe delay this feature one iteration if things aren't clear? Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
