Undionly.kpxe and ipxe.efi

Wayne Workman

Just dumping my journalctl logs for dnsmasq

Sep 10 21:54:16 fog dnsmasq[22507]: compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect
Sep 10 21:54:16 fog dnsmasq-dhcp[22507]: DHCP, proxy on subnet 10.0.0.3
Sep 10 21:54:16 fog dnsmasq[22507]: reading /etc/resolv.conf
Sep 10 21:54:16 fog dnsmasq[22507]: using nameserver 10.0.0.1#53
Sep 10 21:54:16 fog dnsmasq[22507]: using nameserver 8.8.8.8#53
Sep 10 21:54:16 fog dnsmasq[22507]: read /etc/hosts - 2 addresses
Sep 10 21:54:34 fog dnsmasq-dhcp[22507]: 3068132478 available DHCP subnet: 10.0.0.3/255.255.255.0
Sep 10 21:54:34 fog dnsmasq-dhcp[22507]: 3068132478 vendor class: PXEClient:Arch:00000:UNDI:002001
Sep 10 21:54:39 fog dnsmasq-dhcp[22507]: 3084909694 available DHCP subnet: 10.0.0.3/255.255.255.0
Sep 10 21:54:39 fog dnsmasq-dhcp[22507]: 3084909694 vendor class: PXEClient:Arch:00000:UNDI:002001
Sep 10 21:54:43 fog dnsmasq-dhcp[22507]: 3101686910 available DHCP subnet: 10.0.0.3/255.255.255.0
Sep 10 21:54:43 fog dnsmasq-dhcp[22507]: 3101686910 vendor class: PXEClient:Arch:00000:UNDI:002001

Wayne Workman

The craziness that is my ltsp.conf file right now:

#port=0
log-dhcp
tftp-root=/tftpboot
dhcp-option=17,/images
dhcp-no-override

#---------------------------------------
#this line is suspicious to me. What the heck does 6,2b mean ?
#dhcp-option=vendor:PXEClient,6,2b

#Here, I define netboot types
#dhcp-vendorclass=BIOS,"PXEClient:Arch:00000"
#dhcp-vendorclass=UEFI,"PXEClient:Arch:00007"

#Set bootfile names depending on the client vendor identifier
#dhcp-boot=net:BIOS,"undionly.0",10.0.0.3,10.0.0.3
#dhcp-boot=net:UEFI,"ipxe.0",10.0.0.3,10.0.0.3

#---------------------------------------

#dhcp-match=set:efi,option:client-arch,7
#dhcp-boot=tag:efi,ipxe.efi,pxeserver,10.0.0.3
#dhcp-match=set:bios,option:client-arch,6
#dhcp-boot=tag:bios,undionly.kkpxe,pxeserver,10.0.0.3

#-------------------------------------

#dhcp-option=vendor:PXEClient,66,"10.0.0.3"
#dhcp-option=vendor:PXEClient:Arch:00000,67,"undionly.0"
#dhcp-option=vendor:PXEClient:Arch:00007,67,"ipxe.0"


#---------------------------------------

dhcp-match=BIOS, option:client-arch, 0
dhcp-match=UEFI, option:client-arch, 7

dhcp-boot=tag:BIOS,undionly.0
dhcp-boot=tag:UEFI,ipxe.0

#--------------------------------------

dhcp-range=10.0.0.3,proxy

Wayne Workman

@Developers @Moderators
I’ve been able to give out ipxe.efi (32bit and 64bit copies) via dnsmasq - without checking vendor class just to see if it works or not.

Using a Lenovo L530 laptop in UEFI mode, it does not work.

Not only does it not work, I’ve verified through TCPDump that the transfer of the file never happens.

Here is my current /etc/dnsmasq.d/ltsp.conf file that I used to test with:

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=ipxe.0,10.0.0.3,10.0.0.3
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt="Press F8 for boot menu", 3
pxe-service=X86PC, “Boot from network”, ipxe
pxe-service=PC98, “Boot from network” ipxe
pxe-service=IA64_EFI, “Boot from network”, ipxe
pxe-service=Alpha, “Boot from network”, ipxe
pxe-service=Arc_x86, “Boot from network”, ipxe
pxe-service=Intel_Lean_Client, “Boot from network”, ipxe
pxe-service=IA32_EFI, “Boot from network”, ipxe
pxe-service=BC_EFI, “Boot from network”, ipxe
pxe-service=Xscale_EFI, “Boot from network”, ipxe
pxe-service=X86-64_EFI, “Boot from network”, ipxe
dhcp-range=10.0.0.3,proxy

