Hacking Around Fedora 16’s Lack of Growable RAID Support

In Fedora 16, you are no longer allowed to use growable members in non-RAID0 RAID sets in a kickstart script. Take the following snippet from a Fedora kickstart file…

clearpart --all --initlabel
bootloader --location=mbr --timeout=15 --driveorder=sda,sdb --append="rhgb quiet"

#sda
part biosboot --fstype=biosboot --asprimary --ondisk=sda --size=1
part /boot --fstype=ext3 --asprimary --size=500 --ondisk=sda
part raid.1 --size=1 --grow --ondisk=sda

#sdb
part biosboot --fstype=biosboot --asprimary --ondisk=sdb --size=1
part /boot2 --fstype=ext3 --asprimary --size=500 --ondisk=sdb
part raid.2 --size=1 --grow --ondisk=sdb

#raid stuffs
raid pv.1 --encrypted --level=1 --device=md0 raid.1 raid.2

#LVM stuffs
volgroup LVM --pesize=32768 pv.1
logvol swap --name=swap --vgname=LVM --size=4000
logvol / --fstype=ext4 --name=root --vgname=LVM --size=30016
logvol /home --fstype=ext4 --name=home --vgname=LVM --size=50016

In looking at this, one would expect that each physical disk would get a BIOS boot partition, a /boot(2) partition for your bootloader/kernel stuff, and finally an encrypted RAID1 built out of the third partition of each disk. Well, Fedora 16 won’t let you do that. If you try specifying --grow on a RAID partition, you’ll get this message:

Only RAID0 arrays can contain growable members

Using some pre-install scripting, you can get around this. Fedora is perfectly happy to install itself into pre-existing partitions, so its up to you to make some. Pre-install scripting makes this happen.

%pre --interpreter /bin/sh
echo "Wiping first 1000MB of /dev/sda"
dd if=/dev/zero of=/dev/sda bs=1M count=1000
echo "Wiping first 1000MB of /dev/sdb"
dd if=/dev/zero of=/dev/sdb bs=1M count=1000

parted -- /dev/sda mklabel gpt
parted -- /dev/sda unit MB mkpart primary 1 5
parted -- /dev/sda unit MB mkpart primary 5 500
parted -- /dev/sda unit MB mkpart primary 500  -0
parted -- /dev/sda set 1 bios_grub on
parted -- /dev/sda set 2 boot on
parted -- /dev/sda set 3 raid on

parted -- /dev/sdb mklabel gpt
parted -- /dev/sdb unit MB mkpart primary 1 5
parted -- /dev/sdb unit MB mkpart primary 5 500
parted -- /dev/sdb unit MB mkpart primary 500  -0
parted -- /dev/sdb set 1 bios_grub on
parted -- /dev/sdb set 2 boot on
parted -- /dev/sdb set 3 raid on

#missing floppy drives can make partprobe take a *VERY* long time.
rmmod floppy
partprobe
%end

clearpart --none
bootloader --location=mbr --timeout=15 --driveorder=sda,sdb --append="rhgb quiet"

#sda
part biosboot --fstype=biosboot --onpart=sda1
part /boot --fstype=ext3 --onpart=sda2
part raid.1  --onpart=sda3

#sdb
part biosboot --fstype=biosboot  --onpart=sdb1
part /boot2 --fstype=ext3 --onpart=sdb2
part raid.2  --onpart=sdb3

#raid
raid pv.1 --encrypted --level=1 --device=md0 raid.1 raid.2

#lvm
volgroup LVM --pesize=32768 pv.1
logvol swap --name=swap --vgname=LVM --size=4000
logvol / --fstype=ext4 --name=root --vgname=LVM --size=20016
logvol /home --fstype=ext4 --name=home --vgname=LVM --size=40016

In this above snippet, partitions are created manually using parted after using dd to wipe away the the first gigabyte worth of data on the disk. This, combined with partprobe, should obliterate any evidence of previous partitions, but it doesn’t always work. It’s good to start with a blank set of disks. dban is an excellent tool for this.

The parted command that creates the third partition is where we get our flexibility. The “-0” at the minus sign tells parted that the specified offset should be in relation to the “end” of the disk, and not the “beginning.”  As a result, we get a partition that starts at the 500th megabyte of the disk, and goes all the way to the end.

In the partitioning section, notice that we’ve changed a few things. The clearpart section has lost the “–all –initlabel” flags and replaced them with “–none.” This is important, for two reasons. The big one is that it tells anaconda not to clobber the existing partition structure (which we just created manually). Secondly, there’s currently a bug in anaconda where things won’t install properly in our scenario if clearpart isn’t specified.

Also, the ondisk references have changed to onpart. This tells anaconda to try using a pre-existing partition (which we’ve created) instead of creating one itself.

  1. Great stuff a small bug and a question. Fist the bug you need to use parted with the -s option or this will halt as it asks the user to proceed.

    Question: You created two /boot partitions and two boisboot partitions. I think the install will only populate one of them. How can I make the system boot from both drives?

    • Good catch on the parted thing. I haven’t come across a scenario where it waits for user input, but that doesn’t mean it can’t happen.
      I was intending to go back after the fact and make /boot and /boot2 into a software RAID1 partition that the system can boot from, but as things so often go, I haven’t got back to doing it yet. In theory, it should be really easy to do as long as the RAID1 is created with the old 0.90 metadata format. The older grub could handle those with no issue, and is easy to install on each physical disk. I’ve only used grub2 a small amount, so I’m not sure if it’ll work in the same way.

  2. That would be cool if you could get a RAID1 boot partition. I’m using GRUB2 so maybe it’s no problem? How about the biosboot partitions do they both get grub installed? I think anaconda will only install grub in one of them so the second one won’t boot.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>