On Monday, July 13, 2020 3:12:22 AM MST Lennart Poettering wrote: > On Fr, 10.07.20 18:55, Chris Murphy (li...@colorremedies.com) wrote: > > > > > There's really no need to complicate things by pushing btrfsisms into > > > user-visible concepts needlessly. > > > > > > > > It's been this way in Fedora for a decade. > > > Well, that's an argument one could also use against btrfs. We are > trying to improve things here, hence arguing with "this has always > been that way" is not leading anywhere... > > > > When I say understandable, I mean a user can follow a trail of > > breadcrumbs for boot, startup, and assembly: not just rootflags, but > > also that systemd at sysroot mount time, also uses the 'subvol=' mount > > option. Whereas if this is a leap, they can't follow it. > > > 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... > > > > If the user mounts this file system elsewhere, including from a > > livecd, they actually won't see their home, it's hidden. How are they > > supposed to know where it is or how to find it, without learning > > btrfsisms? > > > Booting is something you do every day, we want that safe and robust. > > Mounting a foreign btrfs on your system to investigate it is a debug > job for the experienced users. > > You simplify and make robust the common case, not the exotic debug > case. > > 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, not just at boot, but also in systemd-nspawn > when you point it to such an image, and various other systemd tools. I > am pretty sure it would be reall nice if btrfs would be set up the > same way: entirely self descriptive, so that the mount hierarchry is > determined from itself, without needing an external config source such > as the kernel cmdline or fstab.
Trying to hide these things from the end user, instead of providing them with the tools necessary to maintain their system, isn't going to help anyone. I know this is counter to what seems to be so popular today, but more options and tools isn't a bad thing. As far as cmdline verbosity, the end user doesn't see that unless they explicitly want to, in which case it's actually better to generate a verbose cmdline from Anaconda's initial installation, such that the end user can see the options they may want to modify first. Removing these options is harmful. These things shouldn't try to hide themselves away in "generators". The best way to go about it, as I see it, is the way we've always handled it. The root mountpoint is read from /etc/fstab, and used when generating the bootloader config, and the rest are read from /etc/fstab on boot. If it's not in /etc/ fstab, it shouldn't be mounted, with few exceptions (/dev, /sys, /tmp, for example). -- 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
