-
Notifications
You must be signed in to change notification settings - Fork 138
Enable UEFI booting (Supporting hybrid boot) #100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
4e531d5 to
24798f3
Compare
|
@amontalban , |
|
This patch in freebsd should fix the loader.efi size problem permanently |
|
It seems it's still not EFI-bootable, right? I'm about to hand out a lot of rescue USB sticks built using |
|
I would also like to see a UEFI-bootable mfsBSD. How can I help? My ultimate goal is however to PXE-netboot mfsBSD to hosts with UEFI-only BIOSes (no legacy boot support). I have been PXE-netbooting mfsBSD images with pxelinux for more than a decade, but what worked on BIOS-based machines, does not work on UEFI-based ones. |
|
Is a UEFI boot known to work at this time? That is, work just as well as a standard FreeBSD install. My own efforts show that the mfsBSD system isn't recognised as a valid boot entry and so it appears from a UEFI boot that there is no OS installed. Under BIOS, it boots fine. On the other hand, a base FreeBSD (13, encrypted ZFS root for example) install boots just fine in UEFI mode. This has been the case for me on a couple of systems. I'm wondering if it's possible to increase the chances that the resultant mfsBSD "install" is seen as a bootable OS by primarily building on top of what a standard FreeBSD (13) install would produce, and then hand modifying the result to make it a memory filesystem like image. This would lose the flexibility of just being able to "dd" an image onto a system, but would still achieve the main end result that I value, which is running the system as an MFS. Along those lines I'm wondering if some other memory root subsystem would also work, like a root filesystem of type tmpfs, or one whose free space is dictated by free RAM instead of a prearranged maximum value. If there is a "failsafe" approach to adapting a FreeBSD install to become that of a memory filesystem / tmpfs like root, I wouldn't mind running the steps manually. However I'm not sure in principle which boot loader "properties" (and other correlated changes) are necessary to make the resultant boot MFS-like. Any thoughts are appreciated. |
Based on analysis of GhostBSD-build and FreeBSD release scripts, implemented the proper FreeBSD method for creating hybrid bootable ISOs using mkimg. Key changes: - Use mkimg to create GPT/MBR hybrid boot structure - Include protective MBR (pmbr) for proper partition detection - Add freebsd-boot partition with isoboot code - Support EFI system partition for UEFI boot - Write 32KB hybrid image to ISO system area (FreeBSD standard) - Fallback to simple MBR method if mkimg unavailable This matches how FreeBSD and GhostBSD create ISOs that boot from both CD/DVD and USB drives in BIOS and UEFI modes. References: - https://github.com/freebsd/freebsd-src/blob/master/release/amd64/mkisoimages.sh - mmatuska/mfsbsd#100 - https://github.com/ghostbsd/ghostbsd-build
This PR enables UEFI booting while maintaining BIOS booting, I used the official FreeBSD approach on this.
I removed the
mkisofssupport because official FreeBSD release scripts usesmakefs.Finally I had to use the XigmaNAS loader.efi file that is custom compiled so the
mfsroot.gzfile can be loaded.I tried to use official
loader.efibut was failing even using 11.3-STABLE ISO with this commit.The error I was seeing was:
Fixes #73.