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's UUID.

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
  • Can you check to see if vol_id -u /dev/sde1 returns the same UUID as blkid does? – user88808 Jul 25 '11 at 11:12
  • Debian 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. – rzetterberg Jul 26 '11 at 9:23

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

  • Thank you for the link. And your theory about usb not going loaded before fstab sounds really reasonable! I tried adding the udev rule but it never executes the command. So for now I have just put the mount command in the /etc/rc.local. Which works, but it feels like a nasty hack. – rzetterberg Jul 26 '11 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.