Fedora-Rawhide-20220405.n.2 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 12/231 (x86_64), 15/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220404.n.0): ID: 1212517 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1212517 ID: 1212518 Test: x86_64 Server-dvd-iso install_blivet_standard_partition_ext4 URL: https://openqa.fedoraproject.org/tests/1212518 ID: 1212555 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home URL: https://openqa.fedoraproject.org/tests/1212555 ID: 1212580 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1212580 ID: 1212582 Test: x86_64 Workstation-live-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1212582 ID: 1212596 Test: x86_64 Workstation-live-iso desktop_printing_builtin URL: https://openqa.fedoraproject.org/tests/1212596 ID: 1212628 Test: x86_64 Silverblue-dvd_ostree-iso base_selinux URL: https://openqa.fedoraproject.org/tests/1212628 ID: 1212641 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1212641 ID: 1212686 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1212686 ID: 1212704 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1212704 ID: 1212705 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1212705 ID: 1212876 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/1212876 ID: 1212907 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1212907 Old failures (same test failed in Fedora-Rawhide-20220404.n.0): ID: 1212620 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1212620 ID: 1212682 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi URL: https://openqa.fedoraproject.org/tests/1212682 ID: 1212702 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1212702 ID: 1212754 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1212754 ID: 1212759 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1212759 ID: 1212767 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1212767 ID: 1212769 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1212769 ID: 1212773 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1212773 ID: 1212775 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1212775 ID: 1212839 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1212839 ID: 1212898 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1212898 ID: 1212910 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1212910 ID: 1212911 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1212911 ID: 1212913 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1212913 Soft failed openQA tests: 12/231 (x86_64), 4/161 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20220404.n.0): ID: 1212585 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1212585 ID: 1212589 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1212589 ID: 1212600 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1212600 ID: 1212617 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1212617 Old soft failures (same test soft failed in Fedora-Rawhide-20220404.n.0): ID: 1212610 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1212610 ID: 1212627 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1212627 ID: 1212632 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1212632 ID: 1212634 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1212634 ID: 1212635
Re: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
hi, could someone kindly tell me if my toshiba l750 machine has EFI support? i'm blind and efi/bios screens are in accessible. Majid > Sent: Wednesday, April 06, 2022 at 6:03 am > From: "Gary Buhrmaster" > To: "Development discussions related to Fedora" > > Subject: Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal) > > On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour > wrote: > > > > On 4/5/22 19:38, Chris Murphy wrote: > > > We either want users with NVIDIA hardware to be inside the Secure Boot > > > fold or we don't. I want them in the fold *despite* the driver that > > > needs signing is proprietary. That's a better user experience across > > > the board, including the security messaging is made consistent. The > > > existing policy serves no good at all and is double talk. If we really > > > care about security more than ideological worry, we'd sign the driver. > > > > I agree with this. Sign the driver. > > Nvidia has their driver signed for their > Windows drivers. That they choose > not to do so for Linux is their right, > even if some wish they did. > > It should be noted that while many > might wish nvidia chose a different > way, that is completely orthogonal > to bios vs uefi. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour wrote: > > On 4/5/22 19:38, Chris Murphy wrote: > > We either want users with NVIDIA hardware to be inside the Secure Boot > > fold or we don't. I want them in the fold *despite* the driver that > > needs signing is proprietary. That's a better user experience across > > the board, including the security messaging is made consistent. The > > existing policy serves no good at all and is double talk. If we really > > care about security more than ideological worry, we'd sign the driver. > > I agree with this. Sign the driver. Nvidia has their driver signed for their Windows drivers. That they choose not to do so for Linux is their right, even if some wish they did. It should be noted that while many might wish nvidia chose a different way, that is completely orthogonal to bios vs uefi. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Move existing build into side tag?
On Tue, Apr 5, 2022 at 10:04 PM Neal Gompa wrote: > On Tue, Apr 5, 2022 at 11:01 PM Richard Shaw wrote: > > > > Google has failed me, how do I go about moving an existing build into a > side tag I just created? > > > > koji tag-build > Thanks, there's so many options in koji I wasn't sure which was the right one. Thanks, RIchard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Move existing build into side tag?
On Tue, Apr 5, 2022 at 11:01 PM Richard Shaw wrote: > > Google has failed me, how do I go about moving an existing build into a side > tag I just created? > koji tag-build -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Move existing build into side tag?
Google has failed me, how do I go about moving an existing build into a side tag I just created? Thanks, RIchard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20220405.n.2 changes
OLD: Fedora-Rawhide-20220404.n.0 NEW: Fedora-Rawhide-20220405.n.2 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 14 Dropped packages:1 Upgraded packages: 150 Downgraded packages: 0 Size of added packages: 4.51 MiB Size of dropped packages:7.27 MiB Size of upgraded packages: 8.22 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -136.96 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220405.n.2.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: SDL2_sound-2.0.1-1.fc37 Summary: An abstract soundfile decoder library RPMs:SDL2_sound SDL2_sound-devel Size:1.57 MiB Package: rust-bytes-cast-0.2.0-1.fc37 Summary: Safely re-interpreting &[u8] bytes as custom structs without copying, for efficiently reading structured binary data RPMs:rust-bytes-cast+default-devel rust-bytes-cast-devel Size:25.49 KiB Package: rust-bytes-cast-derive-0.1.1-1.fc37 Summary: Safely re-interpreting &[u8] bytes as custom structs without copying, for efficiently reading structured binary data RPMs:rust-bytes-cast-derive+default-devel rust-bytes-cast-derive-devel Size:22.41 KiB Package: rust-format-bytes-0.3.0-1.fc37 Summary: Macro to format bytestrings RPMs:rust-format-bytes+default-devel rust-format-bytes-devel Size:24.00 KiB Package: rust-format-bytes-macros-0.4.0-1.fc37 Summary: Macros for the format-bytes crate RPMs:rust-format-bytes-macros+default-devel rust-format-bytes-macros-devel Size:18.90 KiB Package: rust-is_ci-1.1.1-1.fc37 Summary: Super lightweight CI environment checker RPMs:rust-is_ci+default-devel rust-is_ci-devel Size:19.11 KiB Package: rust-micro-timer-0.4.0-1.fc37 Summary: Dumb tiny logging timer RPMs:rust-micro-timer+default-devel rust-micro-timer-devel Size:19.11 KiB Package: rust-micro-timer-macros-0.4.0-1.fc37 Summary: Macros for the micro-timer crate RPMs:rust-micro-timer-macros+default-devel rust-micro-timer-macros-devel Size:18.34 KiB Package: rust-owo-colors-3.3.0-1.fc37 Summary: Zero-allocation terminal colors that'll make people go owo RPMs:rust-owo-colors+default-devel rust-owo-colors+supports-color-devel rust-owo-colors+supports-colors-devel rust-owo-colors-devel Size:53.70 KiB Package: rust-supports-color-1.3.0-1.fc37 Summary: Detects whether a terminal supports color, and gives details about that support RPMs:rust-supports-color+default-devel rust-supports-color-devel Size:24.30 KiB Package: rust-supports-hyperlinks-1.2.0-1.fc37 Summary: Detects whether a terminal supports rendering hyperlinks RPMs:rust-supports-hyperlinks+default-devel rust-supports-hyperlinks-devel Size:22.51 KiB Package: rust-supports-unicode-1.0.2-1.fc37 Summary: Detects whether a terminal supports unicode RPMs:rust-supports-unicode+default-devel rust-supports-unicode-devel Size:22.13 KiB Package: rust-twox-hash-1.6.2-1.fc37 Summary: Rust implementation of the XXHash and XXH3 algorithms RPMs:rust-twox-hash+default-devel rust-twox-hash+digest_0_10-devel rust-twox-hash+digest_0_9-devel rust-twox-hash+rand-devel rust-twox-hash+serde-devel rust-twox-hash+serialize-devel rust-twox-hash+std-devel rust-twox-hash-devel twox-hash Size:775.54 KiB Package: rust-vcsgraph-0.2.0-1.fc37 Summary: Library to perform various computation of a version control graph RPMs:rust-vcsgraph+cli-devel rust-vcsgraph+default-devel rust-vcsgraph+structopt-devel rust-vcsgraph-devel vcsgraph Size:1.92 MiB = DROPPED PACKAGES = Package: golang-github-jamesclonk-vultr-2.0.3-3.fc36 Summary: Vultr CLI and API client library RPMs:golang-github-jamesclonk-vultr golang-github-jamesclonk-vultr-devel Size:7.27 MiB = UPGRADED PACKAGES = Package: OpenImageIO-2.3.14.0-1.fc37 Old package: OpenImageIO-2.3.13.0-1.fc37 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 21.51 MiB Size change: 42.46 KiB Changelog: * Mon Apr 04 2022 Richard Shaw - 2.3.14.0-1 - Update to 2.3.14.0. Package: annobin-10.62-1.fc37 Old package: annobin-10.59-2.fc37 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 4.67 MiB Size change: 15.41 KiB Changelog: * Thu Mar 31 2022 Timm B??der redhat.com> - 10.60-1 - Add support for building using meson+ninja. * Sat Apr 02 2022 Nick Clifton - 10.61-1 - gcc-plugin: Add remap of OPT_Wall. - configure: Fix typo in top level configure.ac. * Tue Apr 05 2022 Nick Clifton - 10.62-1 - llvm-plugin: Fix a thinko in the sources. Package: appres-1.0.6-1.fc37 Old package: appres-1.0.5-4.fc36 Summary:
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 9:07 PM Demi Marie Obenour wrote: > > On 4/5/22 16:09, Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson wrote: > >> > >> On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: > >> > >>> We also lack solutions for dealing with the NVIDIA driver in > >>> UEFI+Secure Boot case. Are you planning to actually *fix* that now? > >>> Because we still don't have a way to have kernel-only keyrings for > >>> secure boot certificates to avoid importing them into the firmware. > >> > >> Couple of thoughts, here: > >> > >> 1 - This is a non sequitur to the question of removing BIOS support, > >> because Secure Boot is not a BIOS feature, so nobody relying on Secure > >> Boot today would stand to lose anything. > >> > >> 2 - How is this our problem to solve? NVIDIA are the ones with the > >> private source code. > >> > > > > It's our problem because the problem isn't specific to NVIDIA, it's > > specific to how people compile and load kernel modules of their own. > > We should not require loading keys into firmware for user built kernel > > modules. An OS-level module should be trustable at the OS kernel > > level. > > > > Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel > > -> user cert -> user kmod. > > > >> 3 - Your complaint describes solution: import NVIDIA's signing key > >> into your firmware. If you want both Secure Boot and nvidia.ko so > >> badly, then you as the consumer need to tell your platform to trust > >> what NVIDIA signs. If that's a burden, again, see point 2 about who > >> exactly is making your life hard here. Remedies there might include > >> some UI streamlining around mokutil, or getting nvidia and nouveau to > >> use the same (open) kernel driver so the question just goes away. > >> > > > > This problem also makes life miserable for people working with third > > party open source kernel modules too. As a live streamer, for example, > > I need to use v4l2loopback, which will never exist in mainline because > > v4l2 maintainers don't like it at all. > > Are you sure about that? There is probably a better place to talk > about this, but Qubes OS also will be needing v4l2loopback soon (for > Qubes Video Companion) and so I have a strong interest in getting it > upstreamed. > Yes. Last I heard, V4L2 folks think it'd be used to bypass making a real camera driver for the kernel. That's pretty much why it's not there. You may be able to accomplish a good portion of it with PipeWire's camera API, but you'll probably want to ask in the PipeWire Matrix room about that: https://matrix.to/#/#pipewire:matrix.org > > Broad non-Mac hardware only became available after Windows 8 / Windows > > Server 2012 R2. Yes, some hardware existed a few years before, but it > > was not broadly available before 2013. We didn't discontinue i686 in > > Fedora until Fedora Linux 31, which was over 15 years after the first > > x86_64 system. The user experience with x86_64 was immeasurably better > > than i686 at that point in time. > > > > We do not have a better experience with UEFI *right now*. I know of > > plenty of people intentionally choosing BIOS because the user > > experience is better, even though it's older/bad technology. Because > > using BIOS means kmods work. Because using BIOS means hibernate works. > > Because using BIOS means they can get an equivalent experience > > leveraging their hardware that they can get on Windows today with > > UEFI. Maybe none of you proposing this Change use these things, but > > I'm telling you these things matter. > > And this ignores the case of virtualized systems, where the EFI System > Partition is purely wasted space. > The partition can be fairly small if it just contains EFI blobs, but I think we give a fairly large one by default. > > And the amount of resistance to improving UEFI experience for hardware > > is amazingly awful. The workstation working group has tried to figure > > out ways to improve the experience, only to be simultaneously stymied > > by the UEFI firmware management tools and unwillingness by anyone > > involved to even consider that we should make this better. > > > > I will *not* force people to deal with importing keys into firmware. > > It's brittle, buggy, and often completely broken on motherboards. Many > > of those UEFI implementations are extremely buggy and terrible. I've > > dealt with a lot of it as part of my job over the years and it leads > > to a terrible user experience for Linux users. > > And even if it worked great on all platforms, **users should not need > to do it**. > > Because let’s face it: If you have unrestricted root access, getting > kernel access is almost certainly going to be possible. If nothing > else, just boot into Windows and take advantage of any one of the admin > ⇒ kernel privilege escalations known on that platform. For secure > boot to actually be more than security theater, it needs to disallow > insecure OSs (such as Windows) from booting.
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> On 4/5/22 19:38, Chris Murphy wrote: > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > > indicate Apple and Microsoft trust the driver itself. It is trusting > > the providence of the blob, in order to achieve an overall safer > > ecosystem for their users. s/providence/provenance/ I'd like to blame this on autocorrect... -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 16:09, Neal Gompa wrote: > On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson wrote: >> >> On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: >> >>> We also lack solutions for dealing with the NVIDIA driver in >>> UEFI+Secure Boot case. Are you planning to actually *fix* that now? >>> Because we still don't have a way to have kernel-only keyrings for >>> secure boot certificates to avoid importing them into the firmware. >> >> Couple of thoughts, here: >> >> 1 - This is a non sequitur to the question of removing BIOS support, >> because Secure Boot is not a BIOS feature, so nobody relying on Secure >> Boot today would stand to lose anything. >> >> 2 - How is this our problem to solve? NVIDIA are the ones with the >> private source code. >> > > It's our problem because the problem isn't specific to NVIDIA, it's > specific to how people compile and load kernel modules of their own. > We should not require loading keys into firmware for user built kernel > modules. An OS-level module should be trustable at the OS kernel > level. > > Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel > -> user cert -> user kmod. > >> 3 - Your complaint describes solution: import NVIDIA's signing key >> into your firmware. If you want both Secure Boot and nvidia.ko so >> badly, then you as the consumer need to tell your platform to trust >> what NVIDIA signs. If that's a burden, again, see point 2 about who >> exactly is making your life hard here. Remedies there might include >> some UI streamlining around mokutil, or getting nvidia and nouveau to >> use the same (open) kernel driver so the question just goes away. >> > > This problem also makes life miserable for people working with third > party open source kernel modules too. As a live streamer, for example, > I need to use v4l2loopback, which will never exist in mainline because > v4l2 maintainers don't like it at all. Are you sure about that? There is probably a better place to talk about this, but Qubes OS also will be needing v4l2loopback soon (for Qubes Video Companion) and so I have a strong interest in getting it upstreamed. > Broad non-Mac hardware only became available after Windows 8 / Windows > Server 2012 R2. Yes, some hardware existed a few years before, but it > was not broadly available before 2013. We didn't discontinue i686 in > Fedora until Fedora Linux 31, which was over 15 years after the first > x86_64 system. The user experience with x86_64 was immeasurably better > than i686 at that point in time. > > We do not have a better experience with UEFI *right now*. I know of > plenty of people intentionally choosing BIOS because the user > experience is better, even though it's older/bad technology. Because > using BIOS means kmods work. Because using BIOS means hibernate works. > Because using BIOS means they can get an equivalent experience > leveraging their hardware that they can get on Windows today with > UEFI. Maybe none of you proposing this Change use these things, but > I'm telling you these things matter. And this ignores the case of virtualized systems, where the EFI System Partition is purely wasted space. > And the amount of resistance to improving UEFI experience for hardware > is amazingly awful. The workstation working group has tried to figure > out ways to improve the experience, only to be simultaneously stymied > by the UEFI firmware management tools and unwillingness by anyone > involved to even consider that we should make this better. > > I will *not* force people to deal with importing keys into firmware. > It's brittle, buggy, and often completely broken on motherboards. Many > of those UEFI implementations are extremely buggy and terrible. I've > dealt with a lot of it as part of my job over the years and it leads > to a terrible user experience for Linux users. And even if it worked great on all platforms, **users should not need to do it**. Because let’s face it: If you have unrestricted root access, getting kernel access is almost certainly going to be possible. If nothing else, just boot into Windows and take advantage of any one of the admin ⇒ kernel privilege escalations known on that platform. For secure boot to actually be more than security theater, it needs to disallow insecure OSs (such as Windows) from booting. Secure boot on Android does that. Secure boot on PCs does not, at least with the default list of trusted bootloaders. Qubes OS (which has security as its very reason for existing) does *not* use secure boot right now, and while support for secure boot would be nice, it is *not* the top priority right now. Measured boot, combined with disk encryption keys tied to these measurements, provides much more security in practice. If the attacker is at the point where they can tamper with the bootloader of a running system with the disks unlocked, they have already won. If this is an offline attack, measured boot is a much more effective mitigation. > If you are making UEFI the
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 8:59 PM Demi Marie Obenour wrote: > > On 4/5/22 19:38, Chris Murphy wrote: > > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez wrote: > > > >> The security of UEFI systems is immeasurably better. Standardized firmware > >> updates, support for modern secure TPMs, OS protection from firmware (SMM > >> mitigations), HTTP(S) boot support, largely shared and open sourced > >> firmware codebases that aren't a pile of assembly code, and a lot of other > >> features are UEFI-only. > > > > When users have a suboptimal experience by default, it makes Fedora > > look bad. We can't have security concerns overriding all other > > concerns. But it's really pernicious to simultaneously say security is > > important, but we're also not going to sign proprietary drivers. This > > highly incentivizes the user to disable Secure Boot because that's so > > much easier than users signing kernel modules and enrolling keys with > > the firmware, and therefore makes the user *less safe*. > > > > > >>> And the amount of resistance to improving UEFI experience for hardware > >>> is amazingly awful. The workstation working group has tried to figure > >>> out ways to improve the experience, only to be simultaneously stymied > >>> by the UEFI firmware management tools and unwillingness by anyone > >>> involved to even consider that we should make this better. > >> > >> > >> Which tools? What specific efforts have been stymied? How is any of this > >> specific to UEFI versus trying to deal with things that aren't supported > >> by someone? > > > > Namely, Fedora signing NVIDIA's proprietary driver. > > > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > > indicate Apple and Microsoft trust the driver itself. It is trusting > > the providence of the blob, in order to achieve an overall safer > > ecosystem for their users. > > > > We either want users with NVIDIA hardware to be inside the Secure Boot > > fold or we don't. I want them in the fold *despite* the driver that > > needs signing is proprietary. That's a better user experience across > > the board, including the security messaging is made consistent. The > > existing policy serves no good at all and is double talk. If we really > > care about security more than ideological worry, we'd sign the driver. > > I agree with this. Sign the driver. > My preference would be to somehow get NVIDIA to offer GPU documentation and firmware blobs so nouveau could be further developed. But it seems like nobody is trying to get them to do that anymore, so I don't know what else we can do anymore. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 6:55 PM Jared Dominguez wrote: > > > > On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy wrote: >> >> On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: >> > 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. >> >> What is the distinction between "support is not removed" and "removing >> support entirely"? i.e. what are the additional steps for entirely >> removing support? And what's the approximate time frame for it? >> >> "Support is not removed" seems incongruent with "new installations are >> not supported." What continues to be supported? Will grub-pc still be >> built and updated? Will grub2-install still work on BIOS systems? >> >> >syslinux goes away entirely >> >> If the installation media used BIOS GRUB, syslinux could still go >> away. What consideration has occurred to switch from syslinux to BIOS >> GRUB for installation media? Is BIOS GRUB being deprecated? Or is it >> being discontinued in Fedora? >> >> If security vulnerabilities in BIOS GRUB are discovered, and >> grub2-install doesn't apply the most recently available fixes, I >> consider this an unsupported configuration. We can't say "support is >> not removed" while removing the ability to apply security fixes to the >> embedded bootloader. >> >> > * Some machines are BIOS-only. This change does not prevent their use >> > yet, but they are effectively deprecated. grub2 (our default >> > bootloader) is already capable of both BIOS and UEFI booting. >> >> This is inconsistent with the previous language "new non-UEFI >> installation is not supported". Clearly the change prevents their use >> if new clean installations on them aren't possible. >> >> >> > However, this modifies the baseline Fedora requirements and some >> > hardware will no longer be supported for new installations. >> >> This is removal of support. No mere deprecation. >> >> >> > Installs will continue to work on UEFI, and will not work on Legacy >> > BIOS. >> >> Again, removal of support. The change does prevent their use for new >> clean installations. > > > A less phased approach was considered when we were working on the change > proposal and would actually be more desirable from a development point of > view, but a more generous approach seemed more palatable since it'd give > people more time to handle transition. This generosity doesn't answer any of the questions I've asked, or address the inconsistent language I've noted. What is less phased in than what's being proposed? There are advocates of planned obsolescence of BIOS systems, with a soft landing, I'm one of them. But this is not anything like what I've imagined. It's not a plan, it's a notification. And it's a very hard landing, significant removal of support is actually in this proposal, not merely deprecation. It leaves essentially no time to plan alternatives. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 19:38, Chris Murphy wrote: > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez wrote: > >> The security of UEFI systems is immeasurably better. Standardized firmware >> updates, support for modern secure TPMs, OS protection from firmware (SMM >> mitigations), HTTP(S) boot support, largely shared and open sourced firmware >> codebases that aren't a pile of assembly code, and a lot of other features >> are UEFI-only. > > When users have a suboptimal experience by default, it makes Fedora > look bad. We can't have security concerns overriding all other > concerns. But it's really pernicious to simultaneously say security is > important, but we're also not going to sign proprietary drivers. This > highly incentivizes the user to disable Secure Boot because that's so > much easier than users signing kernel modules and enrolling keys with > the firmware, and therefore makes the user *less safe*. > > >>> And the amount of resistance to improving UEFI experience for hardware >>> is amazingly awful. The workstation working group has tried to figure >>> out ways to improve the experience, only to be simultaneously stymied >>> by the UEFI firmware management tools and unwillingness by anyone >>> involved to even consider that we should make this better. >> >> >> Which tools? What specific efforts have been stymied? How is any of this >> specific to UEFI versus trying to deal with things that aren't supported by >> someone? > > Namely, Fedora signing NVIDIA's proprietary driver. > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > indicate Apple and Microsoft trust the driver itself. It is trusting > the providence of the blob, in order to achieve an overall safer > ecosystem for their users. > > We either want users with NVIDIA hardware to be inside the Secure Boot > fold or we don't. I want them in the fold *despite* the driver that > needs signing is proprietary. That's a better user experience across > the board, including the security messaging is made consistent. The > existing policy serves no good at all and is double talk. If we really > care about security more than ideological worry, we'd sign the driver. I agree with this. Sign the driver. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 8:51 PM Chris Murphy wrote: > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > > 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. > > What is the distinction between "support is not removed" and "removing > support entirely"? i.e. what are the additional steps for entirely > removing support? And what's the approximate time frame for it? > > "Support is not removed" seems incongruent with "new installations are > not supported." What continues to be supported? Will grub-pc still be > built and updated? Will grub2-install still work on BIOS systems? > > >syslinux goes away entirely > > If the installation media used BIOS GRUB, syslinux could still go > away. What consideration has occurred to switch from syslinux to BIOS > GRUB for installation media? Is BIOS GRUB being deprecated? Or is it > being discontinued in Fedora? > > If security vulnerabilities in BIOS GRUB are discovered, and > grub2-install doesn't apply the most recently available fixes, I > consider this an unsupported configuration. We can't say "support is > not removed" while removing the ability to apply security fixes to the > embedded bootloader. > > > * Some machines are BIOS-only. This change does not prevent their use > > yet, but they are effectively deprecated. grub2 (our default > > bootloader) is already capable of both BIOS and UEFI booting. > > This is inconsistent with the previous language "new non-UEFI > installation is not supported". Clearly the change prevents their use > if new clean installations on them aren't possible. > > > > However, this modifies the baseline Fedora requirements and some > > hardware will no longer be supported for new installations. > > This is removal of support. No mere deprecation. > > > > Installs will continue to work on UEFI, and will not work on Legacy > > BIOS. > > Again, removal of support. The change does prevent their use for new > clean installations. > A less phased approach was considered when we were working on the change proposal and would actually be more desirable from a development point of view, but a more generous approach seemed more palatable since it'd give people more time to handle transition. > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering If I am emailing outside of business hours (mine or yours), it is my choice and does not mean I expect you to respond today. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > 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. What is the distinction between "support is not removed" and "removing support entirely"? i.e. what are the additional steps for entirely removing support? And what's the approximate time frame for it? "Support is not removed" seems incongruent with "new installations are not supported." What continues to be supported? Will grub-pc still be built and updated? Will grub2-install still work on BIOS systems? >syslinux goes away entirely If the installation media used BIOS GRUB, syslinux could still go away. What consideration has occurred to switch from syslinux to BIOS GRUB for installation media? Is BIOS GRUB being deprecated? Or is it being discontinued in Fedora? If security vulnerabilities in BIOS GRUB are discovered, and grub2-install doesn't apply the most recently available fixes, I consider this an unsupported configuration. We can't say "support is not removed" while removing the ability to apply security fixes to the embedded bootloader. > * Some machines are BIOS-only. This change does not prevent their use > yet, but they are effectively deprecated. grub2 (our default > bootloader) is already capable of both BIOS and UEFI booting. This is inconsistent with the previous language "new non-UEFI installation is not supported". Clearly the change prevents their use if new clean installations on them aren't possible. > However, this modifies the baseline Fedora requirements and some > hardware will no longer be supported for new installations. This is removal of support. No mere deprecation. > Installs will continue to work on UEFI, and will not work on Legacy > BIOS. Again, removal of support. The change does prevent their use for new clean installations. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 7:39 PM Chris Murphy wrote: > On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez wrote: > > > The security of UEFI systems is immeasurably better. Standardized > firmware updates, support for modern secure TPMs, OS protection from > firmware (SMM mitigations), HTTP(S) boot support, largely shared and open > sourced firmware codebases that aren't a pile of assembly code, and a lot > of other features are UEFI-only. > > When users have a suboptimal experience by default, it makes Fedora > look bad. We can't have security concerns overriding all other > concerns. But it's really pernicious to simultaneously say security is > important, but we're also not going to sign proprietary drivers. This > highly incentivizes the user to disable Secure Boot because that's so > much easier than users signing kernel modules and enrolling keys with > the firmware, and therefore makes the user *less safe*. > Understandable concern. Secure Boot is still a different topic from UEFI (and many of the features provided by UEFI, including those impacting security), and UEFI can be utilized even without Secure Boot. Nonetheless, several folks have been exploring options to be able to support Nvidia's driver in Fedora. > >> And the amount of resistance to improving UEFI experience for hardware > >> is amazingly awful. The workstation working group has tried to figure > >> out ways to improve the experience, only to be simultaneously stymied > >> by the UEFI firmware management tools and unwillingness by anyone > >> involved to even consider that we should make this better. > > > > > > Which tools? What specific efforts have been stymied? How is any of this > specific to UEFI versus trying to deal with things that aren't supported by > someone? > > Namely, Fedora signing NVIDIA's proprietary driver. > > Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all > indicate Apple and Microsoft trust the driver itself. It is trusting > the providence of the blob, in order to achieve an overall safer > ecosystem for their users. > Apple and Microsoft are held to different license terms in their operating systems than we are. > We either want users with NVIDIA hardware to be inside the Secure Boot > fold or we don't. I want them in the fold *despite* the driver that > needs signing is proprietary. That's a better user experience across > the board, including the security messaging is made consistent. The > existing policy serves no good at all and is double talk. If we really > care about security more than ideological worry, we'd sign the driver. > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Jared Dominguez (he/him) Software Engineering Manager New Platform Technologies Enablement team RHEL Workstation Engineering ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Those figures are recommended minimums, not requirements. I have a single core F35 machine which works fine. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:08 PM Jared Dominguez wrote: > The security of UEFI systems is immeasurably better. Standardized firmware > updates, support for modern secure TPMs, OS protection from firmware (SMM > mitigations), HTTP(S) boot support, largely shared and open sourced firmware > codebases that aren't a pile of assembly code, and a lot of other features > are UEFI-only. When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*. >> And the amount of resistance to improving UEFI experience for hardware >> is amazingly awful. The workstation working group has tried to figure >> out ways to improve the experience, only to be simultaneously stymied >> by the UEFI firmware management tools and unwillingness by anyone >> involved to even consider that we should make this better. > > > Which tools? What specific efforts have been stymied? How is any of this > specific to UEFI versus trying to deal with things that aren't supported by > someone? Namely, Fedora signing NVIDIA's proprietary driver. Apple and Microsoft signing NVIDIA's proprietary driver doesn't at all indicate Apple and Microsoft trust the driver itself. It is trusting the providence of the blob, in order to achieve an overall safer ecosystem for their users. We either want users with NVIDIA hardware to be inside the Secure Boot fold or we don't. I want them in the fold *despite* the driver that needs signing is proprietary. That's a better user experience across the board, including the security messaging is made consistent. The existing policy serves no good at all and is double talk. If we really care about security more than ideological worry, we'd sign the driver. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Hi On Tue, Apr 5, 2022 at 6:59 PM Kevin Kofler wrote: > > > Current owners plan to orphan some packages regardless of whether the > > proposal is accepted. > > And that is completely unacceptable blackmailing. > Blackmail is always conditional. Stating openly that someone is going to do something unconditionally is just disclosure. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Ben Cotton wrote: > 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. > > == Owner == > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > Konečný]], [[User:bcl| Brian C. Lane]] > * Email: rharw...@redhat.com Considering that this will desupport my notebook that runs Fedora just fine, and that I am not alone with this issue judging from the other comments, I am totally opposed to this change. > == Detailed Description == > UEFI is defined by a versioned standard that can be tested and > certified against. By contrast, every legacy BIOS is unique. Legacy > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > and on its way out. As it ages, maintainability has decreased, and > the status quo of maintaining both stacks in perpetuity is not viable > for those currently doing that work. I do not see what is there to maintain given that it is legacy technology that does not change anymore. > It is inevitable that legacy BIOS will be removed in a future release. Hence, I do not see the inevitability at all! > To ease this transition as best we can, there will be a period (of at > least one Fedora release) where it will be possible to boot using the > legacy BIOS codepaths, but new installations will not be possible. > While it would be easier for us to cut support off today, our hope is > that this compromise position will make for a smoother transition. > Additional support with issues during the transition would be > appreciated. As others have pointed out, that broken "compromise" means that corrupt installations, hard disk failures, etc. can no longer be recovered on those machines. So it does not solve the problem at all. And I disagree with the ultimate goal of the transition (complete desupport of legacy BIOS) to begin with. By the way, if you just drop support from Anaconda, that does not preclude installing Fedora on those systems using Calamares. > While this will eventually reduce workload for boot/installation > components (grub2 reduces surface area, syslinux goes away entirely, > anaconda reduces surface area), the reduction in support burden > extends much further into the stack - for instance, VESA support can > be removed from the distro. That (dropping VESA), too, will desupport a whole class of perfectly working hardware, though it should not affect me personally. > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > mandates that machines must have been made after 2006). My notebook has a 2.4 GHz Core 2 Duo T7700, so it fits that requirement. (But Fedora probably actually runs on even lower-powered machines. After all, the PinePhone, on which Fedora is known to run, has a 1.2 GHz aarch64 CPU (with 4 cores).) Still, the notebook does not support UEFI. > Like the already accepted Fedora 37 change to retire ARMv7 support, > the hardware targeted tends to be rather underpowered by today’s > standards, and the world has moved on from it. The difference is, Fedora on ARM has always been a niche thing, so dropping ARMv7 affects far fewer users than dropping support for some x86_64 machines. (Also note that the change was not about dropping a subset of aarch64 machines, only 32-bit was dropped, years after that happened for x86.) And also, performance-wise, my Core 2 Duo notebook is probably faster than most of those 32-bit ARMv7 devices. > Intel stopped shipping the last vestiges of BIOS support in 2020 (as have > other vendors, and Apple and Microsoft), so this is clearly the way things > are heading - and therefore aligns with Fedora’s “First” objective. "First" was never meant to be a synonym for planned obsolescence of hardware. It means being first to offer the latest and greatest software, nothing more. > * There is no way to deprecate hardware without causing some amount of > friction. Indeed. So do not do that then. > Current owners plan to orphan some packages regardless of whether the > proposal is accepted. And that is completely unacceptable blackmailing. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 15:58, Adam Jackson wrote: > On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton wrote: > >> While this will eventually reduce workload for boot/installation >> components (grub2 reduces surface area, syslinux goes away entirely, >> anaconda reduces surface area), the reduction in support burden >> extends much further into the stack - for instance, VESA support can >> be removed from the distro. > > I'm flattered, but I intend to drop vesa in F37 regardless of the > outcome of this particular change. The only supported way to get to > graphics with vesa is to use Xorg, and we sincerely want to be out of > the business of maintaining Xorg the hardware server. (We'll need an X > server forever, Xwayland isn't going away, don't misread me here.) Does that mean that F37 will only have an Xwayland package, not an Xorg package? And does it mean that XFCE support is being deprecated? Qubes OS relies on the latter. > And frankly at this point if you seriously want to use vesa it's > because you're trying to like reverse engineer some obscure card's > VBIOS, and if you're doing that you're probably building your own X > server anyway, I know I would be. Its use as an emergency driver on > physical GPUs is negligible, we have native drivers for virtually > everything made in the last 20 years. Its use as an emergency driver > in virtual machines is more statistically significant, maybe, but even > there we usually have a drm driver these days, and where we don't we > can probably club it into bochs_drm since that's the only rom anyone > bothers to use for that. Do we have DRM drivers for the UEFI framebuffer and the standard QEMU-emulated graphics? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: filesystems and year 2038
On Tue, Apr 5, 2022 at 8:50 AM Chris Adams wrote: > > Once upon a time, Colin Walters said: > > Ah but with a 512M disk I do get 256 bit inodes, I bet that's the > > difference. > > It comes from /etc/mke2fs.conf... kind of. Below 512M, mke2fs chooses > to use the "small" config from there, which includes the smaller > inode_size. The thresholds are hard-coded in mke2fs though. OK this explains what's going on. Anaconda doesn't do mkfs.ext4, it executes mke2fs, so the small fs_type values are probably being applied, rather than the ext4 fs_type. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: filesystems and year 2038
On Tue, Apr 5, 2022 at 8:27 AM Colin Walters wrote: > Or, maybe it's an Anaconda thing to override it? I don't think so (from Workstation edition installation) # grep mke2 /var/log/anaconda/storage.log INFO:program:Running... mke2fs -t ext4 /dev/vda2 INFO:program:b'mke2fs 1.46.5 (30-Dec-2021)' Pretty sure what you need is the extra_isize feature, which requires 256 byte inode size, which near as I can tell is the mkfs.ext4 default. When I change to a 300M loop device size, and reformat, I still get 256 inode_size, and extra_isize is also set. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:42 PM Gregory Bartholomew wrote: > > On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy wrote: >> >> On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew >> wrote: >> >> > I haven't done a "default" Fedora Server installation in a long time, so >> > I'm not sure how they are laid out. But I seem to remember /boot being a >> > separate partition for a long time (it used to be required because some >> > older BOISs couldn't read beyond a certain sector on the disk). Could not >> > /boot be converted to the ESP (i.e. reformatted with FAT32) on such >> > systems? >> >> No. It would need to be reformatted as FAT to be firmware readable. >> And thus this is an irreversible modification. There will be lengthy >> periods of time that are simply not crash safe. So the risk is >> probably unacceptably high that the user ends up abandoned on a >> deserted island, in which case it's better to just steer them toward >> the well understood and document process of reprovisioning (clean >> install time). Yes it's tedious, but it's well understood and very >> reliable, and that counts for more than convenience in QA terms. > > > I get where you are coming from. But I might have an idea about how at least > the "There will be lengthy > periods of time that are simply not crash safe" problem could be addressed. > > What if upgrades from BIOS to UEFI mode *had* to be done from an installation > DVD/Thumb drive? Doesn't matter, it still wouldn't be crash safe on its own. You'd have to design an upgrade utility that uses a journal such that any interruption can be resumed where it left off. Only that journal would know the actual state of the system at each step of the migration. That's a lot of work and pretty much out of scope. >Then there is a guaranteed way that the system can be booted (otherwise the >user would not have been able to initiate the automated upgrade). But without a journal it wouldn't be resumable or reversible. Since none of our installation media are writable out of the box, we'd also have to redesign one that does. > Additionally, the upgrade process could make a dd backup of the previous > /boot partition (and the 440-byte boot sector) before reformatting it. In the > worst-case scenario, the backup of the BIOS bootsector and partition could be > restored. Only if the upgrade utility is designed to do such a restoration, the current upgrade service knows nothing about that. This is non-trivial work. And users can just upgrade. How will they even know about migration or what the benefits are? There's insufficient incentive to do the migration, even if they were aware of it. I think it'd be a lot of effort for very few users. The problem is that BIOS systems cannot have new installations performed on them. This makes the proposal a removal of support, not a deprecation. Deprecation is an expression of disapproval, it shouldn't have a direct impact on users. It's notice that this will (soon) involve an impact on users. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 5:46 PM Richard Shaw wrote: > > On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel > wrote: == >> Is it actually true though? You need to be able to find some space >> for an EFI partition but assuming that can be done is there some >> other reason you can't migrate from BIOS to UEFI booting? > > > I actually did it manually several releases ago when I got a new computer > that supported EFI but kept the same OS drive. > > I'm not going to lie, it was VERY painful and took me a while to figure > everything out, a lot of googling and trying stuff. It wasn't for the faint > of heart. I did it a few years ago when I decided to (finally) convert a ~9 year old (at the time, ~11 year old now) PC from BIOS to (U)EFI (initially my belief was that Linux support for (U)EFI was not as mature as it is now, which is why I choose to stay in BIOS mode). However, I had thought ahead all those years ago, and partitioned using GPT and had reserved both a BIOS boot partition (which was suggested somewhere during that period) and a EFI system partition, so I did not have to deal with extensive re-partitioning steps. As I recall it was not all *that* hard[0], although I agree it was not at all well described (and because I was paranoid I had built (and tested) a USB emergency boot drive just in case, although I did not end up needing it (probably because I had it)). I will agree that there are enough edge cases that for all practical purposes one should likely recommend reinstall most of the time (after the two+ tested backups one should make, of course). btw, since the time I did so, a red behatted individual described the steps they used at https://www.redhat.com/sysadmin/bios-uefi which is clearly a proof by example it can be done. Sometimes. Gary [0] It is always possible that I have suppressed all the painful memories as a survival technique. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:51 PM Chris Murphy wrote: > On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew > wrote: > > > I haven't done a "default" Fedora Server installation in a long time, so > I'm not sure how they are laid out. But I seem to remember /boot being a > separate partition for a long time (it used to be required because some > older BOISs couldn't read beyond a certain sector on the disk). Could not > /boot be converted to the ESP (i.e. reformatted with FAT32) on such systems? > > No. It would need to be reformatted as FAT to be firmware readable. > And thus this is an irreversible modification. There will be lengthy > periods of time that are simply not crash safe. So the risk is > probably unacceptably high that the user ends up abandoned on a > deserted island, in which case it's better to just steer them toward > the well understood and document process of reprovisioning (clean > install time). Yes it's tedious, but it's well understood and very > reliable, and that counts for more than convenience in QA terms. > I get where you are coming from. But I might have an idea about how at least the "There will be lengthy periods of time that are simply not crash safe" problem could be addressed. What if upgrades from BIOS to UEFI mode *had* to be done from an installation DVD/Thumb drive? Then there is a guaranteed way that the system can be booted (otherwise the user would not have been able to initiate the automated upgrade). Additionally, the upgrade process could make a dd backup of the previous /boot partition (and the 440-byte boot sector) before reformatting it. In the worst-case scenario, the backup of the BIOS bootsector and partition could be restored. But another option the user could have if they so chose would be to leave the installation media connected to the computer such that it would provide the legacy boot chain if the UEFI upgrade didn't fully work for whatever reason. I'm guessing that if a user is willing to put up with running such old hardware that it doesn't support UEFI, they might also be OK with going *really* old-school and having to boot the system off an external media (e.g. leave the CD in the drive bay or leave the thumb drive plugged into the back of the machine for the remainder of its life)? Presumably the installation media could be configured to default to chain-loading the /boot/loader/entries file if one exists that is equal to or newer than the kernel of the installation disc? This is just an idea that I'm throwing out there. I'm not even sure how much I care for it myself. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: newRepo is slow today
On Fri, Apr 01, 2022 at 07:05:24PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 01, 2022 at 10:16:01AM -0700, Kevin Fenzi wrote: > > On Fri, Apr 01, 2022 at 06:10:03PM +0100, Richard W.M. Jones wrote: > > > On Fri, Apr 01, 2022 at 10:07:39AM -0700, Kevin Fenzi wrote: > > > > On Fri, Apr 01, 2022 at 05:54:52PM +0100, Richard W.M. Jones wrote: > > > > > > > > > > Been waiting a couple of hours I think. > > > > > > > > There's nothing in the queue waiting: > > > > > > > > https://koji.fedoraproject.org/kojira/queue > > > > > > > > What repo were you waiting for and what package? > > > > > > $ koji wait-repo f37-build > > > --build=systemtap-4.7~pre16468670g9f253544-2.fc37 > > > > > > Did I get the comment wrong? > > > > No, thats right, but the build is blocked by gating: > > > > "1 of 2 required tests failed, 1 result missing" > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-f6c14b3f13 > > .. in Rawhide? yes. In rawhide. > Also the install test is bogus. I already checked locally that the > built package installs. The test fails with some 404 errors: > > https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/installability-pipeline/job/master/63472/testReport/(root)/tests/_install/ > > Anyhow I waived the tests. Yeah, that looks like the koji bug we hit with some signed packages being a permission where they were not synced. ;( So, yeah, waiving was just fine in this case IMHO. (Or I suppose waiting until the next compose and rerunning the tests). kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 4:10 PM Neal Gompa wrote: > On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson wrote: > > > > On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: > > > > > We also lack solutions for dealing with the NVIDIA driver in > > > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > > > Because we still don't have a way to have kernel-only keyrings for > > > secure boot certificates to avoid importing them into the firmware. > > > > Couple of thoughts, here: > > > > 1 - This is a non sequitur to the question of removing BIOS support, > > because Secure Boot is not a BIOS feature, so nobody relying on Secure > > Boot today would stand to lose anything. > > > > 2 - How is this our problem to solve? NVIDIA are the ones with the > > private source code. > > > > It's our problem because the problem isn't specific to NVIDIA, it's > specific to how people compile and load kernel modules of their own. > We should not require loading keys into firmware for user built kernel > modules. An OS-level module should be trustable at the OS kernel > level. > > Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel > -> user cert -> user kmod. > > > 3 - Your complaint describes solution: import NVIDIA's signing key > > into your firmware. If you want both Secure Boot and nvidia.ko so > > badly, then you as the consumer need to tell your platform to trust > > what NVIDIA signs. If that's a burden, again, see point 2 about who > > exactly is making your life hard here. Remedies there might include > > some UI streamlining around mokutil, or getting nvidia and nouveau to > > use the same (open) kernel driver so the question just goes away. > > > > This problem also makes life miserable for people working with third > party open source kernel modules too. As a live streamer, for example, > I need to use v4l2loopback, which will never exist in mainline because > v4l2 maintainers don't like it at all. > > Broad non-Mac hardware only became available after Windows 8 / Windows > Server 2012 R2. Yes, some hardware existed a few years before, but it > was not broadly available before 2013. We didn't discontinue i686 in > Fedora until Fedora Linux 31, which was over 15 years after the first > x86_64 system. The user experience with x86_64 was immeasurably better > than i686 at that point in time. > The security of UEFI systems is immeasurably better. Standardized firmware updates, support for modern secure TPMs, OS protection from firmware (SMM mitigations), HTTP(S) boot support, largely shared and open sourced firmware codebases that aren't a pile of assembly code, and a lot of other features are UEFI-only. > We do not have a better experience with UEFI *right now*. I know of > plenty of people intentionally choosing BIOS because the user > experience is better, even though it's older/bad technology. Because > using BIOS means kmods work. Because using BIOS means hibernate works. > Because using BIOS means they can get an equivalent experience > leveraging their hardware that they can get on Windows today with > UEFI. Maybe none of you proposing this Change use these things, but > I'm telling you these things matter. > This is really vague, especially considering that the amount of official hardware support for Linux outside the top 3 OEMs is dicey anyway. Additionally, lots of vendors are treating legacy boot as unsupported (or "supported" but only for Linux, i.e. not really tested), so the same argument could be made the other way. > And the amount of resistance to improving UEFI experience for hardware > is amazingly awful. The workstation working group has tried to figure > out ways to improve the experience, only to be simultaneously stymied > by the UEFI firmware management tools and unwillingness by anyone > involved to even consider that we should make this better. > Which tools? What specific efforts have been stymied? How is any of this specific to UEFI versus trying to deal with things that aren't supported by someone? > I will *not* force people to deal with importing keys into firmware. > It's brittle, buggy, and often completely broken on motherboards. Many > of those UEFI implementations are extremely buggy and terrible. I've > dealt with a lot of it as part of my job over the years and it leads > to a terrible user experience for Linux users. > In general, all of the stuff about Secure Boot and signing is really tangential. This change proposal is about reducing maintenance burden because we already know that pretending to continue to support legacy x86 boot is problematic. As stated in the change proposal, "Community assistance is required to continue the status quo. Current owners plan to orphan some packages regardless of whether the proposal is accepted." By the way, VMware also deprecated legacy x86 boot support: https://kb.vmware.com/s/article/84233 > If you are making UEFI the only way people boot, ***fix*** the > experience. If you're not committed to that,
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 11:47 AM Gregory Bartholomew wrote: > > On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa wrote: >> >> Fedora Server users *must* fully reinstall, because there's no way to >> make space for an ESP and reconfigure things. > > > I haven't done a "default" Fedora Server installation in a long time, so I'm > not sure how they are laid out. But I seem to remember /boot being a separate > partition for a long time (it used to be required because some older BOISs > couldn't read beyond a certain sector on the disk). Could not /boot be > converted to the ESP (i.e. reformatted with FAT32) on such systems? No. It would need to be reformatted as FAT to be firmware readable. And thus this is an irreversible modification. There will be lengthy periods of time that are simply not crash safe. So the risk is probably unacceptably high that the user ends up abandoned on a deserted island, in which case it's better to just steer them toward the well understood and document process of reprovisioning (clean install time). Yes it's tedious, but it's well understood and very reliable, and that counts for more than convenience in QA terms. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 11:31 AM Tom Hughes via devel wrote: > > On 05/04/2022 15:52, Ben Cotton wrote: > > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > This is where I have a problem with this, the fact that there is > no upgrade path - virtually my entire installed base of Fedora is > running legacy BIOS and not being able to upgrade them will be > something of a headache. > > Is it actually true though? You need to be able to find some space > for an EFI partition but assuming that can be done is there some > other reason you can't migrate from BIOS to UEFI booting? a. There's no way to automate the switch from CSM/BIOS to UEFI. The user must interact with the firmware setup directly to make the switch happen. b. It's not immediately obvious that the migration worked, from a user's perspective. They need to run efiboormgr and know what's expected. Fedora Cloud edition base images are dual BIOS and UEFI boot, using GPT partition scheme. It is possible to do this. But Cloud has a much narrower set of virtualized firmwares to deal with, and getting bugs fixed is pretty likely. Whereas any bugs discovered in hardware's firmware is unlikely to get fixed anytime soon. The biggest though is likely lack of resources. It'd amount to foisting this arrangement onto users and come what may. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 4:28 PM Chris Murphy wrote: > > On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer wrote: > > > > * Peter Robinson: > > > > > This is out of context here because you can disable Secure Boot but > > > still use UEFI to make that work. You're trying to link to different > > > problems together. > > > > I think there's firmware out there which enables Secure Boot > > unconditionally in UEFI mode, but still has CSM support. > > The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM > enabled renders Secure Boot impossible. So I'm not sure how the > firmware can simultaneously enforce Secure Boot, but then permit the > loading of non-compliant bootloaders. That'd seem to be a Secure Boot > break worthy of a firmware update. In particular if it's also possible > to invoke CSM boot via NVRAM variables. > Many boards offered this capability, even though it violates the standard. It's one of the reasons why Intel demanded PC makers stop supporting CSM at all. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 9:56 AM Florian Weimer wrote: > > * Peter Robinson: > > > This is out of context here because you can disable Secure Boot but > > still use UEFI to make that work. You're trying to link to different > > problems together. > > I think there's firmware out there which enables Secure Boot > unconditionally in UEFI mode, but still has CSM support. The UEFI spec makes CSM and Secure Boot mutually exclusive. CSM enabled renders Secure Boot impossible. So I'm not sure how the firmware can simultaneously enforce Secure Boot, but then permit the loading of non-compliant bootloaders. That'd seem to be a Secure Boot break worthy of a firmware update. In particular if it's also possible to invoke CSM boot via NVRAM variables. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Chris Murphy writes: > On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore >> mandates that machines must have been made after 2006). > > Where do we require this? I see only one location for such minimums: > > https://getfedora.org/en/workstation/download/ https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/ Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote: > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > mandates that machines must have been made after 2006). Where do we require this? I see only one location for such minimums: https://getfedora.org/en/workstation/download/ * Fedora requires a minimum of 20GB disk, 2GB RAM, to install and run successfully. Double those amounts is recommended. Should this be modified to better communicate the actual minimums? I like the idea of making this less ambiguous: e.g. CPU release date 4th quarter 2006 or later; or a list of CPU features? > * Drawing a clear year cutoff, let alone a detailed list of hardware > this change affects, is basically impossible. This is unfortunate but > unlikely to ever change. OK I'm confused now. > * There is no migration story from Legacy BIOS to UEFI - > repartitioning effectively mandates a reinstall. As a result, we > don’t drop support for existing Legacy BIOS systems yet, just new > installations. OK let's set aside the case of native UEFI with CSM enabled legacy BIOS. That's plainly (a) change the settings, and (b) reinstall. But this leaves out native BIOS systems entirely, for new installations. How is this not removing BIOS support entirely if users can only do upgrades, but not clean installs on BIOS systems? I think an intermediate step is necessary. One possible idea is to stop creating hybrid ISO images. Instead make separate GPT only images for non-optical (typically USB stick) booting, and consider one or more images for the optical boot case using strictly conforming ISO 9660 or UDF? Again stop making universal media with all the weird (but awesome) hacks, and multiple bootloaders. Fedora Cloud edition's base images now have GPT partition scheme (only) with both BIOS and UEFI bootloaders and partitions. We can create spec compliant (no funny business) images, reducing the overall complexity as an intermediate step before fully dropping BIOS. Instead of using ISOLINUX as the BIOS bootloader, just use GRUB for both, just as Cloud edition is today. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 4:01 PM Sebastian Crane wrote: > If the installation media can not install onto BIOS-only machines yet > all the bootloader stages support BIOS, then there will be an awkward > stage where some existing Fedora installations can be upgraded, but if > anything goes wrong it'd be impossible to reinstall them! The lack of a > BIOS installer as a fallback would make running Fedora on BIOS-only > machines risky enough that it seems to me as no better than removing > support entirely. Could I missing something here? If I were interested in keeping BIOS machines installable, I'd probably just rebuild the F36 installer every so often, pointing it at newer repos by default each time. Long term that might be a little weird - if the installed system stops knowing about BIOS partition tables you might end up with a machine unable to inspect its own disk layout from like gnome-disks - but... - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Wed, Apr 6, 2022 at 1:18 AM Ben Cotton wrote: > > 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. > > == Owner == > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > Konečný]], [[User:bcl| Brian C. Lane]] > * Email: rharw...@redhat.com > > > == Detailed Description == > UEFI is defined by a versioned standard that can be tested and > certified against. By contrast, every legacy BIOS is unique. Legacy > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > and on its way out. As it ages, maintainability has decreased, and > the status quo of maintaining both stacks in perpetuity is not viable > for those currently doing that work. > > It is inevitable that legacy BIOS will be removed in a future release. > To ease this transition as best we can, there will be a period (of at > least one Fedora release) where it will be possible to boot using the > legacy BIOS codepaths, but new installations will not be possible. > While it would be easier for us to cut support off today, our hope is > that this compromise position will make for a smoother transition. > Additional support with issues during the transition would be > appreciated. > Just a personal frustration here, I recently worked on a project to rewrite the mesa driver for a range of intel GPUs from gen4->gen7, we ship it in Fedora 35 as the default driver on those GPUs. It was of great benefit to me and the community that I could use Fedora for developing this sort of feature, and have a place to roll it out for validation. This change would invalidate a wide range of the machines I wrote this on from being used. I have a fully operational 965G desktop machine that runs f35, a mostly operational 965GM HP laptop with busted fan, and a GM45 in a Thinkpad W500 machine that are all pre-UEFI but still can run fedora. I've got one Ironlake HP laptop that has UEFI but only if I hand pick the boot file since its UEFI implementation has a bunch of BIOS warnings around it saying not to enable it for normal use. The T440s I have doesn't seem to be installed in UEFI mode and that likely means I need to nuke it and start again. This would mean for future projects I'd probably have to consider moving off Fedora would definitely count as a major pita for me, I also cleanly installed all these machines with F35 as I didn't want the behaviour of updating from f31 to f33 to f35 etc. Dave. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:38 PM Adam Jackson wrote: > > On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: > > > We also lack solutions for dealing with the NVIDIA driver in > > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > > Because we still don't have a way to have kernel-only keyrings for > > secure boot certificates to avoid importing them into the firmware. > > Couple of thoughts, here: > > 1 - This is a non sequitur to the question of removing BIOS support, > because Secure Boot is not a BIOS feature, so nobody relying on Secure > Boot today would stand to lose anything. > > 2 - How is this our problem to solve? NVIDIA are the ones with the > private source code. > It's our problem because the problem isn't specific to NVIDIA, it's specific to how people compile and load kernel modules of their own. We should not require loading keys into firmware for user built kernel modules. An OS-level module should be trustable at the OS kernel level. Thus, it should be: MS cert -> shim -> Fedora cert -> grub -> kernel -> user cert -> user kmod. > 3 - Your complaint describes solution: import NVIDIA's signing key > into your firmware. If you want both Secure Boot and nvidia.ko so > badly, then you as the consumer need to tell your platform to trust > what NVIDIA signs. If that's a burden, again, see point 2 about who > exactly is making your life hard here. Remedies there might include > some UI streamlining around mokutil, or getting nvidia and nouveau to > use the same (open) kernel driver so the question just goes away. > This problem also makes life miserable for people working with third party open source kernel modules too. As a live streamer, for example, I need to use v4l2loopback, which will never exist in mainline because v4l2 maintainers don't like it at all. Broad non-Mac hardware only became available after Windows 8 / Windows Server 2012 R2. Yes, some hardware existed a few years before, but it was not broadly available before 2013. We didn't discontinue i686 in Fedora until Fedora Linux 31, which was over 15 years after the first x86_64 system. The user experience with x86_64 was immeasurably better than i686 at that point in time. We do not have a better experience with UEFI *right now*. I know of plenty of people intentionally choosing BIOS because the user experience is better, even though it's older/bad technology. Because using BIOS means kmods work. Because using BIOS means hibernate works. Because using BIOS means they can get an equivalent experience leveraging their hardware that they can get on Windows today with UEFI. Maybe none of you proposing this Change use these things, but I'm telling you these things matter. And the amount of resistance to improving UEFI experience for hardware is amazingly awful. The workstation working group has tried to figure out ways to improve the experience, only to be simultaneously stymied by the UEFI firmware management tools and unwillingness by anyone involved to even consider that we should make this better. I will *not* force people to deal with importing keys into firmware. It's brittle, buggy, and often completely broken on motherboards. Many of those UEFI implementations are extremely buggy and terrible. I've dealt with a lot of it as part of my job over the years and it leads to a terrible user experience for Linux users. If you are making UEFI the only way people boot, ***fix*** the experience. If you're not committed to that, then you're causing more pain for no gain. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
I frequently use BIOS-only machines which don't have a UEFI boot option - and one of those machines is indeed running Fedora! Certainly, I understand that there are better ways of booting systems now, but for the time being BIOS is still very important. If the installation media can not install onto BIOS-only machines yet all the bootloader stages support BIOS, then there will be an awkward stage where some existing Fedora installations can be upgraded, but if anything goes wrong it'd be impossible to reinstall them! The lack of a BIOS installer as a fallback would make running Fedora on BIOS-only machines risky enough that it seems to me as no better than removing support entirely. Could I missing something here? Also, one thing that I would be greatly reassured by is a date for removal of BIOS support entirely. This would at least give confidence that is worth installing Fedora on these machines for use in a limited, but known, duration, rather than looking at alternative distributions now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton wrote: > While this will eventually reduce workload for boot/installation > components (grub2 reduces surface area, syslinux goes away entirely, > anaconda reduces surface area), the reduction in support burden > extends much further into the stack - for instance, VESA support can > be removed from the distro. I'm flattered, but I intend to drop vesa in F37 regardless of the outcome of this particular change. The only supported way to get to graphics with vesa is to use Xorg, and we sincerely want to be out of the business of maintaining Xorg the hardware server. (We'll need an X server forever, Xwayland isn't going away, don't misread me here.) And frankly at this point if you seriously want to use vesa it's because you're trying to like reverse engineer some obscure card's VBIOS, and if you're doing that you're probably building your own X server anyway, I know I would be. Its use as an emergency driver on physical GPUs is negligible, we have native drivers for virtually everything made in the last 20 years. Its use as an emergency driver in virtual machines is more statistically significant, maybe, but even there we usually have a drm driver these days, and where we don't we can probably club it into bochs_drm since that's the only rom anyone bothers to use for that. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: > We also lack solutions for dealing with the NVIDIA driver in > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > Because we still don't have a way to have kernel-only keyrings for > secure boot certificates to avoid importing them into the firmware. Couple of thoughts, here: 1 - This is a non sequitur to the question of removing BIOS support, because Secure Boot is not a BIOS feature, so nobody relying on Secure Boot today would stand to lose anything. 2 - How is this our problem to solve? NVIDIA are the ones with the private source code. 3 - Your complaint describes solution: import NVIDIA's signing key into your firmware. If you want both Secure Boot and nvidia.ko so badly, then you as the consumer need to tell your platform to trust what NVIDIA signs. If that's a burden, again, see point 2 about who exactly is making your life hard here. Remedies there might include some UI streamlining around mokutil, or getting nvidia and nouveau to use the same (open) kernel driver so the question just goes away. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 15:09, Neal Gompa wrote: > On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour > wrote: >> >> On 4/5/22 13:38, Neal Gompa wrote: >>> On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel >>> wrote: On 05/04/2022 15:52, Ben Cotton wrote: > * There is no migration story from Legacy BIOS to UEFI - > repartitioning effectively mandates a reinstall. As a result, we > don’t drop support for existing Legacy BIOS systems yet, just new > installations. This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache. Is it actually true though? You need to be able to find some space for an EFI partition but assuming that can be done is there some other reason you can't migrate from BIOS to UEFI booting? >>> >>> In Fedora Linux default partitioning for all but Server, it is >>> possible to reconfigure existing systems to UEFI. Fedora Server is >>> screwed because they use XFS and you cannot shrink an XFS volume. >> >> Time to get the XFS developers to support shrinking? >> > > That's not likely to happen anytime soon. Is this because of lack of demand from paying RHEL customers? > That said, up until Fedora > Linux 33, a swap partition was created by default too. You can shrink > that and reuse some of that space to create an ESP outside of the > LVM+XFS setup. As I was reminded earlier in this thread, swap is a > good chopping block to work with. Yeah, you can use a swap file instead. Also LVM thin volumes may be getting shrinking support. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 3:06 PM Demi Marie Obenour wrote: > > On 4/5/22 13:38, Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel > > wrote: > >> > >> On 05/04/2022 15:52, Ben Cotton wrote: > >> > >>> * There is no migration story from Legacy BIOS to UEFI - > >>> repartitioning effectively mandates a reinstall. As a result, we > >>> don’t drop support for existing Legacy BIOS systems yet, just new > >>> installations. > >> > >> This is where I have a problem with this, the fact that there is > >> no upgrade path - virtually my entire installed base of Fedora is > >> running legacy BIOS and not being able to upgrade them will be > >> something of a headache. > >> > >> Is it actually true though? You need to be able to find some space > >> for an EFI partition but assuming that can be done is there some > >> other reason you can't migrate from BIOS to UEFI booting? > >> > > > > In Fedora Linux default partitioning for all but Server, it is > > possible to reconfigure existing systems to UEFI. Fedora Server is > > screwed because they use XFS and you cannot shrink an XFS volume. > > Time to get the XFS developers to support shrinking? > That's not likely to happen anytime soon. That said, up until Fedora Linux 33, a swap partition was created by default too. You can shrink that and reuse some of that space to create an ESP outside of the LVM+XFS setup. As I was reminded earlier in this thread, swap is a good chopping block to work with. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 13:38, Neal Gompa wrote: > On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel > wrote: >> >> On 05/04/2022 15:52, Ben Cotton wrote: >> >>> * There is no migration story from Legacy BIOS to UEFI - >>> repartitioning effectively mandates a reinstall. As a result, we >>> don’t drop support for existing Legacy BIOS systems yet, just new >>> installations. >> >> This is where I have a problem with this, the fact that there is >> no upgrade path - virtually my entire installed base of Fedora is >> running legacy BIOS and not being able to upgrade them will be >> something of a headache. >> >> Is it actually true though? You need to be able to find some space >> for an EFI partition but assuming that can be done is there some >> other reason you can't migrate from BIOS to UEFI booting? >> > > In Fedora Linux default partitioning for all but Server, it is > possible to reconfigure existing systems to UEFI. Fedora Server is > screwed because they use XFS and you cannot shrink an XFS volume. Time to get the XFS developers to support shrinking? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Akamai owns Linode, which is a prominent VPS that focuses on Linux (Linode is a contraction meaning "Linux Node"). +1 DigitalOcean similarly is Linux centric and so Windows doesn't matter. +1 Most web hosting providers and VPSes are Linux-centric and so Windows doesn't matter. +1 Ironic that Windows11 compat is being floated as any kind of rationale here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 12:29, Michael Catanzaro wrote: > On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood > wrote: >> Users wishing to use NVIDIA hardware have the following options: >> >> - Use nouveau (free, open source, cool) >> - Sign their own copy of the proprietary driver (involves messing with >> certificates, so not appropriate for all users) >> - Disable Secure Boot (note that this is still UEFI) >> >> The NVIDIA driver is proprietary, so of course it's not going to get >> signed. > > The user experience requirement is: user searches for NVIDIA in GNOME > Software and clicks Install. No further action should be necessary. We > didn't make the NVIDIA driver available from the graphical installer > with the intention that arcane workarounds would be required to use it. > > Michael Bingo. None of the three options Robbie suggested are reasonable for non-technical users. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #22: 6.62 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.62 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/22 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Summary/Minutes from today's FESCo Meeting (2022-04-05)
=== #fedora-meeting: FESCO (2022-04-05) === Meeting started by mhroncok at 17:00:17 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2022-04-05/fesco.2022-04-05-17.00.log.html . Meeting summary --- * init process (mhroncok, 17:00:26) * #2774 provenpackager for trodgers (mhroncok, 17:03:28) * mhroncok plans to help trodgers pushing the boost bumps this time, it hasn't happened yet, but mhroncok is ready (mhroncok, 17:04:24) * trodgers withdraws their provenpackager request for now, and will retry later (mhroncok, 17:16:28) * #2766 Change proposal: Make pkexec and pkla-compat optional (mhroncok, 17:17:46) * AGREED: REJECTED (+0, 3, -5) (mhroncok, 17:22:25) * #2759 Proposal: periodic check on packagers reachability (mhroncok, 17:22:44) * FESCo, please post your votes to the ticket and nitpicks to the PR (mhroncok, 17:36:45) * Next week's chair (mhroncok, 17:37:06) * ACTION: nirik will chair next meeting (mhroncok, 17:40:31) * Open Floor (mhroncok, 17:40:48) Meeting ended at 17:50:16 UTC. Action Items * nirik will chair next meeting Action Items, by person --- * nirik * nirik will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * mhroncok (92) * Eighth_Doctor (36) * zbyszek (24) * zodbot (23) * nirik (20) * trodgers (18) * mboddu (13) * dcantrell (12) * bcotton (10) * tstellar (6) * sgallagh (4) * decathorpe (1) * Conan_Kudo (0) * Pharaoh_Atem (0) * Son_Goku (0) * King_InuYasha (0) * Sir_Gallantmon (0) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #22: 6.62 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.62 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/22 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 2:36 PM Robbie Harwood wrote: > > PGNet Dev writes: > > > Curious, has anyone from @redhat or @fedora though to actually > > communicate with any of the 'big' hosting providers, to perhaps > > coordinate/influence/compromise/plan? > > > > I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest > > hosting providers where 'new installs' would be happening on their > > VPSs -- would be quite interested in making sure that THEIR customers > > had smooth install/migration options for Redhat/Centos*/Fedora > > variants. > > > > I know my _own_ solution to UEFI-install only if those^ providers > > don't support it; I'm guessing not everyone will have the same > > goals/approach. > > Any VPS that supports Windows 11 needs to support UEFI-only already. In > particular, the top 3 (AWS, Azure, Google Cloud) are all UEFI-capable. > > (Akamai is, to my knowledge, not a provider of VPSs.) > Akamai owns Linode, which is a prominent VPS that focuses on Linux (Linode is a contraction meaning "Linux Node"). DigitalOcean similarly is Linux centric and so Windows doesn't matter. Most web hosting providers and VPSes are Linux-centric and so Windows doesn't matter. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
(Akamai is, to my knowledge, not a provider of VPSs.) https://www.linode.com/press-release/akamai-to-acquire-linode/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
PGNet Dev writes: > Curious, has anyone from @redhat or @fedora though to actually > communicate with any of the 'big' hosting providers, to perhaps > coordinate/influence/compromise/plan? > > I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest > hosting providers where 'new installs' would be happening on their > VPSs -- would be quite interested in making sure that THEIR customers > had smooth install/migration options for Redhat/Centos*/Fedora > variants. > > I know my _own_ solution to UEFI-install only if those^ providers > don't support it; I'm guessing not everyone will have the same > goals/approach. Any VPS that supports Windows 11 needs to support UEFI-only already. In particular, the top 3 (AWS, Azure, Google Cloud) are all UEFI-capable. (Akamai is, to my knowledge, not a provider of VPSs.) Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 1:17 PM Jason L Tibbitts III wrote: > > For those who might be curious, the systems are Supermicro 6026TT-HTRF > machines with four nodes in 2U. I have three, so twelve machines in > total. The machines have X8DTT-HF+ motherboards. I actually have older > hardware than that around and still in use (all Supermicro), but oddly > some of it actually has an EFI option. > > Check out this beauty that I still run. # cat /etc/redhat-release Fedora release 34 (Thirty Four) # dmidecode # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.3 present. 87 structures occupying 3232 bytes. Table at 0x000F9920. Handle 0xDA00, DMI type 218, 11 bytes OEM-specific Type Header and Data: DA 0B 00 DA B2 00 17 00 0E 20 00 Handle 0x, DMI type 0, 20 bytes BIOS Information Vendor: Dell Computer Corporation Version: A07 Release Date: 04/25/2008 Address: 0xF Runtime Size: 64 kB ROM Size: 1 MB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for Toshiba 1.2 MB is supported (int 13h) 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported BIOS boot specification is supported Function key-initiated network boot is supported But I don't really expect Fedora Linux to support something that old. I fully understand that I may have to jump through some manual hoops to keep it running at this point. In fact, I do. I have this system customized to boot using syslinux with BLS support. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
So you've heard that we're overloaded, and you know that UEFI is the direction the world is heading. Well, so is (was?) 'IPv6' ... Your solution to this is... what, stick our heads in the sand and ignore that? Just do legacy? We already have UEFI-only platforms (see also: the mention of ARM you're belaboring), so that's obviously not going to fly, even if we were willing to, which we're not. There are enough, different plots of sand for different folks to stick their heads into. To my read, noone's suggested ignoring the future -- rather the suggestions appear to be to NOT ignore reality. Curious, has anyone from @redhat or @fedora though to actually communicate with any of the 'big' hosting providers, to perhaps coordinate/influence/compromise/plan? I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest hosting providers where 'new installs' would be happening on their VPSs -- would be quite interested in making sure that THEIR customers had smooth install/migration options for Redhat/Centos*/Fedora variants. I know my _own_ solution to UEFI-install only if those^ providers don't support it; I'm guessing not everyone will have the same goals/approach. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> Ben Cotton writes: > == Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). My problem here is that I have real, useful hardware which has always run Fedora that I would like to continue using. But it's just old enough (purchased in 2011) and doesn't support UEFI at all. These machines are repurposed computational servers and work perfectly well to do things like provide some public Fedora mirrors. > Like the already accepted Fedora 37 change to retire ARMv7 support, > the hardware targeted tends to be rather underpowered by today’s > standards, and the world has moved on from it. I know there is this tendency to dismiss anything that's old as useless, and 20 years ago, a decade-old machine wasn't something you probably wanted to use. But the rate of progress has slowed down, and a Xeon X5670 with 96GB of memory and a pile of disk just isn't a piece of garbage. I know I'll have to toss it out eventually, but I'd hope to do that when it either fails or is actually no longer useful. I understand that this isn't going to be how the primary user experience is directed. I can deal with having to jump through hoops to get a machine installed. But it would be kind of sad if my alternatives are to use another distro or toss the stuff in the trash. (There would be a certain irony in not being able to run Fedora to provide a Fedora mirror.) For those who might be curious, the systems are Supermicro 6026TT-HTRF machines with four nodes in 2U. I have three, so twelve machines in total. The machines have X8DTT-HF+ motherboards. I actually have older hardware than that around and still in use (all Supermicro), but oddly some of it actually has an EFI option. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> Am 05.04.2022 um 19:57 schrieb Robbie Harwood : > > Peter Boy writes: > >> And I also don't understand why we should give up a hallmark of free >> Linux, namely to support old, but still good usable hardware (unlike >> commercial system, not only Windows but also e.g. RHEL). > > Developers are free to support whatever systems they like. If someone > wants to support systems, they'll be supported; if not, they won't. > There's no law that says Linux MUST keep supporting hardware forever. > See also: armv7 removal, i386/i686 removal, ppc removal, m68k removal, I =don’t= say must! I ask if that is wise! Of course, Fedora is free to discontinue support for bios boot, and may we have to because of lack of manpower. Users will then move away from Fedora to somewhere else, Suse or Debian. And certainly no new users will switch to Fedora because we no longer support BIOS boot and it's so cool. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-36-20220405.n.0 compose check report
No missing expected images. Failed openQA tests: 7/229 (x86_64), 11/161 (aarch64) New failures (same test not failed in Fedora-36-20220404.n.0): ID: 1211773 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1211773 ID: 1211779 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1211779 ID: 1211822 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1211822 ID: 1211838 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1211838 ID: 1211847 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1211847 Old failures (same test failed in Fedora-36-20220404.n.0): ID: 1211741 Test: x86_64 Workstation-live-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1211741 ID: 1211776 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1211776 ID: 1211851 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1211851 ID: 1211874 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1211874 ID: 1211875 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1211875 ID: 1211877 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1211877 ID: 1211908 Test: x86_64 Workstation-upgrade apps_startstop URL: https://openqa.fedoraproject.org/tests/1211908 ID: 1211911 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1211911 ID: 1211926 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1211926 ID: 1211930 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1211930 ID: 1211932 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi URL: https://openqa.fedoraproject.org/tests/1211932 ID: 1211996 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1211996 ID: 1212055 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1212055 Soft failed openQA tests: 10/229 (x86_64), 5/161 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-36-20220404.n.0): ID: 1211744 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1211744 ID: 1211748 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1211748 ID: 1211759 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1211759 ID: 1211769 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1211769 ID: 1211786 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1211786 ID: 1211791 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/1211791 ID: 1211793 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1211793 ID: 1211794 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1211794 ID: 1211800 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1211800 ID: 1211889 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1211889 ID: 1211890 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1211890 ID: 1211894 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1211894 ID: 1211902 Test: x86_64 Workstation-upgrade desktop_browser URL: https://openqa.fedoraproject.org/tests/1211902 ID: 1211924 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1211924 ID: 1211937 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1211937 Passed openQA tests: 145/161 (aarch64), 212/229 (x86_64) New passes (same test not passed in Fedora-36-20220404.n.0): ID: 1211836 Test: aarch64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1211836 ID: 1211891 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1211891 ID: 1211906 Test: x86_64 Workstation-upgrade desktop_printing URL: https://openqa.fedoraproject.org/tests/1211906 ID: 1211910 Test: x86_64 Workstation-upgrade desktop_printing_builtin URL:
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Tom Hughes writes: > On 05/04/2022 18:51, Robbie Harwood wrote: > >> Right, you need the EFI partition (EFI System Partition, or ESP). I >> don't remember what we default those to these days - I usually make >> about 600M, but I need it larger for testing stuff. The partition >> scheme also needs to be GPT, not MBR. Once that's all set, the EFI >> grub2 packages need to be installed, but that's the easy part :) > > I actually checked that on wikipedia because I wondered if it > had to be GPT and it seemed to say MBR was supported? > > https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_device_compatibility That may work, but what's important is that it's not close to as well-tested - Windows binds UEFI support to needing GPT. (Also, the 2.2T limitation on MBR makes GPT very attractive.) Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> Am 05.04.2022 um 19:38 schrieb Neal Gompa : > > Fedora Server is > screwed because they use XFS and you cannot shrink an XFS volume. Server is not screwed because of XFS, according to the change, an existing installation can still use bios boot. That is not a Problem. (And you could easily relocate logical volumes and adjust the physical volume without a complete reinstallation, although only offline) Instead, the change will „screw“ Server because some data center require bios boot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Gregory Bartholomew writes: > But I seem to remember /boot being a separate partition for a long > time (it used to be required because some older BOISs couldn't read > beyond a certain sector on the disk). Could not /boot be converted to > the ESP (i.e. reformatted with FAT32) on such systems? Only if there's somewhere else for /boot to reside. If e.g., / is encrypted, we're not prepared out of the box to handle that. A determined user could probably make it work, but it's again niche. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Peter Boy writes: > And I also don't understand why we should give up a hallmark of free > Linux, namely to support old, but still good usable hardware (unlike > commercial system, not only Windows but also e.g. RHEL). Developers are free to support whatever systems they like. If someone wants to support systems, they'll be supported; if not, they won't. There's no law that says Linux MUST keep supporting hardware forever. See also: armv7 removal, i386/i686 removal, ppc removal, m68k removal, ... Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 05/04/2022 18:51, Robbie Harwood wrote: Right, you need the EFI partition (EFI System Partition, or ESP). I don't remember what we default those to these days - I usually make about 600M, but I need it larger for testing stuff. The partition scheme also needs to be GPT, not MBR. Once that's all set, the EFI grub2 packages need to be installed, but that's the easy part :) I actually checked that on wikipedia because I wondered if it had to be GPT and it seemed to say MBR was supported? https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_device_compatibility Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Tom Hughes via devel writes: > On 05/04/2022 15:52, Ben Cotton wrote: > >> * There is no migration story from Legacy BIOS to UEFI - >> repartitioning effectively mandates a reinstall. As a result, we >> don’t drop support for existing Legacy BIOS systems yet, just new >> installations. > > This is where I have a problem with this, the fact that there is > no upgrade path - virtually my entire installed base of Fedora is > running legacy BIOS and not being able to upgrade them will be > something of a headache. Yup. That's why there's a deprecation window here. > Is it actually true though? You need to be able to find some space > for an EFI partition but assuming that can be done is there some > other reason you can't migrate from BIOS to UEFI booting? Right, you need the EFI partition (EFI System Partition, or ESP). I don't remember what we default those to these days - I usually make about 600M, but I need it larger for testing stuff. The partition scheme also needs to be GPT, not MBR. Once that's all set, the EFI grub2 packages need to be installed, but that's the easy part :) Repartitioning in the general case is very involved. If the system is using an encrypted LVM, that's two more layers to worry about. The dm-crypt area would need to shrink, which means the LVM needs to shrink, which means the filesystems on it need to shrink (and importantly, not all of them can). That doesn't even touch dual-boot scenarios, where our filesysem support is less good than for Linux native cases. To restate that: I think very determined, patient users can make it work in some cases. But I don't think we can expect that to work for everyone, especially without friendly tooling to accomplish it. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 1:47 PM Gregory Bartholomew wrote: > > On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa wrote: >> >> Fedora Server users *must* fully reinstall, because there's no way to >> make space for an ESP and reconfigure things. > > > I haven't done a "default" Fedora Server installation in a long time, so I'm > not sure how they are laid out. But I seem to remember /boot being a separate > partition for a long time (it used to be required because some older BOISs > couldn't read beyond a certain sector on the disk). Could not /boot be > converted to the ESP (i.e. reformatted with FAT32) on such systems? We do /boot/efi (ESP for EFI blobs) + /boot (everything else). The ESP can be extremely tiny because of it. Fedora Server /boot is XFS, so non-shrinkable. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 1:46 PM Tom Hughes wrote: > > On 05/04/2022 18:38, Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel > > wrote: > >> > >> On 05/04/2022 15:52, Ben Cotton wrote: > >> > >>> * There is no migration story from Legacy BIOS to UEFI - > >>> repartitioning effectively mandates a reinstall. As a result, we > >>> don’t drop support for existing Legacy BIOS systems yet, just new > >>> installations. > >> > >> This is where I have a problem with this, the fact that there is > >> no upgrade path - virtually my entire installed base of Fedora is > >> running legacy BIOS and not being able to upgrade them will be > >> something of a headache. > >> > >> Is it actually true though? You need to be able to find some space > >> for an EFI partition but assuming that can be done is there some > >> other reason you can't migrate from BIOS to UEFI booting? > > > > In Fedora Linux default partitioning for all but Server, it is > > possible to reconfigure existing systems to UEFI. Fedora Server is > > screwed because they use XFS and you cannot shrink an XFS volume. > > > > Fedora < 33 used ext4 by default, and you can do offline shrink and > > open up space for an ESP. In Fedora >= 33, ext4 is still used for > > /boot and you can resize that. Alternatively, the Btrfs / can be > > resized while the system is running to make room for an ESP. > > I generally do my own partitioning rather than using the > default, and all my systems are ext4 so sounds like it's not > necessarily impossible. > > I'm actually looking at stealing swap on some of them, or > just growing disks for VMs. > If you have a swap partition, that's the easiest place to steal from, indeed! -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> Am 05.04.2022 um 16:52 schrieb Ben Cotton : > > 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. > From the Fedora Server Working Group's point of view, I am absolutely against this change (namely to drop new BIOS-boot installations). There are a large number of data centers with rental hardware (e.g. hetzner.com) or co-location that (still) require bios boot even for newer servers. I don't know the reasons, probably due to their support and management infrastructure. I suppose this will change in the future, but foreseeably not for the next 5 - x years. In any case, we would force all users of that environment to switch away from Fedora Server to another distribution. I’m wondering, do we really want to do that? And likewise, we must not make it unnecessarily difficult for users to use this (old) path. We are not a reform school. And I also don't understand why we should give up a hallmark of free Linux, namely to support old, but still good usable hardware (unlike commercial system, not only Windows but also e.g. RHEL). Peter (And to my chagrin, I myself would be affected and forced to leave Fedora and immediately start to move our servers to another distro when this change is accepted.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 12:39 PM Neal Gompa wrote: > Fedora Server users *must* fully reinstall, because there's no way to > make space for an ESP and reconfigure things. > I haven't done a "default" Fedora Server installation in a long time, so I'm not sure how they are laid out. But I seem to remember /boot being a separate partition for a long time (it used to be required because some older BOISs couldn't read beyond a certain sector on the disk). Could not /boot be converted to the ESP (i.e. reformatted with FAT32) on such systems? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 12:31 PM Tom Hughes via devel < devel@lists.fedoraproject.org> wrote: > On 05/04/2022 15:52, Ben Cotton wrote: > > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > This is where I have a problem with this, the fact that there is > no upgrade path - virtually my entire installed base of Fedora is > running legacy BIOS and not being able to upgrade them will be > something of a headache. > > Is it actually true though? You need to be able to find some space > for an EFI partition but assuming that can be done is there some > other reason you can't migrate from BIOS to UEFI booting? > I actually did it manually several releases ago when I got a new computer that supported EFI but kept the same OS drive. I'm not going to lie, it was VERY painful and took me a while to figure everything out, a lot of googling and trying stuff. It wasn't for the faint of heart. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 05/04/2022 18:38, Neal Gompa wrote: On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel wrote: On 05/04/2022 15:52, Ben Cotton wrote: * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache. Is it actually true though? You need to be able to find some space for an EFI partition but assuming that can be done is there some other reason you can't migrate from BIOS to UEFI booting? In Fedora Linux default partitioning for all but Server, it is possible to reconfigure existing systems to UEFI. Fedora Server is screwed because they use XFS and you cannot shrink an XFS volume. Fedora < 33 used ext4 by default, and you can do offline shrink and open up space for an ESP. In Fedora >= 33, ext4 is still used for /boot and you can resize that. Alternatively, the Btrfs / can be resized while the system is running to make room for an ESP. I generally do my own partitioning rather than using the default, and all my systems are ext4 so sounds like it's not necessarily impossible. I'm actually looking at stealing swap on some of them, or just growing disks for VMs. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel wrote: > > On 05/04/2022 15:52, Ben Cotton wrote: > > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > This is where I have a problem with this, the fact that there is > no upgrade path - virtually my entire installed base of Fedora is > running legacy BIOS and not being able to upgrade them will be > something of a headache. > > Is it actually true though? You need to be able to find some space > for an EFI partition but assuming that can be done is there some > other reason you can't migrate from BIOS to UEFI booting? > In Fedora Linux default partitioning for all but Server, it is possible to reconfigure existing systems to UEFI. Fedora Server is screwed because they use XFS and you cannot shrink an XFS volume. Fedora < 33 used ext4 by default, and you can do offline shrink and open up space for an ESP. In Fedora >= 33, ext4 is still used for /boot and you can resize that. Alternatively, the Btrfs / can be resized while the system is running to make room for an ESP. It wouldn't be difficult to provide a tool to make the conversion possible as long as you didn't use XFS. Fedora Cloud 35+ is configured in hybrid mode, so you can seamlessly switch between BIOS and UEFI. Fedora Server users *must* fully reinstall, because there's no way to make space for an ESP and reconfigure things. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20220405.0 compose check report
No missing expected images. Failed openQA tests: 2/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20220404.0): ID: 1212154 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1212154 Old failures (same test failed in Fedora-IoT-36-20220404.0): ID: 1212141 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1212141 Passed openQA tests: 15/15 (x86_64), 13/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.09 to 0.35 Previous test data: https://openqa.fedoraproject.org/tests/1210507#downloads Current test data: https://openqa.fedoraproject.org/tests/1212142#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 05/04/2022 15:52, Ben Cotton wrote: * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache. Is it actually true though? You need to be able to find some space for an EFI partition but assuming that can be done is there some other reason you can't migrate from BIOS to UEFI booting? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #21: 6.62 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.62 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/21 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Am 05.04.22 um 16:52 schrieb Ben Cotton: 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. Short, but hard and clear answer: No. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Once upon a time, Robbie Harwood said: > (Just to be clear here: this change is proposing a deprecation, not a > removal.) No, the change proposes making it impossible to install Fedora on BIOS. That's not a deprecation. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
David Duncan writes: > For similar reasons, I agree with Neal. There are a number of Amazon > EC2 instance types that would be left out of the next generation. I > think it would be better to identify the usage in some way and create > a general awareness that it is being removed prior to outright > removing it. The deprecation period is important IMO. (Just to be clear here: this change is proposing a deprecation, not a removal.) Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > By virtue of how boot stuff is handled in Fedora, the community is > incapable of working on it. Not true. Not at all true. src.fedoraproject.org permits anyone, *anyone* to send PRs to fix issues in the boot stack, or any other package. Even without it, bugzilla doesn't lock down people helping troubleshoot, write patches, work with upstreams, etc.. Just because you can't build an official version of the package doesn't mean you can't help work on it. > Fundamentally, this Change is premature unless there's a fundamental > decision that there's going to be more activity to solve these > problems. You're saying that this will reduce maintenance burden, but > virtually every boot bug I've seen for the last few Fedora releases > have been around UEFI, *not* BIOS. And it's a very real struggle to > get UEFI bugs fixed. So you've heard that we're overloaded, and you know that UEFI is the direction the world is heading. Your solution to this is... what, stick our heads in the sand and ignore that? Just do legacy? We already have UEFI-only platforms (see also: the mention of ARM you're belaboring), so that's obviously not going to fly, even if we were willing to, which we're not. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, 2022-04-05 at 09:33 -0700, David Duncan wrote: > > > > On Apr 5, 2022, at 8:08 AM, Neal Gompa wrote: > > > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton > > wrote: > > > > > > 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 entire > > > > > > == Owner == > > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > > > Konečný]], [[User:bcl| Brian C. Lane]] > > > * Email: rharw...@redhat.com > > > > > > > > > == Detailed Description == > > > UEFI is defined by a versioned standard that can be tested and > > > certified against. By contrast, every legacy BIOS is unique. > > > Legacy > > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, > > > Apple) > > > and on its way out. As it ages, maintainability has decreased, > > > and > > > the status quo of maintaining both stacks in perpetuity is not > > > viable > > > for those currently doing that work. > > > > > > It is inevitable that legacy BIOS will be removed in a future > > > release. > > > To ease this transition as best we can, there will be a period > > > (of at > > > least one Fedora release) where it will be possible to boot using > > > the > > > legacy BIOS codepaths, but new installations will not be > > > possible. > > > While it would be easier for us to cut support off today, our > > > hope is > > > that this compromise position will make for a smoother > > > transition. > > > Additional support with issues during the transition would be > > > appreciated. > > > > > > While this will eventually reduce workload for boot/installation > > > components (grub2 reduces surface area, syslinux goes away > > > entirely, > > > anaconda reduces surface area), the reduction in support burden > > > extends much further into the stack - for instance, VESA support > > > can > > > be removed from the distro. > > > > > > Fedora already requires a 2GHz dual core CPU at minimum (and > > > therefore > > > mandates that machines must have been made after 2006). Like the > > > already accepted Fedora 37 change to retire ARMv7 support, the > > > hardware targeted tends to be rather underpowered by today’s > > > standards, and the world has moved on from it. Intel stopped > > > shipping > > > the last vestiges of BIOS support in 2020 (as have other vendors, > > > and > > > Apple and Microsoft), so this is clearly the way things are > > > heading - > > > and therefore aligns with Fedora’s “First” objective. > > > > > > == Feedback == > > > Dropping legacy BIOS was previously discussed (but not proposed) > > > in 2020: > > > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > > > Important, relevant points from that thread (yes, I reread the > > > entire > > > thread) that have informed this change: > > > > > > * Some machines are BIOS-only. This change does not prevent > > > their use > > > yet, but they are effectively deprecated. grub2 (our default > > > bootloader) is already capable of both BIOS and UEFI booting. > > > * Drawing a clear year cutoff, let alone a detailed list of > > > hardware > > > this change affects, is basically impossible. This is > > > unfortunate but > > > unlikely to ever change. > > > * There is no migration story from Legacy BIOS to UEFI - > > > repartitioning effectively mandates a reinstall. As a result, we > > > don’t drop support for existing Legacy BIOS systems yet, just new > > > installations. > > > * There is no way to deprecate hardware without causing some > > > amount of friction. > > > * While at the time AWS did not support UEFI booting, that is no > > > longer the case and they support UEFI today. > > > > > > == Benefit to Fedora == > > > UEFI is required for many desirable features, including applying > > > firmware updates (fwupd) and supporting SecureBoot. As a > > > standalone > > > change, it reduces support burden on everything involved in > > > installing > > > Fedora, since there becomes only one way to do it per platform. > > > Finally, it simplifies our install/live media, since it too only > > > has > > > to boot one way per arch. Freedom Friends Features First - this > > > is > > > that last one. > > > > > > == Scope == > > > * Proposal owners: > > > ** bootloaders: No change (existing Legacy BIOS installations > > > still supported). > > > ** anaconda: No change (there could be only optional cleanups in > > > the > > > code). However, it needs to be verified. > > > ** Lorax: Code has already been written: > > > https://github.com/weldr/lorax/pull/1205 > > > > > > > This pull request primarily drops legacy BIOS support by dropping > >
[rpms/perl-libwww-perl] PR #21: 6.62 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.62 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/21 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022, 11:15 Neal Gompa wrote: > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: > > > > 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. > > > > == Owner == > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > > Konečný]], [[User:bcl| Brian C. Lane]] > > * Email: rharw...@redhat.com > > > > > > == Detailed Description == > > UEFI is defined by a versioned standard that can be tested and > > certified against. By contrast, every legacy BIOS is unique. Legacy > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > > and on its way out. As it ages, maintainability has decreased, and > > the status quo of maintaining both stacks in perpetuity is not viable > > for those currently doing that work. > > > > It is inevitable that legacy BIOS will be removed in a future release. > > To ease this transition as best we can, there will be a period (of at > > least one Fedora release) where it will be possible to boot using the > > legacy BIOS codepaths, but new installations will not be possible. > > While it would be easier for us to cut support off today, our hope is > > that this compromise position will make for a smoother transition. > > Additional support with issues during the transition would be > > appreciated. > > > > While this will eventually reduce workload for boot/installation > > components (grub2 reduces surface area, syslinux goes away entirely, > > anaconda reduces surface area), the reduction in support burden > > extends much further into the stack - for instance, VESA support can > > be removed from the distro. > > > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > > mandates that machines must have been made after 2006). Like the > > already accepted Fedora 37 change to retire ARMv7 support, the > > hardware targeted tends to be rather underpowered by today’s > > standards, and the world has moved on from it. Intel stopped shipping > > the last vestiges of BIOS support in 2020 (as have other vendors, and > > Apple and Microsoft), so this is clearly the way things are heading - > > and therefore aligns with Fedora’s “First” objective. > > > > == Feedback == > > Dropping legacy BIOS was previously discussed (but not proposed) in 2020: > > > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > Important, relevant points from that thread (yes, I reread the entire > > thread) that have informed this change: > > > > * Some machines are BIOS-only. This change does not prevent their use > > yet, but they are effectively deprecated. grub2 (our default > > bootloader) is already capable of both BIOS and UEFI booting. > > * Drawing a clear year cutoff, let alone a detailed list of hardware > > this change affects, is basically impossible. This is unfortunate but > > unlikely to ever change. > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > * There is no way to deprecate hardware without causing some amount of > friction. > > * While at the time AWS did not support UEFI booting, that is no > > longer the case and they support UEFI today. > > > > == Benefit to Fedora == > > UEFI is required for many desirable features, including applying > > firmware updates (fwupd) and supporting SecureBoot. As a standalone > > change, it reduces support burden on everything involved in installing > > Fedora, since there becomes only one way to do it per platform. > > Finally, it simplifies our install/live media, since it too only has > > to boot one way per arch. Freedom Friends Features First - this is > > that last one. > > > > == Scope == > > * Proposal owners: > > ** bootloaders: No change (existing Legacy BIOS installations still > supported). > > ** anaconda: No change (there could be only optional cleanups in the > > code). However, it needs to be verified. > > ** Lorax: Code has already been written: > > https://github.com/weldr/lorax/pull/1205 > > > > This pull request primarily drops legacy BIOS support by dropping > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > support there if we reuse GRUB there too. Other distributions > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on > live media. > > > * Other developers: > > ** libvirt: UEFI works today, but is not the default. UEFI-only > > installation is needed for Windows 11, and per conversations, libvirt > > is prepared for this change. > > ** Virtualbox:
Re: RFI/RFC: Fedora Linux graphical recovery environment
On Mon, Apr 4, 2022 at 9:40 PM Gordon Messmer wrote: > The ticket mentions Boot Repair, which is the first thing that comes to > mind: https://help.ubuntu.com/community/Boot-Repair Boot repair is obviously tricky because you have to have something bootable to initiate the repair. Practically speaking, I think the best option is to better support dual-drive installations. It should be possible to maintain two EFI partitions in a, b style when the user selects to have a mirrored-disk configuration. In fact I've been doing this on my Fedora Linux systems and I've even written some scripts to support it here: https://github.com/gregory-lee-bartholomew/bootsync Disclaimer though -- I use systemd boot and zfs, not the default grub and btrfs that most Fedora Linux systems are configured with. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> On Apr 5, 2022, at 8:08 AM, Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: >> >> 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 entire >> >> == Owner == >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří >> Konečný]], [[User:bcl| Brian C. Lane]] >> * Email: rharw...@redhat.com >> >> >> == Detailed Description == >> UEFI is defined by a versioned standard that can be tested and >> certified against. By contrast, every legacy BIOS is unique. Legacy >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) >> and on its way out. As it ages, maintainability has decreased, and >> the status quo of maintaining both stacks in perpetuity is not viable >> for those currently doing that work. >> >> It is inevitable that legacy BIOS will be removed in a future release. >> To ease this transition as best we can, there will be a period (of at >> least one Fedora release) where it will be possible to boot using the >> legacy BIOS codepaths, but new installations will not be possible. >> While it would be easier for us to cut support off today, our hope is >> that this compromise position will make for a smoother transition. >> Additional support with issues during the transition would be >> appreciated. >> >> While this will eventually reduce workload for boot/installation >> components (grub2 reduces surface area, syslinux goes away entirely, >> anaconda reduces surface area), the reduction in support burden >> extends much further into the stack - for instance, VESA support can >> be removed from the distro. >> >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore >> mandates that machines must have been made after 2006). Like the >> already accepted Fedora 37 change to retire ARMv7 support, the >> hardware targeted tends to be rather underpowered by today’s >> standards, and the world has moved on from it. Intel stopped shipping >> the last vestiges of BIOS support in 2020 (as have other vendors, and >> Apple and Microsoft), so this is clearly the way things are heading - >> and therefore aligns with Fedora’s “First” objective. >> >> == Feedback == >> Dropping legacy BIOS was previously discussed (but not proposed) in 2020: >> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ >> >> Important, relevant points from that thread (yes, I reread the entire >> thread) that have informed this change: >> >> * Some machines are BIOS-only. This change does not prevent their use >> yet, but they are effectively deprecated. grub2 (our default >> bootloader) is already capable of both BIOS and UEFI booting. >> * Drawing a clear year cutoff, let alone a detailed list of hardware >> this change affects, is basically impossible. This is unfortunate but >> unlikely to ever change. >> * There is no migration story from Legacy BIOS to UEFI - >> repartitioning effectively mandates a reinstall. As a result, we >> don’t drop support for existing Legacy BIOS systems yet, just new >> installations. >> * There is no way to deprecate hardware without causing some amount of >> friction. >> * While at the time AWS did not support UEFI booting, that is no >> longer the case and they support UEFI today. >> >> == Benefit to Fedora == >> UEFI is required for many desirable features, including applying >> firmware updates (fwupd) and supporting SecureBoot. As a standalone >> change, it reduces support burden on everything involved in installing >> Fedora, since there becomes only one way to do it per platform. >> Finally, it simplifies our install/live media, since it too only has >> to boot one way per arch. Freedom Friends Features First - this is >> that last one. >> >> == Scope == >> * Proposal owners: >> ** bootloaders: No change (existing Legacy BIOS installations still >> supported). >> ** anaconda: No change (there could be only optional cleanups in the >> code). However, it needs to be verified. >> ** Lorax: Code has already been written: >> https://github.com/weldr/lorax/pull/1205 >> > > This pull request primarily drops legacy BIOS support by dropping > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > support there if we reuse GRUB there too. Other distributions > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on > live media. > >> * Other developers: >> ** libvirt: UEFI works today, but is not the default. UEFI-only >> installation is needed for Windows 11, and per conversations, libvirt >> is prepared for this change. >> ** Virtualbox: UEFI Fedora installs are working and per virtualbox >> team, UEFI will
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b3413eba96 chromium-99.0.4844.84-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a3ae41bd1e unrealircd-6.0.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing copr-cli-1.100-1.el7 libre-2.2.1-1.el7 python-copr-1.119-1.el7 Details about builds: copr-cli-1.100-1.el7 (FEDORA-EPEL-2022-49ba5c52a1) Command line interface for COPR Update Information: - support for GSSAPI authentication added - re-try 3x the connection to Frontend upon failures - ensure that (error/info) logging is printed even without --debug - list-package-names now uses API pagination ChangeLog: * Mon Apr 4 2022 Pavel Raiskup 1.100-1 - list-package-names now uses pagination - ensure that (error/info) logging is printed even without --debug - support for GSSAPI authentication added - re-try 3x the connection to Frontend upon failures libre-2.2.1-1.el7 (FEDORA-EPEL-2022-1ab0aad07e) Library for real-time communications and SIP stack Update Information: # libre v2.2.1 (2022-04-01) - cmake: add packaging - sha: add sha 256 and 512 digest length OpenSSL compats - main: use `Winsock2.h` - cmake: for Android platform don't enable `ifaddrs`/`getifaddrs` - sa/sa_is_loopback: check full IPv4 loopback range (127.0.0.0/8) ChangeLog: * Sat Apr 2 2022 Robert Scheck 2.2.1-1 - Upgrade to 2.2.1 (#2071123) References: [ 1 ] Bug #2071123 - libre-2.2.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2071123 python-copr-1.119-1.el7 (FEDORA-EPEL-2022-49ba5c52a1) Python interface for Copr Update Information: - support for GSSAPI authentication added - re-try 3x the connection to Frontend upon failures - ensure that (error/info) logging is printed even without --debug - list-package-names now uses API pagination ChangeLog: * Mon Apr 4 2022 Pavel Raiskup 1.119-1 - really depend on filelock component * Mon Apr 4 2022 Pavel Raiskup 1.118-1 - drop the python-mock build-requires again * Mon Apr 4 2022 Pavel Raiskup 1.117-1 - support for GSSAPI added (gssapi=true config option) - better error message when authentication fails - add a connection_attempts, retries connection to Frontend upon failure ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #20: 6.62 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.62 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/20 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood wrote: Users wishing to use NVIDIA hardware have the following options: - Use nouveau (free, open source, cool) - Sign their own copy of the proprietary driver (involves messing with certificates, so not appropriate for all users) - Disable Secure Boot (note that this is still UEFI) The NVIDIA driver is proprietary, so of course it's not going to get signed. The user experience requirement is: user searches for NVIDIA in GNOME Software and clicks Install. No further action should be necessary. We didn't make the NVIDIA driver available from the graphical installer with the intention that arcane workarounds would be required to use it. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFI/RFC: Fedora Linux graphical recovery environment
On Tue, Apr 5, 2022 at 9:47 AM stan via devel wrote: > On Mon, 4 Apr 2022 15:58:14 -0500 > Gregory Bartholomew wrote: > > > > Of topic but related: I wish there was supported option to remove > > > the current rescue kernel, > > > > Is echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf not > > sufficient? > > That is an interesting option. It isn't documented in man dracut.conf. > Is it new? It's definitely not new. I didn't realize it wasn't documented. I don't remember where I found that info now. I may have gotten it from reading the /usr/lib/kernel/install.d/51-dracut-rescue.install script directly. > I just manually remove the rescue vmlinuz and initramfs and > then run > /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" > /lib/modules/$(uname -r)/vmlinuz > in the /boot directory to build a new rescue kernel from the currently > running kernel. Is there an option to do that also? i.e. I invoke dracut from the command line and it automatically does all that if a > rescue_build.conf file is present in /etc/dracut.conf.d/ > Well sort of. If you really want complete control over how the rescue kernels are installed one option is to copy the /usr/lib/kernel/install.d/51-dracut-rescue.install script to /etc/kernel/install.d and tweak it to do whatever you want under whatever conditions you want. As long as the script under /etc/kernel/install.d has the same name as the script under /usr/lib/kernel/install.d, it will override (i.e. run instead of) the one under /usr/lib/kernel/install.d. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #20: 6.62 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.62 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/20 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 36 compose report: 20220405.n.0 changes
OLD: Fedora-36-20220404.n.0 NEW: Fedora-36-20220405.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 16 Dropped packages:1 Upgraded packages: 49 Downgraded packages: 0 Size of added packages: 37.83 MiB Size of dropped packages:9.07 MiB Size of upgraded packages: 900.99 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 20.20 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-36-20220405.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: idevicerestore-1.0.0-1.fc36 Summary: Restore/upgrade firmware of iOS devices RPMs:idevicerestore Size:464.93 KiB Package: libirecovery-1.0.0-1.fc36 Summary: Library and utility to talk to iBoot/iBSS via USB RPMs:libirecovery libirecovery-devel libirecovery-utils Size:364.16 KiB Package: podman-tui-0.3.0-1.fc36 Summary: Podman Terminal User Interface RPMs:podman-tui Size:34.92 MiB Package: python-aexpect-1.6.2-1.module_f36+14042+e4a0adf0 Summary: A python library to control interactive applications RPMs:python3-aexpect Size:90.52 KiB Package: python-avocado-95.0-1.module_f36+14201+0a39d4df Summary: Framework with tools and libraries for Automated Testing RPMs:python-avocado-bash python-avocado-common python-avocado-examples python3-avocado python3-avocado-plugins-golang python3-avocado-plugins-output-html python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict python3-avocado-plugins-varianter-yaml-to-mux Size:936.11 KiB Package: python-myrepos-utils-0.0.2-2.fc36 Summary: Additional utilities for myrepos RPMs:myrepos-utils Size:22.61 KiB Package: rust-indenter-0.3.3-1.fc36 Summary: Formatter wrapper that indents the text, designed for error display impls RPMs:rust-indenter+default-devel rust-indenter+std-devel rust-indenter-devel Size:27.77 KiB Package: rust-is_ci-1.1.1-1.fc36 Summary: Super lightweight CI environment checker RPMs:rust-is_ci+default-devel rust-is_ci-devel Size:18.95 KiB Package: rust-miette-4.2.1-1.fc36 Summary: Fancy diagnostic reporting library and protocol for us mere mortals who aren't compiler hackers RPMs:rust-miette+atty-devel rust-miette+backtrace-devel rust-miette+default-devel rust-miette+fancy-devel rust-miette+owo-colors-devel rust-miette+supports-color-devel rust-miette+supports-hyperlinks-devel rust-miette+supports-unicode-devel rust-miette+terminal_size-devel rust-miette+textwrap-devel rust-miette-devel Size:146.79 KiB Package: rust-miette-derive-4.2.1-1.fc36 Summary: Derive macros for miette RPMs:rust-miette-derive+default-devel rust-miette-derive-devel Size:30.51 KiB Package: rust-nu-ansi-term-0.45.1-1.fc36 Summary: Library for ANSI terminal colors and styles (bold, underline) RPMs:rust-nu-ansi-term+default-devel rust-nu-ansi-term+derive_serde_style-devel rust-nu-ansi-term+serde-devel rust-nu-ansi-term-devel Size:50.51 KiB Package: rust-owo-colors-3.3.0-1.fc36 Summary: Zero-allocation terminal colors that'll make people go owo RPMs:rust-owo-colors+default-devel rust-owo-colors+supports-color-devel rust-owo-colors+supports-colors-devel rust-owo-colors-devel Size:53.38 KiB Package: rust-supports-color-1.3.0-1.fc36 Summary: Detects whether a terminal supports color, and gives details about that support RPMs:rust-supports-color+default-devel rust-supports-color-devel Size:24.13 KiB Package: rust-supports-hyperlinks-1.2.0-1.fc36 Summary: Detects whether a terminal supports rendering hyperlinks RPMs:rust-supports-hyperlinks+default-devel rust-supports-hyperlinks-devel Size:22.34 KiB Package: rust-supports-unicode-1.0.2-1.fc36 Summary: Detects whether a terminal supports unicode RPMs:rust-supports-unicode+default-devel rust-supports-unicode-devel Size:21.96 KiB Package: stressapptest-1.0.9-1.20220222git6714c57.fc36 Summary: Stressful Application Test - userspace memory and IO test RPMs:stressapptest Size:696.79 KiB = DROPPED PACKAGES = Package: golang-github-jamesclonk-vultr-2.0.3-3.fc36 Summary: Vultr CLI and API client library RPMs:golang-github-jamesclonk-vultr golang-github-jamesclonk-vultr-devel Size:9.07 MiB = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.12.44-1.fc36 Old package: ImageMagick-1:6.9.12.40-1.fc36 Summary: An X application for displaying and manipulating images RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs ImageMagick-perl Size: 40.73 MiB Size change: -434.56 KiB Changelog: * Tue Mar 15 2022 Luya Tshimbalanga - 1:6.9.12.42-1 - New upstream release 6.9.12.42 * Wed Mar 23 2022 Luya Tshimbalanga - 1:6.9.12.43-1 - New
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Neal Gompa writes: > And we've still failed to get ARM and RISC-V broadly on board with > UEFI This statement is not correct. ARM in Fedora is UEFI-only, and we were both in the Plumbers conversation around RISC-V's booting. > We also lack solutions for dealing with the NVIDIA driver in > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > Because we still don't have a way to have kernel-only keyrings for > secure boot certificates to avoid importing them into the firmware. Users wishing to use NVIDIA hardware have the following options: - Use nouveau (free, open source, cool) - Sign their own copy of the proprietary driver (involves messing with certificates, so not appropriate for all users) - Disable Secure Boot (note that this is still UEFI) The NVIDIA driver is proprietary, so of course it's not going to get signed. Be well, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #19: 6.62 bump
mspacek merged a pull-request against the project: `perl-libwww-perl` that you are following. Merged pull-request: `` 6.62 bump `` https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/19 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
* Peter Robinson: > This is out of context here because you can disable Secure Boot but > still use UEFI to make that work. You're trying to link to different > problems together. I think there's firmware out there which enables Secure Boot unconditionally in UEFI mode, but still has CSM support. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 11:26 AM Peter Robinson wrote: > > On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa wrote: > > > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: > > > > > > 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. > > > > > > == Owner == > > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > > > Konečný]], [[User:bcl| Brian C. Lane]] > > > * Email: rharw...@redhat.com > > > > > > > > > == Detailed Description == > > > UEFI is defined by a versioned standard that can be tested and > > > certified against. By contrast, every legacy BIOS is unique. Legacy > > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > > > and on its way out. As it ages, maintainability has decreased, and > > > the status quo of maintaining both stacks in perpetuity is not viable > > > for those currently doing that work. > > > > > > It is inevitable that legacy BIOS will be removed in a future release. > > > To ease this transition as best we can, there will be a period (of at > > > least one Fedora release) where it will be possible to boot using the > > > legacy BIOS codepaths, but new installations will not be possible. > > > While it would be easier for us to cut support off today, our hope is > > > that this compromise position will make for a smoother transition. > > > Additional support with issues during the transition would be > > > appreciated. > > > > > > While this will eventually reduce workload for boot/installation > > > components (grub2 reduces surface area, syslinux goes away entirely, > > > anaconda reduces surface area), the reduction in support burden > > > extends much further into the stack - for instance, VESA support can > > > be removed from the distro. > > > > > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > > > mandates that machines must have been made after 2006). Like the > > > already accepted Fedora 37 change to retire ARMv7 support, the > > > hardware targeted tends to be rather underpowered by today’s > > > standards, and the world has moved on from it. Intel stopped shipping > > > the last vestiges of BIOS support in 2020 (as have other vendors, and > > > Apple and Microsoft), so this is clearly the way things are heading - > > > and therefore aligns with Fedora’s “First” objective. > > > > > > == Feedback == > > > Dropping legacy BIOS was previously discussed (but not proposed) in 2020: > > > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > > > Important, relevant points from that thread (yes, I reread the entire > > > thread) that have informed this change: > > > > > > * Some machines are BIOS-only. This change does not prevent their use > > > yet, but they are effectively deprecated. grub2 (our default > > > bootloader) is already capable of both BIOS and UEFI booting. > > > * Drawing a clear year cutoff, let alone a detailed list of hardware > > > this change affects, is basically impossible. This is unfortunate but > > > unlikely to ever change. > > > * There is no migration story from Legacy BIOS to UEFI - > > > repartitioning effectively mandates a reinstall. As a result, we > > > don’t drop support for existing Legacy BIOS systems yet, just new > > > installations. > > > * There is no way to deprecate hardware without causing some amount of > > > friction. > > > * While at the time AWS did not support UEFI booting, that is no > > > longer the case and they support UEFI today. > > > > > > == Benefit to Fedora == > > > UEFI is required for many desirable features, including applying > > > firmware updates (fwupd) and supporting SecureBoot. As a standalone > > > change, it reduces support burden on everything involved in installing > > > Fedora, since there becomes only one way to do it per platform. > > > Finally, it simplifies our install/live media, since it too only has > > > to boot one way per arch. Freedom Friends Features First - this is > > > that last one. > > > > > > == Scope == > > > * Proposal owners: > > > ** bootloaders: No change (existing Legacy BIOS installations still > > > supported). > > > ** anaconda: No change (there could be only optional cleanups in the > > > code). However, it needs to be verified. > > > ** Lorax: Code has already been written: > > > https://github.com/weldr/lorax/pull/1205 > > > > > > > This pull request primarily drops legacy BIOS support by dropping > > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > > support there if we reuse GRUB there too. Other distributions > > (openSUSE and Mageia, notably) both use GRUB for
[Bug 2071865] perl-libwww-perl-6.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2071865 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Michal Josef Spacek --- Changes: 6.62 2022-04-05 01:04:17Z - Allow downloading to a filehandle (GH#400) (Andrew Fresh) Added new functionality, possible for f34, f35, f36 and rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2071865 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-libwww-perl] PR #19: 6.62 bump
mspacek opened a new pull-request against the project: `perl-libwww-perl` that you are following: `` 6.62 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/19 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, 2022-04-05 at 10:52 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > Important, relevant points from that thread (yes, I reread the entire > thread) that have informed this change: > > * Some machines are BIOS-only. This change does not prevent their > use > yet, but they are effectively deprecated. grub2 (our default > bootloader) is already capable of both BIOS and UEFI booting. > * Drawing a clear year cutoff, let alone a detailed list of hardware > this change affects, is basically impossible. This is unfortunate > but > unlikely to ever change. > * There is no migration story from Legacy BIOS to UEFI - > repartitioning effectively mandates a reinstall. As a result, we > don’t drop support for existing Legacy BIOS systems yet, just new > installations. > * There is no way to deprecate hardware without causing some amount > of friction. > * While at the time AWS did not support UEFI booting, that is no > longer the case and they support UEFI today. > Even though aws supports UEFI, many vps providers do not(Vultr and Linode are some examples). But having a soft corner for Systemd-boot and UEFI in general, I think there could be a middle ground. I believe most BIOSes can boot GPT formated disk although there are few that can not and I believe windows never supported this config. But since most of the remaining consumers which real need this configs are VPSes which generaly do not dual boot with windows. Also we can drop support for all bios only bootloader as grub is good enough here. If there is a way to push these companies to to switch to UEFI based VM , that should be done. But removing all other bios config except for bios + grub + gpt could be a fesible starting point. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 4:09 PM Neal Gompa wrote: > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: > > > > 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. > > > > == Owner == > > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > > Konečný]], [[User:bcl| Brian C. Lane]] > > * Email: rharw...@redhat.com > > > > > > == Detailed Description == > > UEFI is defined by a versioned standard that can be tested and > > certified against. By contrast, every legacy BIOS is unique. Legacy > > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > > and on its way out. As it ages, maintainability has decreased, and > > the status quo of maintaining both stacks in perpetuity is not viable > > for those currently doing that work. > > > > It is inevitable that legacy BIOS will be removed in a future release. > > To ease this transition as best we can, there will be a period (of at > > least one Fedora release) where it will be possible to boot using the > > legacy BIOS codepaths, but new installations will not be possible. > > While it would be easier for us to cut support off today, our hope is > > that this compromise position will make for a smoother transition. > > Additional support with issues during the transition would be > > appreciated. > > > > While this will eventually reduce workload for boot/installation > > components (grub2 reduces surface area, syslinux goes away entirely, > > anaconda reduces surface area), the reduction in support burden > > extends much further into the stack - for instance, VESA support can > > be removed from the distro. > > > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > > mandates that machines must have been made after 2006). Like the > > already accepted Fedora 37 change to retire ARMv7 support, the > > hardware targeted tends to be rather underpowered by today’s > > standards, and the world has moved on from it. Intel stopped shipping > > the last vestiges of BIOS support in 2020 (as have other vendors, and > > Apple and Microsoft), so this is clearly the way things are heading - > > and therefore aligns with Fedora’s “First” objective. > > > > == Feedback == > > Dropping legacy BIOS was previously discussed (but not proposed) in 2020: > > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > > > Important, relevant points from that thread (yes, I reread the entire > > thread) that have informed this change: > > > > * Some machines are BIOS-only. This change does not prevent their use > > yet, but they are effectively deprecated. grub2 (our default > > bootloader) is already capable of both BIOS and UEFI booting. > > * Drawing a clear year cutoff, let alone a detailed list of hardware > > this change affects, is basically impossible. This is unfortunate but > > unlikely to ever change. > > * There is no migration story from Legacy BIOS to UEFI - > > repartitioning effectively mandates a reinstall. As a result, we > > don’t drop support for existing Legacy BIOS systems yet, just new > > installations. > > * There is no way to deprecate hardware without causing some amount of > > friction. > > * While at the time AWS did not support UEFI booting, that is no > > longer the case and they support UEFI today. > > > > == Benefit to Fedora == > > UEFI is required for many desirable features, including applying > > firmware updates (fwupd) and supporting SecureBoot. As a standalone > > change, it reduces support burden on everything involved in installing > > Fedora, since there becomes only one way to do it per platform. > > Finally, it simplifies our install/live media, since it too only has > > to boot one way per arch. Freedom Friends Features First - this is > > that last one. > > > > == Scope == > > * Proposal owners: > > ** bootloaders: No change (existing Legacy BIOS installations still > > supported). > > ** anaconda: No change (there could be only optional cleanups in the > > code). However, it needs to be verified. > > ** Lorax: Code has already been written: > > https://github.com/weldr/lorax/pull/1205 > > > > This pull request primarily drops legacy BIOS support by dropping > syslinux/isolinux. We don't necessarily have to drop legacy BIOS > support there if we reuse GRUB there too. Other distributions > (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on > live media. > > > * Other developers: > > ** libvirt: UEFI works today, but is not the default. UEFI-only > > installation is needed for Windows 11, and per conversations, libvirt > > is prepared for this change. > > **
[Test-Announce] Fedora 36 Branched 20220405.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 36 Branched 20220405.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20220401.n.0: anaconda-36.16.2-4.fc36.src, 20220405.n.0: anaconda-36.16.4-1.fc36.src pyparted - 20220401.n.0: pyparted-3.11.7-5.fc36.src, 20220405.n.0: pyparted-3.12.0-1.fc36.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_36_Branched_20220405.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org 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/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFI/RFC: Fedora Linux graphical recovery environment
On Tue, Apr 5, 2022 at 10:47 AM stan via devel wrote: > > On Mon, 4 Apr 2022 15:58:14 -0500 > Gregory Bartholomew wrote: > > > > Of topic but related: I wish there was supported option to remove > > > the current rescue kernel, > > > > Is echo "dracut_rescue_image=no" > /etc/dracut.conf.d/rescue.conf not > > sufficient? > > That is an interesting option. It isn't documented in man dracut.conf. > Is it new? I just manually remove the rescue vmlinuz and initramfs and > then run > /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" > /lib/modules/$(uname -r)/vmlinuz > in the /boot directory to build a new rescue kernel from the currently > running kernel. Is there an option to do that also? i.e. I invoke > dracut from the command line and it automatically does all that if a > rescue_build.conf file is present in /etc/dracut.conf.d/ You could also just remove the "dracut-config-rescue" package from your system. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton wrote: > > 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. > > == Owner == > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > Konečný]], [[User:bcl| Brian C. Lane]] > * Email: rharw...@redhat.com > > > == Detailed Description == > UEFI is defined by a versioned standard that can be tested and > certified against. By contrast, every legacy BIOS is unique. Legacy > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > and on its way out. As it ages, maintainability has decreased, and > the status quo of maintaining both stacks in perpetuity is not viable > for those currently doing that work. > > It is inevitable that legacy BIOS will be removed in a future release. > To ease this transition as best we can, there will be a period (of at > least one Fedora release) where it will be possible to boot using the > legacy BIOS codepaths, but new installations will not be possible. > While it would be easier for us to cut support off today, our hope is > that this compromise position will make for a smoother transition. > Additional support with issues during the transition would be > appreciated. > > While this will eventually reduce workload for boot/installation > components (grub2 reduces surface area, syslinux goes away entirely, > anaconda reduces surface area), the reduction in support burden > extends much further into the stack - for instance, VESA support can > be removed from the distro. > > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > mandates that machines must have been made after 2006). Like the > already accepted Fedora 37 change to retire ARMv7 support, the > hardware targeted tends to be rather underpowered by today’s > standards, and the world has moved on from it. Intel stopped shipping > the last vestiges of BIOS support in 2020 (as have other vendors, and > Apple and Microsoft), so this is clearly the way things are heading - > and therefore aligns with Fedora’s “First” objective. > > == Feedback == > Dropping legacy BIOS was previously discussed (but not proposed) in 2020: > https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ > > Important, relevant points from that thread (yes, I reread the entire > thread) that have informed this change: > > * Some machines are BIOS-only. This change does not prevent their use > yet, but they are effectively deprecated. grub2 (our default > bootloader) is already capable of both BIOS and UEFI booting. > * Drawing a clear year cutoff, let alone a detailed list of hardware > this change affects, is basically impossible. This is unfortunate but > unlikely to ever change. > * There is no migration story from Legacy BIOS to UEFI - > repartitioning effectively mandates a reinstall. As a result, we > don’t drop support for existing Legacy BIOS systems yet, just new > installations. > * There is no way to deprecate hardware without causing some amount of > friction. > * While at the time AWS did not support UEFI booting, that is no > longer the case and they support UEFI today. > > == Benefit to Fedora == > UEFI is required for many desirable features, including applying > firmware updates (fwupd) and supporting SecureBoot. As a standalone > change, it reduces support burden on everything involved in installing > Fedora, since there becomes only one way to do it per platform. > Finally, it simplifies our install/live media, since it too only has > to boot one way per arch. Freedom Friends Features First - this is > that last one. > > == Scope == > * Proposal owners: > ** bootloaders: No change (existing Legacy BIOS installations still > supported). > ** anaconda: No change (there could be only optional cleanups in the > code). However, it needs to be verified. > ** Lorax: Code has already been written: > https://github.com/weldr/lorax/pull/1205 > This pull request primarily drops legacy BIOS support by dropping syslinux/isolinux. We don't necessarily have to drop legacy BIOS support there if we reuse GRUB there too. Other distributions (openSUSE and Mageia, notably) both use GRUB for both BIOS and UEFI on live media. > * Other developers: > ** libvirt: UEFI works today, but is not the default. UEFI-only > installation is needed for Windows 11, and per conversations, libvirt > is prepared for this change. > ** Virtualbox: UEFI Fedora installs are working and per virtualbox > team, UEFI will be/is the default in 7.0+. > ** The Hardware Overview page should be updated to mention the UEFI > requirement: >
[Bug 2071784] perl-Chart-2.401.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2071784 Petr Pisar changed: What|Removed |Added Resolution|--- |RAWHIDE Status|MODIFIED|CLOSED Last Closed||2022-04-05 15:03:52 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2071784 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org 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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
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. == Owner == * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří Konečný]], [[User:bcl| Brian C. Lane]] * Email: rharw...@redhat.com == Detailed Description == UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. Legacy BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) and on its way out. As it ages, maintainability has decreased, and the status quo of maintaining both stacks in perpetuity is not viable for those currently doing that work. It is inevitable that legacy BIOS will be removed in a future release. To ease this transition as best we can, there will be a period (of at least one Fedora release) where it will be possible to boot using the legacy BIOS codepaths, but new installations will not be possible. While it would be easier for us to cut support off today, our hope is that this compromise position will make for a smoother transition. Additional support with issues during the transition would be appreciated. While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro. Fedora already requires a 2GHz dual core CPU at minimum (and therefore mandates that machines must have been made after 2006). Like the already accepted Fedora 37 change to retire ARMv7 support, the hardware targeted tends to be rather underpowered by today’s standards, and the world has moved on from it. Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora’s “First” objective. == Feedback == Dropping legacy BIOS was previously discussed (but not proposed) in 2020: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/ Important, relevant points from that thread (yes, I reread the entire thread) that have informed this change: * Some machines are BIOS-only. This change does not prevent their use yet, but they are effectively deprecated. grub2 (our default bootloader) is already capable of both BIOS and UEFI booting. * Drawing a clear year cutoff, let alone a detailed list of hardware this change affects, is basically impossible. This is unfortunate but unlikely to ever change. * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. * There is no way to deprecate hardware without causing some amount of friction. * While at the time AWS did not support UEFI booting, that is no longer the case and they support UEFI today. == Benefit to Fedora == UEFI is required for many desirable features, including applying firmware updates (fwupd) and supporting SecureBoot. As a standalone change, it reduces support burden on everything involved in installing Fedora, since there becomes only one way to do it per platform. Finally, it simplifies our install/live media, since it too only has to boot one way per arch. Freedom Friends Features First - this is that last one. == Scope == * Proposal owners: ** bootloaders: No change (existing Legacy BIOS installations still supported). ** anaconda: No change (there could be only optional cleanups in the code). However, it needs to be verified. ** Lorax: Code has already been written: https://github.com/weldr/lorax/pull/1205 * Other developers: ** libvirt: UEFI works today, but is not the default. UEFI-only installation is needed for Windows 11, and per conversations, libvirt is prepared for this change. ** Virtualbox: UEFI Fedora installs are working and per virtualbox team, UEFI will be/is the default in 7.0+. ** The Hardware Overview page should be updated to mention the UEFI requirement: https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/Hardware_Overview/ * Release engineering: [https://pagure.io/releng/issue/10738 #Releng issue 10738] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Systems currently using Legacy BIOS for booting on x86_64 will continue to do so. However, this modifies the baseline Fedora requirements and some hardware will no longer be supported for new installations.
