Does the BIOS boot method still work with modern hardware ?

Message

Chidakasha · Post by **Chidakasha** » Thu Mar 18, 2021 5:50 pm

Hi guys, I hope you're all doing well

I'm going to buy a new PC soon and I wanted to know if I'll still be able to go with the old school BIOS boot method. I just find UEFI boot more annoying, is it mandatory with modern motherboards ? I plan to buy an ASUS ROG Crosshair VIII Dark Hero

Thanks in advance.

Buffoon · Post by **Buffoon** » Thu Mar 18, 2021 5:59 pm

Then the fastest way to get this answered would be reading the manual for this board, likely available at ASUS. You should study this manual anyway if you are planning to buy it.

Post by **pietinger** » Thu Mar 18, 2021 6:23 pm

Chidakasha wrote:I just find UEFI boot more annoying, [...]

... because you dont know how to handle it ? Dont panic, you have to do nothing more for an UEFI boot. Just do (almost) the same as for a MBR boot; it is all described in the AMD64-handbook.

Buffoon · Post by **Buffoon** » Thu Mar 18, 2021 6:57 pm

Actually UEFI is better, legacy boot has only one MBR to boot from, therefore you can have only one boot loader [per hard drive]. With UEFI you can drop all your bootloaders to ESP partition and use firmware boot menu to choose which one to boot, see the advantage? I have currently three Gentoo EFI stub kernels in my boot menu, I can set the next one to boot from with efibootmgr or by hitting F11 next boot.

Post by **NeddySeagoon** » Thu Mar 18, 2021 8:06 pm

Chidakasha,

You motherboard may well have a legacy BIOS boot mode installed.
It won't we well tested and nobody will be interested if it won't work for you.

EFI is broken by design, relying on vfat but the path of least resistance is to use EFI.

Buffoon,

I've never had a problem chainloading one boot loader from another.

Buffoon · Post by **Buffoon** » Thu Mar 18, 2021 8:15 pm

I've never had a problem chainloading one boot loader from another.

True, but it feels as too much trouble just to load an OS. Maybe unaesthetic is the word.

Tony0945 · Post by **Tony0945** » Thu Mar 18, 2021 9:11 pm

Try sys-boot/refind Once it is setup it will autoboot the latest kernel. Or you can select at boot (similar to grub). The beauty is once you place your kernel in /boot, there is NO other preparation needed. And you don't need to place your kernels in the FAT partiton, refind will find them on ext4 or btrfs or others (see the use flags). I don't use a separate /boot on any machine including those running grub-legacy.

If you dual boot with windows (I don't since my XP disk failed) I think you can select at boot time also. See the upstream https://www.rodsbooks.com/refind/

xineg · Post by **xineg** » Thu Mar 18, 2021 9:31 pm

On my current motherboard it gives the option to boot legacy or EFI and a third option auto which boots whatever you setup, additionally with auto it has the option to try first, efi or bios. Everything is being replaced by complexity which adds horrific security issues.

Website · Post by **Zucca** » Thu Mar 18, 2021 9:41 pm

rEFInd boot manager is the savior of UEFI.

UEFI is not all good.
I have two machines with multi-disk btrfs filesystem. Disks have no partition table. Raw btrfs.
UEFI requiring FAT filesystem is a pain on those machines. If I booted from BIOS, I could (maybe*) just load the kernel and other stuff right from my /boot subvolume. Now I need a extra drive (USB stick) to store the UEFI FAT.
Why I don't have one disk with a partition table and place UEFI FAT there? For convenience. I currently back up the "boot media" regularly. If the stick dies I can hotswap it too (with few extra steps). If I have btrfs and boot media on one disk I need to do more work to replace it.

Now if some verndor did an UEFI firmware with btrfs support...

Then there is this danger inside /sys/efivars with UEFI. If you accidentally delete a wrong file there, you might end up with bricked MB.

So. UEFI is nice, but it has it's limitations. FAT requirement is the worst.

(* I haven't really tested if any bios boot loaders can load kernel from multi-disk btrfs, I'd asuume some does...)

Goverp · Post by **Goverp** » Fri Mar 19, 2021 9:52 am

Zucca wrote:... Then there is this danger inside /sys/efivars with UEFI. If you accidentally delete a wrong file there, you might end up with bricked MB. ...

If I've correctly read the UEFI specs, that shouldn't happen - if you corrupt the UEFI configuration to that point, UEFI should enter a recovery mode. Of course, that requires the MB's BIOS authors read the UEFI spec as well as me! AFAIK, what can brick the system is putting too much data into the efivars. It's a limited resource, and UEFI has to manage it at boot time

(This fallback behaviour is the reason why UEFI systems boot EFI/boot/bootx62.efi when you make a mess of installing a new boot mananger; this is often incorrectly described as "Broken BIOS ignores my new bootmanager and insists on booting bootx64.efi ".)

One of the problems with UEFI is really that its behaviour depends on which BIOS vendor wrote the one on your motherboard. There aren't many, and it would help if their documentation was centralized with the vendor, rather than scattered across the MB vendors (who typically rely on the BIOS management screens' help text as "documentation" - all two lines of it

)

