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: systemd-tmpfiles-setup.service: Installed new job systemd-tmpfiles-setup.service/start
[ 11.947163] systemd: systemd-udevd-kernel.socket: Installed new job systemd-udevd-kernel.socket/start
[ 11.947217] systemd: systemd-tmpfiles-setup-dev.service: Installed new job systemd-tmpfiles-setup-dev.service/start
[ 11.947232] systemd: systemd-remount-fs.service: Installed new job systemd-remount-fs.service/start
[ 11.947255] systemd: systemd-udevd.service: Installed new job systemd-udevd.service/start
[ 11.947324] systemd: systemd-udev-trigger.service: Installed new job systemd-udev-trigger.service/start
[ 11.948120] systemd: tmp.mount: Installed new job tmp.mount/start
[ 11.948498] systemd: proc-fs.mount: Collecting.
[ 11.948522] systemd: 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
The last three entries are resulting from the
/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
df /tmp to see where /tmp is mounted/situated. Maybe
/etc/fstab is not used then.