per this site, AlmaLinux on AWS (AMI) only supports BIOS boot.
Yet AWS also supports UEFI Boot. Is the BIOS limitation still applicable? If so, what is preventing the use of UEFI boot and any plans to support this in the future?
I want to say when we started building the AWS images they didn’t support UEFI at the time. We can definitely pack up and publish some UEFI images on AWS.
Let me get with @lkhn who leads up our cloud images and I’m sure we can get something going on this pretty quickly.
Hi @mluken,
We are testing 8.9-beta-1 and 9.3-beta-1 AMIs in the “uefi-preferred” boot mode. Which basically means an instance will be created and boot in UEFI if it’s supported by the instance type.
Would you like to help us with the testing?
Here is the AMI IDs on the us-east-1 region. You can also copy them to another region if you want.
AlmaLinux OS 8.9-beta-1.20231107 x86_64: ami-0ebb096e453d2fb20
AlmaLinux OS 9.3-beta-1.20231107 x86_64: ami-04036e2559f9d72d9
1 Like
Yes - I will look for someone to handle this. Thanks for making this available.
HI Elkhan,
My name is Carol Rodrigues from Cisco Systems. I’ve talked to Mike about the UEFI support for AMI and I would be glad to do some testing on that.
Do you have any test plan for this new feature? And, do you have a test environment?
Let me know how can I help you.
Carol R.
Hi Elkhan
We are testing the AlmaLinux AMI using UEFI. We were able to boot up with UEFI but not with secure boot.
Where do we get the secure boot public key for AlmaLinux?
[ec2-user@ip-172-31-47-47 ~]$ sudo bootctl
systemd-boot not installed in ESP.
System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled (unknown)
TPM2 Support: no
Boot into FW: supported
Current Boot Loader:
Product: n/a
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Boot loader sets ESP information
ESP: n/a
File: └─n/a
Random Seed:
Passed to OS: no
System Token: not set
Exists: no
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/055544ac-72ef-4ff9-a947-9248a96b7c39)
File: └─/EFI/BOOT/BOOTX64.EFI
Boot Loaders Listed in EFI Variables:
Title: AlmaLinux
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/055544ac-72ef-4ff9-a947-9248a96b7c39
File: └─/EFI/almalinux/shimx64.efi
Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/055544ac-72ef-4ff9-a947-9248a96b7c39)
0 entries, no entry could be determined as default.
Hi @carorodr,
Thanks a lot for all the help!
I just build a new version of testing AMI with enabled Secure Boot.
Testing Secure Boot AlmaLinux OS 9.3.20231114 x86_64: ami-0d80a9cd7ee31fd63
Using non-standard name for AMI to avoid to break users automation based on “AlmaLinux OS 9.*” regex match 
Here’s some bits from my testing environment and checklist: Checklist of AMI testing · GitHub
Please, let me know how it goes on your end too.
Unfortunately, the mode of the Secure Boot configured as part of the AMI. Which means you cannot disable it on enabled AMI or vice versa. (See: Launch an instance with UEFI Secure Boot support - Amazon Elastic Compute Cloud)
Thus, I haven’t decided which mode I to publish the final build of 8.9 and 9.3 AMIs yet. 
Awesome! Now I see secure-boot enabled.
[ec2-user@ip-172-31-8-102 ~]$ sudo bootctl
systemd-boot not installed in ESP.
System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: no
Boot into FW: supported
Current Boot Loader:
Product: n/a
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Boot loader sets ESP information
ESP: n/a
File: └─n/a
Random Seed:
Passed to OS: no
System Token: not set
Exists: no
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/01459c1b-2439-4d85-ba26-d9eb8103d0d0)
File: └─/EFI/BOOT/BOOTX64.EFI
Boot Loaders Listed in EFI Variables:
Title: AlmaLinux
ID: 0x0002
Status: active, boot-order
Partition: /dev/disk/by-partuuid/01459c1b-2439-4d85-ba26-d9eb8103d0d0
File: └─/EFI/almalinux/shimx64.efi
Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/01459c1b-2439-4d85-ba26-d9eb8103d0d0)
0 entries, no entry could be determined as default.
We are pushing everyone to use secure boot at Cisco. We also are changing the kernel specs to make more secure.
Unfortunately, We cannot publish Secure Boot enabled AMIs for users who build custom kernel and kernel modules. 
Currently, we are evaluating these options in AlmaLinux OS Foundation Chat .
- Single AMI as usual with disabled Secure Boot.
- Provide two AMIs; Secure Boot Enabled and Disabled.
For the first option, we can create a guide on our wiki how to create a secure boot enabled AMI with using the official AMIs as base.
The second options needs renaming of the AMIs in this fashion:
Current:
AlmaLinux OS 9.3.20231114 x86_64
New:
SecureBoot(Enabled|Disabled):
AlmaLinux_OS_9.3-20231114_x86_64_SecureBootEnabled
AlmaLinux_OS_9.3-20231114_x86_64_SecureBootDisabled
SB or none:
AlmaLinux_OS_9.3_20231114_x86_64_SB
AlmaLinux_OS_9.3_20231114_x86_64
SecureBoot or none:
AlmaLinux_OS_9.3_20231114_x86_64_SecureBoot
AlmaLinux_OS_9.3_20231114_x86_64
Or you tell me…
Each option has own advantage and disadvantages; The first option’s advantage is the name changing is not needed so the users doesn’t need to update regexes in their pipelines (AlmaLinux OS 9.*). But users like you need to maintain the creation of the Secure Boot enabled version of the AMI.
The second second option’s advantage is everyone directly gets Secure Boot or non Secure Boot AMIs.
But We need to differentiate them by the name. So, change the naming.
We were not expecting you to publish AMIs based on our kernel modifications so all good here. Feedback on naming from our team:
This makes sense:
SB or none:
- AlmaLinux_OS_9.3_20231114_x86_64_SB
- AlmaLinux_OS_9.3_20231114_x86_64
But adding the feature after the ‘OS’ makes a lot of sense to me. It will also make the regex more explicit: r’AlmaLinux_OS(_SB)?9.3(\d{8})_x86_64’ because I could see them matching on the len and accidentally picking up the SB if it were placed on the end.
SB or none:
- AlmaLinux_OS_SB_9.3_20231114_x86_64
- AlmaLinux_OS_9.3_20231114_x86_64
I am trying to find an image with UEFI without secure boot. Do you have any that I can try?