Wumple.com

Here’s a problem I ran into recently: I temporarily switched the root filesystem of my Fedora 14 install from RAID-5 to non-RAID. After I received the new SSD drives, I switched it to RAID-1 but the dracut boot sequence could not find the RAID-1 array and mount the root filesystem, ending in the errors ‘Can’t mount root filesystem. Boot has failed, sleeping forever’.

Using the dracut rdshell and rdinitdebug kernel boot options to get a shell prompt from the dracut initramfs led me to the RAID assembly failing during boot during “dracut: Autoassembling MD Raid”. I discovered manually assembling the array using mdadm –assemble … then exiting the shell would allow the boot to continue, so at least I had a temporary workaround.

To fix the dracut auto assembly of the RAID array, I did the following:

1. Booted up a Fedora Live CD so I could manipulate the RAID partitions without them being mounted/used (since they contained the root filesystem).
2. After noticing that the volume type was wrong on one of the RAID-1 member partitions by running blkid (TYPE was not “linux_raid_member”) and making sure the other partition was up-to-date with the data, I used wipefs (remember to use the -a option) on the partition with the incorrect data (and let the next step sync the data from the correct partition).
3. Set the system hostname via the hostname command, then did “mdadm –assemble /dev/md1 /dev/sda2 /dev/sdb2 –update=name –update=uuid”. This fixed the array name to be hostname:1.
4. After booting the system back up normally with the workaround, made a backup of /etc/mdadm.conf then did “mdadm –examine –scan > /etc/mdadm.conf” and made sure /etc/mdadm.conf looked correct afterward.

After these steps, the dracut boot sequence was able to auto-assemble the RAID array on boot and mount the root filesystem.

I hope this writeup helps someone who runs into a similar problem. 🙂

Have a USB-attached CyberPower System UPS but can’t get it to work with Network UPS Tools aka nut 2.6.0 (such as from the Fedora 14 or 15 rpms)? See the link to the rpms below I built.

The errors you might see (especially when running usbhid-ups -D -D -D) include “could not connect to ups”, “libusb_get_report: error sending control message: Operation not permitted”, and “Can’t retrieve Report 03: Operation not permitted”.

There is a workaround for a libusb issue affecting communication with USB CyberPower Systen UPSs in the trunk branch of the nut source code that will get into nut 2.7, but was not part of nut 2.6. See the fix here in change 2893 on nut’s trac system. Read more about the problem in this message on nut-upsuser.

To get the fix now (before the 2.7 rpms are released), I rebuilt nut 2.6 rpms (with small changes to the spec file) using the latest source snapshot from nut’s buildbot, r2978. You can download these r2978 rpm’s from here.