1

My systemd does not see /dev/disk/by-label/tmp which is to be mounted on my /tmp. It gets stuck waiting for the mounting service of /tmp. When I run a tty9-debug-shell, then all I have to do is:

mount /tmp

and the system continues booting up nicely.

/etc/fstab contains:

LABEL=tmp /tmp ext4 nofail,errors=remount-ro 0       3

This does not happen if I boot in rescue mode.

How can I make systemd just try the mount /tmp?

$ cat /etc/issue
Ubuntu 17.04 \n \l
$ uname -a
Linux hk 4.10.0-20-generic #22-Ubuntu SMP Thu Apr 20 09:22:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Improve this question
2
  • Not sure, but are the device symlinks already present when the system boots and tries to mount local filesystems? These are created through udevd and that might not be active in rescue mode?
    – ridgy
    Jul 15, 2017 at 15:59
  • @ridgy How do I determine that? I can only react so fast on the tty9-debug-shell.
    – Ole Tange
    Jul 16, 2017 at 0:38

1 Answer 1

Reset to default
0

Although this is not an answer to your question, I have to give it that way for formatting and as it's too long for a comment.

Look at the kernel message buffer with dmesg | less. This shows when which service is started. In my case, I see (leaving unrelated lines): 

[   11.946916] systemd[1]: systemd-tmpfiles-setup.service: Installed new job systemd-tmpfiles-setup.service/start
[   11.947163] systemd[1]: systemd-udevd-kernel.socket: Installed new job systemd-udevd-kernel.socket/start 
[   11.947217] systemd[1]: systemd-tmpfiles-setup-dev.service: Installed new job systemd-tmpfiles-setup-dev.service/start 
[   11.947232] systemd[1]: systemd-remount-fs.service: Installed new job systemd-remount-fs.service/start
[   11.947255] systemd[1]: systemd-udevd.service: Installed new job systemd-udevd.service/start
[   11.947324] systemd[1]: systemd-udev-trigger.service: Installed new job systemd-udev-trigger.service/start
[   11.948120] systemd[1]: tmp.mount: Installed new job tmp.mount/start
[   11.948498] systemd[1]: proc-fs.mount: Collecting.
[   11.948522] systemd[1]: dev-disk-by\x2dlabel.mount: Collecting.
.
[   14.151615] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[   14.173106] XFS (sdb1): Mounting V5 Filesystem
[   14.462102] XFS (sdb1): Ending clean mount

etc.

The last three entries are resulting from the fstabentry 

/dev/disk/by-label/data /data   xfs defaults,nofail,noatime 0   0

I do not know which of the lines in dmesg are really important in this case. But it seems that the mount of /tmp (11.948120) takes place before /dev/disk/by-label is created and populated. So, if there is no special reason, you should not mount /tmp this way.

You might find out by modifying the fstab line to read LABEL=tmp /mnt ext4 nofail,errors=remount-ro 0 3 and then reboot and look at the respective output of dmesg. And when having booted in system rescue mode, try mount or df /tmp to see where /tmp is mounted/situated. Maybe /etc/fstab is not used then.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .