UEFI firmware on old hardware

M

mlcarson

Limp Gawd
Joined
Jul 12, 2009
Messages
385
Not sure if this is the correct forum for this or not. I was attempting to install Linux and FreeBSD on some old hardware that I now wanted to use as a backup server. This was on an MSI P67A-GD65 motherboard. This does support UEFI but just barely. It does not support SecureBoot or have any Win8 settings or Legacy/CSM Boot support settings. It was the first motherboard that I owned with a graphical BIOS/firmware. I know squat about UEFI except that it was required to boot GPT partitions and that GPT partitions were required instead of MBR if you want to boot from a partition greater than 2TB.

I thought that booting from a UEFI enabled USB stick should be pretty easy. I was able to select the USB device as a UEFI device and give it the highest boot priority but it wouldn't boot. I thought maybe it was in the creation of the USB image so tried Rufus, Win32DiskImager, and BalenaEtcher but they all ended with the same result. Win32DiskImager actually was able to bluescreen my Win10 computer twice on a FAT32 error in volmgr so don't recommend it. BalenaEtcher is my new favorite tool for this stuff. I thought maybe a bootable DVD with Windows 10 could install a UEFI OS as proof of concept but it failed too -- MBR only.

The only UEFI boot that I could successfully do was to a UEFI shell. Eventually I figured out that I could use it to boot from the devices that up to this point were failing. The MAP command would show me the drive name for any removable device and I'd just have to switch drives to this drive and enter the \efi\boot directory and run the bootx64.efi file located there. Successful installs would then add options to the boot menu as EFI partitions were created so UEFI shell wasn't required afterwards. It's all easy once you know about it but this is all automatic now.

The new Linux images are creating UEFI dependencies and cause strange errors when trying to use MBR only. The latest freebsd variants wouldn't boot at all, Linux would typically fail when it was time to install Grub at the end of the install. The latest 5.x kernels also make the assumption that you can enable SecureBoot or select standard keys. This creates up to a 30 second boot delay and throws some errors but does successfully boot.

8+ year old motherboards aren't exactly common but they still exist and are still good for certain jobs as long as they continue to function.
 
I can't speak for the Linux distro's, but which image of FreeBSD did you try - memstick or iso? I know sometimes that makes a difference in installation. Also, do you need to boot from UEFI/GPT? If the boot partition size is the primary consideration, I know with FreeBSD, it is relatively simple to setup a separate /boot partition. IIRC, some distro's of Linux I toyed around with a few years ago even set that up by default.
 
jardows said:
I can't speak for the Linux distro's, but which image of FreeBSD did you try - memstick or iso? I know sometimes that makes a difference in installation. Also, do you need to boot from UEFI/GPT? If the boot partition size is the primary consideration, I know with FreeBSD, it is relatively simple to setup a separate /boot partition. IIRC, some distro's of Linux I toyed around with a few years ago even set that up by default.
Click to expand...

I still configure the separate partitions. Partly habit, partly because there's a number of advantages to having your /home separate from your /.
 
I've been booting a bunch of different distributions just to see how they handle UEFI on this board. My conclusions so far is that 4.x Kernels work very well. 5.x Kernels seem to be very bad -- they generally take 1 minute trying to figure out the UEFI stuff because they're expecting standard boot keys which don't exist on my motherboard since it doesn't support Secure Boot. I read somewhere that the latest version of Fedora fixed this but they just hid the errors behind the BIOS splash screen but still took the same 1 minute boot time. Every 5.x kernel seems to have the exact same delay but I think the most up-to-date distro that I tried was Opensuse Tumbleweed with kernel version 5.1.16-1. The later 4.x kernels may have the same issue too -- just encountered it on MXLinux at Kernel 4.19.05. Maybe some distros are just better at hiding the issue. I think most of them that I've tried took about a minute before they seemed to do anything but are not displaying any messages but rather splash screen, progress bars, etc. I guess I'll just have to start looking at boot times rather than error messages.

