Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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'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
share|improve this question
    
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
add comment

1 Answer

up vote 1 down vote accepted

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

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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