Skip to content

Working around missing –label option for RAID partitions in Kickstart

TL;DR – During kickstart, you can initiate “normal” partitions with a simple --label flag, why not a RAID partition? There are hardware setups that cause the on-disk OS to “see” your drives differently than kickstart did (a situation UUIDs normally solves, but referencing the UUID can be non-ideal in certain cases). This work-around fixes some of those cases.

RAID partitions are commonplace, yet RedHat forces them to be treated differently

The --label flag has been available for the partition option in kickstart configs for a long time (since at least RedHat v7.2). RAID partitions are quite common (I imagine more popular than ever, though I don’t know for sure), and labeling RAID partitions is done on the command line just like any single-drive ext2/ext3/xfs partition, yet this functionality isn’t [yet] in anaconda (the kickstart tool).

This had until recently seemed (to me) to just be a mild curiosity, but then I had to fight out a situation where kickstart was seeing the drives of these machines in one order, but the post-kickstart locally-installed OS sometimes saw them in another order. So kickstart sees the on-board SATA controller first (thus containing sda, sdb, …), but on some systems (of the same hardware config) the locally-installed OS sees the PCI-X card first. While it’s [as far as we can tell] non-deterministic which servers will exhibit this logical drive-swap, at least it’s stable and not random during boot.

If this was just a server or two, it’s certainly annoying, but not a huge problem. However, when we’re talking about getting hundreds (or thousands) of systems online, it becomes unmanageable. Fortunately, this situation is easily dealt with by using a non-changing reference to the RAID partition. The options left are UUID & labeling. Using the UUID is the default behavior these days, but for my particular use-case (PXE-initiated local drive booting…an unusual scenario I will lay out in another article) UUIDs are not manageable. Also, UUIDs, since they are just a string stored in the superblock, can and do change due to corruption [or corrective action thereof] — I have encountered a situation where a machine lost power, upon boot-up it runs fsck and then the OS can’t see the partition because the UUID is different. Fixed by booting a rescue image and altering /etc/fstab to mount the new UUID, but still a pain.

Labels, on the other hand, can be configured consistently on all systems and are still deterministic since they are tied to the partition no matter where it shows up in the drive order (just like UUID).

Notably, I’ve filed a bug with RedHat to correct this long-standing oversight, but in the meantime there is a work-around.

Let’s get to it

  1. Set up your kickstart partition configs to use RAID (examples here are / & /boot)
    part raid.0 --ondisk=sda --asprimary --fstype ext2 --size=100
    part raid.1 --ondisk=sdb --asprimary --fstype ext2 --size=100
    raid /boot --level=1 --device=md0 --fstype=ext2 raid.0 raid.1
    part raid.10 --ondisk=sda --asprimary --fstype ext3 --size=10000 --grow
    part raid.11 --ondisk=sdb --asprimary --fstype ext3 --size=10000 --grow
    raid / --level=1 --device=md1 --fstype=ext3 raid.10 raid.11
  2. Add a %post script block to label the RAID partition(s) plus a hack to alter the /etc/fstab. (Example is for ext2/ext3, for XFS use xfs_admin -L <LABEL> /dev/mdX instead of the e2label commands shown.)
    e2label /dev/md0 BOOT
    perl -p -i -e 's!^UUID=[[:alnum:]-]+[[:blank:]]+/boot[[:blank:]]!LABEL=BOOT /boot !' /etc/fstab
    e2label /dev/md1 ROOT
    perl -p -i -e 's!^UUID=[[:alnum:]-]+[[:blank:]]+/[[:blank:]]!LABEL=ROOT /!' /etc/fstab
  3. Kickstart your system(s)


In this example, I labeled these drives “BOOT” and “ROOT” so that it was painfully obvious what part was the label.  In real life, I recommend using something less garish, like “/boot” and “/” respectively.