NVMe boot on unsupported platforms via Clover (#P42)
A bit more background info on last week’s NVMe adapter board used on the incompatible Fujitsu D3348-B1 2011v3 platform.
The Clover boot manager has been around for quite some time now, and its predecessor is already well over a decade old. It once formed from the rEFIt boot loader back when Hackintoshs were the cool gadget to have, and it had an intermediate fork step with rEFInd (oh those EFI puns…). Thankfully I’m really late to the M.2 party (or any other SSD form factors other than 2.5″/3.5″, really) for hardware compatibility reasons, and so all the early adopter issues have been ironed out over the years. No building of custom XML boot configurations with barely documented parameters, no EFI/BIOS payload module insertion, no Windows 7 setup driver file integration, and certainly no physical removal and reflashing of fucked up BIOS chips, because some NVMe mod is, oops, version 0.03 alpha and that was a bug fixed on the master branch fifteen minutes ago.
Well, it’s all so simple nowadays with Clover and 3rd party support for it. For the most basic of use cases, it is downloaded, partially extracted to a USB drive, and the system is good to go.
The project itself is hosted on github/CloverBootloader. There’s a fair bit of external documentation available on github/Clover-Crate, and of course the internet is full of tutorials from simple themed Clover installs to multiboot setups with integrated OS setup functionality.
For my specific setup, I just ran BDU (Boot Disk Utility) from a guy called cVad. It’s a one-click formatter for Clover, so it does format the selected USB drive with suitable settings, then downloads the most recent stable version of Clover (or uses a specific local version), and extracts everything that is needed. It also allows for some OSX recovery magic / user defined payload that I personally do not need.
Making an unformatted USB drive bootable is literally one click – except for when NVMe booting capabilities are required, which aren’t enabled by default in Clover. For that feature, the NvmExpressDxe.efi driver has to be moved manually around the
/EFI/CLOVER/drivers/ folder (from “off” to “UEFI”). I haven’t yet tried the FreeDOS imaging option, which could be useful for future firmware upgrades on e.g. LSI SAS cards, should the need arise.
With that data in place, setting up the BIOS is as simple as choosing the USB drive as first boot device.
I’ve noticed with the recent overhaul of my (Ventoy) multiboot stick that this specific Fujitsu board drops USB boot options permanently when they’re not present during an unknown part of the POST cycle, which was highly annoying for testing several dozens of bootable OS images.
For Clover, the drive should therefore be always available to the board (no hub, no regular extension cable!), and it doesn’t really need to be physically accessible since it won’t change all that often. Best option therefore is an on-board USB socket, which this one fortunately offers. It’s only a 2.0 one and placed a bit fiddly between SATA ports and the bottom PCIe slot, but it’s not like a high-speed drive is required for reading a couple 100KB for the secondary boot loader. Second best option would be a place directly on the I/O shield, third option a pin header cable or direct attach adapter for one of those empty 9/10 pin USB2 twin sockets (say Delock 83292 or Chinese variants). Since literally any USB drive will do, I’ll just buy a thin but not too small one that can be easily removed from the socket. For I/O shield use, I’d recommend the smallest one available to not block adjacent ports, and to not ever be confused with other “useful” drives (nobody uses those crappy and slow micro drives that barely stick out four millimeters from the port, right?)
That’s all the magic required to make an incompatible pre-M.2 generation main board suddenly able to boot M.2 OS drives – chances are, the required USB drive from a retail shop is slightly more expensive than the physical M.2 to PCIe adapter from China. But I’ll work with real PCIe SSDs as well, and U.2 / U.3 are probably no exception. And since we’re in 2022 and NVMe drivers are integrated into every major OS install medium by now, there’s exactly zero additional hurdles for the system installation. It’s perfect to keep “old” boards going a little longer without having the performance penalty of plain old SATA drives!