Ben Cotton <bcotton@xxxxxxxxxx> writes: > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > == Summary == > Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). Legacy BIOS support is not > removed, but new non-UEFI installation is not supported on those > platforms. This is a first step toward eventually removing legacy > BIOS support entirely. I want to add a few thoughts both from an EC2 perspective, and an Amazon Linux as a downstream of Fedora perspective. Currently, nearly all EC2 instance types will boot by default with legacy-bios. All aarch64 instances are UEFI, and I'd find it unlikely that any new x86-64 instance type would not also support UEFI. But the default for all existing Intel and AMD instance types is legacy-bios. This is largely to preserve backwards compatibility, and at least for existing instance types, I cannot forsee this ever changing. You just don't want to needlessly break customers. Relatively recently, UEFI started becoming an option for some non-aarch64 instance types, and can be selected either at instance launch time, or configured to be part of the AMI. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html There are however a *lot* of instance types, a whole bunch of which are less likely to support UEFI - the documentation gives t2.xlarge as an example of one that only supports legacy-bios. AMIs that don't run on all instance types tend to cause confusion, no matter how clear you document the limitations. It's only now that this is something that's even emerging as something that the EC2 APIs would assist in enforcing. In fact, in Amazon Linux 2022 we went for the decision that for aarch64 we'd require Graviton 2 and x86-64v2 as minimal requirements, and having AL2022 AMIs not boot on a1 instances types did surprise some people, even though we documented it. With things like spot instances, there's a lot of customer demand for "the cheapest possible compute, doesn't matter what or where" to run things that aren't time critical. Now, the interesting thing about Cloud images is that there isn't an installer. In fact, Amazon Linux doesn't have one and we don't package Anaconda anywhere. All users come from a disk image, which we create using separate tooling. Thus, from an AL perspective, if Anaconda were to stop supporting installing for legacy-bios, this wouldn't affect us at all. However, we would have a big interest in having legacy-bios work well to boot the OS, likely for a decent number of years to come (however much I wish this wasn't the case). I guess the interesting balance here is maintenance responsibility as well. I *very* much don't want any of this to read like a request for the community to maintain something that's primarily useful only to a specific vendor. There's a point where if it's functionality that's needed by a vendor, then said vendor has to maintain it, or be very involved in maintaining it. (and for non-EC2 and non-Amazon-Linux input, I have at least one machine at home that run Fedora that don't have UEFI, a HP Microserver of a certain age. Now, maybe it's time for me to upgrade that hardware, but I bet there's a lot of folk who either don't want to do that, or cannot reasonably afford to) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
