On Di, 14.07.20 07:09, Chris Murphy (li...@colorremedies.com) 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? Really? > > i.e. if /home is split out into its own fs, then you give it the home > > partition uuid type, but if not, then it is just part of the root > > partition (as that is the immedate parent directory) and thus sits in > > the same partition as the root fs. > > In the case of Btrfs, sysroot and home are in their own subvolumes > (separate namespace, separate btrees). Neither is a parent of the > other. Well, still, /home is conceptually ultimately a child of /, regardless how you organize stuff on the lowest layer... > > 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. > > OK. Roll the dice, add another GUID to the spec. > > 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? > > Well, that's very old, I would't do it like that anymore. But yeah, > > there are ideas there that are related. > > The naming schema would be nice to get figured out. Right now the > naming of subvolumes is user domain in the installer. This concept > necessarily takes that away, it becomes system domain. And what > happens if a user changes the name? Is it a bad idea to stuff a copy > of this information in an XATTR so it can be restored? The schema > needs to account for snapshotting and rollbacks. I'm not sure how much > information really should be encoded in a subvolume name. We manage to name RPMs with versions, epochs, archs and so on, I doubt we need much more for naming subvolumes to auto-assemble. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