I was originally going to install Project Trident which is using TrueOS which is using FreeBSD. The UEFI is not preventing this in any way now but the underlying FreeBSD doesn't see my Marvell 88SE912 controller which I had two drives on so scrapped the idea for now. I could probably figure out how to get it recognized by the OS or just get an LSI card (which I'm liking in another box) for any additional SATA ports.
 
I was able to move my LSI card to this older box and got it working after masking out PCI slot B5-B6 pins; I didn't have to do this on my Ryzen motherboard.. FreeBSD immediately recognized the card and associated drives so there are no hardware issues now. The system boots faster than any of the Linux systems so I'm going to play around with Project Trident for a while as originally planned.
 
mlcarson said:
I was able to move my LSI card to this older box and got it working after masking out PCI slot B5-B6 pins; I didn't have to do this on my Ryzen motherboard.. FreeBSD immediately recognized the card and associated drives so there are no hardware issues now. The system boots faster than any of the Linux systems so I'm going to play around with Project Trident for a while as originally planned.
Click to expand...
Glad you got that working. I hadn't seen anything before about having to mask off PCI pins for an LSI card, care to elaborate a bit more? Some day I'd like to pick up one for my home server, and that sounds like a "gotcha" that would be good to know about before hand.

I'm interested to know what you find out with Trident. Since TrueOS is basically FreeBSD-CURRENT with OpenRC, it could offer some interesting options, especially if they really test the CURRENT code well before pushing it into their updates. I've pretty much stuck to base FreeBSD-RELEASE ever since I first tried PC-BSD (for their easy mirrored root on install, which base FreeBSD adopted later) but their specific updating system caused me problems for me later down the road.
 
Those PCI pins are the SMBus Clock and SMBus data. I'm not sure what LSI is using these for but it conflicts with Intel boards. You won't get a POST with your motherboard if the pins aren't masked. I originally thought it might have been a conflict with the GPU since it was also in a PCIE slot but then remembered the pin masking thing.

The gotchas I've had on Project Trident and GhostBSD so far have been the following. With windows, you have to use Win32DiskImager because the ISO's can't be modified with Rufus/Balenaetcher to create UEFI USB boot sticks like Linux ISO's can. The other big thing with both is that they use TrueOS which is not the same as FreeBSD in one major way -- the init system. TrueOS uses OpenRC which I think is better but not all packages have been converted to OpenRC. URBackup is an example of one that hasn't and Emby is an example of one that has but was done incorrectly. These are of course the two apps that I wanted to run.

There was also an issue with NTPDate upon bootup that I haven't taken the time to figure out yet. The NTPD service won't change the time if it's too far out of sync but NTPDate will but doesn't. I think it's either missing a host server or being called before DNS services are available. If I manually run NTPDate after I login, it works. The times are then close enough that it's no longer needed because NTP keeps the clock sync'd. The NTPDate issue is an obvious thing for somebody converting from Windows because FreeBSD seems to change your system clock to UTC and then use the timezone settings to display the correct time. If you're not in the UTC time zone, your clock will be off by the number of hours that you are different from UTC until NTPDate can correct it or you manually correct the clock. I think there's an option where you can select the local clock to use your timezone rather than UTC but it's not a default. It's just one of those things that's glaringly broke that you wonder how can this not have been noticed by anybody working on the OS.



jardows said:
Glad you got that working. I hadn't seen anything before about having to mask off PCI pins for an LSI card, care to elaborate a bit more? Some day I'd like to pick up one for my home server, and that sounds like a "gotcha" that would be good to know about before hand.

I'm interested to know what you find out with Trident. Since TrueOS is basically FreeBSD-CURRENT with OpenRC, it could offer some interesting options, especially if they really test the CURRENT code well before pushing it into their updates. I've pretty much stuck to base FreeBSD-RELEASE ever since I first tried PC-BSD (for their easy mirrored root on install, which base FreeBSD adopted later) but their specific updating system caused me problems for me later down the road.
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top