Re: CFT EFI Boot Refactoring

Hi Eric,

Thanks for your work on this.

I just applied your diff to my subversion repository, and tried to
buildworld, but the build failed with the following error:

make[6]: make[6]: don't know how to make efipart.c. Stop

make[6]: stopped in /usr/src/sys/boot/efi/drivers
*** [all_subdir_sys/boot/efi/drivers] Error code 2


Does it build ok for you?

Because I use subversion, and I wanted to build it from my main tree, I had
to regenerate your patch using "git diff --no-prefix
master..origin/efize_new > /tmp/efize_new.diff".
I could then apply this cleanly with "svn patch /tmp/efize_new.diff".
I checked the difference between your diff and the diff I generated, and
the only differences were in the file headers. Therefore I don't think the
patch change should make any difference. I have attached my version of the
patch for reference.

For example:

diff --git a/lib/libstand/Makefile b/lib/libstand/Makefile
index 0ebcaf1..3b608c5 100644
--- a/lib/libstand/Makefile
+++ b/lib/libstand/Makefile

Became:

diff --git lib/libstand/Makefile lib/libstand/Makefile
index 0ebcaf1ccfd..3b608c5bc92 100644
--- lib/libstand/Makefile
+++ lib/libstand/Makefile


To show the differences with your patch applied:
$ svn status
M       lib/libstand/Makefile
M       lib/libstand/stand.h
M       sys/boot/efi/Makefile
M       sys/boot/efi/boot1/Makefile
M       sys/boot/efi/boot1/Makefile.fat
M       sys/boot/efi/boot1/boot1.c
D       sys/boot/efi/boot1/boot_module.h
M       sys/boot/efi/boot1/fat-amd64.tmpl.bz2.uu
M       sys/boot/efi/boot1/fat-arm.tmpl.bz2.uu
M       sys/boot/efi/boot1/fat-arm64.tmpl.bz2.uu
M       sys/boot/efi/boot1/fat-i386.tmpl.bz2.uu
M       sys/boot/efi/boot1/generate-fat.sh
D       sys/boot/efi/boot1/ufs_module.c
D       sys/boot/efi/boot1/zfs_module.c
A       sys/boot/efi/drivers
A       sys/boot/efi/drivers/Makefile
A       sys/boot/efi/drivers/efi_drivers.h
A       sys/boot/efi/drivers/fs_driver.c
M       sys/boot/efi/include/efilib.h
M       sys/boot/efi/include/efiprot.h
A       sys/boot/efi/include/string16.h
M       sys/boot/efi/libefi/Makefile
A       sys/boot/efi/libefi/efifs.c
M       sys/boot/efi/libefi/efipart.c
M       sys/boot/efi/libefi/errno.c
M       sys/boot/efi/libefi/handles.c
A       sys/boot/efi/libefi/string16.c
M       sys/boot/efi/libefi/time.c
M       sys/boot/efi/loader/Makefile
M       sys/boot/efi/loader/conf.c
M       sys/boot/efi/loader/loader_efi.h
M       sys/boot/efi/loader/main.c


Regards,
Ben


--
From: Benjamin Woods
woodsb02_at_gmail.com

On 3 December 2016 at 01:02, Eric McCorkle <eric_at_metricspace.net> wrote:

> Hello everyone,
>
> My work to refactor the EFI boot loader has been in review for some time
> now.  This work is a behavior-neutral refactoring which eliminates
> duplicated code in boot1, provides better integration of boot1 and
> loader with the EFI API, and moves towards better compliance with the
> recommendations of the UEFI driver writer's guide.  This work also
> serves as a precursor to more work, such as GELI, hot-plugging, and
> other things.
>
> One of the reviewers was able to trigger a hang on his setup; however,
> it's not clear whether this is a problem in the refactoring, or whether
> it's due to a related bug:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214423
>
> Therefore, I would like to issue a CFT for this changeset.  We need
> people using the boot1/loader EFI boot setup to test their setup using
> boot1 and loader as built with this patch applied.
>
> You can also get the source tree directly from my github
> (https://github.com/emc2/freebsd.git).  Use the efize_new branch to get
> this changeset.  Note that I am maintaining the state of this branch in
> a single change at this point using rebase -i, so there *will* be forced
> pushes to this branch.
>
>
> Here are some notes on testing the changeset:
>
> * To test it, just do a buildworld, then copy loader.efi in place and
> copy boot1.efi to /efi/BOOT/BOOTX64.EFI on your ESP.  If your system
> boots, then the test was successful (there are no new features in this
> changeset).
>
> * The output of boot1 is slightly different, so you'll be able to tell
> if you installed it correctly.
>
> * I recommend keeping a copy of the basic boot1 around on your ESP, just
> in case something goes wrong.  On my setup, I have a backup at
> /efi/BOOT/BOOTX64.BAK (with the main program at /efi/BOOT/BOOTX64.EFI,
> of course)
>
> * I have been using this on a machine with two disks, a ZFS pool
> spanning both disks, and a dummy UFS filesystem for months now, so it
> can be considered relatively safe.
>
> * This has also been tested on basic setups without incident, so
> priority is on complex or odd setups.
>
> * If something goes wrong, you will most likely get a boot-hang.  If
> this happens, please contact me directly with the details, and I'll
> coordinate on diagnosis.
>