FreeBSD kicks me back to BIOS on boot after upgrading CPU

As the title says I upgraded my system from a 3200g to a 5700x and now TrueNAS fails to boot. I get to a FreeBSD screen that says loading bootloader.efi and then it takes me to the BIOS. I’ve done a fresh install of TrueNAS core and the problem still persists. I use a 4060 as a display out since the 5700x doesn’t have an onboard GPU but I’ve tested it with the 3200g and it boots just fine. I’ve also tested this build with a 5700x3D and it has the same problem. I can’t find anyone online talking about using a 5700x3D with TrueNAS but I can find people successfully using a 5700x so I know its supported at least in theory. The motherboard is a MSI b450i and the BIOS is up to date.

I’m really at a loss here as to what could be going wrong and why changing CPUS would cause it to happen. Any ideas would greatly be appreciated.

EDIT: After a lot of messing around in the BIOS I figured out the problem is SecureBoot. Disabling it fixed my problem and TrueNAS boots up just fine. If anyone knows WHY this is happening I would love to know because I would prefer to keep SecureBoot turned on

Why use a “lock”, you haven’t got the “key” for? Vendor side signing is security theater. At best … [1]

BTW.: You could mark this topic as “solved”.

  1. ↩︎

Correct me if I’m wrong but does SecureBoot not make it more difficult for rootkits? Or am I ignorant

Often people try to argue that a little protection is better than no protection at all.

Now I ask (mainly) myself: where do you live? On the ground floor? Do you have windows there (pun intended)? Those, that you’re not allowed to open because otherwise they’ll fall on your feet? But at least they protect you from insects?

Or maybe on the 3rd floor? Do you have a lift there that sometimes crashes or gets stuck? But at least it sometimes takes you up? That’s better than nothing, right? And you can always take the stairwell. You mustn’t lean against the banister, otherwise it could break off and cause serious injury but it’s still better than not having one, isn’t it?

Security requirements for a server with trusted boot are in many respects like those of a railing. It must provide support. Security is about reliability (be it in the computer or in life). It must be deterministic as to which attacks it helps against and which it does does not help.

If the railing can withstand a maximum pressure of 200 kilograms, then you can calculate with that. With “secureboot”, there is no such guarantee because it can be cancelled/switched off/hacked/circumvented. Therefore, a trusted security mechnism must be protected from malicious access. Direct or indirect.

Could any vendor based approach offer a solution? I believe not so.

So what you’re getting at is SecureBoot is not a reliable method of security due to the intrinsic nature of the method and therefore should be disregarded in favor of other approaches to security?

There is no need to install heads/openbmc/coreboot etc. (unless you really need it), but there is no need to boot from (U)EFI either. (Since it offers no gains apart from attack surface.)