Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fedora considers deprecating legacy BIOS

lwn.net

Post reply on HN
Print view View original

141–150 of 233 posts

Re: Fedora considers deprecating legacy BIOS

#141

Post by edgyquant »

sounds wrote: post #131
mjg59 wrote: post #25

Earlier quoted context omitted.

- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…

Quoted post unavailable.

I don’t think this is an important detail, if anything it may skew people against them as it seems they have corporate interests

Re: Fedora considers deprecating legacy BIOS

#142

Post by cestith »

lynguist wrote: post #98

According to Wikipedia, Intel’s 945 chipset for Core 2 processors ships with UEFI. This was originally released in 2006. Note that Google Chrome which is the web browser with the highest adoption rate requires a CPU with SSE3 support which was introduced in 2004. Which platform older than a Core 2 can even run the latest operating systems? The very latest Pentium 4 range (2004-2006)? So we would just be dropping supp…

OpenBSD 7.1 was just released and supports my G5 Mac. It also supports i386, UltraSparc, and Digital Alpha.

NetBSD supports i386, Alpha, Amiga, 32-bit Sparc, 32-bit MIPS, ARMv6, StrongARM, sun2, sun3...

LinuxMint still supports i686.

Debian supports i386, i686, armel, armhf, s390, and MIPS.

Slackware supports i586 and s390.

Kali supports i686.

Void Linux supports i686, ARMv6, ARV7.

FreeBSD supports arm, armel, i386, ia64, mips, mipsel, sparc64, pc98, powerpc, powerpc64, ps3, xbox.

Alpine supports i486, ppc64le, s390x, armhf.

Devuan supports i686.

Gentoo supports i486, i586, i686, alpha, arm, hppa, ia64, mips, powerpc, ppc64, sparc64.

Which of these don't have recent releases?

Re: Fedora considers deprecating legacy BIOS

#143

Post by cestith »

A whole lot of the maintenance headache could be solved by choosing five or fewer BIOS implementations to fully support and letting everything else go by the wayside. Choose the ones from VMware, VirtualBox, and such and a couple of popular server and desktop ones.

Re: Fedora considers deprecating legacy BIOS

#144

Post by Sharlin »

AshamedCaptain wrote: post #62
mjg59 wrote: post #31

My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now.…

Drawing the line at 10 years old is ... way too close for comfort. I could understand to drop i386 because it basically amounts to another entire architecture, and besides it seems with i386 you are also generally RAM limited which makes it harder to use a recent DE. But a 10 year old computer is perfectly capable of running even the latest version of the heavy-est DEs. Also, "working UEFI supports" means working eno…

My current desktop's motherboard and CPU are from 2009. I have no idea if the MB supports UEFI; it definitely boots to BIOS by default. I've upgraded the storage, memory, and GPU, but there's been little cause to waste money on a new MB/CPU. But I guess I wouldn't install Fedora on this machine anyway, so shrug.

Re: Fedora considers deprecating legacy BIOS

#145

Post by homarp »

sounds wrote: post #131
mjg59 wrote: post #25

Earlier quoted context omitted.

- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader th…

Quoted post unavailable.

workED for Red Hat, per wikipedia: https://en.m.wikipedia.org/wiki/Matthew_Garrett

Right now at Aurora

Re: Fedora considers deprecating legacy BIOS

#146

Post by cesarb »

martijnvds wrote: post #11
raverbashing wrote: post #2

Yeah it seems like a bad idea Especially because of: > Fedora is also installed on cloud servers and virtual machines of various sorts, some of which do not support anything other than booting via BIOS. The proposal noted that the time of the 2020 discussion, Amazon's AWS did not support UEFI, but that has changed. Marc Pervaz Boocha pointed out that many virtual private server (VPS) providers do not support UEFI, gi…

It's easy to use EFI when virtualizing things locally. libvirt/kvm supports it, Hyper-V supports it, Virtualbox supports it, ESXi supports it.

> libvirt/kvm supports it,

I recall reading somewhere that using UEFI on qemu/kvm caused problems with snapshotting and/or migration; is that still the case?

Re: Fedora considers deprecating legacy BIOS

#147

Post by zajio1am »

mjg59 wrote: post #31

My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now.…

> My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support

That is AFAIK not true for industrial boards. For example current PC Engines APU2 boards just have Coreboot-based BIOS without UEFI.

Re: Fedora considers deprecating legacy BIOS

#149

Post by mustache_kimono »

BirAdam wrote: post #99

At a time when the world is producing several hundred million tons of e-waste each year, that this was even entertained is bad. I suppose its fine to make toxic trash mountains in the third world to get rid of a small amount of code bloat?

Anyone who says things like this, should be the ones that have to support the legacy code. They should be sentenced to a 15+ year old computer and to explain to their colleagues how we just can't do anything new, because we need to use GCC 4.7 to build the world because , now used by 20 non-paying users, won't work with anything newer.

Fedora is only one, relatively fast moving distro, which gives you their software for free, and which didn't even make this decision, but who could blame them if they did, in their position?

Re: Fedora considers deprecating legacy BIOS

#150

Post by zahllos »

jchw wrote: post #139
blueflow wrote: post #4

> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered usi…

> - EFI "executables" are actually windows executables, who still start with the 'MZ' header from MS-DOS. The real mode code for displaying "This program cannot be run in DOS mode" is, depending on the toolchain, sometimes still included. Also legacy from Microsoft. No. They are not Windows executables. They won’t run under Windows at all for multiple reasons. They are PE executables . PE is the executable format dev…

> No. They are not Windows executables. They won’t run under Windows at all for multiple reasons. They are PE executables.

Starting with the fact they have a dedicated set of "subsystem" values: https://docs.microsoft.com/en-us/windows/win32/debug/pe-form... - the win32 loader won't load anything that isn't the CUI or the GUI Windows one, although the kernel also knows about the native one. You'll just get the "this is not a Windows application" messagebox.

With NASM, you can also override that linker stub. For example save this to a file:

    org 100h
    
    start:
        mov dx, msg
        mov ah, 9
        int 21h
        mov ah, 4Ch
        int 21h

        msg db 'Are you still running DOS in 2022? Wow! 640K enough for you!',13,10,'$'
nasm -fbin -o stub.com stub.asm

then if you are using Microsoft's tools you can use LINK.EXE /STUB:stub.com and voila, if anyone _happens_ to (try to) your code under DOS, they'll get an amusing message.

If you want it to take up minimum space, use this one:

    org 100h
    
    start:
        mov ah,4Ch
        int 21h
which will just exit that program if run under dos.

Apparently the header is hardcoded in mingw, but you could easily binary patch it in the resulting executable.

I think I read somewhere you can also remove the stub completely, but I've never tried it.

Edit: for my last comment, yes, you can definitely drop it: https://stackoverflow.com/a/9659538.

Post reply on HN