Page MenuHomeFreeBSD

Allow LOADER_TFTP_SUPPORT to work again
AbandonedPublic

Authored by sbruno on Sep 22 2017, 3:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Sep 29, 11:13 AM
Unknown Object (File)
Mon, Sep 22, 5:02 AM
Unknown Object (File)
Mon, Sep 22, 12:41 AM
Unknown Object (File)
Sep 11 2025, 1:01 AM
Unknown Object (File)
Aug 6 2025, 6:13 PM
Unknown Object (File)
Jul 28 2025, 6:45 AM
Unknown Object (File)
Jul 27 2025, 11:32 AM
Unknown Object (File)
Jul 26 2025, 7:12 PM
Subscribers

Details

Reviewers
bapt
tsoome
emaste
Summary

LOADER_TFTP_SUPPORT seems to have been broken by the update in svn r318987.

Test Plan

Build PXE loader with LOADER_TFTP_SUPPORT defined and verify that MFS/Kernel are loaded via tftp server.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 11695
Build 12041: arc lint + arc unit

Event Timeline

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

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?

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.

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.

Indeed. My assumption was that using tftp://IP/<path> or tftp:/<path>/ would work. It does not.

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.

yep, pxeboot man does provide examples.

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.

Indeed. My assumption was that using tftp://IP/<path> or tftp:/<path>/ would work. It does not.

There is one issue I have found; and thats about the dhcp.conf, apparently the user-class option may need different approach on check:

if substring (option user-class, 1, 7) = "illumos" {
      option root-path "nfs://192.168.1.244/export/uefi-oi";
}

thats what I have in my isc dhcpd4.conf - of course for freebsd you would need to replace the user class name.

I went back to the man page, just to validate. I used the example from the man page after rebuilding pxeboot with *defaults*. It defintely does not TFTP in this case.

If I recompile with LOADER_TFTP_SUPPORT=y and this patch, it works.

subnet 192.168.100.0 netmask 255.255.255.0 {               
  option        broadcast-address       192.168.100.255;   
  option        routers                 192.168.100.1;     
  option        domain-name-servers     192.168.0.1;       
  option        subnet-mask             255.255.255.0;     
  option        tftp-server             192.168.100.1;     
  next-server                           192.168.100.1;     

  if exists user-class and option user-class = "FreeBSD" { 
        option root-path "tftp://192.168.100.1/tftpboot/"; 
  }                                                        

  host QEMU {                                              
    hardware ethernet 52:54:00:12:34:56;                   
    fixed-address 192.168.100.55;                          
    filename "/boot/pxeboot.mfs";                          
  }   
}

The issues I was running into seem to be related to my attempts to use the old way/old documentation. I can tftp a kernel/ramdisk with the default options.