# New Servers - Legacy BIOS or UEFI?



## spork (Sep 21, 2020)

I have a bunch of new servers, and then eventually some not-so-new servers that will be repurposed that also support both legacy BIOS and UEFI boot. There's no dual-booting or anything fancy here, just headless servers in a colo that may occasionally be touched by the colo's remote hands service if I'm not around.

Looking at non-OS-specific UEFI info the general sense I get is that it's pretty nifty and very complicated, but for a system booting a single OS, I'm not really seeing tangible advantages when weighed against the additional complexity involved. I'm also not finding really solid info on where FreeBSD support for UEFI boot is (we'll be rolling out/upgrading to 12.x).

My gut says go legacy BIOS, any counters to that?


----------



## Phishfry (Sep 21, 2020)

I use Legacy BIOS when I can. I use UFS2 so backups with dump and restore are how I backup.
With EFI installations you have the FAT/EFI partition which cannot be dumped+restored.
So for me that is a good reason to use Legacy BIOS settings. A single partition for boot + OS.
I mostly use GPT formatting except on my NanoBSD builds where GPT is not supported.


----------



## Lamia (Sep 21, 2020)

This is what you wanted - https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot - for EFI.

Its advantages are limitless - speed, security, modern drivers, etc. You can administer with ease and so the engineers at the Colo.


----------



## richardtoohey2 (Sep 21, 2020)

spork said:


> My gut says go legacy BIOS, any counters to that?


My gut used to tell me the same, but I think that was good 5+ years ago.

Newer machines etc. - got to move with the times - so UEFI/GPT and turn off anything legacy *unless* you hit problems.

I've not done any useful checking or benchmarking - just seems to be the "done thing" these days and if you stick to legacy you will eventually get left behind.

Doesn't seem too much faff on new motherboards - turn off anything legacy or dual to UEFI/EFI, use GPT.  Just document what you change!

Depending on your preference for risk - could you try 50% or 25% of the new machines on UEFI/GPT and the rest legacy and see how things go?  Then at least you are trying the new shiny stuff and can get some idea of how much grief (hopefully none) it causes you.


----------



## VladiBG (Sep 21, 2020)

Phishfry said:


> With EFI installations you have the FAT/EFI partition which cannot be dumped+restored.


You are wrong above this. It's a normal partition formatted with FAT32 which can be created on every disk. Refer to the FreeBSD wiki page regarding UEFI and how the EFI partition is now manually created.


			UEFI - FreeBSD Wiki
		


I'm using storage with hardware raid controllers and for file system im using GPT+UFS2 with dump/restore to offsite backup via ssh. Everything is remote controller via ILO and tested for restore once before every FreeBSD update on local VM. The servers are using UEFI Boot. Only recommendation is when you are creating the EFI partition to create it above 800k so there will be free space on that partition in case of new bootstrap code get bigger. 

Only if you have any issues with UEFI on that particular servers then go back to Legacy Bios.


----------



## Lamia (Sep 21, 2020)

VladiBG said:


> Only if you have any issues with UEFI on that particular servers then go back to Legacy Bios.


You nailed it. One of our current systems used legacy bios during installation. Luckily, we were able to create a sizable amount of space 800k or so just  before boot (legacy) & swap partitions and dropped the EFI bootcode there. We then changed the Supermicro mobo to use UEFI and the rest is history. 

I guess on can achieve the same with the earlier sent URL by running the commands for both the legacy and UEFI after creating additional partition on the drive.


----------



## olli@ (Sep 21, 2020)

Phishfry said:


> I use Legacy BIOS when I can. I use UFS2 so backups with dump and restore are how I backup.
> With EFI installations you have the FAT/EFI partition which cannot be dumped+restored.


It’s a standard FAT partition, so you can mount it (preferably read-only) with mount_msdosfs(8) and backup its contents with tar(1), cpio(1) or whatever you like. Alternatively, you can save the whole partition with dd(1) without mounting it, so the filesystem type doesn’t matter at all.

I agree with the other posters that UEFI should be preferred, because it is “future-proof”.
Let me explain why that is important:

Other popular operating systems (Windows 10 and current Linux distributions) use UEFI when present. This means that BIOS programmers and mainboard vendors will put less efforts in maintaining and testing legacy BIOS booting mechanisms, and I expect that support for that will slowly fade away. At some point in the not-too-distant future, an increasing percentage of PCs will be UEFI-only. When you upgrade to such a PC, you can simply continue to use your existing installation if it already uses UEFI-booting. But If your previous installation uses legacy BIOS booting, you’re going to have some work to do, possibly a completely new installation (worst-case). So, when you’re installing a new server now anyway, it’s better to use UEFI right from the start and avoid future headache.


