Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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 Aug 2 '12 at 13:16
+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_ Aug 2 '12 at 13:18
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 Aug 2 '12 at 13:42
@JRT I agree 100%, actually have had that happen. +1 – Tim Aug 2 '12 at 14:04
OK, thanks guys! I'll switch to UUIDs. – Wukerplank Aug 2 '12 at 14:07
up vote 4 down vote accepted

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:


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

Disks are addresses 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.

share|improve this answer

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.

share|improve this answer
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. – syntaxerror Oct 20 '13 at 22:15

Your Answer


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.