Undionly.kpxe and ipxe.efi

Wayne Workman

Can someone play with this? I just threw it together based on the below links.

class "UEFI" {
match if substring(option vendor-class-identifier, 0, 7) = "PXEClient";
filename "ipxe.efi";
option vendor-class-identifier "PXEClient";
vendor-option-space PXE;
option PXE.mtftp-ip 0.0.0.0;
# IP of you TFTP server
next-server x.x.x.x;
}

class "Legacy" {
match if substring(option vendor-class-identifier, 0, 0) = "PXEClient";
filename "undionly.kkpxe";
option vendor-class-identifier "PXEClient";
vendor-option-space PXE;
option PXE.mtftp-ip 0.0.0.0;
# IP of you TFTP server
next-server x.x.x.x;
}

Edit: this particular config does not work.

Tom Elliott

I believe, if I’m reading the configs correctly, those are settings for isc-dhcp-server?

Wayne Workman

This post is deleted!

Wayne Workman

This post is deleted!

Wayne Workman

Just found a highly helpful post! http://www.unix.com/linux/139267-dhcp-what-does-vendor-class-identifier-0-9-mean.html

the numbering in the match substring part is in reference to what characters to check in the option vender-class-identifier!! it makes so much sense now!

the 0, 7 would specify starting the comparison at character zero, and ending it at character 7, and then compare it to the string in quotes.

So, based on this knowledge, this should work:

class "UEFI" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
next-server x.x.x.x;
   filename "ipxe.efi";
}

class "Legacy" {
match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
next-server x.x.x.x;
   filename "undionly.kkpxe";
}

Here is another reference, also: https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/diskless-dhcp-config.html

Wayne Workman

Bumping this thread so I can find it easier.

I’m no-longer running dnsmasq at home - due to an issue with it that I became impatient with. I’ve turned DHCP off of my small little consumer grade combo-device and it’s running on the FOG server now, which has been running along with the other Linux servers for probably 3 months straight now… might as well put it to work! lol.

Anyways,

I now have a super safe and easy means of playing around with Linux DHCP and BIOS/UEFI co-existence. I’ll be testing out what I’ve posted below in the coming days and I’ll share the results. If I’m successful, I’ll update the aforementioned WiKi article on the subject.

Wayne Workman

Just reposting this stuff below so I don’t loose it.

It’s really easy to set it up for just UEFI. You just change the filename in the ltsp.conf file, and then make sure you have the appropriate symbolic link for the file you want to use.

As far as legacy & UEFI co-existence using dnsmasq - we don’t have an answer for that yet. If you figure it out, I will add it to this wiki article: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

However - since I have been looking into this lately, give this a shot… if it blows up I’m sorry, it’s not been tested - but maybe you can figure it out. I’ve been intending on testing this for a while but just haven’t gotten around to it. Let me know any errors that you encounter with the dnsmasq service status and any weird behavior.

port=0
log-dhcp
tftp-root=/tftpboot

# I commented this line out because we don't want to blast out one file for everything.
#dhcp-boot=undionly.0,x.x.x.x,x.x.x.x

dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override

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

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

pxe-prompt="Press F8 for boot menu", 3
pxe-service=X86PC, “Boot from network”, undionly
pxe-service=X86PC, "Boot from local hard disk", 0
dhcp-range=x.x.x.x,proxy

Resource used:
http://ltsp.fi/howto/LTSP-PNP/LTSP-PNP1.pdf

And to make sure the resource doesn’t go away, here’s a copy of what’s in that PDF:

