Embora isso não seja uma resposta para a sua pergunta, eu tenho que dar isso para formatação e como é muito longo para um comentário.
Veja o buffer de mensagem do kernel com dmesg | less
. Isso mostra quando o serviço é iniciado. No meu caso, vejo (deixando linhas não relacionadas):
[ 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
As últimas três entradas são resultantes da entrada fstab
/dev/disk/by-label/data /data xfs defaults,nofail,noatime 0 0
Não sei quais das linhas em dmesg
são realmente importantes neste caso.
Mas parece que a montagem de /tmp
(11.948120) ocorre antes de /dev/disk/by-label
ser criada e preenchida. Portanto, se não houver um motivo especial, você não deve montar o / tmp dessa maneira.
Você pode descobrir modificando a linha fstab
para ler LABEL=tmp /mnt ext4 nofail,errors=remount-ro 0 3
e, em seguida, reinicializar e examinar a respectiva saída de dmesg
. E quando você inicializar no modo de recuperação do sistema, tente mount
ou df /tmp
para ver onde / tmp está montado / situado. Talvez /etc/fstab
não seja usado.