# Device naming assignments

## gr0x0rd

Hello all,

By editing udev rules, I've been able to shuffle devices around (such as renaming eth1 to eth0 after installing a new ethernet adapter). 

Currently, I have a system with 6 SATA hard disks and an eSATA port. Sata ports 1-2 contain SSD disks in a RAID1 configuration containing /boot, swap and /. Sata ports 3-6 contain 4x2TB HDD disks in a RAID5 configuration containing /home .

I noticed that despite this, the kernel has identified the HDD in port 3 as /dev/sdb . The first time I configured my grub.conf, I only had the SSD drives connected to the system, so the devices were logically /dev/sda and /dev/sdb. After connecting the initial drives, the drive in port 3 bumped the drive in port 2 to /dev/sdc. The system still booted, but I had to manually resynchronize the RAID1 for /: thankfully this didn't take long due to the speed of the SSDs. Thankfully, mdadm is smart enough to assemble arrays based on the superblock contents, so only what is defined in the grub.conf is susceptible to getting "bumped" when drives are present/not present.

Enter the eSATA port. I powered down my system, and without thinking of any consquence, connected an external backup drive. On boot, the kernel detected this drive as /dev/sda! Of course, because of the other ordering, there's no longer a /dev/sdb listed, so the "shuffling" results in a non-bootable system.

Have any others run into this? From the googling I've done, I've seen the only way to solidify the way devices are named is by doing some fairly significant kernel hacking. Is there another (graceful) way to reserve names for devices when detected at boot by the kernel?

Thanks for reading.

----------

## Mad Merlin

Where do you need literal device names like that? I have / and /boot on RAID, and do something like so for grub:

```

title Gentoo 3.4.3

root (hd0,0)

kernel /boot/kernel-3.4.3-gentoo root=/dev/md1

```

Now, admittedly, all of my drives have grub installed on them, so the drive order doesn't matter at all.

However, if you have no MBR on the unbootable drives, shouldn't the system continue on to the next (several) drive(s) to try and boot from (them)?

In a number of other systems I manage, the drives have been shuffled around numerous times and still booted fine (despite not all drives being bootable). I'm fairly sure at least once an unbootable drive ended up as /dev/sda with no issues.

----------

## VoidMage

It seems you're asking the wrong question.

You should probably look at selecting boot device by UUID or (if you're using GPT partitions) PARTUUID

----------

## BillWho

gr0x0rd.

I encountered a similar situation with a Dell workstation a couple of years ago. The BIOS SATA operation was set to RAID Autodetect / ATA - I switched it to RAID Autodetect / AHCI and that rectified the problem.

----------

