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.

LGTM:)

I do not know much about bsdinstall scripts but as much as it counts, seems ok for me;)

In D10603#223350, @bapt wrote:

What I mean is we cannot use the one I listed above because they are interpreted by ipxe. For example if one netboots from qemu it will use ipxe under the hood first, then if you pass rootpath tftp:/ ipxe will say

Next server: 192.168.42.1
Filename: /pxeboot
Root path: tftp:/
Could not open SAN device: Invalid argument (http://ipxe.org/1c126002)
No more network devices

and the boot process fails.

Which is why what I propose is tftpfs:/ because it is not used by ipxe
and by default we remain on over nfs so we don't break existing usage