[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60246: Inability to add pseudo-filesystem fstab entries
From: |
Tobias Geerinckx-Rice |
Subject: |
bug#60246: Inability to add pseudo-filesystem fstab entries |
Date: |
Wed, 21 Dec 2022 23:50:08 +0100 |
Hi Bruno,
mirai 写道:
Does not result in a fstab entry line, which makes it impossible
to mount. According to Guix docs, this shouldn't be the case:
Hm, yes, strictly speaking that is so.
It feels a bit weird to add or omit fstab entries based on MOUNT?
being true or false, but… it seems like a good proxy for what the
user *means* in both cases?
If the following is really true, we have little other choice:
;; In particular, things like GIO (part of GLib) use it to
determine the set
;; of mounts, which is then used by graphical file managers and
desktop
;; environments to display "volume" icons. Thus, we really need
to exclude
;; those pseudo file systems from the list.
so I wouldn't be opposed to it.
%pseudo-file-system-types)
I disagree that overlayfs is a ‘pseudo-file-system’, any more than
NFS would be. It should not be in that list to begin with.
And this is where it gets fun: apparently… it was added at my
request‽ :-)
Or at least Ludo's interpretation of that requests, in commit
df1eaffc3:
file-systems: Expound '%pseudo-file-system-types'.
Reported by Tobias Geerinckx-Rice <me@tobias.gr>.
* gnu/system/file-systems.scm (%pseudo-file-system-types): Add
"debugfs", "efivarfs", "hugetlbfs", "overlay", and
"securityfs".
Even in this list, ‘overlayfs’ has huge
one-of-these-is-not-like-the-others energy, so I wonder what the
reason was. I don't remember.
I'd happily revert it if I didn't suspect that it was to work
around some real (installer?) bug…
Kind regards,
T G-R
signature.asc
Description: PGP signature