Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Mandriva Linux system that was upgraded in-place using urpmi from version 2010.0 to 2010.1 and then 2011.0. I did run into a few minor issues, but nothing I couldn't handle.

A few weeks back, the Mandriva updater informed me that in order to update shorewall, I had to also replace sysvinit with systemd and systemd-sysvinit. Naturally, I was reluctant to let the updater touch something as critical as the boot system for no reason, so I put it off. Naturally, the Mandriva updater applet kept bugging me. Naturally, I eventually gave up and agreed. And, naturally, it made enough of a mess that my system cannot boot on its own.

It starts-up normally, spouts of a few messages, and then I get a whole lot of messages in this format:

Starting XXXX aborted because a dependency failed.

where XXXX is something filesystem-related, either an fsck call or a filesystem mount. It drops me into the root shell, where the dependency that failed soon becomes obvious: most MD arrays have not been started. Manually executing

# mdadm -As
# mount -a
# systemctl default

in this order allows the system to complete the booting process.

I have several physical drives split into partitions, which are then combined in a few RAID-1 (e.g. /boot) and RAID-5 (/, swap and pretty much everything else) arrays. The partitions and the arrays, as well as the filesystems they contain were created manually and then Mandriva Linux was installed. There where no problems of note and everything worked fine, till systemd came along.

I think that I have tracked this issue down to a degree. The old sysvinit system used to run /etc/rc.d/rc.sysinit which, as provided by Mandriva, contains this line:

MDADM_RETURN=`/sbin/mdadm -As --auto=yes --run 2>&1`

which starts any MD array specified in /etc/mdadm.conf that has not been started. As far as I can tell, this file is not used any more after system was installed and the line above has been replaced by this line from /lib/systemd/fedora-storage-init:

[ -r /proc/mdstat -a -r /dev/md/md-device-map ] && /sbin/mdadm -IRs

Unfortunately. my system seems to be missing the /dev/md/md-device-map file, so mdadm is not executed. I can think of a few ways to "fix" this issue, such as editing the systemd scripts or modifying my /boot/initrd.img to start all MD arrays, but I'd rather do it in a way that will not break with the next package upgrade.

  • What is the format of /dev/md/md-device-map and how do I create it? Is this file common, e.g. with newer mdadm versions, or is it something Fedora/Mandriva-specific? I have seen a few samples in the Fedora forums, but nothing solid.

  • What is the "proper" way to fix this boot failure? I'd rather not resort to brain surgery if I can avoid it...

  • Why, why, why did I not stick with the "If it is not broken, don't fix it!" maxim? (Yes, this is a rhetorical one...)

share|improve this question
up vote 1 down vote accepted

I managed to track down this issue. /dev/md/md-device-map is apparently the mdadm device map file on Fedora systems, while my Mandriva system uses /dev/.mdadm/map instead. Therefore, the /lib/systemd/fedora-storage-init script failed to launch mdadm since it was looking at the wrong place.

Rather than edit that script file and risk losing the modifications at a future package update, I added my own script:

$ cat /lib/systemd/mdadm-array-start 

# Start any MD RAID arrays that have not been started yet
[ -r /proc/mdstat ] && /sbin/mdadm --assemble --scan

exit 0

I also created a unit file for systemd:

$ cat /lib/systemd/system/mdadm-array-start.service 
Description=Start MD arrays



Then I just enabled the service:

# systemctl enable mdadm-array-start.service
ln -s '/lib/systemd/system/mdadm-array-start.service' '/etc/systemd/system/'

This ensures that any MD arrays are started without intervention by an administrator.

share|improve this answer
FYI: user-created units should go to /etc/systemd/system. – grawity Dec 5 '11 at 0:00
@grwity: True, since /etc/systemd/ units take precedence. In my case though, I consider my unit to be part of the system, much like a bug-fix patch... – thkala Dec 5 '11 at 0:02
The distinction here is not "part of the system" or not; rather it's "installed by package manager from a package" versus "installed by the user/sysadmin manually". – grawity Dec 5 '11 at 0:06
@grawity: err... my rule was installed using a package manager... it was the only way to avoid unfortunate mishaps that could kill my system when I am a 4-hour drive away... This way rpm will start whining if anyone tries to overwrite my additions... – thkala Dec 5 '11 at 0:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.