dmraid not starting on system boot

[TimBlundell]

Binary package hint: dmraid

On Feisty i386, dmraid service not starting when booting.
Have tried reinstalling the latest package dmraid-1.0.0.rc13-2ubuntu but still must invoke dmray -ay -v manually to configure drives on /dev/mapper and then can finally mount the partitions on raid drive.

[Tormod Volden (tormodvolden)]

Does "sudo /etc/init.d/dmraid start" work?

[alteeno (alteeno-sina)]

I have the same problem, and ZZZZ"sudo /etc/init.d/dmraid start" doesn't work.
When I chroot to /target, run "dpkg-reconfigure --all", it report "acpid: can't open /proc/acpi/event: Device or resource busy"
"invoke-rc.d: initscript acpid, action 'start' failed".

[Tormod Volden (tormodvolden)]

Alteeno, so you are saying "sudo /etc/init.d/dmraid start" does not work, and "dmraid -ay" works? Then run "sudo sh -x /etc/init.d/dmraid start 2>output.txt" and attach output.txt, please.

That the reconfiguration of acpid fails is not related to dmraid AFAICS.

[alteeno (alteeno-sina)]

"sudo /etc/init.d/dmraid start" doesn's work.
I guess that the dmraid doesn't work when system booting. Because when I add "break=mount" to the kernel option in the /boot/grub/menu.lst, and run "dmraid -ay" at the shell then exit when the system booting break, the dmraid works fine. But without "break=mount", the system says "no block device found" and run into the initramfs shell.
The acpid error isn't the reason, but when I upgrade from edgy to feisy, it always shows the same error, when I install feisty to the clean partition, it will works fine.

[Tormod Volden (tormodvolden)]

Alteeno, what do you mean by "doesn't work"? Can you please attach that output.txt?

Can you also try this: boot with "break=mount" and run "scripts/local-top/udev" and then exit the initramfs shell (without running dmraid). I have a suspicion that dmraid is run too early, before udev has found the raw disks.

[alteeno (alteeno-sina)]

"scripts/local-top/udev" not found. There are only "mdrun" and "dmraid" in the path "scripts/local-top/".
Here is the output.txt you wanted.

[Tormod Volden (tormodvolden)]

Ok, I think I have figured out why it doesn't find the raid when booting. First init-premount/udev is run, and starts to find devices. However, local-top/dmraid is run straight after, before the raw disks have been detected, so the dmraid does not set up any raid. Then the raw disks come rolling in, and the mountroot function loops waiting for the root disk to appear. But dmraid is not run again to find the raid and make the root disk available.

The right solution would probably be to make a udev rule that reruns dmraid each time a raw disk device is detected. A workaround would be to not run dmraid before all devices has been detected.

Alteeno, can you confirm that it is enough to boot with break=bottom, then wait ten seconds before you leave the initramfs shell (and without running any command)?

If this works, a quick workaround for you would be to add "sleep 10" to /usr/share/initramfs-tools/scripts/local-top/dmraid, on a line just before the /sbin/dmraid command, and run: update-initramfs -u

[Felipe Lerena (lipe)]

I had the exact same problem, and it can be solved as Tormod Volden said in the last post

[alteeno (alteeno-sina)]

what you means is change the menu.lst uses "kernel /vmlinuz break=bottom root=/...." to replace "kernel /vmlinuz break=mount root=/...."?
I do so, and wait about 3 minutes to entering the initramfs shell.Then I wait about 20 Sec, nothing happened.

So I use " "kernel /vmlinuz break=bottom break=mount root=/...." to replace "kernel /vmlinuz break=mount root=/....", It really WORKS.

[Richard Bailey (rmjb)]

I do not have access to a feisty installation at hand but can someone check what order dmraid is run relative to udev? You can check this is /etc/rcS. dmraid should be initialised *after* udev for this same reason. There was a bug about this in debian that was fixed, I opened a bug here but that was dismissed since this issue was no longer occurring at that time. If it has re-emerged a simple fix would be to move dmraid to initialize after udev in rcS.

[Tormod Volden (tormodvolden)]

Sorry, I meant "break=mount" and not "break=bottom" !

[Tormod Volden (tormodvolden)]

Maybe adding "udevplug -W" before the /sbin/dmraid line in the local-top/dmraid script would do the job. Or, inspired by https://wiki.ubuntu.com/UdevLvm, adding a udev rule like:
SUBSYSTEM=="block", RUN+="watershed /sbin/dmraid -ay -i"

