I think it should be possible to make our generic cloud images hybrid UEFI and BIOS bootable. There should be no reason for any of this to fail, as far as I know.

This also dovetails nicely into the discussion that @johannbg had on devel@ about emphasizing UEFI support more across Fedora.

@dustymabe, @mhayden, do either of you know of any reasons why we couldn't do that?

Presumably the goal is to just having to maintain one image for both Azure and on premis but the Generation 2 features are only supported on premises hyper V not Azure [1].

That said I personally generate all my images using mkosi perhaps that is an option?

1. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/generation-2

According to the document you linked, Generation 2 virtualization is available on both on-premises Hyper-V and on-cloud Azure platforms (at least since February). So I think this is still a perfectly valid ask.

I think the idea here is that @sramanujam does not want to generate the base image himself, he wants to rely on the golden image we provide. That is absolutely a valid use-case for us to cater to.

Hmm I took the red x-is under the Azure column under "Azure doesn't currently support some of the features that on-premises Hyper-V supports for generation 2 VMs" not being supported but granted I'm no Azure expert and I just skimmed through it's documentation.

Yeah sure it's most definitely a valid use case and most certainly the way forward from my pov if it's supported.

Just adding this info
AWS - Does not support UEFI
GCP - Does support UEFI
Azure - Does support UEFI

Which means if the same Golden image is used on these 3 different platforms we have to wait for AWS/XenServer based solution to catchup or we have to maintain 2 images one "Legacy ( Xen )" and one "Modern" for the rest of the cloud world Alibabacloud/Azure/GCP/IBM etc.

Not really. We can make an image support booting with either UEFI or BIOS. We just haven't done this before. My experience with building images using KIWI (another image building tool) is that if you build a UEFI image, it always includes support for booting via BIOS too.

I think the only reason we haven't done this too is that Lorax doesn't allow this by default? I think that's what we're using for our cloud image builds... @bcl might know more here.

I'm not sure how the cloud images are built, but when using livemedia-creator you need to actually run it on a UEFI host or VM in order for Anaconda to create the image with UEFI support. Since we're using Anaconda to do the actual install and bootloader setup it depends on the environment it is running in.

Anaconda bug: https://bugzilla.redhat.com/show_bug.cgi?id=1858921

We discussed this in the meeting today. Since Image Builder/osbuild appears to support this feature we came away with this action item:

Action Items
------------
* King_InuYasha to engage mhayden to see if the cloud base images might
  be a good candidate for Image Builder

I talked to @davdunc during Nest today, and found out that hybridizing would likely break using Fedora on AWS (on Xen hypervisors).

Based on some discussion with @ausil and @davdunc, it is likely a better idea to produce a second UEFI-optimized cloud image for providers that support UEFI (Azure and GCP).

Based on the discussion here. Don't we want to close the https://pagure.io/cloud-sig/issue/309#comment-666516 bug? Seems to me that even if this would be a valid use-case it should be done by osbuild rather than Anaconda. For the installation of the system PoV you want support just for UEFI/BIOS not both.

It appears that it is now possible to boot x86_64 images on AWS in UEFI mode.

We should support this, though I don't know if there are special things we need to account for. @davdunc may be able to help here.

This complete kickstart for el8 was suggested in the devel discussion

Contains all the central elements to make it work:

• BIOS VM to create the image, so that grub2-install installs a BIOS GRUB
• custom kickstart creates GPT + BIOS Boot + EFI System + bootfs + rootfs
• %post runs grub2-mkconfig which now might be something we can skip, since the "real" grub.cfg is in the same location no matter the firmware
• shim and grub2-efi packages will drop the UEFI bootloader in the correct place on the ESP
• open question how to get grub2-common, or split out its script, to create the ESP grub.cfg that forwards to the real one at /boot/grub2/grub.cfg

This complete kickstart for el8 was suggested in the devel discussion

That's very similar to what the kickstart files for CentOS Stream 9 images.

BIOS qemu-kvm, Workstation Live ISO, inst.gpt, followed by a custom partitioning: BIOSBoot, /boot/efi, /boot, /, /var, /home. And I get the attached kickstart.

It is BIOS and UEFI bootable, with some help. BIOS works alright as is. UEFI has two problems:

• edk2-ovmf doesn't recognize the partition table at all, and I get an EFI shell. It's due to parted setting a pmbr_boot flag on the disk.
  • /usr/sbin/parted -s /dev/vda disk_set pmbr_boot off is the fix. Once I do that, I get a grub prompt instead.
• The ESP//EFI/fedora/grub.cfg stub file that points to BOOT//grub2/grub.cfgdoesn't exist.
  • No work around yet. Maybe we can dnf reinstall grub2-common in a %post section of the kickstart file?
  • OK there is a work around in the earlier centos 9 kickstart, starting here.

Filed RFE ticket with Fedora QA, enhance openQA Cloud image tests accounting for hybrid firmware support. Adding it here for visibility, in case someone can help make part or all of that happen. We should have hybrid images in Rawhide pretty soon.

I've done the initial work so far:

• comps: https://pagure.io/fedora-comps/pull-request/664
• kickstarts: https://pagure.io/fedora-kickstarts/pull-request/820

There's still one followup left: https://pagure.io/fedora-kickstarts/pull-request/821

This is now done with Fedora Linux 35.