RAID UUID and initramfs

After many many reboots between the running system and the rescue console of the Fedora DVD I figured out the root cause: Each Software RAID created with mdadm has a unique identifier (a UUID to be precise). You can determine your one with

mdadm --misc -D /dev/md0

(side remark: for the time being I assume that the software RAID device is called /dev/md0) What follows are the metadata details of your RAID. Amonst others there is a line which looks like this:

UUID : c9d6cd07:d2960626:1eb1e02d:b8b6db4b

This UUID is being written (during setup of Fedora) to the file /etc/mdadm.conf where (in my case) it reads something like this:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=10c62146:3d716744:bf078010:bc810f04

If you recreate your software RAID manually, the UUID changes — but the line in /etc/mdadm.conf is not! Please note that this is no bug, because the system cannot know what the purpose of the just newly created software RAID device is. Having found this point, I changed it accordingly (which is a good idea), but it soon turned out that this was not enough: the same error still was shown to me. When booting Fedora does not use this file on the root partition directly, but it starts from the initramfs file which you can find in your /boot directory. In this boot image a copy (!) of /etc/mdmadm.conf has been stored when it was created during the setup procedure of Fedora. The error message above therefore is quite misleading: The root cause of it is not that the root file system cannot be found, but that the software RAID array with the old UUID is not being detected (and thus the system cannot gain access to the root file system). As you need a running system for creating a new initramfs I did the following workaround:

1. I made a copy of the initramfs file – just to make sure that if I killed something I could revert back to the start at any time
2. By renaming the file I added the postfix .gz to it
3. You can uncompress the initramfs now with gunzip
4. The uncompressed file is an archive created with cpio. However, I did not uncompress it
5. Using vi in binary mode

   # vi -b

   I opened the entire file and searched for the term mdadm.conf. Shortly thereafter the content of the mdadm.conf can be seen. As cpio neither does implement a compression algorithm nor does it impose error dedecting codes like CRC checksums or similar, you can change the UUID manually. However, please note that you still need to be careful, because you may not modify the length of the file (otherwise the entire file’s structure does not fit anymore).

I then did the entire chain back again (saving, compressing it, renaming it back to the original name) and started the system: and hurray! The system booted from the new software RAID device without a problem!

Appendix

Please note also that it is a good idea to recreate the initramfs file from scratch again. Unfortunately this can also be a very tricky task. In the case of Fedora Core posts like http://kb.qlogic.com/KanisaPlatform/Publishing/394/12902_f.html can be very misleading: here again, it proofs that Fedora ain’t RedHat – the tool with which you can create a new initramfs file on Fedora is called dracut. You can find more details on this here