There are similar issues for software raids, see bug #75681.

[Richard Bailey (rmjb)]

I just checked and yes, dmraid is initializing before udev in rcS.d. What this means is that dmraid sets up the devices in /dev/mapper, then udev is run and it completely rebuilds /dev, throwing out what dmraid did. Currently udev is initialized at S10 and dmraid at S04, it should be changed to S11.

[Richard Bailey (rmjb)]

Can someone who is currently experiencing this error test with this new deb? It's the same upstream version, the only difference is that dmraid is initialised at S11 instead of S04, i.e. after udev.
I appended my username to the end of the file in case others want to try to build a deb and attached it to this bug we wont get confused.

[Tormod Volden (tormodvolden)]

I can confirm this bug on upgrading from Edgy to Feisty. I solved it by inserting a "udevsettle --timeout=30" line before the modprobe lines in /usr/share/initramfs/scripts/local-top/dmraid and building a new initramfs with "update-initramfs -u -k all".

If you upgrade, do this _before_ you reboot to avoid a lot of hassle, especially if you have root on dmraid like me...

[Tormod Volden (tormodvolden)]

For those interested and courageous enough, I have implemented the above mentioned udev rule solution in bug #106177.

[Tormod Volden (tormodvolden)]

Here is a patch for calling udevsettle before calling dmraid, like I did in comment 17.

[Richard Bailey (rmjb)]

Ready for upload, would like this to get in before feisty since it breaks upgrades from edgy for those that have / on FakeRAID.

[Lukas Fittl (lfittl)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 13 Apr 2007 16:02:00 -0400
Source: dmraid
Binary: dmraid-udeb dmraid
Architecture: source
Version: 1.0.0.rc13-2ubuntu3
Distribution: feisty
Urgency: high
Maintainer: Ubuntu MOTU Developers <email address hidden>
Changed-By: Richard Bailey (3-Oct-2006) <email address hidden>
Description:
 dmraid - Device-Mapper Software RAID support tool
 dmraid-udeb - Device-Mapper Software RAID support tool
Launchpad-Bugs-Fixed: 93810
Changes:
 dmraid (1.0.0.rc13-2ubuntu3) feisty; urgency=high
 .
   * Call udevsettle during initrd before continuing. Patch submitted by Tormod Volden. (LP: #93810)
Files:
 a9a0f70ff99da6a88e7f2ed7b2679fa7 990 admin optional dmraid_1.0.0.rc13-2ubuntu3.dsc
 4ba3149c77ed69f92b02e4cfa122f862 5132 admin optional dmraid_1.0.0.rc13-2ubuntu3.diff.gz
Original-Maintainer: Utnubu Team <email address hidden>
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQCVAwUBRh/meg4fNBjHo0sKAQIQVAQAoiwWpzFI3pD7YJJSmUkqnnShH3hLZjWo
AC4/n1K84RKsc4AW4oCitG4QjYRnqwFtznoSOOp42ZXN/fJg1xDtNf94EkLnCFVs
GrrjsVlTg2CPhuvgd4HyWsbm39KdKuQq4zA7USfBC0D8mhfwyKc8I6h2VL3GDHdq
qka3cPw7WNg=
=NniS
-----END PGP SIGNATURE-----

[René (pirateking)]

Today I upgraded to the new version of dmraid and it works. Finally I can omit break=mount - Thank you very much!

[Ciarán Coffey (mail-ccoffey-com)]

I have the same issues as described above. Running a clean install of 7.04 x86_64. Fakeraid 0 on an intel ICH7R controller.
When booting my / is not found, and after some time i get dumped to the initfsram prompt. "ls /dev/mapper/" does not list my raid, and only "control". Running "dmraid -ay" restores the array, so I can ctrl -d, and then the system resumes as normal. This seems to be the issue as what was above, but I seem to have all the fixes as above.
dmraid: Version: 1.0.0.rc13-2ubuntu3,
udev: Version: 108-0ubuntu4,
/usr/share/initramfs-tools/scripts/local-top/dmraid does contain "udevsettle --timeout=30", and i added a sleep statement "sleep 5" before "[ -x /sbin/dmraid ] && /sbin/dmraid -ay" to no avail.
"update-initramfs -u -k all" has been run also.
I apologize if this is the wrong place for this, but to me it feels like it's the same issue.