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

In D10603#223317, @bapt wrote:

so ipxe will catch and use: iscsi:/ tftp:/ nfs:/ http:/ https:/ etc, maybe we should use tftpfs:/

In this case pxe will give a message saying (ignore unsupported root path) and continue what do you think?

In D10603#223301, @bapt wrote:

We need to find a better mechanism, as this break usage where rootpath /something was before this patch expecting NFS to be located on the same serveur as the tftp server. This is now broken (it is used quite a lot apparently)

LGTM.

menu entry has extra l.

bios chain is missing size, add efi chain.

allow to read boot code from file

In D10754#222704, @bcr wrote:

You need to bump the .Dd as you made a content change in the man page.

.Dd update for manual.

Updated to revision 318337.

update pxeboot manual.

add missing __FBSDID("$FreeBSD$");

add comment to ip.c about the origins.

In D10663#221137, @cem wrote:

I'd suggest changing this interface from void ** to more typed pointers to catch this, although I'd expect GCC/Clang to catch passing a void * to void ** parameter. Maybe check WARNS level?

simple fix for NULL...

rebase on top of 317886

This fix did remove the first 2 errors, but remaining 2 are still there, however, they appear to be related something else - looks like we are getting wrap over 0 there as the reported lba 4294967288 is 0x00000000fffffff8. I think the remaining ones have to be dealt with separate issues/commits anyhow.

well, the root path idea is not bad (IMO;) just I have a bit the same concern that at the end of the day it still may not be enough for whatever reason and then we are still back on the beginning:D

In D10485#219375, @kczekirda wrote:

@tsoome
I based on the Intel's PXE Specification and there 66 exists.

Nevermind, let's focus on the root-path. If we cannot use prefix tftp, maybe it can be a suffix? iPXE ignores bad root-path like: "192.168.22.19:/:tftp"

btw, I did test with my vmware fusion VM, the pxe boot is sending out:
DHCP: Message type = DHCPDISCOVER
DHCP: Requested Options:
DHCP: 1 (Subnet Mask)
DHCP: 2 (UTC Time Offset)
DHCP: 3 (Router)
DHCP: 5 (IEN 116 Name Servers)
DHCP: 6 (DNS Servers)
DHCP: 11 (RFC 887 Resource Location Servers)
DHCP: 12 (Client Hostname)
DHCP: 13 (Boot File size in 512 byte Blocks)
DHCP: 15 (DNS Domain Name)
DHCP: 16 (SWAP Server)
DHCP: 17 (Client Root Path)
DHCP: 18 (BOOTP options extensions path)
DHCP: 43 (Vendor Specific Options)
DHCP: 54 (DHCP Server Identifier)
DHCP: 60 (Client Class Identifier =)
DHCP: 67 (Simple Mail (SMTP) Servers)
DHCP: 128 (Site Option)
DHCP: 129 (Site Option)
DHCP: 130 (Site Option)
DHCP: 131 (Site Option)
DHCP: 132 (Site Option)
DHCP: 133 (Site Option)
DHCP: 134 (Site Option)
DHCP: 135 (Site Option)
DHCP: Maximum DHCP Message Size = 1260 bytes
DHCP: Unrecognized Option = 97, length = 17 octets
DHCP: Value = 0x00 0x56 0x4D 0xED 0x79 0xDF 0xA9 0x40 0xE1 0x61 0xAC 0x8F 0x85 0x11 0x7B 0xF5 0x59 (unprintable)
DHCP: Unrecognized Option = 93, length = 2 octets
DHCP: Value = 0x00 0x00 (unprintable)
DHCP: Unrecognized Option = 94, length = 3 octets
DHCP: Value = 0x01 0x02 0x01 (unprintable)
DHCP: Client Class Identifier = "PXEClient:Arch:00000:UNDI:002001"

In D10485#219245, @kczekirda wrote:

@rgrimes
Please try to boot CURRENT over tftp protocol and without any third part software like iPXE.

@tsoome

Note that dhcp servers in real life can offer all the configured data. And well, we can process both 66 and 150 just because that data may be there anyhow.

It's not the server side problem, but the client's side. How we can process option 150 if it not exists? I'm sorry, but I'm not able to do this.

