FS#29344 - Raid5 and Raid6 system is not able to boot after mkinitcpio, udev and filesystem update

Attached to Project: Arch Linux
Opened by M Carreira Silva (mcsilva) - Sunday, 08 April 2012, 23:01 GMT
Last edited by Dave Reisner (falconindy) - Monday, 09 April 2012, 02:10 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

The upgrade from udev-181-5 to udev-181-9, mkinitcpio-0.8.5-1 to mkinitcpio-0.8.6-2 and filesystem-2012.2-2 to filesystem-2012.2-4 breaks Raid 5 and 6.
Raid 1 is not affected (I don't know about Raid 4 and 10).

Booting a Raid 5 system with the oldest versions, the terminal messages are:

:: Running Hook [mdadm]
mdadm: /dev/md0 has been started with 3 drives.
mdadm: /dev/md1 has been started with 3 drives.
mdadm: /dev/md2 has been started with 3 drives.
INIT: version 2.88 booting
....

After the upgrade, the terminal messages during boot are:

:: Running Hook [mdadm]
mdadm: /dev/md0 has been started with 3 drives
mdadm: failed to RUN_ARRAY /dev/md1: Invalid argument
mdadm: failed to RUN_ARRAY /dev/md2: Invalid argument
:: mounting '/dev/md1' on real root
mount: you must specify the filesystem type
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs/]#


So, Raid 1 array starts cleanly, but raid 5 arrays don't.
Inside the shell cat /proc/mdstat shows:

md2 : inactive sda4[0] sdc4[3] sdb4[1]
984585 blocks super 1.2

md1 : inactive sda3[0] sdc3[3] sdb3[1]
21914131 blocks super 1.2

md0 : active raid1 sda1[0] sdc1[2] sdb1[1]
488192 blocks [3/3] [UUU]

Doing the downgrade of udev, filesystem and mkinitcpio fixes the issue.
I don't know which the package is responsible for the issue, but the downgrade of each one of them alone can not solve it.
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 09 April 2012, 02:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  testing/mkinitcpio-0.8.7
Comment by Dave Reisner (falconindy) - Sunday, 08 April 2012, 23:38 GMT
Please attach the faulty initramfs and your config.
Comment by Dave Reisner (falconindy) - Sunday, 08 April 2012, 23:38 GMT
Ahhh crap. I think I know what it is already. If I'm right, mkinitcpio 0.8.6 should still make you a valid fallback initramfs. Please test this.
Comment by M Carreira Silva (mcsilva) - Monday, 09 April 2012, 00:04 GMT
Yes! You are right!
It boots with fallback.
Comment by M Carreira Silva (mcsilva) - Monday, 09 April 2012, 00:14 GMT
Here are the faulty initramfs and config files compressed.
(application/x-gzip)    initramfs.tgz (0.2 KiB)
(application/x-gzip)    mkinitcpioconf.tgz (1.3 KiB)
Comment by Dave Reisner (falconindy) - Monday, 09 April 2012, 00:16 GMT
Something tells me even your faulty initramfs is more than 200 bytes... Anyways, shouldn't be necessary.

I'm testing a fix on a VM as soon as I finish building it (I don't have a raid[456] VM yet). If you'd like, you can patch your autodetect hook with the attached diff and it should fix the autodetect-enabled images.
   0001-mdadm-fix-raid-456-autod... (1 KiB)
Comment by M Carreira Silva (mcsilva) - Monday, 09 April 2012, 01:28 GMT
Yep! I tested the patch and it worked in raid 5 and raid 6.
By the way: I also tested raid 10 and it was not affected (before and after the patch)

Thanks!
Comment by Dave Reisner (falconindy) - Monday, 09 April 2012, 01:32 GMT
Yeah, this only affected raid4, raid5, and raid6, because they're all shared by the raid456 module. The remainder of the raid levels have their own module with the same name of the level of fault tolerance.

I'll be packaging up a new release tonight. Thanks for testing.
Comment by Dave Reisner (falconindy) - Monday, 09 April 2012, 02:10 GMT
One final note... please use mdadm_udev over mdadm. If you have problems with this hook, report them. I'd like to get rid of the old mdadm hook eventually.

Loading...