Failed to start Mount removable media on sda1

This is what my splash screen shows at boot for each of my built-in SATA devices, acompanied by:

“See systemctl status mount-media@sda1.service for details”. But when I try that, Manjaro responds that that service doesn’t exist.

During operation, the computer hangs and freezes regularly, mostly when disk operations are involved.

I have this issue on kernel 6.5.5-1, but had it as well on the latest LTS kernel. Both kernels start in EFI.

What exactly did you try?

Post the content of you /etc/fstab file, and also the output from sudo blkid - this may help someone take a guess. Cheers.

By “trying that”, I meant isueing the systemctl that the splash screen mentioned.

Very strange…

my fstab looks like this:

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=71623048-78e9-4e5a-b104-89476a1d7be7	/		ext4	defaults,noatime,commit=60	0  1
UUID=82582173-f957-4a03-b3b5-289447c2726d	swap		swap	defaults,noatime,discard	0  1
UUID=6B91-F5AA					/boot/efi	vfat	umask=0077			0  2
tmpfs						/tmp		tmpfs	defaults,noatime,mode=1777	0  0

UUID=caa00fa2-bb4d-4ed6-b4c8-de1ff8011ec7	/mnt/x/1	ext4	defaults,noatime,commit=60	0  2
UUID=af36579b-933c-4b79-a8a9-c21f2940aa97	/mnt/x/2	ext4	defaults,noatime,commit=60	0  2

/mnt/x/2/s/shiarta.opt		/opt/shiarta		ext4	defaults,bind		0  0
/mnt/x/2/s/home			/home			ext4	defaults,bind		0  0

/mnt/x/1/g		/mnt/g/1	ext4	defaults,bind		0  0
/mnt/x/2/g/p		/mnt/g/2	ext4	defaults,bind		0  0
/mnt/x/2/g/i		/mnt/g/2i	ext4	defaults,bind		0  0

/mnt/x/1/o		/mnt/o/1	ext4	defaults,bind		0  0
/mnt/x/2/o		/mnt/o/2	ext4	defaults,bind		0  0

but blkid shows only:

/dev/sda3: UUID="82582173-f957-4a03-b3b5-289447c2726d" TYPE="swap" PARTUUID="d3ae67fe-f097-459d-a0ed-cc6feffa480d"

It has to show you more. For example, mine:

$ blkid
/dev/nvme0n1p3: UUID="D563-DAB7" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="0653a05b-0f22-f64c-a283-7cc0dcb83551"
/dev/nvme0n1p1: UUID="1b3f894f-5481-4241-ace5-c129a0cdb412" TYPE="swap" PARTUUID="30f1cded-fe63-be47-9fe7-e2bdf635f38f"
/dev/nvme0n1p2: UUID="9a26c8d0-43f4-44ad-a7d3-861d6f6cdbfa" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b84f55b3-2488-a14c-9c4a-6acd385f2db6"
/dev/sdb1: LABEL="5TB" UUID="953836d8-e355-4c6d-ac1a-0914b8414f50" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7a05b57a-5368-c647-baa3-410f462004a6"
/dev/sda1: LABEL="4TB" UUID="c47c5a52-db30-4aef-bcbc-af35b7b021fd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="32f8a311-a601-ed4c-96d3-0d4cf6e6bd04"

That is only one partition, and not your main one at that.

Yeah, I know. It should show all those mounted disks. But it doesn’t.

As is, I don’t even have a hypothesis. I can access each of those disks nonetheless. But it takes several seconds for them to respond.

And what happens when you run:

mount

Have you perhaps tested it in a live environment?

mount shows this:

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=8068528k,nr_inodes=2017132,mode=755,inode64)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sdd2 on / type ext4 (rw,noatime,commit=60)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19493)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,noatime,inode64)
/dev/sdc1 on /mnt/x/2 type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sdd3 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sdc1 on /home type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sda4 on /mnt/x/1 type ext4 (rw,noatime,commit=60)
/dev/sdc1 on /mnt/g/2 type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sdc1 on /mnt/g/2i type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sdc1 on /mnt/o/2 type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sdc1 on /opt/shiarta type ext4 (rw,noatime,commit=60,stripe=8191)
/dev/sda4 on /mnt/g/1 type ext4 (rw,noatime,commit=60)
/dev/sda4 on /mnt/o/1 type ext4 (rw,noatime,commit=60)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1616016k,nr_inodes=404004,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

I did do several things with a Live-USB indeed, but that one seems to be able to access the disks properly.

Are any partitions handled by LVM?

1 Like

OK, I’m no expert, but in the mount output:

…it would seem 2 drives are being mounted. So let’s double-check that. Please provide the output of:

lsblk

…as well as:

ls -l /mnt/x/2

To my knowledge, I didn’t install it along with Manjaro. I do recall having seen such option, but left it unticked.

Is there a way for me to verify it?

Shouldn’t be needed, if you didn’t choose it. It’s been a long time since I used LVM (I prefer standard partitions). I was really just reaching… eg: maybe if swap were on a standard partition, and the others in LVM, that something could go awry because of that. – Just ignore it though, as it’s probably not relevent.