figueroa · Post by **figueroa** » Sat Mar 20, 2021 3:06 am

A couple of years ago when I set up my "new" circa 2012 hardware (DMI: Hewlett-Packard h8-1260t/2AB5, BIOS 7.12 10/12/2011) primary desktop machine, I had a choice of UEFI or legacy. I chose legacy and I have been eternally happy with my choice. I have, since, set up a handful of new systems not for personal use using UEFI, and all were buggy in different though aggravating ways. In my opinion, UEFI is like a cancer.

Post by Hu » Sat Mar 20, 2021 4:48 pm

The problem with UEFI is that, like BIOS before it, it needs to exist in order for the system to be marketable, but it is not a selling point, so vendors are strongly motivated to spend as little money as possible making BIOS/UEFI work. UEFI added plenty of complexity over what BIOS required. Complex systems have more places for the programmer to make mistakes, and since the company is only motivated to fix mistakes that would render the device unsuitable for sale, a frustrating number of serious mistakes are allowed to stand. Add in that, as a low level component, patching it is not easy, so there is a good chance that if it was not right on the first try, it never will be made right. Even worse, because UEFI, like BIOS, is somewhat aware of the hardware, vendors may not be in a position to have a single UEFI that they use on every board they sell for a multi-year period, so they cannot amortize the cost of a "good" UEFI across multiple models. If cost is not amortized, then the pressure to control costs will be even stronger.

Faced with all these factors that push for releasing the lowest-quality barely-functional firmware the vendor thinks they can get away with, we need something to provide an incentive to do better. Broadly, this would be:

