On Tue, Jul 14, 2020 at 1:39 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Mo, 13.07.20 19:07, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > Yes, the kernel also supports an initrd-less mode, where it's the > kernel itself that parses root=/rootflags=, but we don't use that in > Fedora (and because btrfs.ko is a module on Fedora can't be done at > all if your rootfs is btrfs). In this mode the syntax of root= is a > lot simpler, as the kernel itself doesn't grok all syntaxes we support > in libblkid/udev. > > So yes, root=/rootflags= is territory of udev/dracut/systemd on > Fedora. On Fedora the kernel does *not* parse that itself. The kernel > will ultimately get the parsed data passed back in, via the mount() > syscall, but that's all. :facepalm: OK now I'm getting some idea why you like no initrd capable boot. BTW, btrfs is built-in as of kernel 5.8.0-0.rc5.1.fc33 (yesterday). > > > In the single existing example of a distribution using btrfs default > > subvolumes, (open)SUSE, the bootloader automatically discovers the > > read only snapshots, and understands how to do rollback by specifying > > the proper /boot and / snapshot pairing. > > Are you sure? Yes. > > > 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. > > Ok but my home, server and variable data are all on the same volume, > > each in their own subvolume. Why does this file system get the Root > > partition type GUID and not the home, server, or var partition type > > GUIDs? > > There's a hierarchy here: You put the root of the file system tree in > some partition, and then if you decide to split off some subtree of > it, that subtree will get its own fs with its own partition type > UUID, but only then. > > 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. In the case of Silverblue, it is the same except they are separate directories, but still neither is a parent of the other regardless of what file system is used. > 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. > > I regularly install multiple Fedora's, each in their own subvolume, on > > a single Btrfs file system. That's way easier and much more space > > efficient to deal with than using separate partitions and file systems > > for each one. So you're saying, that's not a valid enough use case, > > just use separate file systems for that? > > Well, as a matter of fact OSes like to fully own stuff, i.e. the boot > loader, a file system and so on. If you want them to cooperate extra > work needs to be done, i.e. specs written so that they don't fight for > ownership but cooperate. For boot loaders the Boot Loader Spec can do > that. But if you actually want to go as far sharing the same fs > between multiple OSes, then you better have a very good spec in place > that clarifies how they are supposed to cooperate and name stuff so > that they don't constantly step on each other's toes. Things are better in F33. I've got a proof of concept for F32 and F33 sharing the ESP and /boot volumes. > > This is different in detail, but not altogether different from > > http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html > > 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. -- 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
