Server BIOS/UEFI configuration: performance and boot
Three things matter in a dedicated server BIOS/UEFI: the boot mode (UEFI or Legacy) with the right device order, the CPU power profile, and the behaviour after a power loss. Everything else you touch only for a specific reason. A wrong boot order or a deep C-state left enabled costs more than any kernel tuning will win back.
- A Performance power profile instead of Balanced removes the ramp-up delay on clock speed, which is visible on databases and game servers.
- Restore on AC Power Loss must be set to Power On, otherwise the server stays off after a power event.
- Changing settings remotely is safe only over the IPMI console, which costs $5/month and is included with Dedicated Enterprise US.
UEFI or Legacy BIOS
Xeon E3-1230v5, E3-1270v6 and E5-2680v4 platforms offer both modes. UEFI is the default choice: it handles disks larger than 2 TB without workarounds, boots faster and supports Secure Boot. Legacy (CSM) stays for older images and for systems whose bootloader is not built for EFI.
The main rule is not to change the mode after the OS is installed. A disk laid out for UEFI with an ESP partition simply will not present a bootloader in Legacy mode, and you get a black screen with "no bootable device". If you do need to rebuild it, read about rescue mode first: the bootloader is restored from there in a handful of commands.
# which mode the system booted in
[ -d /sys/firmware/efi ] && echo UEFI || echo "Legacy BIOS"
# UEFI boot entries and their order
efibootmgr -v
# firmware version and date
dmidecode -t bios | grep -E 'Version|Release Date'
# full BIOS dump to a file so you can diff it after an update
dmidecode -t bios,system,processor > /root/firmware-before.txt 2>&1Which settings to change and how
| Menu setting | Value | What it does |
|---|---|---|
| Power Profile / OS Control | Performance or Max Performance | The CPU stops dropping to low clocks between requests |
| C-States (C6, package C-state) | Disable on latency-sensitive workloads | Removes tens of microseconds of core wake-up time |
| Turbo Boost | Enable | Higher clocks on lightly threaded work |
| VT-x / VT-d (IOMMU) | Enable | Required for KVM, Proxmox, NVMe and NIC passthrough |
| NUMA / Node Interleaving | NUMA on, interleaving off | Keeps memory local on the dual-socket Enterprise US |
| Restore on AC Power Loss | Power On | The server comes back up on its own after a power failure |
| Boot Mode | UEFI | Disks over 2 TB, faster boot, Secure Boot support |
Virtualization is its own topic: without VT-d, device passthrough into guests will not work at all. What else to enable for a hypervisor is covered in the article on virtualization on a dedicated server.
Verify from the OS that the settings took effect
The BIOS menu shows intent; the actual CPU state is visible only from the operating system. Three checks cover almost every case.
# current governor and clock speeds
cpupower frequency-info
grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
# virtualization support shows up as the vmx (Intel) or svm (AMD) flag
grep -c -E 'vmx|svm' /proc/cpuinfo
# IOMMU is really on when this directory is not empty
ls /sys/kernel/iommu_groups/ | wc -l
# NUMA topology
numactl --hardware
lscpu | grep -i -E 'numa|thread|core'Boot order and remote access
There is no keyboard attached to a server in someone else's data centre. Any change to the boot order has to leave you a way back.
Do not enable Secure Boot or flip Boot Mode "just in case". Secure Boot with a self-built kernel or third-party modules (ZFS, NIC drivers) blocks the boot, and changing Boot Mode on an installed system makes the disk unbootable. You end up with a server that answers no SSH and shows nothing beyond POST. The safe sequence: open the IPMI console and confirm you see the screen, then change the setting, then reboot without closing the console. Post-reboot check: efibootmgr -v shows a BootCurrent matching the entry you expect, and journalctl -b -p err contains no bootloader errors.
Connecting to the console and working with virtual media is described in the article on IPMI and KVM-over-IP. If you are installing the system from scratch at the same time, see installing an OS over IPMI, which also covers choosing the partition scheme.
Firmware updates
Update the BIOS for a specific reason: a CPU microcode fix, a disk detection bug, a hypervisor requirement.
Before updating, dump the settings (the dmidecode command above), write down every value you changed by hand and schedule a window. After a flash the settings are often reset to factory defaults, including Restore on AC Power Loss and the virtualization options, which is why guests suddenly refuse to start. Check memory health at the same time: new microcode also changes ECC error handling, and the counters are read as described in the article on testing server RAM.
CPU configurations per plan, including which ones are dual-socket, are listed on the dedicated servers page.
Key takeaways
- UEFI by default; never change the boot mode after the system is installed.
- Performance profile, Turbo on, deep C-states off for latency-sensitive workloads.
- VT-x and VT-d are mandatory for a hypervisor; verify IOMMU through
/sys/kernel/iommu_groups/. - Make every change with the IPMI console open and verify the result from the OS, not from memory of the menu.