Inability to add pseudo-filesystem fstab entries

  • Open
  • quality assurance status badge
Details
2 participants
  • Tobias Geerinckx-Rice
  • mirai
Owner
unassigned
Submitted by
mirai
Severity
normal
M
(name . bug-guix)(address . bug-guix@gnu.org)
ccb0ccf0-624c-b43f-cdce-8f0715e8eff2@makinata.eu
An entry of the form:

Toggle snippet (13 lines)
(file-system
(mount-point "/media/foo-mount")
(create-mount-point? #t)
(mount? #f)
(device "none")
(type "overlay")
(flags '(no-atime no-dev no-suid no-exec read-only))
(options (string-append "lowerdir="
(string-join '("/srv/foo/overlays/bar"
"/srv/foo/overlays/baz") ":")))
(check? #f))

Does not result in a fstab entry line, which makes it impossible to mount. According to Guix docs, this shouldn't be the case:

Toggle snippet (5 lines)
mount? (default: #t)

This value indicates whether to automatically mount the file system when the system is brought up. When set to #f, the file system gets an entry in /etc/fstab (read by the mount command) but is not automatically mounted.

Looking at gnu/services/base.scm there's this snippet:

Toggle snippet (18 lines)
(define (file-system-fstab-entries file-systems)
"Return the subset of @var{file-systems} that should have an entry in
@file{/etc/fstab}."
;; /etc/fstab is about telling fsck(8), mount(8), and umount(8) about
;; relevant file systems they'll have to deal with. That excludes "pseudo"
;; file systems.
;;
;; 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.
(remove (lambda (file-system)
(or (member (file-system-type file-system)
%pseudo-file-system-types)
(memq 'bind-mount (file-system-flags file-system))))
file-systems))

That seems to remove such pseudo-fs entries, regardless of 'mount?' value.
This is not a "documentation" bug, as there are valid uses for having pseudo-fs entries.

Right now I'm trying to add an overlayfs mount that is layered over a NFS system and
Guix doesn't exactly deal very well with mounting NFS as it depends on networking. To sidestep this,
I am mounting the NFS volume through a simple-service that puts a dependency on networking.

From here the fstab problem begins: since it can't be mounted at boot "conventionally", it is set
as mount? #f with the intention to mount it later via "mount /media/foo-mount" after NFS volume is ready
but since this entry does not end up in /etc/fstab, there's no way to mount it.
T
T
Tobias Geerinckx-Rice wrote on 21 Dec 2022 23:50
(name . mirai)(address . mirai@makinata.eu)
87cz8c8hoc.fsf@nckx
Hi Bruno,

mirai ???
Toggle quote (3 lines)
> 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:

Toggle quote (8 lines)
> ;; 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.

Toggle quote (2 lines)
> %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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY6OVgw0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15QPMA/37Tm7M3GBIAt5E5INuIPB/MS9y4D5v2YQnQ6WjA
jXVmAQCQWm0EVtWJkfq7wWy6pwIJweEwzn5KUCVu7tiWnuk7AA==
=qh5I
-----END PGP SIGNATURE-----

M
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
4da5e6b4-c5d3-94ba-b0ac-9b8447171482@makinata.eu
Hi,

On 2022-12-21 22:50, Tobias Geerinckx-Rice wrote:
Toggle quote (8 lines)
>
> 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.

If that's the case, an approach for these "unspeakable" file-systems whose presence must not be recorded in fstab
would be to at least "generate" some file-system- shepherd services (and have them enabled/disabled according to mount? value).
This way there's at least a way to "start" these mounts rather than them ending up in the /dev/null abyss.
T
T
Tobias Geerinckx-Rice wrote on 22 Dec 2022 00:41
(name . mirai)(address . mirai@makinata.eu)
878rj08gsc.fsf@nckx
mirai ???
Toggle quote (4 lines)
> This way there's at least a way to "start" these mounts rather
> than
> them ending up in the /dev/null abyss.

A non-standard and hard to discover way, sure.

I liked the (unless mount? (add-to-fstab)) suggestion better.

(I'm taking the comment at face value—I'd have suggested adding
them all to fstab otherwise.)

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY6OaBQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15vDUBAMnkr7i6uD/yUpJamw5uKtXqjdVqha/L+Gk/iL0u
kQ+RAP9mEqOyq5HDz5RVf/HTux6050fmIrhrAVZ/w5lXOwv0Cg==
=3Pn3
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 60246@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 60246
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch