UEFI boot support
Background
GeoSciences had an urgent need to build some server boxes which required UEFI to boot.
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.
- 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.
- 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.
- 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
).
- The
grub2-install
utility has a --efi-directory
option, do we need to specify it?
- menuentry in grub config needs to use
linuxefi
and initrdefi
instead of linux16
and initrd16
- target platform needs to be
x86_64-efi
- 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.
- Is it ever necessary to run grub2-install? fedora wiki page suggests not
, also: redhat bug#886412
- 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
- Turns out that having the 'pmbr_boot' flag set on a disk makes the bios consider it to only be legacy bootable.
- 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.
- 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
- 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
- Copy grub
.efi
files into /var/lib/tftpboot
- 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%