On Mon, Jul 13, 2020 at 12:14 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > Quite frankly, I don't see why the boot loader should care about the > btrfs subvolume the initrd later picks at all. As far as I'm aware, rootflags= is a kernel boot parameter, and it informs the kernel of mount options for the file system defined by the root= boot parameter. Neither are initrd related. None of Btrfs options or assembly are done by initrd or dracut magic. 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. 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. > > > 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. > > 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. I'll buy some of this argument. But I'm not going to expect this parameter is going away in Fedora 33, just like that. > > And it is currently. I don't see how it's any more safe and robust by > > eliminating only rootflags, but not 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. > > https://systemd.io/DISCOVERABLE_PARTITIONS 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? 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? > 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. Yeah I use a bootloader menu entry to boot between different roots. It contains that information. And also the specific options for that particular root, which sometimes includes a different kernel that is root specific. That example, again, exists. If you're proposing something different, that is in the category of design and planning. > > 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. > > > 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. To discover the names of subvolumes you have to mount the file system first. So you're thinking: 1. The specific file system to be mounted as sysroot is the one with the Root partition type GUID as defined in discoverable partitions spec. 2. The specific subvolume that is mounted when doing (1) is the default subvolume defined by 'btrfs subvolume set-default' 3. Mount can thus happen without root= or rootflags= and can happen on the first mount attempt 4. Upon mount a full subvolume listing is possible by BTRFS_IOC_TREE_SEARCH + BTRFS_IOC_INO_LOOKUP 5. Now you can mount home, var, srv, subvolumes per a schema This is different in detail, but not altogether different from http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html 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. -- 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
