Hi, On 4/6/22 16:23, Neal Gompa wrote: > On Wed, Apr 6, 2022 at 10:18 AM Hans de Goede <hdego...@redhat.com> wrote: >> >> Hi, >> >> <to be clear I'm replying on a personal title here, not on >> behalf of my employer (Red Hat)> >> >> On 4/5/22 16:52, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS >> >> <snip> >> >>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore >>> mandates that machines must have been made after 2006). >> >> But machines made between 2006-2012 generally did not have >> EFI support, anf for example at home I still have several >> machines from that era which are BIOS only in active use: >> >> 1. My daughter's workstation is an i5-2400 with 8G RAM, this >> is a 3.1 GHz base-freq quad-core processor very easily >> matching Fedora's minimal requirements. Currently running >> Fedora 35 just fine. Making it impossible to keep using this >> in the future is just causing unnecessary ewaste for no good >> reason IMHO. >> >> 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual >> core machine with 4G RAM, which also still works fine for >> what she uses it for. >> >> 3. The living room laptop is another Core 2 Duo machine with >> 4G RAM. >> >> Looking specifically at fixed PCs and not laptops this >> proposal would (eventually) turn 2/5 PCs in my home >> unusable, which really is unacceptable IMHO. >> >> Also note that all these machines use somewhat older Intel >> integrated graphics. As he has already mentioned on this >> this thread, Dave Airlie has just spend a lot of time on >> making sure those iGPU-s will work with a gallium driver >> so that the classic mesa code can be removed and it seems >> rather silly to drop support for this hw after just investing >> a significant chunk of time to breathe new live into their >> GPU support. >> >> So a big -1 from me for this proposal as it stand. >> >> ### >> >> But I do completely understand that there is a workload issue >> for the bootloader team and the proposal also mentions: >> >>> == Contingency Plan == >>> Leave things as they are. Code continues to rot. Community >>> assistance is required to continue the status quo. Current owners >>> plan to orphan some packages regardless of whether the proposal is >>> accepted. >> >> If the current owners no longer want to support some packages >> which are only necessary for legacy BIOS support, then orphaning >> these seems completely reasonable to me. >> >> Maybe you can provide a list of these pkgs before hand so that >> people can already volunteer as co-maintainers now and then >> when they are orphaned, instead of orphaning them they can >> be directly handed over (using the "give away" button) to the >> new maintainers ? >> >>> Another fallback option could be, if a Legacy BIOS SIG organizes, to >>> donate the relevant packages there and provide some initial mentoring. >> >> I believe that that is a great idea, I hereby volunteer to >> try and setup such a SIG. If anyone reading this is interested >> in joining such a SIG please drop me an email. >> >> I realize that there have been similar attempts around keeping >> 32 bit x86 alive and that those have failed, but I believe that >> this is different for a number of reasons: >> >> 1. i686 support required making sure that *all* of Fedora kept >> working on i686, the problem was not just the kernel breaking >> sometimes, but also that huge projects like libreoffice would >> no longer start on i686 (at least on some of my machines). >> >> Legacy BIOS boot support is basically only about the image-creation >> tools + the bootloader. As various people have mentioned in the >> thread BIOS support is still very much a thing in data-centers, >> so I expect the upstream kernel community to keep the kernel >> working with this for at least a couple of years. Where as both >> the kernel + many userspace apps were breaking on i686. >> >> 2. I personally basically gave up on i686 support also because >> there was very little 32 bit only x86 hw around remaining in >> active use when it was dropped. And what was still on active >> use was getting close to unusable from a performance pov. >> Where as here we are talking about up to 2nd and 3th gen >> core i5 / i7 machines which are still quite performant. >> >> Esp. the 2nd gen core machines (Sandy Bridge) are still >> quite popular and lots of people have hung on to desktops >> with those because the CPU performance increase in generations >> after SNB have been rather underwhelming. >> >>> Longer term, packages that cannot be wholly donated could be split, >>> though it is unclear whether the synchronization thereby required >>> would reduce the work for anyone. >> >> I've been thinking about how this could be done for grub; also >> because of the issue that the EFI builds of grub need to be >> signed with Fedora's secure boot keys, which means only a few >> people can do grub2 builds atm. >> >> One option which I think we should consider is sticking with >> a single downstream git fork (until we have managed to get >> everything we need upstream), so stick with: >> >> https://github.com/rhboot/grub2/ >> >> As the Source0 provider for the packages and then next to: >> >> https://src.fedoraproject.org/rpms/grub2 >> >> Add a: >> >> https://src.fedoraproject.org/rpms/grub2-bios >> >> And moving the build of all sub-packages which are >> only necessary for BIOS support to the second src.rpm. >> >> This way the Legacy BIOS SIG could maintain >> the grub2-bios src.rpm (and binary pkgs it builds). >> The SIG _must_ then of course still submit pull-reqs to: >> https://github.com/rhboot/grub2/ for any changes. >> >> But in case of e.g. a beta blocking BIOS only bug they >> could solve that with a patch in the src.rpm and kickof >> a build right away without blocking on the bootloader >> team and thus without causing a spike in >> work-pressure/load for the bootloader team. >> >> And then once the pull-req is merged (possibly >> a revised version of it) the next build of >> the grub2-bios src.rpm can pull in the new Source0 >> and drop its local changes (IOW grub2-bios _must_ >> not become a separate fork). >> > > Constructively speaking, I would prefer to drop syslinux regardless, > and porting lorax templates to use GRUB for BIOS boot for live media > instead of syslinux as other distributions have done would drastically > reduce the burden of things. Syslinux is a special burden in itself > and I'd rather have it gone.
I agree that it would be good if we don't need to maintain both syslinux and grub, but that would require someone to actually find the time to adjust lorax and then run a whole bunch of tests after that to ensure the new way of doing things will still work on most (legacy BIOS) hw. Regards, Hans _______________________________________________ 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