----------



## ekvz (Sep 21, 2020)

As far as being future proof is concerned what could seriously happen besides the OS dropping legacy support? While i agree that UEFI will rather sooner than later become unavoidable i don't see a need to speed this up. It's one of those things where in my opinion the added complexity by far outweights the gained functionality (what exactly would that even be?).


----------



## drhowarddrfine (Sep 21, 2020)

ekvz said:


> the added complexity


Another one of those things we all must suffer because of Microsoft's problems and Microsoft alone.


----------



## kpedersen (Sep 21, 2020)

Plus if we manage to drag out the standard BIOS for an extra 10-15 years than usual, it might give UEFI time to become more elegant and have better implementations by the time we *have* to use it.

Unlike many consumer communities, we can be happy to wait until the next version becomes functionally superior in every way before we charge ahead in the name of blind progress. In particular progress is not something to be feared if we take time and do it correctly


----------



## VladiBG (Sep 21, 2020)

> Intel is planning to deprecate legacy compatibility by 2020, and is working with partners on a smooth industry transition





			https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf


----------



## ekvz (Sep 21, 2020)

kpedersen said:


> Plus if we manage to drag out the standard BIOS for an extra 10-15 years than usual, it might give UEFI time to become more elegant and have better implementations by the time we *have* to use it.



Exactly. There is a lot that could happen in 10 years. I hope by then https://raptorcs.com/TALOSII/ has become a little cheaper and better supported   Those don't even seem to have anything like Intel ME built in by default.


----------



## Mjölnir (Sep 21, 2020)

BTW what's the status of SFI?  Deprecated?


ekvz said:


> Exactly. There is a lot that could happen in 10 years. I hope by then https://raptorcs.com/TALOSII/ has become a little cheaper and better supported   Those don't even seem to have anything like Intel ME.


The OpenBMC runs Linux... Brrr


----------



## a6h (Sep 21, 2020)

mjollnir said:


> BTW what's the status of SFI? Deprecated?


MAINTAINERS: Mark simple firmware interface (SFI) obsoletecore/documentation





						kernel/git/tip/tip.git - Unnamed repository; edit this file 'description' to name the repository.
					






					git.kernel.org


----------



## kpedersen (Sep 21, 2020)

VladiBG said:


> https://uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf



Quite interesting. I notice that slide 6 gives the two main reasons people stick with BIOS and yet the rest of the slides do absolutely *nothing* to address these.
It shows Intel are well aware that the BIOS is more appropriate for specific use-cases but they simply only have an interest in chasing money from the largest userbase possible. Hardly innovative.


----------



## Bobi B. (Sep 21, 2020)

Some time ago I was looking into ways of telling EFI bootloader which UFS GPT partition to start from, but I was not able to. More precisely, I'm looking into using UEFI with nanobsd, where there are two (or more) read-only root filesystems to allow atomic upgrades. I was able to do it with BIOS and GPT/MBR, but not UEFI. It that now possible?


----------



## a6h (Sep 21, 2020)

`INT 10H`


----------



## ekvz (Sep 21, 2020)

mjollnir said:


> The OpenBMC runs Linux... Brrr



Yes, the support needs to be improved


----------



## VladiBG (Sep 21, 2020)

@ *Bobi B.*

It look for the first freebsd-ufs to load the /boot then you can change it via currdev=disk0p2 in loader.conf or manually on the efi console with `set currdev=disk0p2` then `boot`
use lsdev in efi console to see the list of the disk






						uefi(8)
					






					www.freebsd.org


----------



## Mjölnir (Sep 22, 2020)

I'd like to have more feedback from UFS users to insert the I/O scheduler with this rc(8) script.


----------



## a6h (Sep 22, 2020)

Ioozer: Did you fix your UEFI problem?








						FreeBSD just destroyed my UEFI
					

It could be my UEFI firmware bug, but could be FreeBSD's, too. The only two OSes that caused this problem for me are OpenIndiana and FreeBSD. There is no Linux distro has such problem. I could say it's because Linux's support for UEFI is much better, or to be more correctly Linux's support for...




					forums.freebsd.org


----------



## Jose (Sep 23, 2020)

I'm going to stick to BIOS for as long as I can. I was screwed over way too many times by corrupted FAT filesystems back in the day. Yeah, I know these are not mounted after boot, yada, yada, but I still don't trust 'em.

That plus the fact that the openness status of EFI is somewhat in question, and the fact that those who would know are not fans, makes me wanna wait and hope a better alternative arises.


----------