This is the contents of my /tftpboot directory.

[root@fog tftpboot]# ls -la
total 5256
drwxr-xr-x   4 fog  root   4096 Sep 12 22:36 .
dr-xr-xr-x. 25 root root   4096 Sep 12 21:02 ..
-rw-r--r--   1 fog  root    840 Sep 10 19:46 boot.txt
-rw-r--r--   1 root root    423 Sep 10 19:46 default.ipxe
drwxr-xr-x   2 fog  root   4096 Sep 10 19:46 i386-efi
-rw-r--r--   1 fog  root 183872 Sep 10 19:46 intel.efi
-rw-r--r--   1 fog  root  91955 Sep 10 19:46 intel.kkpxe
-rw-r--r--   1 fog  root  92003 Sep 10 19:46 intel.kpxe
-rw-r--r--   1 fog  root  91965 Sep 10 19:46 intel.pxe
-rw-r--r--   1 root root 906400 Sep 12 22:36 ipxe.0
-rw-r--r--   1 fog  root 906400 Sep 10 19:46 ipxe.efi
-rw-r--r--   1 fog  root 329868 Sep 10 19:46 ipxe.kkpxe
-rw-r--r--   1 fog  root 329916 Sep 10 19:46 ipxe.kpxe
-rw-r--r--   1 fog  root 329446 Sep 10 19:46 ipxe.krn
-rw-r--r--   1 fog  root 329959 Sep 10 19:46 ipxe.pxe
-rw-r--r--   1 fog  root 123448 Sep 10 19:46 ldlinux.c32
-rw-r--r--   1 fog  root 187820 Sep 10 19:46 libcom32.c32
-rw-r--r--   1 fog  root  26468 Sep 10 19:46 libutil.c32
-rw-r--r--   1 root root    606 Sep 10 21:02 ltsp.conf.experimental
-rw-r--r--   1 fog  root  26140 Sep 10 19:46 memdisk
-rw-r--r--   1 fog  root  29208 Sep 10 19:46 menu.c32
-rw-r--r--   1 fog  root  43186 Sep 10 19:46 pxelinux.0
-rw-r--r--   1 fog  root  43210 Sep 10 19:46 pxelinux.0.old
drwxr-xr-x   2 fog  root   4096 Sep 10 19:46 pxelinux.cfg
-rw-r--r--   1 fog  root 183552 Sep 10 19:46 realtek.efi
-rw-r--r--   1 fog  root  92881 Sep 10 19:46 realtek.kkpxe
-rw-r--r--   1 fog  root  92929 Sep 10 19:46 realtek.kpxe
-rw-r--r--   1 fog  root  92929 Sep 10 19:46 realtek.pxe
-rw-r--r--   1 fog  root 182848 Sep 10 19:46 snp.efi
-rw-r--r--   1 fog  root 183072 Sep 10 19:46 snponly.efi
-rw-r--r--   1 root root  91582 Sep 10 20:03 undionly.0
-rw-r--r--   1 fog  root  91582 Sep 10 19:46 undionly.kkpxe
-rw-r--r--   1 fog  root  91630 Sep 10 19:46 undionly.kpxe
-rw-r--r--   1 fog  root  91608 Sep 10 19:46 undionly.pxe
-rw-r--r--   1 fog  root  29728 Sep 10 19:46 vesamenu.c32

Here’s the TCPDump file of the communications.
test4.pcap

Notice packet 41, ipxe.0 was given out but the laptop either didn’t accept it or somehow didn’t acknowledge it.
Screenshot from 2015-09-12 22-27-55.png

I’ve also confirmed that with the exact same ltsp.conf configuration abovie -** but with my Lenovo L530 laptop in Legacy mode, the ipxe.0 file DOES download**… so this means the configuration is good… but UEFI is not accepting the offer for some reason.

Any help at all is appreciated. I’m not sure where this is going wrong… But after quite extensive searching on the net, it looks like nobody is having luck with using dnsmasq for ProxyDHCP with UEFI systems…

Wayne Workman

@Developers @Moderators

Uncle Frank had me try out a modification to my last post. It gave better results!

