Automated Installs with UEFI kickstart on software raid

Hey All,

Some background:
We provision physical systems via an automated provisioning system, doing Legacy based BIOS installations with GPT partitioning schemes, however we want to move over to support UEFI.

When we did Legacy BIOS boot with GPT partitioning, on software raid 1 - we had consistent partition numbering between sda and sdb disks, however when moving over to UEFI we are running into issues where the partition numbering is not consistent across both disks.

It seems like ordering is not being adhered to what is in kickstart template, extract of software raid partitioning we use in the kickstart template.

  • Not raiding ESP partition (read a few articles which states to rather not raid ESP partition), so will create a backup on 2nd disk which we will keep in sync.

Partition kickstart extract:

zerombr
clearpart --all --initlabel --disklabel=gpt

bootloader --driveorder=sda,sdb

part /boot/efi --fstype=efi --size=512 --ondisk=sda
part /boot/efi_backup --fstype=efi --size=512 --ondisk=sdb

part raid.01 --fstype=raid --ondisk=sda --size=1024
part raid.02 --fstype=raid --ondisk=sdb --size=1024
part raid.03 --fstype=raid --grow --ondisk=sda --size=1
part raid.04 --fstype=raid --grow --ondisk=sdb --size=1

raid /boot --fstype=ext4 --level=1 --device=md0 raid.01 raid.02
raid / --fstype=ext4 --level=1 --device=md1 raid.03 raid.04

Results of this:

lsblk -f
NAME    FSTYPE            FSVER LABEL                   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                         
├─sda1                                                                                                      
├─sda2  linux_raid_member 1.2   localhost.localdomain:0 76084f35-10eb-2e8f-77c5-c78542bf81bc                
│ └─md0 ext4              1.0                           1807e582-87fb-4ba5-9a45-8ae3448cd7b5  743.6M    18% /boot
├─sda3  vfat              FAT32                         1A40-9F95                               511M     0% /boot/efi_backup
└─sda4  linux_raid_member 1.2   localhost.localdomain:1 09d08275-f48f-bebb-8d1d-5f1b3c221614                
  └─md1 ext4              1.0                           c1592839-f78b-4a80-8c17-e70474a3d1da  831.6G     0% /
sdb                                                                                                         
├─sdb1  vfat              FAT32                         1A47-376E                             503.9M     1% /boot/efi
├─sdb2                                                                                                      
├─sdb3  linux_raid_member 1.2   localhost.localdomain:0 76084f35-10eb-2e8f-77c5-c78542bf81bc                
│ └─md0 ext4              1.0                           1807e582-87fb-4ba5-9a45-8ae3448cd7b5  743.6M    18% /boot
└─sdb4  linux_raid_member 1.2   localhost.localdomain:1 09d08275-f48f-bebb-8d1d-5f1b3c221614                
  └─md1 ext4              1.0                           c1592839-f78b-4a80-8c17-e70474a3d1da  831.6G     0% /

cat /proc/mdstat 
Personalities : [raid1] 
md1 : active raid1 sdb4[0] sda4[1]
      935985152 blocks super 1.2 [2/2] [UU]
      [====>................]  resync = 22.5% (211236544/935985152) finish=60.1min speed=200890K/sec
      bitmap: 6/7 pages [24KB], 65536KB chunk

md0 : active raid1 sdb3[0] sda2[1]
      1046528 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Is there anyway using kickstart to adhere to consistent partition numbering across both disks?

Feedback appreciated.

Thanks

Hi,
The issue here I believe is around the inconsistent partition numbering across disks due to how Anaconda processes partitions and ordering, especially when EFI System Partitions are involved and not RAIDed.

So, would it be possible to try the following in your kickstart?
Different order…

# sda layout (primary)
part /boot/efi --fstype=efi --size=512 --ondisk=sda
part raid.01 --size=1024 --ondisk=sda
part raid.03 --size=1 --grow --ondisk=sda

