On Tue, Jul 14, 2020 at 2:45 PM 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? > > Really? It's not needed with BLS, we don't ship it in the IoT Edition. > > > 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@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 _______________________________________________ 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
