New Servers - Legacy BIOS or UEFI?

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?
 
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.
 
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.
 
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.

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.
 
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.
 
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.
 
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?).
 
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 ;)
 
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.
 
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?
 
Ioozer: Did you fix your UEFI problem?
 
Back
Top