Fstab mounting fails at boot, but succeeds when invoked manually
I immediately thought that the USB drivers for the device, or whatnot, aren't getting loaded before fstab is "executed." So after googling "mounting usb drive fstab" I found this: http://solutionsandtips.blogspot.com/2009/05/uuid-fstab-and-automatically-mount-usb.html
rzetterberg
An evolutionary algorithm in form of a human being.
Updated on September 18, 2022Comments
-
rzetterberg over 1 year
Background
On our development/backup server at my company we have 4 drives which are setup using software Raid 1, like this:
- Raid 1 (system disk): 2 x 320 GB
- Raid 1 (store/backup disk): 2 x 2 TB
Forming 2 "virtual" disks.
Now some people at the office want to migrate some data from an 1 TB drive from an old server. So what I've done is that I have a docking station for the disk which is connected to our server through USB. Now I've added that drive to
fstab
using it'sUUID
.The problem
The problem is that the drive fails during boot:
fsck.ext3: Unable to resolve 'UUID=36c78260-3c5d-4746-9759-682797e12609' fsck died with exit status 8
Surely there is something I have missed. Also it would be nice not being forced to set checking to 0.
Troubleshooting I have done so far
1) Trying to mount the drive from
fstab
manually:mount -a
Works fine without errors
2) Running
fsck
on the drive manually:root@overlord:/var/log/fsck# fsck -t ext3 /dev/sde1 fsck from util-linux-ng 2.17.2 e2fsck 1.41.12 (17-May-2010) /dev/sde1: clean, 195327/61054976 files, 240677045/244190000 blocks
Additional information
fstab
file:# <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 UUID=17239a5a-4dc4-459a-8cee-2a44c4070d0a / ext3 errors=remount-ro 0 1 UUID=07c02b0a-c98e-4858-8acb-bc7b9e8bfec7 /mnt/store ext3 defaults 0 2 UUID=36c78260-3c5d-4746-9759-682797e12609 /mnt/backup ext3 defaults 0 2
blkid
output:/dev/sda1: UUID="78dc058d-d6d9-ff3f-4ff1-526ea2d9ea75" LABEL="overlord:0" TYPE="linux_raid_member" /dev/sdb1: UUID="78dc058d-d6d9-ff3f-4ff1-526ea2d9ea75" LABEL="overlord:0" TYPE="linux_raid_member" /dev/sdc1: UUID="c17a04c7-79f9-b140-dcbc-2adbe4e2b483" LABEL="overlord:1" TYPE="linux_raid_member" /dev/sdd1: UUID="c17a04c7-79f9-b140-dcbc-2adbe4e2b483" LABEL="overlord:1" TYPE="linux_raid_member" /dev/md0: UUID="17239a5a-4dc4-459a-8cee-2a44c4070d0a" TYPE="ext3" /dev/md1: UUID="07c02b0a-c98e-4858-8acb-bc7b9e8bfec7" SEC_TYPE="ext2" TYPE="ext3" /dev/sde1: UUID="36c78260-3c5d-4746-9759-682797e12609" SEC_TYPE="ext2" TYPE="ext3"
by-uuid
output:root@overlord:/# ls -la /dev/disk/by-uuid/ total 0 drwxr-xr-x 2 root root 100 Jul 25 22:06 . drwxr-xr-x 5 root root 100 Jul 25 22:06 .. lrwxrwxrwx 1 root root 9 Jul 25 22:06 07c02b0a-c98e-4858-8acb-bc7b9e8bfec7 -> ../../md1 lrwxrwxrwx 1 root root 9 Jul 25 22:06 17239a5a-4dc4-459a-8cee-2a44c4070d0a -> ../../md0 lrwxrwxrwx 1 root root 10 Jul 25 22:06 36c78260-3c5d-4746-9759-682797e12609 -> ../../sde1
-
Admin almost 13 yearsCan you check to see if vol_id -u /dev/sde1 returns the same UUID as blkid does?
-
rzetterberg almost 13 yearsDebian doesn't seem to have the
vol_id
command. Never the less, the disk mounts fine when invoked manually. Shouldn't that mean we can rule out that it would be the wrong UUID? I have added the output of/dev/disk/by-uuid
in my question, though.