Market pressure, in the form of widespread refusal to buy boards with garbage firmware. In practice, bad firmware doesn't hurt enough of the right people to cause meaningful pushback.
Private regulatory pressure. Microsoft demonstrated that, for certain things, they could force vendors to do what Microsoft wanted, rather than what profitability would dictate, because Microsoft would use its position to hurt profitability if the vendor did not cooperate. (For example, the rules around when a computer could have the "Ready for Windows" type logo could be used to browbeat the vendor. Either the vendor provides a system Microsoft approves of, or the vendor cannot use the logo. The vendor presumes that having the logo improves marketability, so they want the logo. This then forces them to comply with Microsoft's requirements.) Generally, end users do not have the collective bargaining to do anything like this.
Public regulatory pressure. Bad firmware doesn't have the broad negative effects that usually justify government regulators getting involved, so this doesn't tend to happen.

Fitzcarraldo · Post by **Fitzcarraldo** » Sat Mar 20, 2021 5:17 pm

figueroa wrote:A couple of years ago when I set up my "new" circa 2012 hardware (DMI: Hewlett-Packard h8-1260t/2AB5, BIOS 7.12 10/12/2011) primary desktop machine, I had a choice of UEFI or legacy. I chose legacy and I have been eternally happy with my choice. I have, since, set up a handful of new systems not for personal use using UEFI, and all were buggy in different though aggravating ways. In my opinion, UEFI is like a cancer.

I am in a somewhat similar situation; I selected PC BIOS for my main laptop even though PC BIOS and UEFI are both supported by the laptop's firmware. In my opinion the choice of FAT was a retrograde step and UEFI is fiddly and messy. My server runs fine with PC BIOS+GPT. I do have a desktop that uses UEFI, but that's only because it runs Lubuntu and I accepted the Installer default. I may opt to use UEFI if I install Gentoo on the next laptop I purchase, simply to keep up with the latest approach., but it doesn't fill me with enthusiasm.

pa4wdh · Post by **pa4wdh** » Sat Mar 20, 2021 5:57 pm

I also use BIOS boot wherever I can, fortunately all my systems are still able to do BIOS boot, but i have already seen systems without that option.

Market pressure, in the form of widespread refusal to buy boards with garbage firmware. In practice, bad firmware doesn't hurt enough of the right people to cause meaningful pushback.

Problem is that you only discover the garbage firmware after you bought the board and installed it, it's near impossible (hence the question by the OP) to know it upfront.
Maybe it would be nice to have a sort of review site that reviews the BIOS and/or UEFI on boards, naming and shaming helps to create the market pressure and gives users the ability to make an informed choice.

Tony0945 · Post by **Tony0945** » Sat Mar 20, 2021 7:06 pm

Hu wrote: and since the company is only motivated to fix mistakes that would render the device unsuitable for sale, a frustrating number of serious mistakes are allowed to stand

And only those mistakes that affect Windows. And Windows 10 to boot. The Linux/FreeBSD market is way to small to spend money on.
It's hard to get vendor's to tell how to read the internal sensors on their motherboard but somehow pay software always can do it on Windows.

One of my server's CPU temperature sensors is reading 17.6 degrees F. Ambient temperature is 66 degrees. I greatly doubt if the CPU is 50 degrees below ambient. Indeed, the sensors say it is hard frozen.

Logicien · Post by **Logicien** » Sat Mar 20, 2021 10:30 pm

You can have many Efi bootloaders, one for Linux, one for Bsd, one for Windows, etc. You need to configure many bootloaders menus and choose the order of them to load at boot in the Efi menu.

If you have a good Dos/Mbr boot loader than it's alone in the Mbr and you need to configure only one bootloader menu for all systems if all are supported by it. If the Efi boot method is the future than the legacy boot mode may end one day.

I would like that each operating system would be able to initialise the hardware at boot with it's own microcode wtitten in the Cmos memory like Coreboot and advoid to configure the Bios/Efi plus the operating system. This is a know flaw in Pc architecture. I like the Arm architecture who allow to configure the boot process through a configure file acessible from the running system. It's more convinient than have to enter and go out a Bios/Efi setup menu.

Too many utilities who want to do the same thing is bad. For me Grub2 do all well in mbr boot mode. it carry well it's name the GRand Unifier Boot loader. I must say that I must be aware that one of my systems overwrite it with an other bootloader on upgrade.

It's better to have only one bootloader install for all systems to advoid this, the one to use. Some systems like Windows may not have an option to not overwrite the boot loader with it's own. This is one ennoying side of the multiboot in mbr mode.

Chidakasha · Post by **Chidakasha** » Sun Mar 21, 2021 1:52 pm

Thanks for all the really interesting replies, guys

I just tried a UEFI installation in a virtual machine and it's true that rEFInd makes everything very easy.

klas · Post by **klas** » Wed Aug 25, 2021 12:20 am

I have dark hero crosshair and 5900x of processor, I tried to install gentoo on it but I am not yet successful I think it may be the UEFI thing
I will try with BIOS as gentoo is the way for me

Tony0945 · Post by **Tony0945** » Wed Aug 25, 2021 12:55 am

klas, your installation media must be UEFI also.

Spanik · Post by **Spanik** » Wed Aug 25, 2021 5:59 am

With the desktop (Supermicro H11SSL) legacy BIOS is a disaster. It is a kind of emulation that taken several minutes until it hits the disk for the bootmanager. On top of that when using bios you cannot boot from the nVME disk. So you have to put boot on a sata disk. For one reason or another, then I got into grub issues not being able to find the nVME and having to go to Lilo.

I went EFI after that and now this board behaves nicely, booting grub from the nVME. So I guess it depends on the motherboard.

szatox · Post by **szatox** » Wed Aug 25, 2021 9:34 am

Tony0945 wrote:klas, your installation media must be UEFI also.

You sure about it?
I never had any issues. Just mount efivars to modify boot options from within your system. Or reboot into bios and change boot options there (after your efi system is already installed)

Post by **pietinger** » Wed Aug 25, 2021 11:18 am

szatox wrote:[...] Just mount efivars to modify boot options [...]

I think you have meant "efivarfs".

Tony0945 · Post by **Tony0945** » Wed Aug 25, 2021 4:08 pm

szatox wrote:
Tony0945 wrote:klas, your installation media must be UEFI also.
You sure about it?
I never had any issues. Just mount efivars to modify boot options from within your system. Or reboot into bios and change boot options there (after your efi system is already installed)

{shrug} That's what I was told when I was having problems like efivars not running.

Jaglover · Post by **Jaglover** » Wed Aug 25, 2021 9:21 pm

You do not need to boot in EFI mode to install Gentoo, you can set it all up for EFI booting while booted in legacy mode. When you rename your EFI stub kernel and put it in boot/efi/boot/bootx64.efi then at next boot you can choose EFI mode in BIOS and it will boot. Because this is the standard location for EFI executable and it will be found without you modifying efivars. Any other location and/or name of executable and you need boot at least once in EFI mode from an external media to get access to the efivars.

Post by **pietinger** » Wed Aug 25, 2021 10:20 pm

Jaglover wrote:You do not need to boot in EFI mode to install Gentoo, you can set it all up for EFI booting while booted in legacy mode. When you rename your EFI stub kernel [...]

This is true IF you install a stub kernel (first). But you will get an abort when you try to install strictly with AMD64-handbook and try to install grub2 configured as efi-64 (because the installation routine from grub2 then tries to set an UEFI-boot-entry which it cant do because there is no mounted efivarfs; this leads to an abort).

Does the BIOS boot method still work with modern hardware ?

Does the BIOS boot method still work with modern hardware ?

Re

artition. I don't use a sepaerate /boot on any machine (even