On Tuesday, July 14, 2020 12:39:01 AM MST Lennart Poettering 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. That's done in the bootloader, not the initrd. If you'd like to see this behavior to day, you need only reboot and wait for GRUB2 to show up. > That all said, it might make sense to define a new partition type uuid > for "btrfs-all-in-one" file systems, because for that it might make > sense to even allow multiple OS archs in the same btrfs file system, > e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of > the OS, but /_root.fedora32.arm64 for the ARM version and then have a > single fs that can be booted on either arch. How would that make any sense? What's wrong with parsing fstab, as with literally every other system? > > And that's a fine idea. But all of this directly involves a design and > > plan for a snapshot and rollback regime. That's not happening for > > Fedora 33. There's enough on our plate right now. > > > All I am asking for is to make this simple and robust and forward > looking enough so that we can later add something like the generator I > proposed without having to rerrange anything. i.e. make the most basic > stuff self-describing now, even if the automatic discovering/mounting > of other subvols doesn't happen today, or even automatic snapshotting. Using a "generator" for this is probably the least discoverable way to go about it, in this case. Again, fstab solves this problem. We don't need to replace our wheels with square ones. -- John M. Harris, Jr. _______________________________________________ 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
