Hi,
Fedora Cloud SIG have a couple of related issues, create images using GPT [1] and create images supporting UEFI boot [2]. What we'd like to do is create a single set of images that are UEFI and BIOS bootable, out of the box. And I'm wondering if this is possible in Anaconda now, or if it could easily be enhanced to make it possible via kickstart?
If the image creation environment is BIOS, grub2-install will populate LBA 0 and BIOS Boot partitions correctly. But I'm uncertain whether anaconda will create and mount /boot/efi, i.e. if the kickstart manually creates an ESP mounting it at /boot/efi, will anaconda resist due to the environment being BIOS? The installation of grub2-efi-* RPMs should work though. We probably don't need efibootmgr to run, we can just expect BOOTX64.EFI fallback to discover there isn't an nvram entry, and add one. And due to Fedora 34 unified grub feature, a single /boot/grub2/grub.cfg should work whether UEFI or BIOS boot.
If the image creation environment is UEFI, grub2-install doesn't work, it'll detect UEFI and it'll fail. And thus no BIOS bootloader can be installed. Maybe we could do a UEFI installation, additionally creating BIOS Boot partition, and run a post install script that does `grub2-install --target=i386-pc` to add the BIOS bootloader?
Thoughts?
[1] https://pagure.io/cloud-sig/issue/330 [2] https://pagure.io/cloud-sig/issue/309
Hello Chris,
Sorry for the very late response.
On 5/27/21 9:25 PM, Chris Murphy wrote:
Hi,
Fedora Cloud SIG have a couple of related issues, create images using GPT [1] and create images supporting UEFI boot [2]. What we'd like to do is create a single set of images that are UEFI and BIOS bootable, out of the box. And I'm wondering if this is possible in Anaconda now, or if it could easily be enhanced to make it possible via kickstart?
I don't think is possible with the Anaconda UI but it's certainly via kickstart. And that is exactly what RHEL/CentOS does for cloud images:
https://gitlab.com/redhat/centos-stream/release-engineering/kickstarts/-/blo...
If the image creation environment is BIOS, grub2-install will populate LBA 0 and BIOS Boot partitions correctly. But I'm uncertain whether anaconda will create and mount /boot/efi, i.e. if the kickstart manually creates an ESP mounting it at /boot/efi, will anaconda resist due to the environment being BIOS? The installation of grub2-efi-* RPMs should work though. We probably don't need efibootmgr to run, we can just expect BOOTX64.EFI fallback to discover there isn't an nvram entry, and add one. And due to Fedora 34 unified grub feature, a single /boot/grub2/grub.cfg should work whether UEFI or BIOS boot.
Yes, relying on the default EFI boot behavior is completely reasonable.
If the image creation environment is UEFI, grub2-install doesn't work, it'll detect UEFI and it'll fail. And thus no BIOS bootloader can be installed. Maybe we could do a UEFI installation, additionally creating BIOS Boot partition, and run a post install script that does `grub2-install --target=i386-pc` to add the BIOS bootloader?
Thoughts?
You could do it either way with a custom quickstart, doing a BIOS install and add the EFI bits on top or do an EFI install and add the BIOS bits.
I *think* the CentOS-Stream-9-kvm-x86_64.ks shared above could work for either case.
[1] https://pagure.io/cloud-sig/issue/330 [2] https://pagure.io/cloud-sig/issue/309
Best regards,
anaconda-devel@lists.stg.fedoraproject.org