lsblk:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0  16.4T  0 disk 
├─sda1   8:1    0    64G  0 part 
├─sda2   8:2    0    64G  0 part 
├─sda3   8:3    0    32G  0 part [SWAP]
└─sda4   8:4    0  16.2T  0 part /mnt/o/1
                                 /mnt/g/1
                                 /mnt/x/1
sdb      8:16   0  16.4T  0 disk 
├─sdb1   8:17   0    64G  0 part 
├─sdb2   8:18   0    32G  0 part 
├─sdb3   8:19   0    32G  0 part 
├─sdb4   8:20   0  16.2T  0 part 
└─sdb5   8:21   0    16M  0 part 
sdc      8:32   0   2.7T  0 disk 
├─sdc1   8:33   0   2.6T  0 part /opt/shiarta
│                                /mnt/o/2
│                                /mnt/g/2i
│                                /mnt/g/2
│                                /home
│                                /mnt/x/2
├─sdc2   8:34   0     1M  0 part 
├─sdc3   8:35   0  48.2G  0 part 
└─sdc4   8:36   0    40G  0 part 
sdd      8:48   0 111.8G  0 disk 
├─sdd1   8:49   0  50.4G  0 part 
├─sdd2   8:50   0    60G  0 part /
└─sdd3   8:51   0   1.3G  0 part /boot/efi

sudo ls -l /mnt/x/2:

total 213540
drwxr-xr-x  5 root   root                4096 Aug 23 18:47 20210401
-rw-r--r--  1 alicia alicia              1034 Aug 23 12:51 fstab
drwxr-xr-x  4 root   root                4096 Apr 18  2020 g
drwxrwxrwx  7 root   root               49152 Apr 14  2017 lost+found
drwxr-xr-x  3 root   root                4096 Aug 14  2021 manjaro
drwxrwxrwx 44 root   alicia              4096 Aug 28 11:58 o
drwxr-xr-x  3 root   root                4096 Apr 18  2020 oi
drwxrwxrwx  5 root   alicia              4096 Aug 14  2021 old
drwxr-xr-x  7 root   root                4096 Aug 23 19:16 s
drwxrwxrwx  5 root   nm-openconnect      4096 Apr 25  2020 teamspeak
-rw-rw-rw-  1 root   root           218574613 Apr 18  2020 usr-share.zip

The /mnt/x mount point is set to root:root 770 which always worked fine.

OK, now I see everything mount-related looks OK to me, so let’s see if we can see anything about that failed service. Please return the output for:

sudo systemctl list-units --state=failed

and

sudo systemctl status mount-media@sda1.service

and

sudo journalctl -xeu mount-media@sda1.service --no-pager

Ah, here come some hints (I think)…

sudo systemctl list-units --state=failed:

  UNIT                     LOAD   ACTIVE SUB    DESCRIPTION                  
● media-mount@sda1.service loaded failed failed Mount removable media on sda1
● media-mount@sda2.service loaded failed failed Mount removable media on sda2
● media-mount@sda3.service loaded failed failed Mount removable media on sda3
● media-mount@sda4.service loaded failed failed Mount removable media on sda4
● media-mount@sdb1.service loaded failed failed Mount removable media on sdb1
● media-mount@sdb2.service loaded failed failed Mount removable media on sdb2
● media-mount@sdb3.service loaded failed failed Mount removable media on sdb3
● media-mount@sdb4.service loaded failed failed Mount removable media on sdb4
● media-mount@sdb5.service loaded failed failed Mount removable media on sdb5
● media-mount@sdc1.service loaded failed failed Mount removable media on sdc1
● media-mount@sdc2.service loaded failed failed Mount removable media on sdc2
● media-mount@sdc3.service loaded failed failed Mount removable media on sdc3
● media-mount@sdc4.service loaded failed failed Mount removable media on sdc4
● media-mount@sdd1.service loaded failed failed Mount removable media on sdd1
● media-mount@sdd2.service loaded failed failed Mount removable media on sdd2
● media-mount@sdd3.service loaded failed failed Mount removable media on sdd3

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
16 loaded units listed.

sudo systemctl status mount-media@sda1.service:

Unit mount-media@sda1.service could not be found.

Looks like there’s something not installed, or that it’s broken. But half an hour before starting this thread, I did pacman -Syyu.

The main question now is why it failed. Isn’t there a log that I could check for details?

I’ll go over dmesg. Perhaps it has something useful to say.

The last messages go something like this (several times in a row):

[ 9637.556696] ata1.00: configured for UDMA/133
[ 9656.219872] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 9656.220058] sd 0:0:0:0: [sda] Stopping disk

I honestly do not have a cooking clue…

Let’s dig some more, except if someone that does know wants to and can chime in. Please provide the output for:

sudo systemctl list-unit-files --type=service --state=failed --all

and

ls -l /etc/systemd/system/

and

ls -l /usr/lib/systemd/

Are these drives USB? (I saw ‘removable’).

Is it possible that systemctl is attempting to mount these volumes before they are ready? Maybe mounting could be somehow delayed a few seconds; a short sleep period, before mounting…

1 Like

That has me thinking as well for a while now indeed. They really are internal disks, but somehow Linux appears to misjudge them.