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@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
