[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: External USB HD showing up late in /dev



Davide Mancusi wrote:
Hi .*,

	I have an external USB hard disk that I use for automated
backups. I have written the following udev rules:
  SUBSYSTEMS=="usb", ATTRS{serial}=="574341535530323537353839", KERNEL=="sd?", SYMLINK+="exthd", GROUP="plugdev"
  SUBSYSTEMS=="usb", ATTRS{serial}=="574341535530323537353839", KERNEL=="sd?1", SYMLINK+="exthd1", GROUP="plugdev"
to create symlinks to the right device and partition, and I have a
fstab entry:
  /dev/exthd1    /mnt/exthd    ext3    user,auto,errors=remount-ro   0   2
to mount the backup partition automatically at boot time.

	The problem is that sometimes, when init calls
fsck, /dev/exthd1 has not appeared yet, fsck bombs and init drops me to
an emergency shell. This happens about 50% of the times. Then I use the
emergency prompt to check if /dev/exthd1 actually exists, and, again,
50% of the times it doesn't; the /dev/sd?1 file is always there,
though. When /dev/exthd1 doesn't exist, a "udevadm trigger" will bring
it up.

	This looks like some kind of race condition between kernel and
udev, but I don't really understand why udev doesn't pick on the new
devices automatically, as soon as the kernel creates them. I have tried
to add WAIT_FOR="/dev/exthd1" to my udev rule, but it didn't help.

	Any help would be appreciated.

Davide

I'd mentioned using 'rootdelay' when I had this problem a long time ago. Today, while fooling around with booting I encountered it again with an external USB HD that was mounted in /etc/fstab and had previously been working without any delay parameters of any kind.

I'd switched the boot image from Debian's standard "every module under the sun" approach to just the modules needed for this particular machine and suddenly the drive was no longer spun up and ready by the time udev tried to pick up on it, despite the kernel seeing it as /dev/sdc. I'm guessing that the asynchronous way that kernel modules are loaded at boot means that with a trimmed-down module selection, whatever module is responsible is now being loaded much earlier in the boot process than before.

I switched back to the standard set of Debian modules for the time being, as I don't have the time or experience (yet!) to resolve the issue but I did find this rather long discussion (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401916) indicating that it's been an ongoing concern for quite a while. Maybe you can dig around in there and find something useful.

--
Mark.


Reply to: