bug#60246: Inability to add pseudo-filesystem fstab entries

bug#60246: Inability to add pseudo-filesystem fstab entries

[mirai]

An entry of the form:

--8<---------------cut here---------------start------------->8---
  (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))
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
(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))
--8<---------------cut here---------------end--------------->8---

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.

bug#60246: Inability to add pseudo-filesystem fstab entries

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#60246: Inability to add pseudo-filesystem fstab entries

[mirai]

Hi,

On 2022-12-21 22:50, Tobias Geerinckx-Rice wrote:
> 
> 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.

bug#60246: Inability to add pseudo-filesystem fstab entries

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

mirai 写道：
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]