Fedora 37 Looks To Deprecate Legacy BIOS Support

[birdie]

I like lilo

This one is actually dead, it's horribly difficult to setup, it needs direct disk access and breaks far too often.

My favourite boot loader has always been ASP Linux Boot Loader but probably no one here has ever heard about it.

[RahulSundaram]

From the proposal page:

Contingency Plan
Leave things as they are. Code continues to rot.

What?? What's there to rot if there are no modern PCs with BIOS and ADL/Zen 4 systems lack compatibility mode/CSM altogether? It works, it doesn't need to be maintained.... It's like saying that true/false utilities from coreutils need maintenance.

Boot loader code is not at all similar to a simple coreutils binary. It is a lot more complicated. Changes in GRUB routinely break legacy code and then there are blocker bugs on a release because it is part of the release criteria to support both modes. If you are curious to learn more, look at the qa blocker bugs app in Fedora.

[birdie]

Boot loader code is not at all similar to a simple coreutils binary. It is a lot more complicated. Changes in GRUB routinely break legacy code and then there are blocker bugs on a release because it is part of the release criteria to support both modes. If you are curious to learn more, look at the qa blocker bugs app in Fedora.

GRUB2 has two distinct code paths: BIOS and EFI and I've believed they are quite distinct. Any references to the aforementioned breakage?

[RahulSundaram]

GRUB2 has two distinct code paths: BIOS and EFI and I've believed they are quite distinct. Any references to the aforementioned breakage?

If you are curious to learn more, look up the qa blocker bugs app in Fedora or reach out the developers involved in the proposal and they might be able to give you some examples.

[birdie]

ASPLinux Loader:

[sinepgib]

Boot loader code is not at all similar to a simple coreutils binary. It is a lot more complicated. Changes in GRUB routinely break legacy code and then there are blocker bugs on a release because it is part of the release criteria to support both modes. If you are curious to learn more, look at the qa blocker bugs app in Fedora.

And eventually dropping VESA is also mentioned, which I heard (not corroborated tho) many cards tend to be non-compliant and require workarounds, and in that case code rot is bound to happen as the mainstream moves to a BIOS-less world. There are also some BIOS services for which you can stop building paths AFAIK, that are also likely to become less well tested.

[sinepgib]

ASPLinux Loader:

Where can I find more information about this?

[RahulSundaram]

And eventually dropping VESA is also mentioned, which I heard (not corroborated tho) many cards tend to be non-compliant and require workarounds, and in that case code rot is bound to happen as the mainstream moves to a BIOS-less world. There are also some BIOS services for which you can stop building paths AFAIK, that are also likely to become less well tested.

Yes, there is a lot of components involved in the boot process and configuration (anaconda, shim, grub, syslinux, systemd, kernel..) and it is a large surface area. Up until this change it also involved grubby. Some of this has gotten better over time (GRUB upstream used to inactive for a while) but I understand the temptation to try to simplify it. It is probably too early and I expect the proposal to get rejected but the feedback is useful to collect for now I suppose.

[stormcrow]

When I say capable, I mean only performance wise. For example, i7 920 is still a pretty capable CPU today. Idk, what CPU bugs are you talking about, but apart from my main PC, I also have an old Core 2 Quad Q8200 system and it runs any modern OS without any issues.

Perhaps so. But that's only because in the months and years after Nehalem was released the C-states bug and the spurious interrupts bug which makes the CPU unstable (and I believe they're related) and any other errata (including Spectre and modern performance killing bugs) have been partially worked around in software. Since they're CPU bugs they affect how all OSes run on Nehalem & Westmere CPUs.

Your system may be capable for your particular use case; that's fine. I'm just pointing out that the example given is probably one of the worst ones that could have been brought up because of its awful errata history.

[birdie]

Where can I find more information about this?

The last version of this distro with this loader: http://ftp.vim.org/pub/os/Linux/dist...inux/i386/7.3/
A Wikipedia article in Russian: https://ru.wikipedia.org/wiki/ASPLinux

The distro died around 2009, so there's very little information.

I've digged a little, here's what I've found out:

• This bootloader was closed source and written by SWsoft Pte. which was later renamed into Parallels.
• A very similarly looking bootloader was developed by Acronis, maybe it's a shared/reused product, it is called Acronis OS Selector. Version 8 looks almost the same as ASPLinux Loader.

Acronis and Parallels have the same co-founders, Maxim Tsyplyaev and Serguei Beloussov (Serg Bell), so I wonder if these are the same product or not. Very well might be.