In D10447#262729, @imp wrote:

I wonder why we even have boot1 anymore after these changes.... It's turning into a mini loader.efi. I wonder why we don't just kill it entirely. We don't need boot volume selection (that's supposed to be the EFI boot BIOS's job). We seem to duplicate a lot of code just to load /boot/loader.efi off of UFS or ZFS partitions. However, we could just use loader.efi directly (though some of the root detection code would need to be tweaked). boot1 used to be small, limited and basically unchanging (so updates weren't needed). Now that boot1.efi has hitched its wagon to loader.efi, I wonder why have an extra boot stage that seems to be good at messing up it's partition guessing...

I'm going to go ahead and commit this (after adding back the bits I keep saying were bogusly deleted), but I'm thinking strongly that we consider just moving to loader.efi installed into \efi\freebsd\loader.efi starting in FreeBSD 12 since we'll be able to point efibootmgr at it by then.

In D12466#258441, @tsoome wrote:

In D12466#258432, @sbruno wrote:

In D12466#258416, @tsoome wrote:

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.

Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.

I can not check the man pxeboot right now, but we have tftp:// prefix etc. I am not sure if the man has received the update, or it is just a,bout the source.

In D12466#258432, @sbruno wrote:

In D12466#258416, @tsoome wrote:

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

I'm unsure as what I can tell is that the current version of pxeboot won't tftp an MFSroot + Kernel in its current state.

Its possible that I just don't know what the magical incantation is in dhcpd.conf to get it to work right, but tcpdump doesn't show a TFTP req if this code isn't in place.

This is busting all the effort of avoiding to define tftp or NFS at build time, isn’t it?

update after cstyle fix commit.

In D12368#256547, @emaste wrote:

The whitespace changes make this a bit hard to read - do you have them as a separate local change that could be committed first?

svn update

use memset instead of initializer

Added missing newlines.

In D10447#245408, @imp wrote:

Also, the current change in size for boot1.efi from these changes is going to present problems for the upgrade path since we foolishly chose such small FAT partitions in the past, in violation of the UEFI standard (though to be honest, even at work where we have acres of disk space, I only make 50MB partitions). Some thought may need to be given to the upgrade path since the old installs won't be able to upgrade to the new boot1.efi.

Are there some specific examples about systems needing this?

Use the struct based array.

Comments updated.

Comment wording as suggested by allanjude

In D11174#231247, @allanjude wrote:

Looks good to me. What needs to be done for the GELI bits?

In D7600#229139, @delphij wrote:

Thanks for the work! (I thought this was already landed last year :)

The change looks good to me (and I appreciate it as a step forward -- duplicated copies of cryptographic code is a big headache for us) overall.

(Totally optional: I wonder if the cryptoboot library could be folded into libstand? Or is there some specific reasons we have to create a new library instead? I'm asking because doing so would avoid building it multiple times, and the license of the source are all BSD compatible.)

Updated to revision 319604.

In D11007#228039, @kczekirda wrote:

It's the only one from pxeloader. I can safety remove the same from iPXE and in summary, during boot chain I have less a half of DHCP request in network. Let's say grain by grain...

LGTM.

LGTM.

LGTM.

ok, that explanation does make sense, LGTM.

IMO if it is really supposed to be default, then the correct place is in /boot/defaults/loader.conf - overloading /boot/loader.conf will only confuse people.