On Tue, Jul 14, 2020 at 7:45 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Di, 14.07.20 07:09, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > > > > Why at boot time? Well if your default subvolume contains a recent > > > > update that for some reason renders it unbootable, it might be nice to > > > > be able to pick a prior snapshot. That's how they do this. It isn't > > > > how we have to do it, but that's the example that we know works > > > > because it's actually designed, planned, implemented and maintained. > > > > > > Nah, this kind of selection you do in the initrd, not in the boot loader. > > > > There are two examples of the latter: (open)SUSE and rpm-ostree. I'm > > not aware of any examples of the former. > > I am sorry, what? rpm-ostree has a grub module it needs to operate? No. You said "this kind of selection" - which suggests user action. The user action to choose a particular tree version has two examples, and both of them happen in the bootloader (really, the boot manager's menu of boot entries). I don't know what selection of this would look like if it were in the initrd - maybe some kind of automatic test for successful boot and if it doesn't succeed it reboots and tries some other tree automatically? But changing trees like this means you need a way to specify them without depending on read-write mount. You may not have read-write mount during the failed boot. > > Note however that there's resistance supporting arbitrary partition > > type GUIDs, due to tooling. The installer depends on 'parted' for > > doing the partitioning and 'parted' has no concept of arbitrary > > partition types, each one must be explicitly added, and they are way > > behind where fdisk and gdisk are. As in, nothing in the Discoverable > > Partition Spec is in 'parted' right now. I've asked multiple times > > over the years. > > use libfdisk instead? That's up to anaconda/blivet folks. I can't estimate the amount of work to do that, versus the gains. -- Chris Murphy _______________________________________________ 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
