# Drive names change with kernel upgrade

## Carnildo

I've got a computer with a boot drive attached via PATA (Intel 945 chipset) and five SATA hard drives attached to a 3ware 9500 RAID controller in JBOD mode.  When booting a 2.6.38 kernel, the boot drive is /dev/sda and the RAID disks are /dev/sdb through /dev/sdf.  With a 3.5.7 kernel, the boot drive is /dev/sdf and the RAID disks are /dev/sda through /dev/sde.  How do I get the names back the way they were?

For bonus points, the kernel upgrade is preparation for adding another five disks attached to an Areca ARC-1120 RAID controller (probably in JBOD mode as well).  Is this going to scramble my drive names again, and if so, how do I prevent it?

----------

## VoidMage

Chances are adding the disks will scramble the order.

The general solution is not to rely on this order.

The exact solution varies on the exact problem.

----------

## Veldrin

I am not sure, where that behaviour comes from, but at least on my FreeBSD Server, the harddrive on a addin card are listed before the onboard ones. 

Assuming, that Linux behaves the same way, you drives will be moved around again. On the bright side, they will be in the same order, but the first drive might be off (e.g sda -> sdf or similar).

On way to avoid this problem is to access the drives via labels or uuid, though uuid might be the better solution in your case. 

uuid and label can be using in grub as well as in fstab.

I hope that helps in some way.

V.

----------

## Carnildo

 *VoidMage wrote:*   

> Chances are adding the disks will scramble the order.
> 
> The general solution is not to rely on this order.
> 
> The exact solution varies on the exact problem.

 

The exact problems are:

1) The kernel panics about not being able to find root on startup

2) If I bypass 1) by passing a "root=" parameter from the LILO prompt, my software RAID array fails to build

3) Because the order is different between 2.6.38 and 3.5.7, if I change config files to solve 1) and 2), I lose the ability to drop back to an older kernel if the 3.5.7 kernel has problems.

----------

## Carnildo

 *Veldrin wrote:*   

> On way to avoid this problem is to access the drives via labels or uuid, though uuid might be the better solution in your case. 
> 
> uuid and label can be using in grub as well as in fstab.

 

/dev/disk/by-path/ looks like the IDs will change if I move the RAID cards around, /dev/disk/by-uuid doesn't have entries for my RAID disks, and /dev/disk/by-id/ doesn't look entirely sane (for example, my boot disk has two entries, as "/dev/disk/by-id/ata-CF_CARD_4GB_0" and "/dev/disk/by-id/scsi-SATA_CF_CARD_4GB_0").

----------

## VoidMage

As for 1), booting by PARTUUID might be the solution, though that requires gpt-partitioned disk (though 3.8 will have a patch, that will enable something similar for MBR).

As for 3), Veldrin probably already covered it.

----------

## floppymaster

The most reliable method would be to mount your root file system using a UUID. This requires the use of an initramfs.

----------

## wcg

Userspace will work on 2.6.38 and 3.5.7 with the same

linux-headers version? I doubt it. (Some kernel datatypes

exported to userspace will be too different for kernels

that far apart. Some exported by one kernel may not

even exist in the other kernel.)

----------

