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
--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
- 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
- Add a
%postscript 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/mdXinstead of the
%post 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 %end
- 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.