Here’s the conf file:

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=,10.0.0.3,10.0.0.3
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt="Press F8 for boot menu", 3
pxe-service=X86PC, “Boot from network”, ipxe
pxe-service=PC98, “Boot from network” ipxe
pxe-service=IA64_EFI, “Boot from network”, ipxe
pxe-service=Alpha, “Boot from network”, ipxe
pxe-service=Arc_x86, “Boot from network”, ipxe
pxe-service=Intel_Lean_Client, “Boot from network”, ipxe
pxe-service=IA32_EFI, “Boot from network”, ipxe
pxe-service=BC_EFI, “Boot from network”, ipxe
pxe-service=Xscale_EFI, “Boot from network”, ipxe
pxe-service=X86-64_EFI, “Boot from network”, ipxe
dhcp-range=10.0.0.3,proxy

The only difference is the removal of “ipxe.0” from the dhcp-boot= line.

Here is the TCPDump file: issue.pcap

Tom Elliott

@Wayne-Workman To be honest, I imagine the dhcp-boot line may not even be needed. I say this because it is going to present you the menu options you have, and load that file. I suppose it does need to know where to look for the relevant NBP file.

Sebastian Roth

Yes you are tight Tom. Wayne and I were just trying something “unusual” to see if we could make his EFI machine boot. Unfortunately we couldn’t. Too bad.

But we found something new. Stay tuned on this…

Quantum

I’m not as familiar with dnsmasq and ipxe, but I have been successful using isc-dhcp and syslinux.efi for a while in another pxe environment. It was successfully loading memtestx86+ and gparted live in EFI mode. Again, I don’t know about ipxe, but Syslinux is now packing all their libraries (c32’s) in architecture specific subdirectories. I should also note that - in my experience - once the efi version is loaded, it can’t load a BIOS loader: eg. cant load pxelinux.0 from syslinux.efi. Likewise, I wasn’t able to load any kernels that didn’t have EFI boot stubs.This weekend I’ll try setting up a copy of the above environment at home and see if I can switch it to iPXE. Can’t make a promise that it will happen this weekend though because it’s my daughters birthday.

option architecture-type code 93 = unsigned integer 16;
#64 bit syslinux.efi renamed to bootx64.efi
#32 bit syslinux.efi no name change
#changed from pxelinux.0 to new lpxelinux.0
if option architecture-type = 00:09 {
filename "bootx64.efi"
} elsif option architecture-type = 00:07 {
  filename "bootx64.efi"
} elsif option arch = 00:06 {
 filename "syslinux.efi"
} else {
 filename "lpxelinux.0"
}

Sebastian Roth

You are welcome to give it a try with iPXE. I am pretty sure it works. Your config options look alright. Wayne has already done it with ISC DHCP too. But we are now trying to get this running with dnsmasq in proxy mode (isc-dhcp unfortunatelly cannot do proxy mode) as this would be great for a lot of users who cannot alter their main DHCP config in a productive environment.

Wayne Workman

I just stumbled across something that might be the key to our woes with dnsmasq and linux DHCP…

I’m using this configuration with Linux ISC-DHCP right now:
https://docs.google.com/document/d/1cDKvUXkWVE_FOHAD8e13GF8scwAgtx99fMgXaVcsnZI/edit?usp=sharing

My UEFI enabled work laptop still will not network boot, it just sits there saying “iPXE initialising devices”

However, look what journalctl -xe reveals!
a TFTP error!

Screenshot 2015-10-04 at 12.08.12 PM.png

Sebastian Roth

@Wayne-Workman said:

My UEFI enabled work laptop still will not network boot, it just sits there saying “iPXE initialising devices”

To me this sounds like iPXE does not like your network card in UEFI mode. You might want to compile a binary with debugging enabled to find out what’s wrong. I doubt this has something to do with TFTP.

@Wayne-Workman said:

However, look what journalctl -xe reveals!
a TFTP error!

Maybe I am blind but I only see “client does not accept options”. That’s not an issue (https://en.opensuse.org/SDB:PXE_boot_installation#No_options_accepted) and can be ignored if you see iPXE coming up (gets loaded via TFTP).

Wayne Workman

I’ve been thinking A LOT about the many many problems with all the Vendor Class identifiers that Apple has…

Because PC is so standard (like PXEClient:Arch:00000 and PXEClient:Arch:00007 ), and because Apple are extreme non-conformists,

It makes no sense to try to define a class for each apple device. it’s stupid.

I say - make ipxe.efi the default and then make classes for the various PC PXEClient architectures.

Abandon Macs that are 32 bit. Just don’t worry about them.

Undionly.kpxe and ipxe.efi

246

11.7k

17.2k

154.7k