make dmraid play nice with udev

[Tormod Volden]

Binary package hint: dmraid

This is a wishlist bug: Make dmraid use the "new world-order" event-based detection, and assemble fakeraid arrays as soon as the corresponding block devices are detected. Similar work has already been done for lvm, mdadm, etc.

I should probably sketch up a "Blueprint" specification for this, but for the moment I'll attach files and patches here, which I have tested successfully on my system which has root on a mirror fakeraid (Intel).

[Tormod Volden (tormodvolden)]

Here is a udev rule that works. To improve this further, udev (vol_id) should be extended to detect fakeraid members, so that the rule could be written to only trigger when relevant block devices are discovered.

[Tormod Volden (tormodvolden)]

The initramfs hook has here been modified so that the initrd loads the dm-* kernel modules before udevd is started.

Additionally, the old initramfs script /usr/share/initramfs-tools/scripts/local-top/dmraid is not needed anymore and should be deleted.

The old /etc/init.d/dmraid can still be present, at least for stopping the fakeraid at shutdown.

[Richard Bailey (rmjb)]

If this will make upgrades to feisty possible for dmraid users, should it make it in before feisty is released?
Or should more testing and work go into this and it not be rushed?

[Tormod Volden (tormodvolden)]

I would not rush this. On the other hand, the udevsettle workaround should go into Feisty IMO.

[Richard Bailey (rmjb)]

You are referring to your first patch where your call dmraid -ay when a
block device is detected?

[Tormod Volden (tormodvolden)]

No, the two patches here (and the removal of /usr/share/initramfs-tools/scripts/local-top/dmraid) go together. This bug is Gutsy Gibbon meat.

To solve (upgrade) issues in Feisty (bug #93810), the udevsettle trick in that bug should be added to /usr/share/initramfs-tools/scripts/local-top/dmraid.

[Chad Bernier (berniercr)]

I'm not exactly sure what problem your patches are trying to fix. I applied them anyways. I was hoping it would get rid of this problem.

I keep getting a ton of messages that look like this.

attempt to access beyond end of device.

any idea on how to fix those?

[Phillip Susi (psusi)]

I know what causes it, but fixing it will take some convincing of higher powers. The kernel is trying to treat the partition table on the first disk as a correct partition table for just that disk, but it fact, that partition table applies to the raid set, not just the first disk. The partition table shows that the disk is larger than it actually is, so the kernel complains when it tries to access partitions that are beyond the end of the disk. There was a patch posted to lkml some time ago to get the kernel to notice that the partitions are beyond the end of the disk, and not bother trying to use them knowing it will fail, but it was never merged for some silly reason.

[Chad Bernier (berniercr)]

I hope they fix it this time. You can't see what else is going on because those messages flood the system.

[Tormod Volden (tormodvolden)]

A word of warning: These patches might expose some deficiencies in dmraid, due to race conditions in the device discovery. Do only test this on a test setup. I am not sure these patches were the reason, but I have experienced desyncing of mirrored disks, and the machine would boot up and show the contents of one disk one time and of the other another time.

[Chad Bernier (berniercr)]

I don't really need this patch right now, how do i remove it?

[Tormod Volden (tormodvolden)]

Chad, it should be enough to delete the /etc/udev/rules.d/S92-dmraid.rules and then reinstall the dmraid package so that
/usr/share/initramfs-tools/hooks/dmraid and /usr/share/initramfs-tools/scripts/local-top/dmraid are restored.

[Tormod Volden (tormodvolden)]

The work on this bug should probably be following https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain and pay attention to the issues discussed in https://www.redhat.com/archives/ataraid-list/2007-May/msg00007.html

[Peter L Jones (peter-drealm)]

Just to say that the udevsettle in scripts/local-top/dmraid doesn't solve the problem for me. I'll check further but I currently have
> /sbin/udevsettle --timeout=60
as the last line of scripts/init-premount/udev. I'm not sure if it's the timeout value or the placement of the call that makes a difference (I'll try with just the dmraid udevsettle with a timeout of 90 then 60).

[Phillip Susi (psusi)]

As far as I can see there was no reason to mark this bug as invalid since no description was provided for the change, and the spec has not been rejected, so I am changing it back.

[Tormod Volden (tormodvolden)]

Seems like udev and dmraid work well together in Ubuntu 9.10. (Except smaller issues like bug 362768.)

[Arie Skliarouk (skliarie)]

I had problem with similar symptoms and in my case the problem was that the disks already have foreign RAID signature that either dmraid on Intel driver took into account:
http://skliarie.blogspot.com/2010/12/buggy-intel-raid.html

May be it will help someone...