# PATA read as SDA

## Bigun

This wasn't a big issue until I installed some SATA data drives and they took the SDA, SDB, and SDC slots, and now my boot drive is SDD.  I would like it to be HDA so that I won't have to worry about anything pushing it out of the way.

Is there a kernel option that does this?

*edit*

changed topic to make more sense

----------

## eccerr0r

What happened: you finally removed legacy IDE support from your kernel.

"correct" way to fix this: initrd and boot by uuid or label

Alternate options: put legacy IDE support back.

----------

## VoidMage

I don't see how the 'alternate option' could be seen as fixing things.

You could always look at fixed cdrom rules and basing on them add a symlink

to the chosen disk, then use that symlink for fstab.

Obviously, that won't work for bootloaders.

----------

## Bigun

 *eccerr0r wrote:*   

> What happened: you finally removed legacy IDE support from your kernel.
> 
> "correct" way to fix this: initrd and boot by uuid or label
> 
> Alternate options: put legacy IDE support back.

 

After a bit of googling I can definitely see the benefits of booting to UUID instead of block devices..... so..... I don't mean to be a smart-ass but, why isn't this in the Gentoo installation handbook?

----------

## Bigun

 *VoidMage wrote:*   

> I don't see how the 'alternate option' could be seen as fixing things.
> 
> You could always look at fixed cdrom rules and basing on them add a symlink
> 
> to the chosen disk, then use that symlink for fstab.
> ...

 

Anyway to use UUID's in grub?

----------

## cyrillic

 *eccerr0r wrote:*   

> "correct" way to fix this: initrd and boot by uuid or label
> 
> Alternate options: put legacy IDE support back.

 

Another alternate:  compile your PATA controller driver into the kernel, and compile your SATA controller driver as a module.

This will change the order in which the drives are enumerated (in a way that you will probably like).

----------

## Simba7

Wow.. I haven't heard of using /dev/hd* in a LONG time. What was the last version of your kernel?

----------

## Cyker

This is one of the big shortcomings of everything being given /dev/sdx assignments - The /dev/sdx assignments are slightly dangerous to use because they are not assigned in a predictable way like /dev/hdx is and any changes to the disk layout can mess up the /dev/sdx assignments enough to make the system stop booting  :Sad: 

This is why I'm still using the BLK_DEV drivers; They are much more predictable and I can't break the boot by leaving an eSATA drive plugged in  :Wink: 

I was trying to hack udev to assign hdx's to IDE devices in a similar way to how the BLK-DEV does it, but I can't find a nice portable way of doing it  :Sad: 

If you figure out the PCI path of all the controllers you can do it on a per-system basis tho'.

If you aren't having issues with the size of your kernel, the easiest thing to get a stable boot assignment for the IDE drive is to remove the libata IDE drivers and compile in the BLK_DEV IDE drivers - All IDE devices will be /dev/hdx and the /dev/sdx's will reshuffle themselves.

(Obviously, leave libata for SATA stuff; the BLK_DEV drivers for SATA suck  :Smile: )

----------

## ccp

 *Bigun wrote:*   

>  *VoidMage wrote:*   I don't see how the 'alternate option' could be seen as fixing things.
> 
> You could always look at fixed cdrom rules and basing on them add a symlink
> 
> to the chosen disk, then use that symlink for fstab.
> ...

 

May not consider directly to answer your question, but with initrd/initramfs you can use root=UUID=... or root=LABEL=... at kernel command line options.

The initrd/initramfs can be easily build with "blkid" included to locate your root disk.

----------

## Hu

 *Simba7 wrote:*   

> Wow.. I haven't heard of using /dev/hd* in a LONG time. What was the last version of your kernel?

 Kernels built with the lower performance legacy IDE drivers still name devices as hdX.  Using them is not a good idea, but it can be done even with modern kernels.  I did it by accident once on a new install and performance was terrible until I realized what I had done and switched to a proper SATA driver.

----------

## Cyker

Yeah, the older drivers are not very good for SATA as development never really got off the ground, but for IDE they're just as fast as libata and the default dev assignments are much more stable.

As long as you keep libata SATA-only and the BLK_DEV drivers IDE-only, it's perfectly possible to use both.

Since the OP is talking about an IDE drive, this is an easy solution.

----------

