UEFI boot support

Background

We were able to get things going by building a vanilla SL7 machine to bootstrap LCFG.

Requirements

The main requirements were a suitably formatted partition (see bug#1073 for details), and the right RPMS installed before reboot.

I used the second partition for UEFI, and mounted it as /boot/efi - this seems to suffice. This replaces using the second partition as /boot for grub.

Additional RPMs

Initial attempts failed because updaterpms removed UEFI support. Experiment suggests that the RPMS needed are: grub2-efi-x64 and shim-x64 (plus dependencies, including: mokutil and efivar-libs ) See bug#1072 for more details.

The following packages have been added to lcfg_sl74_base.rpms, lcfg_sl74_installroot.rpms and lcfg_sl74_installbase.rpms

efibootmgr-15-2.el7
efivar-libs-31-4.el7
grub2-efi-x64-2.02-0.64.sl7
grub2-efi-x64-modules-2.02-0.64.sl7/noarch
mokutil-12-1.sl7
shim-x64-12-1.sl7

It seems that grub2-efi-x64-modules is only required when using grub2-install to rebuild the .efi bootloader, this is not recommended practice for Fedora/Redhat systems.

grub2 component

As of Friday 8th June with version 0.12.12 of the grub2 component booting with EFI is supported.

1. The grub2-efi-x64 package converts the /boot/grub2/grubenv into a symlink to the /boot/efi/EFI/redhat/grubenv file, this may point to a non-existent file (see Redhat bug#1497918) which seems to break some of the scripts shipped with grub2 itself. The component has been modified so that it converts it back into a file.
2. In the LCFG installer the grub2 install method is now called at the baseinstall stage so that it is chrooted into the new root filesystem. This makes everything a lot simpler and means we don't need a hacked version of the grub2-mkconfig script just for the installer.
3. The component needs to be able to manage the /boot/efi/EFI/redhat/grub.cfg file (instead of or as well as /boot/grub2/grub.cfg).
4. The grub2-install utility has a --efi-directory option, do we need to specify it?
5. menuentry in grub config needs to use linuxefi and initrdefi instead of linux16 and initrd16
6. target platform needs to be x86_64-efi
7. The grub2-install script seems a little confused and is looking for /boot/efi/EFI/scientific when the files are actually in /boot/efi/EFI/redhat, that behaviour can be overridden using the --bootloader-id option.
8. Is it ever necessary to run grub2-install? fedora wiki page suggests not, also: redhat bug#886412
9. More useful notes - https://superuser.com/questions/596317/how-would-i-reinstall-the-grub-efi-bootloader-on-fedora-linux, https://docs.fedoraproject.org/quick-docs/en-US/bootloading-with-grub2.html

fstab component

1. Turns out that having the 'pmbr_boot' flag set on a disk makes the bios consider it to only be legacy bootable.
2. hackparts needs support for setting the "esp" flag on a partition, it seems that with GPT this is an alias for the "boot" flag, certainly parted in EL7 does not support an "esp" flag.
3. fstab needs support for formatting the esp partition as vfat and setting appropriate mount options, the current fat support is not sufficient as it hardwires unhelpful options into the /etc/fstab file
4. dosfstools package needs adding to base/installroot/installbase package lists so partitions can be formatted as fat32

LCFG installer

There are two parts to the work required for the LCFG installer.

Firstly, the ISO itself needs to be UEFI bootable.

Secondly, it needs to be able to setup the environment necessary for the grub2 component to be able to make the new system UEFI bootable. As part of this second issue the baseinstall component needs to bind mount /sys/firmware/efi/efivars when it is available. The problem here is that this will only be available when the machine has been UEFI booted and we don't want separate configs/installers for the two modes unless really necessary. Currently the baseinstall component will fail if a path cannot be bind mounted. To workaround this problem I've added support to the component for optional paths which will not be bind mounted when they do not exist. This is indicated by prefixing the path with a ? (question mark) character, for example:

!baseinstall.bind_mounts mADD(?/sys/firmware/efi/efivars)

Turns out /sys was already being mounted so this is not a requirement.

PXE boot

To PXE boot using UEFI some changes need to be made to the PXE tftp service and possibly the dhcp server config: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/installation_guide/chap-installation-server-setup

1. Copy grub .efi files into /var/lib/tftpboot
2. Create a simple grub config file

Actually might be that an update to the latest syslinux packages would give us UEFI support without needing to generate grub configs. Currently we have 4.05 which was released in December 2011, latest is 6.03. Fedora syslinux package mostly just works but needed modification to put the tftpboot files into /var/lib/tftpboot to match standard SL7 packages.

Some work was required for the pxeclient and pxeserver components to support using sub-directories in the tftpboot directory for alternate boot modes (e.g. efi64 and efi32).

Bootstrap Process

The bootstrap process was simplified by harvesting a kickstart file from a first build (in /root/anaconda.cfg ) and modifying it. Apart from fixing partitions, the main requirement was to disable SELinux or LCFG gets very confused.

Once running on suitable partition scheme the procedure was:

• Copy in a suitable /etc/yum.repos.d/lcfg.repo
• Set correct values for HOST and DOMAIN
• Run the following:

hostname $HOST.$DOMAIN
hostname > /etc/hostname
yum  -y --nogpgcheck install lcfg-client lcfg-updaterpms perl-LWP-Protocol-https
rdxprof -u http://lcfg.is.ed.ac.uk/profiles/$DOMAIN/$HOST/XML/profile.xml
om client install
om client configure
om updaterpms start
om systemd start
om kernel start
om kerberos start
reboot

shane - 2018-05-28

Comments

%COMMENT%