I’ve been using TrueNAS Core for a backup server for a couple years now. This server is a direct installation and NOT running in a VM. My system is a custom machine. Asus x370-Pro Motherboard, 32GB non-ECC RAM, M.2 boot Drive with server installed on it. Storage array is a 12 x 12gb storage array connected to the server with a 10gb fiber connection.
TrueNAS-13.0-U6.2 is the currently installed version.
There is a 250GB cache SSD.
When the server is first started up, it won’t boot, just gives me an error message, indicating that the server cannot boot from a data disk. AFAIK the server installation locked out access to most of the BIOS, as pressing the Delete key (ASUS motherboard bios shortcut key) during boot, doesn’t get me anywhere. If I press the F8 key, it gets me to the boot select screen of which I can select the REAL boot SSD and it starts normally. That said, any time my UPS fails, due to any excessively long power outages, the server will not restart without me once again manually selecting the boot drive with the F8 key. There is no option to change the boot drive in the bios, those kinds of recommendations don’t help.
How do I select and save which boot drive the system should be using if I cannot do it in the bios?
NAS1% uname -a
FreeBSD NAS1.company.example.com 13.1-RELEASE-p9 FreeBSD 13.1-RELEASE-p9 n245431-b8ec9bde091 TRUENAS amd64
NAS1% sudo efibootmgr
Boot to FW : false
BootCurrent: 0003
Timeout : 1 seconds
BootOrder : 0003, 0004, 0002, 0001
+Boot0003* UEFI OS
Boot0004* UEFI OS
Boot0002 UEFI: Built-in EFI Shell
Boot0001 Hard Drive
Same on Linux (mostly, at least). That said, the UX is pretty gnarly, so the system firmware setup menu is, most of the time, still a better option for anything that doesn’t need to be scripted.
No, it sounds like you enabled fast boot or whatever your firmware calls it. Fortunately, UEFI has a way for OSes to notify the firmware that, on the next reboot, it should boot to the setup menu.
On FreeBSD/Core, you want to use efibootmgr -f to set that flag, then reboot.
Regarding efibootmgr, in a shell with ROOT privileges, this generates the message “efi variables not supported on this system.”
Regarding
I have tried 2 different keyboards, and both delete keys on each keyboard. I have tried the fn key on, off and toggling as fast as I’m pressing the delete key, to no avail…
Regarding
For decades, motherboards usually use pressing the delete key during boot, to get into the bios of a motherboard. If I press the delete key, I get this:
It definitely wasn’t straightforward, but resetting the CMOS gave me access to the bios. That said, it took an hour of screwing around before I figured out that this bios seems to always override the M.2 drive over a normal SSD. The M.2 drive in this machine is the cache and it made more sense for it to have the fastest access instead of the boot drive, which basically boots then sits and waits. The SSD was only available to boot from as an alternate drive. I literally had to go into a submenu on the Advanced options and select the SSD instead of the M.2 drive to boot from. After that, it was a matter of selecting the SSD as the boot drive on the normal boot menu and it’s working correctly. While there, I upgraded the RAM to 64gb (motherboard max) of ECC memory. I have not experienced any bit drop kinds of failures ever, but now that should never ever be an issue…
Thank you for forcing me down the path of resetting the CMOS. I’ve had systems completely brick after doing this in the past, which is why I remain hesitant with doing it…
Make sure you’re disabling any and all CSM or Legacy crap. Booting in BIOS compatibility mode in 2024 is just a terrible idea in every way, and it would be nice if motherboard vendors and AMI got the message already.