tcpdump: listening on br-lan, link-type EN10MB (Ethernet), capture size 65535 bytes
23:39:38.527420 IP (tos 0x0, ttl 20, id 0, offset 0, flags [none], proto UDP (17), length 576)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 84:8f:69:f1:00:2d, length 548, xid 0x69f1002d, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 84:8f:69:f1:00:2d
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Parameter-Request Option 55, length 36: 
	      Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
	      IEN-Name-Server, Domain-Name-Server, RL, Hostname
	      BS, Domain-Name, SS, RP
	      EP, RSZ, TTL, BR
	      YD, YS, NTP, Vendor-Option
	      Requested-IP, Lease-Time, Server-ID, RN
	      RB, Vendor-Class, TFTP, BF
	      Option 128, Option 129, Option 130, Option 131
	      Option 132, Option 133, Option 134, Option 135
	    MSZ Option 57, length 2: 1260
	    GUID Option 97, length 17: 0.68.69.76.76.67.0.16.50.128.89.185.192.79.87.80.49
	    Client-ID Option 61, length 17: "DELLC^@^P2M-^@YM-9M-@OWP1"
	    ARCH Option 93, length 2: 0
	    NDI Option 94, length 3: 1.2.1
	    Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 181
23:39:39.007131 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 342)
    192.168.22.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 314, xid 0x69f1002d, Flags [Broadcast] (0x8000)
	  Your-IP 192.168.22.56
	  Server-IP 192.168.22.19
	  Client-Ethernet-Address 84:8f:69:f1:00:2d
	  file "pxeboot"
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 192.168.22.1
	    Lease-Time Option 51, length 4: 3600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 192.168.22.1
	    Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
	    Hostname Option 12, length 5: "e6220"
	    RP Option 17, length 15: "192.168.22.19:/"
	    BR Option 28, length 4: 192.168.22.255
	    TFTP Option 66, length 4: "test"
	    END Option 255, length 0

If we want to process data from dhcp_try_rfc1048() we have to drop option 150, because it's not exists there.
I like your idea for detecting protocol type.

In D10485#218907, @kczekirda wrote:

Until I go forward with your comments about the code I want to highlight it's not possible to support option 150, because we have to ask DHCP server for this option. PXE client (I mean network card firmware) never asks about option 150. I can't see any chance to use this non standard option but revert r314948 and always do DHCP request for everything. The second option is doing DHCP request in #ifdef LOADER_TFTP_SUPPORT directive, what is something bad too, because we want to have one universal loader for both (NFS and TFTP) protocols. The third option is to force DHCP request in ifdef directive when somebody really wants to do this. And the last one option - to leave support for option 150, because it has never appear in the documentation. I can't see any really good solution, now your move to comment.

I think we should really keep both 66 and 150. But also definitely we should point out in docs that in case of option 66, the ip address should be used, as in current code, we do not have name resolver. This does add some more complications to the validation and feedback.

netinet/if_ether.h does already include net/ethernet.h

use ETHER_ALIGN and proper packet size calculation for efi and ofw.

Somehow I did lost one semicolon...

In D10232#216150, @ian wrote:

I have tested this on armv6 (beaglebone and wandboard) and it works. It's hard to say if there is any change in performance since on the wandboard it already took about 1.5 seconds to load the kernel, and it seems to be about the same, but it's hard to time something that short "by eye".

changes suggested by ian.

In D10232#213091, @allanjude wrote:

Can you tell me a bit more about the testing you have done on this, and what remains to be done?

Maybe we can get Andrew Turner to try net booting an ARM64 machine with this.

Update to revision 317100

We do not really need double loop and pointer game.

i is not the loop variable.

I did not replicate the same comments for all the instances;)

need to include sys/disk.h

Small comment update.

Shame on me, userboot was also missed.

Implement ofw_net and uboot net changes.

Second take - provide partition size as global variable and hand it back to
the vdev_probe.

In D10302#213242, @imp wrote:

In D10302#213232, @tsoome wrote:

In D10302#213231, @imp wrote:

This suggests that getting the size is wrong and using it the way you do is flawed.

For the pool, yes, we really should get the partition size eventually - assuming we want to get the correct location for the last 2 labels.

The backup GPT is defined to be where the primary GPT says it is, which is not necessarily the last sector(s).

yea, but in this case it is not really even about GPT, as the old sparcs only do support vtoc and GPT support was added for T4 and up. Anyhow, as you do mention GPT, for practical purposes using the GPT backup label location is enough, as it is the last thing *after* the data, and so that will give us good size limit in any case, even if the physical device is larger, it has no data after the backup label.

True. The reason I mention it is that our mem sticks all have backup labels that aren't at the end of media except for a vanishingly small set of USB sticks...

In D10302#213231, @imp wrote:

This suggests that getting the size is wrong and using it the way you do is flawed.