# sdb layout (mirror)
part /boot/efi_backup --fstype=efi --size=512 --ondisk=sdb
part raid.02 --size=1024 --ondisk=sdb
part raid.04 --size=1 --grow --ondisk=sdb

raid /boot --fstype=ext4 --level=1 --device=md0 raid.01 raid.02
raid /     --fstype=ext4 --level=1 --device=md1 raid.03 raid.04

I believe Anaconda might respect the order in which things are created. I could be wrong however.

in %post you could (as you mentioned in your opening post)

echo "[INFO] Syncing ESP to backup copy..."
mkdir -p /boot/efi_backup
mount /dev/sdb1 /boot/efi_backup
rsync -a /boot/efi/ /boot/efi_backup/

echo "[INFO] ESP backup complete."

Hey,

So unfortunately no luck:

Will play around with the ordering some more, but what I have observed so far it seems like there’s not really any adherence to ordering in the partitioning.

Thanks

OK,

So just to close the loop on this one, seems like the only way I can accomplish this at the moment is with a bit more manual intervention, what we have to do now:

( Extracts from our kickstart partition template)*

%pre
zerombr
%end

%pre --interpreter=/bin/bash
for disk in /dev/sda /dev/sdb; do
  wipefs -a -f $disk
  sgdisk --zap-all $disk
  sgdisk -o $disk

  sgdisk -n 1:0:+512M -t 1:ef00 -c 1:"EFI System" $disk
  sgdisk -n 2:0:+1G  -t 2:fd00 -c 2:"boot RAID" $disk
  sgdisk -n 3:0:0  -t 3:fd00 -c 3:"root RAID" $disk
done
%end

%pre
bootloader --driveorder=sda,sdb

part /boot/efi --fstype=efi --size=512 --onpart=sda1
part raid.01 --size=1024 --onpart=sda2
part raid.03 --size=1 --grow --onpart=sda3

part /boot/efi_backup --fstype=efi --size=512 --onpart=sdb1
part raid.02 --size=1024 --onpart=sdb2
part raid.04 --size=1 --grow --onpart=sdb3

raid /boot --fstype=ext4 --level=1 --device=md0 raid.01 raid.02
raid /     --fstype=ext4 --level=1 --device=md1 raid.03 raid.04
%end

End results:

cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdb2[0] sda2[1]
      1046528 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdb3[0] sda3[1]
      935986496 blocks super 1.2 [2/2] [UU]
      [==>..................]  resync = 12.7% (118975232/935986496) finish=67.5min speed=201396K/sec
      bitmap: 7/7 pages [28KB], 65536KB chunk

unused devices: <none>

lsblk -f
NAME    FSTYPE            FSVER LABEL                   UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                         
├─sda1  vfat              FAT32                         6DB1-1B93                               511M     0% /boot/efi_backup
├─sda2  linux_raid_member 1.2   localhost.localdomain:0 637bcc97-c248-4096-9393-cafbce91380f                
│ └─md0 ext4              1.0                           9e0ff69d-16a6-4a01-990b-26cc9f046002  743.6M    18% /boot
└─sda3  linux_raid_member 1.2   localhost.localdomain:1 8f24660a-99dc-4c91-4806-f1fb699763bc                
  └─md1 ext4              1.0                           265f9829-076e-4728-86d4-823295f5ad0a  831.6G     0% /
sdb                                                                                                         
├─sdb1  vfat              FAT32                         6FF6-6297                             503.9M     1% /boot/efi
├─sdb2  linux_raid_member 1.2   localhost.localdomain:0 637bcc97-c248-4096-9393-cafbce91380f                
│ └─md0 ext4              1.0                           9e0ff69d-16a6-4a01-990b-26cc9f046002  743.6M    18% /boot
└─sdb3  linux_raid_member 1.2   localhost.localdomain:1 8f24660a-99dc-4c91-4806-f1fb699763bc                
  └─md1 ext4              1.0                           265f9829-076e-4728-86d4-823295f5ad0a  831.6G     0% /

Just going to cleanup a bit and see if we can streamline it a bit more.

Thanks

1 Like