On Tue, Jul 14, 2020 at 5:31 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > 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? > I think it's documented somewhere, but I'll have to look for it... > > > 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? > Changing the names for the subvolumes is *easy*, but right now I'm working on getting ARM disk images built. Everything else is basically done. I only really have bandwidth to work on one thing at a time right now, so I'm literally talking about days or a week or so before I can think about changing the scheme. It's not a "feature delay" thing, it's a "Neal can only do one thing at a time" thing. :) -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
