4

I run a small home server with one IDE drive (for the system) and a few SATA drives (for a software RAID).

The IDE drive used to be at /dev/hda and the SATA drives at /dev/sd*. After a power outage the IDE drive claims to be /dev/sde and wreaks havoc with my RAID.

How do I get my IDE drive to behave well again?

4
  • 3
    It's in general a bad idea to rely on the order of the drives. udev assigns them dynamically and the order might change. To address a file sytem use the label or the UUID.
    – Marco
    Commented Aug 2, 2012 at 13:16
  • 1
    +1 @Marco, there's some useful information on UUIDs here. (Still the issue itself is weird. Everything else, besides the name, is behaving fine? No errors in dmesg etc. The home server being a long-running machine that due to the outage was rebooted for the first time with an updated kernel would be an explanation, I suppose...)
    – sr_
    Commented Aug 2, 2012 at 13:18
  • 3
    I suspect the reason things have changed is a while back the ATA subsystem in the linux kernel was changed so that PATA and SATA drives were handled the same, so all ?ATA drives have the device nodes /dev/sd??. At some point I'm guessing a kernel update has been performed but has not taken effect until this power outage caused you to reboot the system.
    – JRT
    Commented Aug 2, 2012 at 13:42
  • @JRT I agree 100%, actually have had that happen. +1
    – Tim
    Commented Aug 2, 2012 at 14:04

2 Answers 2

4

It's in general a bad idea to rely on the order of the drives. udev assigns them dynamically and the order might change.

File systems are better addressed by label or UUID:

/dev/disk/by-label/
/dev/disk/by-uuid/

Use the command blkid to find out information about your file systems.

Disks are addresses by id

/dev/disk/by-id/

If the disk ids are too ugly to work with you can symlink them to e.g. /dev/mainhdd, /dev/backupdrive, etc. via udev rules. Manual symlinks would not be persistent, since /dev is a kind of ram disk.

0
2

You can add an udev rule to impose a particular device path for a particular device. For example:

KERNEL=="sd*", ATTRS{DRIVER}=="ide*", NAME="hda%n"

This line goes into a file called /etc/udev/rules.d/59-wukerplank-storage.rules. It takes effect when the device is added; you can tell udev to reapply rules but this is not a good idea if the device is in use.

Note that you should not rely on names like hda or sda, they are not expected to be constant. If you need a persistent name for a device, it is best to use udev to create an alias for it:

KERNEL=="sd*", ATTRS{model}=="ZXQ-500", ATTRS{serial}=="123456", SYMLINK+="disks/by-alias/zxq"

The command udevadm info -a -n sda shows what properties you can use to match /dev/sda.

RAID configurations normally use a unique identifier (UUID) to tell which disk is which. This is necessary, for example, if you plug the disks in a different machine or in a different order. So it is strange that your RAID would have trouble with device names. If you have custom scripts that depend on device names, make them call mdadm to query the components of the array instead.

1
  • 1
    Yes, but frankly, I'd rather strangle myself than getting convinced to work with UUIDs in /etc/fstab, to begin with. It just messes up the listing with its insanely long hex values (and my eyes, too). They're no less annoying to work with than Class IDs on Windoze. Commented Oct 20, 2013 at 22:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .