# udev 151 hates old IDE devices

## actionunits

udev-151 no longer likes any IDE drivers located under the deprecated "ATA/ATAPI/MFM/RLL support" of the kernel config. I have a production system (a firewall) that requires the via82cxxx driver. Has anyone had success substituting a driver under the "Serial ATA and Parallel ATA drivers" category?

Unfortunately the machine is located remotely, and it's in production use. I cannot experiment on it ad hoc. And since it's a hardware driver issue, I cannot test in a VM.

Does anyone else think it's a load of crap that udev is dropping support for all these old IDE devices without having any clear upgrade path? I bought this computer 2 years ago; it's not ancient.

----------

## Veldrin

get an lspci -n from the system an post it here. Don't worry, that is says debian - pappy uses that very same page to create his seeds.

you should get an overview of what drivers should be used - including a kernel version, since when they are supported.

cheers

V.

----------

## dmpogo

 *actionunits wrote:*   

> udev-151 no longer likes any IDE drivers located under the deprecated "ATA/ATAPI/MFM/RLL support" of the kernel config. I have a production system (a firewall) that requires the via82cxxx driver. Has anyone had success substituting a driver under the "Serial ATA and Parallel ATA drivers" category?
> 
> Unfortunately the machine is located remotely, and it's in production use. I cannot experiment on it ad hoc. And since it's a hardware driver issue, I cannot test in a VM.
> 
> Does anyone else think it's a load of crap that udev is dropping support for all these old IDE devices without having any clear upgrade path? I bought this computer 2 years ago; it's not ancient.

 

Wouldn't it be reasonable to a production machine with no remote access (or is there for somebody ?) to switch to a fixed /dev/ directory ? Or one has to have /dev/dynamic nowadays ?

----------

## actionunits

You'd think that would work. But I worry about future compatibility. That's why I don't just mask udev and forget the whole business. It is likely that the same people who made this change to udev are also going to change the kernel itself.

----------

## Cyker

Is the devfs-compat USEflag any use there?

I'm on udev-149 which is still functional. If you want, I could copy my /lib/udev/rules.d here so you can see what's been removed?

It is possible to go libata only, but it requires a lot of testing to make sure you don't inadvertently break something because all drive assignments will be altered in a mostly non-predictable way. This will be a problem for you  :Sad: 

The easiest thing is probably just to go back to udev-149 tbh; It's not like udev is a critical system component anyway; The interfaces that udev uses to create its nodes are fairly stable AFAIK. I bet it's going to be obsoleted and swapped for something else in the not too distant future anyway when someone comes up with a new idea...Last edited by Cyker on Sat Oct 16, 2010 7:14 pm; edited 1 time in total

----------

## actionunits

udev-149 is the last version that supports the old IDE library. That's where I am masked at present.

More details on the libata migration please? What should I turn on in menuconfig? Or what are the symbol names in .config? What will the new driver be called?

----------

## Cyker

 *actionunits wrote:*   

> udev-149 is the last version that supports the old IDE library. That's where I am masked at present.
> 
> More details on the libata migration please? What should I turn on in menuconfig? Or what are the symbol names in .config? What will the new driver be called?

 

Ahh. I'd stay there if I were you!

As for the migration, basically you disable all BLK_DEV drivers and then enable the equivalent libata drivers.

On reboot, libata will be handling the drives now, but don't do it yet as you have a bigger problem:

The reason I HATE libata is that it assigns EVERYTHING a /dev/sdx assignment; In your case this is dangerous because there is no way of knowing in advance what all the drives will end up on.

You'll need to modify at least fstab, but any other files that reference any /dev/hdx or /dev/sdx will probably need to be altered too, including your bootloader...

----------

## actionunits

Luckily I have an AMI out-of-band management card installed, so I have the ability to fix such bootup issues. But it is a PITA to boot a machine from a remote CD image. I never tried it, but I'm curious what would happen if I put several lines in fstab for the same mount point? If only one device node existed, would it "win"? Of course grub is a problem.

----------

## jburns

You could reference the drives by UUID or label in the fstab.

----------

## Hu

Grub does not use your kernel driver, so changing the used driver will have no effect on the grub naming of the drives.

Specifying multiple mounts in fstab is not likely to produce good results.  Even if it did, it does not address the fundamental issue that the rootfs must be mounted without using fstab, so the root= line passed to the kernel must be correct.  If you cannot predict the name your hard drive will get under libata, getting the root= line correct on the first try will be tricky.

As for dropping support for old IDE devices, the kernel has been on a clear path to deprecate the IDE drivers for quite a while now.  I am surprised that udev continued to name those drivers for as long as it did.

----------

## Jaglover

I have VIA chipset in one of my boxes, lspci -knn

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

        Subsystem: Micro-Star International Co., Ltd. Device [1462:7199]

        Kernel driver in use: sata_via

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

        Subsystem: Micro-Star International Co., Ltd. Device [1462:7199]

        Kernel driver in use: pata_via

        Kernel modules: pata_via
```

----------

## dmpogo

 *Hu wrote:*   

> Grub does not use your kernel driver, so changing the used driver will have no effect on the grub naming of the drives.
> 
> Specifying multiple mounts in fstab is not likely to produce good results.  Even if it did, it does not address the fundamental issue that the rootfs must be mounted without using fstab, so the root= line passed to the kernel must be correct.  If you cannot predict the name your hard drive will get under libata, getting the root= line correct on the first try will be tricky.
> 
> As for dropping support for old IDE devices, the kernel has been on a clear path to deprecate the IDE drivers for quite a while now.  I am surprised that udev continued to name those drivers for as long as it did.

 

That can be doable, if you configure several choices for root (i.e completely different entries, each with its own guess for root) and use grub 'fallback' mechanism

----------

## coolsnowmen

After disabling the ( ATA/ATAPI... suppoer (DEPRECATED), I have my hard drives in /dev/sd*, but I don't have my cdrom/dvd reader/writer.  What am I missing?

Edit 1: hmm, http://kmuto.jp/debian/hcl/index.rhtmlx may have found my answer.

----------

## NeddySeagoon

coolsnowmen,

SCSI CDROM support or the PATA driver under SATA for the chip set that the CDROM is connected to. See this Rough Guide

----------

## coolsnowmen

Thanks!

 *NeddySeagoon wrote:*   

> 
> 
> SCSI CDROM support or the PATA driver under SATA for the chip set that the CDROM is connected to. See this Rough Guide

 

So the scsi cdrom support is (and related checks) what added /dev/sr0.

Any idea how to get the /dev/dvd links automatically created? Or should I do it myself?

----------

## NeddySeagoon

coolsnowmen,

Udev should do that.  /etc/udev/rules.d/70-persistent-cd.rules controls it.

Delete that file - it will be recreated when you reboot and you should have your links.

----------