LTSP-PNP #1 (KVM)
LTSP-PNP server with one network interface, dnsmasq with other dhcpd server.
DHCP SERVER = 192.168.100.77
LTSP-PNP SERVER = 192.168.100.120
GATEWAY = 192.168.100.10
DNS SERVER = 192.168.43.1
A. INTERFACES/NETWORK
A1. /etc/netwrok/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.100.120
netmask 255.255.255.0
gateway 192.168.100.10
A2. /etc/resolvconf/resolv.conf.d/tail
nameserver 192.168.43.1
nameserver 8.8.4.4
nameserver 8.8.8.8
B. DNSMASQD
B1. /etc/dnsmasq.d/ltsp-server-dnsmasq.conf
# Configures dnsmasq for PXE client booting.
# All the files in /etc/dnsmasq.d/ override the main dnsmasq configuration in
# /etc/dnsmasq.conf.
# You may modify this file to suit your needs, or create new ones in dnsmasq.d/.
# Log lots of extra information about DHCP transactions.
#log-dhcp
# IP ranges to hand out.
#dhcp-range=192.168.67.20,192.168.67.250,8h
# If another DHCP server is present on the network, you may use a proxy range
# instead. This makes dnsmasq provide boot information but not IP leases.
# (needs dnsmasq 2.48+)
dhcp-range=192.168.100.0,proxy
# The rootpath option is used by both NFS and NBD.
dhcp-option=17,/opt/ltsp/i386
# Define common netboot types.
dhcp-vendorclass=etherboot,Etherboot 
dhcp-vendorclass=pxe,PXEClient
dhcp-vendorclass=ltsp,"Linux ipconfig"
# Set the boot filename depending on the client vendor identifier.
# The boot filename is relative to tftp-root.
dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0
dhcp-boot=net:etherboot,/ltsp/i386/nbi.img
dhcp-boot=net:ltsp,/ltsp/i386/lts.conf
# Kill multicast.
dhcp-option=vendor:pxe,6,2b
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# We don't want a PXE menu since we're using a graphical PXELinux menu.
#pxe-prompt="Press F8 for boot menu", 3
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
pxe-service=X86PC, "Boot from network", /ltsp/i386/pxelinux
# A boot service type of 0 is special, and will abort the
# net boot procedure and continue booting from local media.
#pxe-service=X86PC, "Boot from local hard disk", 0
# Comment the following to disable the TFTP server functionality of dnsmasq.
enable-tftp
# The TFTP directory. Sometimes /srv/tftp is used instead.
tftp-root=/var/lib/tftpboot/
# Disable the DNS server functionality of dnsmasq by setting port=0
port=0
# Don't listen on lo, to prevent conflicts with Ubuntu's local resolver hack
(LP: #959037).
#except-interface=lo
#bind-interfaces
C. DHCP
C1. /etc/dhcp/dhcpd.conf
#
# Default LTSP dhcpd.conf config file.
#
authoritative;
subnet 192.168.100.0 netmask 255.255.255.0 {
 range 192.168.100.200 192.168.100.250;
 option domain-name "ltsp-pnp";
 option domain-name-servers 192.168.43.1;
 option broadcast-address 192.168.100.255;
 option routers 192.168.100.10;
 option subnet-mask 255.255.255.0;
 option root-path "/opt/ltsp/i386";
 if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
 filename "/ltsp/i386/pxelinux.0"; 
 } else {
 filename "/ltsp/i386/nbi.img";
 }
}
D. LTS.CONF
D1. /var/lib/tftpboot/ltsp/i386/lts.conf
[Default]
SCREEN_02=shell
SCREEN_07=ldm
#
RM_SYSTEM_SERVICES="dnsmasq nbd-server"
RM_THIN_SYSTEM_SERVICES="qemu-kvm virtualbox"
#
LDM_DIRECTX=True
USE_LOCAL_SWAP=True
SSH_FOLLOW_SYMLINKS=False
NFS_HOME=/home
#
LDM_FORCE_SESSION=/usr/bin/startlubuntu
LDM_FORCE_LANGUAGE="fi_FI.UTF-8"
LDM_LIMIT_ONE_SESSION=True
LDM_LIMIT_ONE_SESSION_PROMPT=True
XKBLAYOUT="fi"
X_BLANKING=0
X_NUMLOCK=False
#
[52:54:00:00:57:B2]
HOSTNAME=ltsp001
LDM_AUTOLOGIN=True
LDM_USERNAME=ltsp001
LDM_PASSWORD=ltsp001
E. NFS
E1. /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check)
hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home *(rw,sync,no_subtree_check)

Wayne Workman

This post is deleted!

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

137

10.9k

16.6k

151.9k