I assume the machine uses the latest BIOS update; it could add needed support for whatever controller is used.
sudo systemctl list-unit-files --type=service --state=failed --all
0 unit files listed.
ls -l /etc/systemd/system/
drwxr-xr-x 2 root root 4096 Aug 22 22:20 bluetooth.target.wants
lrwxrwxrwx 1 root root 41 Aug 22 22:20 dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root 44 Aug 22 22:20 dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root 44 Aug 22 22:20 dbus-org.freedesktop.ModemManager1.service -> /usr/lib/systemd/system/ModemManager.service
lrwxrwxrwx 1 root root 57 Aug 22 22:20 dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root 49 Aug 23 19:54 dbus-org.freedesktop.timesync1.service -> /usr/lib/systemd/system/systemd-timesyncd.service
lrwxrwxrwx 1 root root 39 Aug 22 22:20 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x 2 root root 4096 Jan 4 2023 getty.target.wants
lrwxrwxrwx 1 root root 9 Aug 29 23:37 lvm2-monitor.service -> /dev/null
drwxr-xr-x 2 root root 4096 Aug 27 02:36 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Aug 22 22:20 network-online.target.wants
drwxr-xr-x 2 root root 4096 Aug 22 22:20 printer.target.wants
lrwxrwxrwx 1 root root 37 Aug 25 23:47 rc-local.service -> /opt/shiarta/scripts/rc-local.service
drwxr-xr-x 2 root root 4096 Aug 22 22:20 sockets.target.wants
drwxr-xr-x 2 root root 4096 Aug 23 19:54 sysinit.target.wants
lrwxrwxrwx 1 root root 56 Oct 21 2018 systemd-fsck-silent-root.service -> /usr/lib/systemd/system/systemd-fsck-silent-root.service
lrwxrwxrwx 1 root root 52 Oct 21 2018 systemd-fsck-silent@.service -> /usr/lib/systemd/system/systemd-fsck-silent@.service
lrwxrwxrwx 1 root root 9 Jan 4 2023 systemd-rfkill.service -> /dev/null
lrwxrwxrwx 1 root root 9 Jan 4 2023 systemd-rfkill.socket -> /dev/null
drwxr-xr-x 2 root root 4096 Jan 4 2023 timers.target.wants
ls /usr/lib/systemd/
catalog scripts systemd-cgroups-agent systemd-homework systemd-journal-remote systemd-networkd systemd-quotacheck systemd-socket-proxyd systemd-udevd systemd-veritysetup user
import-pubring.gpg system systemd-coredump systemd-hostnamed systemd-journal-upload systemd-networkd-wait-online systemd-random-seed systemd-sulogin-shell systemd-update-done systemd-volatile-root user-environment-generators
libsystemd-core-254.5-1.so systemd systemd-cryptsetup systemd-import systemd-localed systemd-network-generator systemd-remount-fs systemd-sysctl systemd-update-utmp systemd-xdg-autostart-condition user-generators
libsystemd-shared-254.5-1.so systemd-backlight systemd-export systemd-importd systemd-logind systemd-oomd systemd-reply-password systemd-sysroot-fstab-check systemd-userdbd system-environment-generators user-preset
network systemd-battery-check systemd-fsck systemd-import-fs systemd-machined systemd-pcrphase systemd-resolved systemd-sysupdate systemd-user-runtime-dir system-generators
ntp-units.d systemd-binfmt systemd-growfs systemd-integritysetup systemd-makefs systemd-portabled systemd-rfkill systemd-timedated systemd-user-sessions system-preset
portable systemd-bless-boot systemd-hibernate-resume systemd-journald systemd-measure systemd-pstore systemd-shutdown systemd-t
You could always try adding noauto to the options list.
Or you could move to systemd mount units and set the mount to only happen later…
I’m sure it can be done in fstab as well, I just don’t know how.
You mention a BIOS update, but my system booots in EFI. Could that have something to do with it?
sudo umount -a; sudo mount -a does remount the disks, but it doesn’t solve the issue. So I doubt that mounting at a later time would help, if the mount service still doesn’t start.
It’s arguably still a BIOS; and there are sure to be updates available from the manufacturer site. Seems like you haven’t ever done that. The manufacturer should have all info needed; including if it’s needed.
The motherboard and the CPU were installed 6 weeks ago, so I assume that the BIOS is up-to-date.
In an ideal world, yes, but experience has shown it’s often not the case. That said, only update if the BIOS seems like it will solve a particular problem.
Don’t assume. Confirm and be sure.
One of my teachers used to say that is you assume you make an ass out of u and me…
Good one! I should keep that in mind 
I’ll have the BIOS flashed then. I have a computer guy who does those things for me.
Hopefully, it’ll solve the issue.
Hope that they don’t close this thread until that’s done.
I have not heard that in sooo long. 
Look up the manufacturer site anyway. If there’s no BIOS listed to download, then it saves wasted time.
Now I feel old… 
This is what ChatGPT has to say about delaying the mount:
(Please don’t try this at home without verifying everything.)
Create a systemd service unit file:
sudo nano /etc/systemd/system/delayed-mount.service
Add the following content:
[Unit]
Description=Delayed Mount for /dev/sdX
[Service]
Type=oneshot
ExecStartPre=/bin/sleep 30
ExecStart=/bin/mount /dev/sdX TARGET_MOUNT_POINT
[Install]
WantedBy=multi-user.target
Reload systemd and enable the service:
sudo systemctl daemon-reload
sudo systemctl enable delayed-mount.service
Start the service:
sudo systemctl start delayed-mount.service
Check the status:
sudo systemctl status delayed-mount.service
Reboot system:
sudo reboot
PS: I couldn’t resist 
It almost looks legit. ‘Reboot’ could use some work.
This should be achievable instead, with a boot script of some kind, I imagine.
That’s what I’d have suggested as well. Well mostly. I’d have exchanged the:
ExecStartPre=/bin/sleep 30
…in the [Service] section for a dependency of some sort in the [Unit] section. For example, this is a service I use for checking automounting Raspberry PI’s Apache directory:
$ sudo systemctl cat mnt-minikeeper-www.automount
# /etc/systemd/system/mnt-minikeeper-www.automount
[Unit]
Description=Automount Minikeeper websites
ConditionPathExists=/mnt/minikeeper/www
[Automount]
Where=/mnt/minikeeper/www
TimeoutIdleSec=30m
[Install]
WantedBy=multi-user.target
It makes it nice and easy to specify the order in which services are started.
1 Like
Using ‘nofail’ where appropriate in /etc/fstab might also be worth considering, but then the problem of identifying which drives should be prioritized, still remains. It seems like they all need to be delayed.
I saw something similar recently: 
This concept could be modified in the form of a boot script thst invokes sleep for a specified time before systemctl attempts to mount the volumes. As stated " with the nofail mount option, so that the system doesn’t hang".
I simply don’t know how this would work in practice.
1 Like
Or, as this answer suggests:
Just add
noautoto the mount options in fstab, and mount inrc.local.
That looks promising too, but with Arch parlance.
1 Like
Couple of things I see in your fstab.
- Your line for swap looks like this:
UUID=82582173-f957-4a03-b3b5-289447c2726d swap swap defaults,noatime,discard 0 1
but AFAIK (and the way it is on my desktop) it should look like this:
UUID=82582173-f957-4a03-b3b5-289447c2726d none swap defaults 0 0
- Then this line:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
can be safely removed. I read about it not too long ago here: Manjaro Wiki page about `/etc/fstab` needs corrections
1 Like
I just updated my laptop last night and mounting my external usb drive has been broken since. I had another laptop that wasn’t updated and it worked fine. I updated it and getting the same result now.
edit: wrong thread issue.
My NTFS external USB not mounting was solved in
This is minor, but
media-mount != mount-media
2 Likes
I’m not sure of the need for the mask, but:
tmpfs /tmp tmpfs defaults 0 0
should normally suffice.