Bug 235806

Summary: [PATCH] loader.efi won't load from embedded memory disk
Product: Base System Reporter: Dave Rush <northwoodlogic.free>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Some People CC: dch, mhorne, ross, vangyzen
Priority: --- Keywords: patch
Version: 12.0-STABLE   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
fix loader.efi embedded md loading none

Description Dave Rush 2019-02-17 14:24:50 UTC 
Created attachment 202095 [details]
fix loader.efi embedded md loading

It would be very helpful for me to bring back the embedded MD support.

The FreeBSD Foundation article mentions embedding a MD image in loader.efi. This article appears to be a couple years old and some time between then and now MD image embedding must have broke. I'm not so interested in secure boot, but it is important to me to be able to load a fully functional / self contained system via the UEFI firmware network boot or from a system partition. Chainloading a loader.efi that doesn't have an embedded MD and having that continue on and load kernel & other things piece-meal from NFS, TFTP, or UFS/ZFS filesystems is not going to work for me.

https://www.freebsdfoundation.org/freebsd-uefi-secure-boot/
    
One problem is that the EFI loader's conf.c does not include the md_dev in its devsw[] pointer list if MD_IMAGE_SIZE is defined. The second problem is that the EFI loader's main.c doesn't try to probe the md device as "currdev". The actual image itself was being correctly included in loader.efi when MD_IMAGE_SIZE is defined before this patch.
Comment 1 Dave Rush 2019-04-01 23:10:43 UTC 
Is anyone able to help me with review of the loader.efi patch I submitted?
Comment 2 Mitchell Horne freebsd_committer freebsd_triage 2021-07-07 21:25:47 UTC 
Hi Dave,

I'm sorry that your patch was not looked at. If you are still interested, someone added this functionality very recently, see:
https://cgit.freebsd.org/src/commit/stand/efi/loader/conf.c?id=5984246f9626fbc3d356ee2d3b3cd159f6d0a7c2

It looks like the change hasn't yet been MFC'd to any stable branches, so CC'ing Eric who committed it.
Comment 3 Mitchell Horne freebsd_committer freebsd_triage 2022-06-17 17:11:45 UTC 
(In reply to Mitchell Horne from comment #2)

This is now merged back to all stable branches.