"mount: /dev/mqueue: must be superuser to use mount" when starting a Yocto Linux system via NFS and TFTP

user_327648 0
Viewed 856

I followed the guide "Yocto NFS & TFTP boot" from the i.MX knowledge base to make my embedded Linux device run a kernel and a filesystem on my development machine.

The kernel seems to be correctly loaded via TFTP, but the system doesn't boot up properly and systemd goes into maintenance mode.

Here's the first error in the log:

[   10.637534] systemd[1]: dev-mqueue.mount: Mount process exited, code=exited, status=32/n/a
[   10.657077] systemd[1]: dev-mqueue.mount: Failed with result 'exit-code'.
[   10.666907] systemd[1]: Failed to mount POSIX Message Queue File System.
[FAILED] Failed to mount POSIX Message Queue File System.
See 'systemctl status dev-mqueue.mount' for details.

It seems similar to the log included in an unanswered comment in that same guide.

Looking into systemctl status dev-mqueue.mount I see:

* dev-mqueue.mount - POSIX Message Queue File System
     Loaded: loaded (/lib/systemd/system/dev-mqueue.mount; static)
     Active: failed (Result: exit-code) since Sun 2022-03-06 11:52:40 UTC; 5h 29min ago
      Where: /dev/mqueue
       What: mqueue
       Docs: man:mq_overview(7)
             https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

Mar 06 11:52:40 pico-imx7 mount[180]: mount: /dev/mqueue: must be superuser to use mount.
Notice: journal has been rotated since unit was started, output may be incomplete.

Not sure what's wrong, or why the system would fail like this.

yocto embedded-linux nfs linux
1 Answers

The message must be superuser to use mount is a hint to a permission problem.

The Linux system expects most system files to be owned by UID 0 (root), but when reading the NFS filesystem set up in the guide it actually reads UID 1000, or the UID of whoever built the system in the development machine. If I list the contents of ${YOCTO_BUILD_DIR}/tmp/work/${TARGET}-poky-linux-gnueabi/${IMAGE}/1.0-r0/rootfs, I get:

drwxr-xr-x 20 1000 1000 4096 Mar  9  2018 ./
drwxr-xr-x 14 1000 1000 4096 Mar  5 19:19 ../
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 bin/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 boot/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 dev/
drwxr-xr-x 59 1000 1000 4096 Mar  9  2018 etc/
drwxr-xr-x  4 1000 1000 4096 Mar  9  2018 home/
drwxr-xr-x 10 1000 1000 4096 Mar  9  2018 lib/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 media/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 mnt/
drwxr-xr-x  4 1000 1000 4096 Mar  9  2018 opt/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 proc/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 run/
drwxr-xr-x  3 1000 1000 4096 Mar  9  2018 sbin/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 srv/
drwxr-xr-x  2 1000 1000 4096 Mar  9  2018 sys/
drwxr-xr-t  2 1000 1000 4096 Mar  9  2018 tmp/
drwxr-xr-x 38 1000 1000 4096 Mar  9  2018 unit_tests/
drwxr-xr-x 11 1000 1000 4096 Mar  9  2018 usr/
drwxr-xr-x  9 1000 1000 4096 Mar  9  2018 var/

Notice the 1000 as UID and GID.

Compare that with the listing of the filesystem image tarball, made with tar --exclude=\*/\*/\* --no-wildcards-match-slash -tjvf ${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.tar.bz2:

drwxr-xr-x 0/0               0 2018-03-09 13:34 ./
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./bin/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./boot/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./dev/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./etc/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./home/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./lib/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./media/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./mnt/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./opt/
dr-xr-xr-x 0/0               0 2018-03-09 13:34 ./proc/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./run/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./sbin/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./srv/
dr-xr-xr-x 0/0               0 2018-03-09 13:34 ./sys/
drwxrwxrwt 0/0               0 2018-03-09 13:34 ./tmp/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./unit_tests/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./usr/
drwxr-xr-x 0/0               0 2018-03-09 13:34 ./var/

Here the root directories are correctly owned by root.

The same permissions are in the .ext4 image file, that is part of the SD/MMC image file.

Two possible solutions:

  • mount ${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.ext4 file as loop in a directory, then export that directory via NFS (might require root privileges);
  • extract ${YOCTO_BUILD_DIR}/tmp/deploy/images/${TARGET}/${IMAGE}-${TARGET}.tar.bz2 in a directory, then export that directory via NFS; will require root privileges and some more time to extract the embedded filesystem.
user_3276480
Related