On 4/6/22 12:57, Neal Gompa wrote: (trimming)
* NVIDIA graphics * Broadcom wireless The former case is excessively common, and the latter case is fairly common with HP and Dell machines as well as some smaller OEMs. I literally helped someone this past week with both[1][2][3]. The Workstation WG has been tracking both issues for years now[4][5]. This situation is *worse* now because we have Fedora Linux preloaded on computers, and OEMs basically have to disable Secure Boot to make things "work". How's that for improving security?
I too have been a bit surprised at some of the difficulties of hibernate/secure boot on recent fedora releases. It seems people are entirely unaware that ACPI/S3 standby is gone from most consumer laptops, and the modern standby replacement implementations tend to work very poorly WRT conserving battery with the lid closed in Linux.
Leaving hibernate as the only workable solution if you want to just close the laptop lid, and come back the next day without having the machine at 0% battery. This is the expected/default windows behavior too. After ~5% IIRC battery loss in modern standby mode, it hibernates. (look up windows adaptive hibernate).
So, on a recent fedora machine, it took me more than 4 hours to get a hibernation file on btrfs plus LUKS encrypted partition working. The documentation for that wasn't to be found anywhere on the fedora/RH sites and required compiling a tool to do the block offset calculations and manually adding the resume_offset options to grub/etc. All while avoiding the mass of incorrect information found on the internet. And of course it also requires disabling swap on zram (which was nonsense on the machine anyway, given the disks are faster than it can compress/decompress pages).
And of course the lockdown patches in the kernel still aren't smart enough to be able to detect that the swapfile is actually encrypted, so it also requires disabling secure boot (this IMHO is frankly unacceptable, that one can't have both options enabled at the same time).
So, this is really less about BIOS/EFI and more about some pretty basic functionality being broken in the distro.
On the cloud side, it's been very difficult to articulate any benefits for supporting UEFI when the majority of the consumers of Fedora Cloud don't have any pressing need to do it and things like hibernation and snapshotting are non-functional. Last year, I changed Fedora Cloud to hybrid boot[6] so that our image artifacts support both boot modes. While GCP requires UEFI and Azure prefers it, AWS has very basic support for UEFI and using UEFI causes you to lose some features that exist only in BIOS mode. One of those is leveraging hibernation in the cloud for spot instances[7]. Moving past the Big Three(tm), the actual cloud providers that matter from a Fedora context are the smaller outfits that principally serve Linux users. These are companies like DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who graciously do offer Fedora Linux in their platforms. All of their virtualization platforms are BIOS only right now, and getting them to switch requires them to uplift their platforms to support UEFI in the first place. And again, when UEFI means things like VM snapshots and cloud hibernation don't work, it's not very compelling. You'd think that given how important this is for the Cloud that it would have mattered for RHEL, but nope. These problems are not new. They've existed since we supported UEFI Secure Boot, and given how people have responded saying these issues are irrelevant to this Change, it shows how out of sync with reality this Change is.
Frankly, I'm extremely frustrated and exhausted over the situation. [1]: https://twitter.com/Det_Conan_Kudo/status/1508968025785049088 [2]: https://twitter.com/Det_Conan_Kudo/status/1508984123339202560 [3]: https://twitter.com/Det_Conan_Kudo/status/1511755879687012354 [4]: https://pagure.io/fedora-workstation/issue/155 [5]: https://pagure.io/fedora-workstation/issue/116 [6]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot [7]: https://lwn.net/Articles/821158/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
_______________________________________________ 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
