# [SOLVED] Switching to libata PATA drivers, need some advice

## Sadako

I want to try out the libata PATA driver, but I have a couple of questions/problems that I need help with before doing so.

That most obvious one is how will my ide devices be named?

I have two SATA disks, one IDE disk and an IDE DVD drive, this is on a VIA K8T800Pro based chipset, with (according to lspci);

```
00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)

00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
```

From what I've read, with the PATA drivers the IDE device nodes seem to be created as /dev/sd* after the SATA device nodes are created, i.e. in my case hda would show up as /dev/sdc.

Can I really rely upon this, or could the ide disk show up as /dev/sda, changing the devices names for the SATA drives too?

Or is there any definitive statement I've missed somewhere that states the devices are created in a particular order (such as SCSI, SATA, PATA, USB)?

If someone actually has experience with this and the specific chipset I'm using, that would be great.

Second problem: Encrypted swap.

I'm using hda2 as a swap partitiion, encrypted through dmcrypt with the following in /etc/conf.d/cryptfs and fstab;

```
swap=swap

source='/dev/hda2'
```

```
/dev/mapper/swap        none                    swap            sw                      0 0
```

The problem with this is it indiscriminately runs mkswap on /dev/hda2 upon every boot.

I've only ever had the one IDE disk, so I've never worried about it before, but I'm not willing to risk it with the new naming scheme, so can anyone suggest a way around this?

I was thinking about having udev create a /dev/hdx symlink to the IDE drive based on the drive's serial number, but I don't know how to do this (yet), and I'm not sure if it would be created early enough.

I don't think it would be the best way to do it anyway, so I'm looking for other suggestions.

Thanks for any advice you can give.

----------

## desultory

Try using the device links in /dev/disk/by-uuid/, or /dev/disk/by-label.

----------

## Sadako

 *desultory wrote:*   

> Try using the device links in /dev/disk/by-uuid/, or /dev/disk/by-label.

 Thanks for the reply, and this might help safely setting it up so I can boot using PATA without worrying, 

but I'd still need to know how the devices would be named if those udev rules were removed, would I be able to discern that somehow when it's up and running?

Also, I don't think this will work for the encrypted swap, as from what I can gather both the uuid and labels are actually part of the filesystems on the partitions, 

but upon boot the swap partition doesn't have a filesystem, it's essentially just random data at this stage.

mkswap will give it a uuid, but a little late for my needs.

Anyway, I'm looking into creating the devices by uuid now, it should allow me to at least boot safely, so thanks again.

Any other ideas?

----------

## Sadako

One more question, how will this affect grub (or any other boot loader)?

I know the "root (hd0,0)" part won't change, as this is how grub sees things before the kernel loads, 

but I doubt I can use the uuid for the "root=" part of the kernel parameters.

I'm booting to /dev/md_d1p1, a partitioned raid mirror across the two SATA disks, 

which I think might complicate things further and I should have asked about earlier.

----------

## desultory

If you use an initrd, you could try deliberately letting the mounting of the actual system root partition fail and try to use the initrd environment to determine where the drives and partitions are after the changes have taken effect.

 *Hopeless wrote:*   

> I'm booting to /dev/md_d1p1, a partitioned raid mirror across the two SATA disks, 
> 
> which I think might complicate things further and I should have asked about earlier.

 Which, I think, could complicate matters significantly. For the purpose of determining where the drives are now presented could you use a disk which is not mirrored?

----------

## Sadako

I finally got around to doing this.

I tested with a live cd using a 2.6.22 kernel and libata for pata (an Arch Linux live cd), which presented the ide drive as sda, and moved the sata drives to sdb and sdc.

Fine, I fix up fstab, reboot with my brand spanking new 2.6.22 kernel, and oh noes, no /var!

/dev/sda5 can't be found!

:Sigh:

The ide drive was created as sdc.

This doesn't exactly inspire confidence in the device naming scheme (or apparent lack thereof)...

 *desultory wrote:*   

>  *Hopeless wrote:*   I'm booting to /dev/md_d1p1, a partitioned raid mirror across the two SATA disks, 
> 
> which I think might complicate things further and I should have asked about earlier. Which, I think, could complicate matters significantly.

 Actually, this was kind of what saved me in the end.

I have / and /usr on a partitioned raid mirror, so they were still /dev/md_d1p1 & /dev/md_d1p2, and as I had the kernel automatically assemble the array at boot, the device names of the underlying disks/partitions was completely irrelevant.

I love the kernel's soft raid, now more so than ever.

Anyway, I'm now using the libata drivers, and I'm working on idea wrt the encrypted swap issue (here), so finally marking this as [SOLVED].

Although I'd still like to know the logic (if any) behind the naming of the devices, or in what order they are created.

desultory, thanks for your replies.

----------

## gazj

I know, i'm picking this thread back up quite late, what kernel options did you use for the via ide chipset??  I'm really stuck on this??

Thanks in advance  :Smile: 

----------

## Cyker

Gak... after reading that, I hope they never remove the hdx drivers!  :Shocked: 

----------

## gazj

It's ok, I worked it out.

The only reason I wanted the /dev/sdx way is because i have came from Arch Linux and am quite attached to this way of working now and found it hard going back to the /dec/hdx way of life, I cannot be doing with dma settings etc

Trust me the new way has some huge advantages once you get past the initial setup barrier.  :Smile: 

Thank guys

----------

