On Monday, July 13, 2020 11:13:50 AM MST Lennart Poettering wrote: > On Mo, 13.07.20 09:23, Chris Murphy (li...@colorremedies.com) wrote: > > > > I offer it to contradict the assertion that the current arrangement is > > "pushing btrfsisms". It is originally Fedora. And having to use btrfs > > specific commands to set/get the default, as you propose, is the > > "btrfsism" - in my opinion. > > > > > > > > Also, Btrfs in Fedora is not new, it's been discussed off and on over > > these same 10 years. Yet this is the first criticism I've come across > > for this use of rootflags. > > > > > > > > Since it's mostly bootloader domain, and relates to a snapshot and > > rollback paradigm as well, I think it's properly addressed in design > > and planning that feature. > > > It's not just a boot loader thing. By requiring this to be specified > explicitly, you make sure that "systemd-nspawn -i" and the various > other tools cannot make sense of it automatically. > > Quite frankly, I don't see why the boot loader should care about the > btrfs subvolume the initrd later picks at all..
systemd-nspawn has nothing to do with booting the host system, so I don't see how that matters. This is a bootloader configuration issue, nothing to do with systemd, unless systemd refused to accept the parameter. At that point, we need to look at rolling back systemd being part of initrd, and have it only in the actual userland. > > > I think a system that automatically discovers what it needs and works > > > without configuration and everywhere the same is what we should strive > > > for. Requiring configuration for this kind of stuff just makes stuff > > > fragile... > > > > > > > > Is the root parameter fragile? > > > Yes, because you have to propagate it everywhere, and if you omit it > things break, since it's a secondary place you store information about > the root disk in that you strictly need to have to be able to make > sense of the file system. That it has to be specified in order to work doesn't make it "fragile". It just shows that it's a key part of getting your system to actually boot. > So yes, requiring a special parameter to be passed everywhere just > sucks, as this magic info is needed on every boot and needs to be > passed everywhere, i.e. to the boot loader for physical boots, to the > brain of the hacker who wants to recover the fs if something goes > wrong, to tools like systemd-nspawn (and the other tools systemd has > that can take disk images) and so on. It's not "magic info" either, it's a string defining what to use as the rootfs. If systemd cannot handle that, that's a bug with systemd, not with specifying the root parameter. > You don't need the root parameter, actually. systemd automatically > finds the root fs for you, it can do that if the root fs is properly > advertised via the GPT partition type, according to the Discoverable > Partition Spec. Moving to some systemd thing for partition IDs doesn't make a whole lot of sense. There's nothing wrong with the way we've been doing it for the larger part of the last two decades. > https://systemd.io/DISCOVERABLE_PARTITIONS Additionally, this "spec" has no way of working with Btrfs subvolumes to begin with. > So yes, it is an explicit goal to make things robust so that a kernel > command line is not necessary for the default way things work, you > only use it to deviate from the default. The kernel commandline is going to be different for every system, and that's unavoidable. I really don't understand why you see this as an issue, it's not. > > > BTW, we once upon a time added a TODO list item of adding a btrfs > > > generator to systemd, similar to the existing GPT generator: it would > > > look at the subvolumes of the root btrfs fs, and then try to mount > > > stuff it finds if it follows a certain naming scheme. This would make > > > images entirely self-explanatory (i.e. you wouldn't have to know > > > external info such as subvol=root is the root, and subvol=home is > > > /home, and so on), but the file system would describe itself entirely, > > > just by having things named in a certain way. Because right now for > > > GPT we have this behaviour: if you use the GPT partition types of the > > > "Discoverable Partition Spec", then we'll automatically discover and > > > mount partitions for you, > > > > > > > > A variation on this is in discussion for a little bit now, perhaps > > most recently here: > > https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/2#note_865189 > > > > > > > > There is a difficulty. It is very easy to (externally) parse a GPT, > > and look for a partition type GUID. It is not nearly as easy to > > (externally) parse a Btrfs for subvolumes. The easiest way to get > > access to all subvolumes is via kernel ioctl, but you need to mount > > the file system for this. The other way is enhance the GRUB btrfs > > driver to be able to look for subvolumes and read XATTR, basically use > > it as a read-only parser to find what you're looking for and then > > mount by subvol name or ID. > > > Hm, grub? what? > > I am talking about mounting secondary subvolumes automatically, > i.e. in the initrd or early on after the transition to the host OS. > > In systemd we have enough btrfs code anyway for managing subvols, > writing a generator is trivial for us and would add very little new > code. It's mostly an excercise in figuring out how to name things, and > which subvols to cover. Why would this be handled by some "generator", rather than the host system's / etc/fstab? > > Stuffing this information in an XATTR might be the easiest way to go > > about it. I'm not sure whether the btrfs uuid tree could be used to > > associate file btrees (subvolumes) with arbitrary partition type > > GUIDs, or whether there's an advantage of doing so versus the work > > implied. > > > xattrs? That sounds unnecessary. I think the easiest would be to just > operate on subvoumes that are named a certain way. For example, we > could say, if the generator finds a set of subvolumes called > "/_home.<something>" on the root fs, then it would sort them by name, and > pick the last one of it, and automatically synthesize a .mount unit > that mounts it to /home. And similar for other relevant dirs. That > way, if you want to opt into this simple logic, just name your subvols > /_home.xyz and there you go. The suffix you can then use for versioning > or so, if you like, but we wouldn't care in the generator how you > actually make use of it. I don't know why xattrs would be used for this, but I don't see how trying to automagically mount things based on the name is a good solution either. The same solution I've recommended above works here: Read /etc/fstab, mount as shown. -- John M. Harris, Jr. _______________________________________________ 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
