Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31257 - [systemd] boot fails beccause of missing fakeraid support

Attached to Project: Arch Linux
Opened by Pierpaolo Valerio (gondsman) - Thursday, 23 August 2012, 08:56 GMT
Last edited by Dave Reisner (falconindy) - Thursday, 23 August 2012, 12:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I've recently encountered many problems with my current HD setup. I have two HDs (sda and sdb) in a RAID1 configuration using intel on-board raid (fakeraid). Up until now the system was working using dmraid to assemble the array together with sysVinit. Note that my root partition is on the raid array as well, so in order for the kernel to boot I had to add dmraid to the HOOKS section of mkinitcpio.conf.
I found out that dmraid is now not maintained anymore and it's considered "buggy" by more or less everyone. In fact I could not get grub2 to install on the raid while using dmraid and I noticed other distributions (fedora mainly) don't use dmraid anymore to manage fakeraid arrays. systemd was failing to boot as well (see bug and no further effort is being made to improve the situation given the status of dmraid.
I thus decided to move to mdadm, which should manage the array in place of dmraid (the aforementioned fedora uses it).
I changed the mkinitcpio to:

HOOKS="base udev autodetect pata scsi sata mdadm_udev filesystems"

(the BINARIES line is needed, otherwise the partitions are mounted as read-only during boot).
Now the devices are assembled correctly as /dev/md126p* and the boot sequence works fine with sysVinit. The shutdown fails as described in even though I even tried to uninstall dmraid, so the problem is with mdadm itself, it's not a conflict between it and dmraid. The shutdown problem is also present if I boot an arch iso and mount the partitions manually.

Anyway, now grub2 installation worked properly, so I thought systemd would have worked as well, but it's not the case. The boot sequence is still failing with a timeout while mounting the home partition, exactly like what's described in bug A few things I have found out while trying to investigate the issue:
- If I remove the /home line from /etc/fstab and mount the partition with a mount command in rc.local the system boots fine. This is of course not advisable, as the check on the filesystem is not performed at boot, so I would consider it a poor workaround.
- If I mount the partitions manually in the recovery shell after the timeout the boot sequence continues normally.
- If I refer to the home partition by UUID in the fstab file the boot fails miserably, as systemd tries to mount the individual disks and not the assembled array. This behaviour is not present when I use the old initscripts
- If I use mdadm instead of mdadm_udev in the HOOKS line of mkinitcpio.conf (which should work according to the wiki) the kernel segfaults failing to mount the root partition.

I don't know what else to try, tell me if more informations are needed.
I should also add that this bug is arch-specific, as fedora uses mdadm and systemd and can boot properly on my system.

Additional info:
The system is fully up-to-date, systemd version is 188-2
This task depends upon

Closed by  Dave Reisner (falconindy)
Thursday, 23 August 2012, 12:32 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#31236 

No, support exists.