# udev ordering my disks badly, HELP!

## Moriah

I just upgraded the kernel on an old amd64 box with 4 IDE drives using the "Serial ATA (prod) and Parallel ATA (experimental) drivers" instead of the old way.  Yes, it works, but stupid udev is scrambling the ordering of my drives in a way I find highly annoying.  After it boots, my raid drives appear on sda, sdb, and sdc, while the boot drive appears as sdd.  This is just highly unnatural for me!    :Evil or Very Mad: 

How can I force the boot drive to be sda, and the raid drives to follow it?  Not having sda as the boot drive is sure to confuse me sometime in the future, as I have a bunch of systems running gentoo, and this is the olny on with the boot drive appearing other than the first drive alphabetically.  I looked in /etc/udev, but only found persistent rules for network adapters and CD drives.  I need a persistent hard drive file somewhere.

Can somebody please help me solve this?

Thanks!    :Very Happy: 

----------

## fangorn

You could make udev call a script that identifies the UUID or any other form of data and assigns names according to the results. 

I for my part went the easier way and use Filesystem labels to identify my partitions. Instead of mounting /dev/sda3 I mount /dev/disks/by-label/root-gentoo. So regardless if I have 5 or none optional drives installed at boottime, my system works.   :Wink: 

----------

## Rexilion

Don't know how to solve it. But there is a workaround called UUID. Will that help?

----------

## fangorn

UUID is the other option for identifying partitions when mounting. 

In fstab both work. For passing as kernel boot parameter root=UUID=<id> works in most modern distributions, root=LABEL=<label> did not always work. 

Labels of filesystems are easy to set. So if you change harddisk or partition scheme, serial number of the harddisk or UUID of the partition change, but the label can be easily made the same. If it works, I prefer the label solution.

----------

## pdr

Just add a udev rule that identifies the drive and symlink it to a nice name like"Boot" so you end up with /dev/Boot and use that in /etc/fstab. I do this with my backup external drive and with my thumb drives.

I've never found a way to "force" the /dev/sd* (they appear to always be labelled in discovery order) and frankly, unless you can compile it into the kernel or put it in an initrd then there will no way it CAN - can't be anything in / when the drives haven't been labelled yet (let alone mounted and accessed). The nice thing with udev symlinking is that you don't have to worry about it - just use the symlink instead. I have a Silverstone e/sata "docking station" where I can plug in my external drive and it runs full SATA speed; when I plug it in it is like a thumb drive - might get any /dev/sd* designator depending on what I already have plugged in. So I added the below to /etc/udev/rules.d/85_mine.rules:

```
ATTRS{model}=="WDC WD3200BEVT-1", NAME="%k", SYMLINK="Silverstone"
```

After I dock the drive I end up with /dev/Silverstone - and that is what I use in /etc/fstab.

(edit) I think the 'NAME="%k"' is redundant and discouraged in the newer udev - this is my headless server and haven't watched the boot messages in a while..

----------

## Cyker

Yeah, this is why I still use the older block driver for IDE stuff.

I've been trying to figure out a way of hacking up some udev rules to simulate assigning devices names by port, but it is very tricky; You can kludge it on a system-by-system basis if you know the PCI assignment of your disk controllers, but things are still not guaranteed when other devices are involved.

I don't know why it's possible with the blk_dev drivers but not with libata - With blk_dev, you plug it into the primary master, you get hda. Plug it in secondary slave, you get hdd.

With libata, plug it in port 8 and it'll be sda until you plug something into, say, port 2, then everything changes!

If you use libata, you HAVE to use /dev/disk/by-[label | uuid] to get consistent mounts; The /dev/sdx is mostly useless with libata unless the system drives are totally fixed and no SCSI, USB or (e)SATA devices are plugged in as they can totally change the order of the /dev/sdx assignments, and if you leave one plugged in during a reboot you could potentially cause the boot to fail.

The kernel dev disk assignments are just smegged at this point; They need to pass down more info to udev so we can give disk devices assigned traceable names, e.g. IDE disks hdx, scsi drives sdx, sata drives stx and usb devices udx, with the x being assigned per-port where possible (Nigh-impossible for SCSI and USB stuff since they are multi-device busses, but should be perfectly possible for IDE and SATA stuff!!)

----------

## fangorn

Yeah, that is an option as long as you have different drive models in the box. 

UDEV by default cannot distinguish between two drives of the same model AFAIK. In that case you would have to use external tools that check the drive serial number or UUID or other properties and tell UDEV "this is drive a" or "this is drive b". And that is a little bit too hackish for my taste. 

I use approx. 12 WD 1TB EADS drives, some fix, some in hotplug drive bays. UDEV itself cannot tell which is which. 

I use UUID in grub for the bootup process mostly, but in fstab I use filesystem labels. Much easier than to remember in which order you plugged them in to know which one to unmount.

@Cyker

I consider it a plus not to have to think that the DVD is plugged in with PATA, the Harddisk is SATA and if I connect an external harddisk via USB or eSATA. All get handled through the same system. 

And if you have just fixed disks in the machine, the device numbering does (usually) not get scrambled, even if you plug in a USB device at boot (if it does, buy other mainboard manufacturer next time  :Wink:  ). 

Problem starts when adding another drive or - like my workstation - have multiple hotplug drive bays, that do or do not contain a harddisk at boot time. The problem does not get easier by the fact that most boards use multiple controllers to power all the SATA ports. So depending on which driver gets loaded first, the one or the other port may get preferred.

----------

## Moriah

Once the system is booted up and running, I use /dev/disk/by-path/* to see where everything is located:

```

baruch ~ # ls -l /dev/disk/by-path/

total 0

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda

lrwxrwxrwx 1 root root 10 Mar 21 05:07 pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Mar 21 05:07 pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sda2

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sdb

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-2:0:0:0 -> ../../sdc

lrwxrwxrwx 1 root root 10 Mar 21 05:07 pci-0000:00:1f.2-scsi-2:0:0:0-part1 -> ../../sdc1

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-3:0:0:0 -> ../../sdd

lrwxrwxrwx 1 root root 10 Mar 21 05:07 pci-0000:00:1f.2-scsi-3:0:0:0-part1 -> ../../sdd1

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-4:0:0:0 -> ../../sde

lrwxrwxrwx 1 root root 10 Mar 21 05:07 pci-0000:00:1f.2-scsi-4:0:0:0-part1 -> ../../sde1

lrwxrwxrwx 1 root root  9 Mar 21 05:07 pci-0000:00:1f.2-scsi-5:0:0:0 -> ../../sr0

baruch ~ # 

```

In the part "scsi-X:0;0;0", the "X" is the number of the controller port, which in my case corresponds to which slot in the hot-swap sata backplane the drive is plugged into.

----------

## Cyker

Be careful about relying on that; I don't know on yours, but on mine the by-path assignments are also not fixed and change if the disk connections are changed.  :Sad: 

----------

## Moriah

As long as you do not add or remove a controller, the by-path connections should always identify a unique controller.  I find them to be quite stable for my sata backplanes on several systems, both intel and amd.  I use them to know what sda, sdb, etc. is in what backplane slot for my hot-swap drives, including usb drives.

----------

