Date: Sun, 17 Feb 2019 14:24:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 235806] [PATCH] loader.efi won't load from embedded memory disk Message-ID: <bug-235806-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235806 Bug ID: 235806 Summary: [PATCH] loader.efi won't load from embedded memory disk Product: Base System Version: 12.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: northwoodlogic.free@gmail.com Created attachment 202095 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D202095&action= =3Dedit 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 boo= t, 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 partit= ion. 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235806-227>