Systemd: libmount utab mount options get lost when we switch root, and thus x-initrd.mount vanishes during initrd transitions

Created on 30 Mar 2020  路  3Comments  路  Source: systemd/systemd

x-initrd.mount (for instance) is used for setting mounts up in initrd. This "application" option is recorded in "utab" so applications (such as systemd) can figure out later which application options have been used for a given mount.

However in initrd, mount points described in fstab are usually mounted under /sysroot, therefore mount paths in utab are usually prefixed with "/sysroot". A typical entry in utab looks like:

SRC=/dev/vdb1 TARGET=/sysroot/mnt ROOT=/ OPTS=x-initrd.mount,_netdev

The problem appears after swithing to the main system: PID1 tries to retrieve the mount options (via mnt_fs_get_options()) for /mnt (not /sysroot/mnt) but nothing is found since the relevant entry has TARGET=/sysroot/mnt.

The previous example is based on x-initrd.mount but the issue can also happen with any other x-* options.

bug 馃悰 pid1

Most helpful comment

Hmm, I wonder what the right approach here... somehow libmount needs to either convert utab or better automatically handle this better.

Maybe the correct approach would be if libmount only ever uses the numeric mount ID (rather than the mount point path) for identifying mounts? that way things should remain robust regardless how many times we switch root.

@karelzak any chance you could rework libmount like that? i.e. replace the utab key with the numeric mount ID?

All 3 comments

Hmm, I wonder what the right approach here... somehow libmount needs to either convert utab or better automatically handle this better.

Maybe the correct approach would be if libmount only ever uses the numeric mount ID (rather than the mount point path) for identifying mounts? that way things should remain robust regardless how many times we switch root.

@karelzak any chance you could rework libmount like that? i.e. replace the utab key with the numeric mount ID?

I'll try it. @poettering suggested to use /proc/self/fdinfo/ to get the ID -- it seems elegant way how to bypass the current mount(2) stupidity (it does not provide any feedback after success). In the future with the new mount API we can get the ID from fsmount() FD.

Hmm... maybe the best would be to add to libmount an extra "switch-root" operation to modify entries in utab to match reality after system switch-root.

Was this page helpful?
0 / 5 - 0 ratings