Lennart Poettering wrote: > Well, if you don#t want that behaviour don't use the partition type > UUIDs from the "discoverable partition spec" for your partitions. > > It's how these type uuids are defined: > > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > By using these partition type uuids you basically say: "please > automatically mount me, thank you". Uh, no. Any tools that create a partition table will use that UUID if I create a swap partition. That's all that UUID really means: "this is a GNU/Linux swap partition". You unilaterally redefined it to mean that the partition should be automatically mounted even if I deliberately keep it commented out in /etc/fstab. That conflicts with the original definition of that UUID, which is followed by all the partitioning tools out there. I have had the systemd-auto-gpt-generator masked on all my systems for years (ever since I found out about its existence), and it will remain that way, sorry. I was really angry back when I looked at the KSensors statistics, noticed that the swap space was twice as large as expected, and realized that systemd has decided to mount my spare swap partition on my SSD behind my back and hence been using up my SSD behind my back for months. Thankfully, the SSD still works years later, looks like I caught it early enough. (You can be glad that you have that warranty disclaimer in the license, in any case…) Ever since, systemd-auto-gpt-generator is masked. IMHO, something that mounts partitions behind my back should not exist to begin with. > I am sorry, but in this day and age I am sure we should default to > stuff that just works, and that means: defaults should apply with > empty or immutable /etc. > > By making this a default but list it in a configuration file to work, > you require /etc to be writable or populated, and that just sucks. I disagree. /etc should be prepopulated by packages and/or the distribution installer. Then the directory is left for the local admin to customize. It makes no sense whatsoever for /etc to be immutable. Being writable is part of the definition of /etc. > I disagree. We should strive for a system that works with empty /etc/ > and if booted that way uses default settings. That is just not going to happen, globally. A lot of applications ship default settings in /etc that are not contained in the code, or even differ from the hardcoded fallback defaults in the code (also because the Fedora defaults may differ from the upstream defaults for various reasons). It is perfectly valid for a package to install %config or %config(noreplace) files to /etc, and you cannot expect the package to work if those files are completely missing. > So that /etc is admin territory where the admin makes changes from the > defaults. That does not conflict with creating an initial config file that sets up zram, either as a %config(noreplace) file in a package, or as an unpackaged (or %ghost-ed) file written by Anaconda (or Calamares or whatever you use to install the system). A lot of existing distribution defaults work that way. That config file can also be the existing /etc/fstab, which already works exactly that way. IMHO, the fewer places we have mounting things, the better. So I want to see ALL default mounts added to /etc/fstab rather than to some magic generator or .mount file, also that magic tmpfs.mount. (I see no valid reason for that not to simply be a line in /etc/fstab.) Having it all in one place makes it much easier for administrators to customize. > Thus, if zram is something to use by default then it should not be stored > in /etc. Thus, I think that this is a non-sequitur. There is nothing wrong with shipping default settings in /etc. It is much better than hardcoding defaults in magic generators somewhere in /usr and requiring users/admins to mask them to turn off the features they do not want (which means that they have to hunt down where the automagic mounting comes from to begin with, which is a huge waste of time for local administrators). Your argument that /etc/fstab still works is not really valid because it only works to add mounts or to replace automagic mounts with some other mount, but there is no fstab syntax to actually completely disable the automagic (because fstab was designed to be the very place where automatic mounts are listed, so why would it have needed a syntax to disable a mount coming from elsewhere?), so one has to mask the systemd file doing the automagic in systemd instead, it cannot be done from /etc/fstab. Kevin Kofler _______________________________________________ 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
