New Servers - Legacy BIOS or UEFI?

spork

Active Member

Reaction score: 11
Messages: 140

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

Son of Beastie

Reaction score: 2,035
Messages: 4,998

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.
 

richardtoohey2

Well-Known Member

Reaction score: 133
Messages: 265

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

Aspiring Daemon

Reaction score: 377
Messages: 881

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.
 

Lamia

Aspiring Daemon

Reaction score: 163
Messages: 633

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@

Aspiring Daemon
Developer

Reaction score: 850
Messages: 807

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

Well-Known Member

Reaction score: 271
Messages: 431

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

kpedersen

Daemon

Reaction score: 1,128
Messages: 2,115

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 ;)
 

ekvz

Well-Known Member

Reaction score: 271
Messages: 431

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.
 

kpedersen

Daemon

Reaction score: 1,128
Messages: 2,115

Bobi B.

Well-Known Member

Reaction score: 190
Messages: 409

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?
 

VladiBG

Aspiring Daemon

Reaction score: 377
Messages: 881

@ [USER=49950]Bobi B.[/USER]

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

 

vigole

Aspiring Daemon

Reaction score: 708
Messages: 660

[USER=63936]Ioozer[/USER]: Did you fix your UEFI problem?
 

Jose

Well-Known Member

Reaction score: 290
Messages: 429

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