Udev rule for ATA raid Controller

nogetfx · 07-05-2007, 04:38 PM

Hi

I'm having trouble with Debian Etch amd64 and a pci ata raid controller. I've seen before that when adding a pci controller the hd device location can shift. The raid controller get hda to hdd and that also happen with this installation (kernel 2.6.18-4-amd64), no problem there...
But then I installed the 2.6.18-4-xen-vserver-amd64 kernel and it only shift location every 2nd or 3th time, so it makes it impossible to mount via fstab and etc. Plus the boot process is stopped to check corrupted filesystems, that of course doesn't exist.
So isn't possible to define a fixed location for the controller via udev? The guides I could found, was most on usb-devises,HD and etc, so I'm still lost...

I can only get info from the device attaches to the controller and not from the controller itself. This is from a correct boot!

Code:

# udevinfo -q all -n hde
P: /block/hde
N: hde
S: disk/by-id/ata-Maxtor_6Y120P0_Y34LWWXE
S: disk/by-path/pci-0000:04:08.0-ide-0:0
E: ID_TYPE=disk
E: ID_MODEL=Maxtor_6Y120P0
E: ID_SERIAL=Y34LWWXE
E: ID_REVISION=YAR41BW0
E: ID_BUS=ata
E: ID_PATH=pci-0000:04:08.0-ide-0:0

# lspci
04:08.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)

Quakeboy02 · 07-05-2007, 04:43 PM

Sounds more like a BIOS issue than a udev issue. What type of array do you have on it? Did you configure an array with the BIOS settings or with mdadm? I'm assuming this is a FakeRaid device.

nogetfx · 07-05-2007, 07:43 PM

The controller just function as extra ata devices, no raid setup. Sorry for not providing a prober description. The system HD is split into /boot and lvm partitions for the system and xen domu.

Code:

# fdisk -l /dev/hda
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          12       96358+  83  Linux
/dev/hda2              13        1459    11623027+  8e  Linux LVM
/dev/hda3            1460       19457   144568935   8e  Linux LVM

I booted again on the "2.6.18-4" kernel, 5 times, and every time the HD order/location was the same. Then I booted on the xen kernel and it was difference the two first time and then it changes back the third. Where the problem lies exactly I don't know, the best solution I can come up with is static rules.

Quakeboy02 · 07-05-2007, 07:52 PM

I don't know what to suggest. Any drives on this controller should be /dev/sd*, and not /dev/hd*. Perhaps it's related to your 64 bit system. I dunno. I just use a 32 bit system.

nogetfx · 07-08-2007, 11:16 AM

Quote:

Originally Posted by Quakeboy02

I don't know what to suggest. Any drives on this controller should be /dev/sd*, and not /dev/hd*. Perhaps it's related to your 64 bit system. I dunno. I just use a 32 bit system.

OK, thank you for your input anyway. I did learn term FakeRAID. ;-)

I talked to another guy and he suggested to mount via partitionlabels (/dev/disk/by-label/*) and work around the problem that way. FX LABEL=boot, it works great.
If other should have similar problem, they can read about it at debian-administration.org/articles/522.
The article only mention ext3. So if you're using reiserfs on your partitions, you should use " reiserfstune -l boot /dev/hda1" to set the labels.

djcs · 07-09-2007, 02:23 AM

I have similar problems with my system, albeit the ata raid card is built into the motherboard.

So far, the problem i have found appears to be related to grub and maybe even the device.map file.

The last kernel upgrade i did completely balked when i tried to reboot.

Grub said that the drive was meant to be hd1,0.
When i changed it to hd0,0 it worked everytime.

I also had to remove the comment for the groot line in menu.lst

I dont know what exactly fixed it, but it seems that my machine is running ok now (touchwood).

It has booted for me fine the last 1/2 dozen times.

DJ

I hope this helps.

nogetfx · 07-12-2007, 04:05 PM

I looked at groot and for me with a separate /boot partition it makes sense to uncomment it. Unfortunately it doesn't change the problem and the labels still the only thing that can cope with the dynamic device order.
As for the device.map. Mine doesn't mention partitions, only device.

Code:

(hd0)   /dev/hda