In last week's Cloud WG meeting, we discussed that with the implementation of #309 with Fedora Linux 35 Cloud Edition images, we can start moving forward with deprecating BIOS boot for the Cloud Edition. @pjones noted in that discussion that BIOS support is effectively at this point already, just not formally declared.
Additionally, a couple of other factors in the market have made this more palatable now than it was before: AWS now supports UEFI for x86_64 VMs, which means all major cloud providers either offer it or require it. We already offered UEFI for Google Cloud images, and we need UEFI for future Azure images. Microsoft Windows 11 will require UEFI with Secure Boot support, which effectively kills all legacy BIOS boot platforms going forward.
UEFI is already used for AArch64 images, and ARMv7 images boot with UEFI(-ish) powered by U-Boot.
The idea is to announce the deprecation of BIOS boot support with either F36 or F37, after we've communicated with all the different stakeholders and gotten things in place for the transition of defaults to be seamless.
Metadata Update from @ngompa: - Issue assigned to ngompa
As a first step, I've filed BZs for the Fedora virt tools to consider preferring UEFI:
virt-manager
cockpit-machines
gnome-boxes
Additionally, I've cloned relevant bugs to RHEL 9:
I've also filed bugs against Red Hat layered virtualization products:
I've filed feature requests for openSUSE Leap to make these changes:
Metadata Update from @davdunc: - Issue tagged with: meeting
discussed in today's cloud meeting. We need a blog if there are a lot of users who want to maintain classic boot, then we are already set to support them. There is no reason to leave anyone behind.
okay. I think I'll add that as the next step in the ticket. I'll keep the meeting flag and next meeting, when we have more attendees, I'll look for an author or co-author for the blog post.
Metadata Update from @davdunc: - Issue untagged with: meeting
Metadata Update from @ngompa: - Issue tagged with: OCI
Looks like @trawets and @davdunc are taking the next step to make our AWS images uefi-preferred for F39: https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred
uefi-preferred
Our GCP and Azure images are UEFI only already.
Not all EC2 Instance Types currently support UEFI, and I wouldn't take the assumption that they all will at some point in the near future.
To quote https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launch-instance-boot-mode.html#UEFI-supported-types as of the time of writing:
Intel and AMD instance types that support UEFI, in addition to Legacy BIOS: - All instances built on the AWS Nitro System, except: bare metal instances, DL1, G4ad, P4, u-3tb1, u-6tb1, u-9tb1, u-12tb1, and VT1
Which at least currently translates to (in us-east-1) to:
us-east-1
aws --region us-east-1 ec2 describe-instance-types --query "InstanceTypes[*].[InstanceType]" --output text | sort > /tmp/all-instance-types aws --region us-east-1 ec2 describe-instance-types --filters Name=supported-boot-mode,Values=uefi --query "InstanceTypes[*].[InstanceType]" --output text | sort > /tmp/uefi-instance-types diff -u /tmp/all-instance-types /tmp/uefi-instance-types |grep '^-'| sed -e 's/^-/* /'
It's 488 supporting it out of 634 total.
The following instance types do not support UEFI in us-east-1:
Most notable currently are the .metal instance types being the stand outs in the broader family that don't support UEFI currently.
.metal
Log in to comment on this ticket.