Undionly.kpxe and ipxe.efi
-
Still researching this… This thread is likely to get very jumbled up as I do this.
Tech Net article: Introduction to DHCP policies:
[url]https://technet.microsoft.com/en-us/library/dn425039.aspx[/url] -
Just found an Awesome article, I’m posting all of what I found because I’d hate for the resource to go away…
SITE: [url]http://www.syslinux.org/archives/2014-January/021404.html[/url]Going to try this out next week!
-----------------------------------------------------------------------Content-----------------------------------------------------------------------
[syslinux] Windows Server DHCP + UEFI recipe
Alexandre Blanchetteblanalex at gmail.com
Wed Jan 15 03:45:05 PST 2014A small how-to for encapsulating option 210 inside option 43 on Windows
DHCP servers would be welcome then
And as far as UEFI x86 system go, one would simply have to create another
vendor class with the value PXEClient:Arch:00006On Wed, Jan 15, 2014 at 12:05 AM, Gene Cumm <[URL=‘http://www.zytor.com/mailman/listinfo/syslinux’]gene.cumm at gmail.com[/URL]> wrote:
I’ve found a way to support PXE booting both UEFI and BIOS architecturesvwith Windows Server DHCP.
This method uses a feature introduced in WinServer 2012: DHCP policies.
First, in the the DHCP console, at the IPv4 root of the server, create a vendor class named PXEClient (UEFI x64) with the following value: PXEClient:Arch:00007 Then create your configuration for your BIOS clients in your scope or as global settings as usual by setting options 66 (IP or hostname of your > TFTP > > host) and 67 (pxelinux.0). For the UEFI clients, you must then create a policy. In the condition > page > > of the wizard, add a condition with the following settings: > > Criteria: Vendor Class > > Operator: Equals > > Value: PXEClient (UEFI x64) > > Tick Append wildcard(*) > > > > Do not configure an IP address range for the policy. > > > > Finally configure options 66 (TFTP server) and 67 (syslinux.efi). You > must > > separate TFTP servers for your BIOS and UEFI clients because Microsoft > DHCP > > server does not send option 210 (path prefix). Microsoft DHCP servers > will > > only send options listed in the Parameter Request List in the > DHCPDISCOVER > > packet. > > > > One could make a cleaner setup by creating a BIOS PXEClient vendor class > > and putting their options within a policy too. >> I haven’t tried WS2012 yet but PXELINUX will parse DHCP option 43 > (vendor-specific information) nicely and I have encapsulated 210 > inside 43 successfully (can’t recall if I tried WS2008R2 and/or > ISC-DHCPd but I did at least one). >> The one oddball missing from your recipe is the UEFI x86 systems that > are not 64 bit. They are rare but exist. >> – > -Gene > _______________________________________________ > Syslinux mailing list > Submissions to [URL=‘http://www.zytor.com/mailman/listinfo/syslinux’]Syslinux at zytor.com[/URL] > Unsubscribe or set options at: > [url]http://www.zytor.com/mailman/listinfo/syslinux[/url] > Please do not send private replies to mailing list traffic. >>–
Alexandre Blanchette <[URL=‘http://www.zytor.com/mailman/listinfo/syslinux’]blanalex at gmail.com[/URL]> -
Just created this article:
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
-
Working on something for Linux DHCP because I have a need for it. Just all research at this point… Again, if I succeed, I’ll update the aforementioned WiKi article.
http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/DHCP_Option_43.php
http://www.ingmarverheij.com/microsoft-vendor-specific-dhcp-options-explained-and-demystified/
http://3dstoneage.com/doc/pxe/dhcpd.conf
http://www.syslinux.org/archives/2014-September/022647.html -
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.
-
I believe, if I’m reading the configs correctly, those are settings for isc-dhcp-server?
-
This post is deleted! -
This post is deleted! -
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
-
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.
-
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,proxyResource used:
http://ltsp.fi/howto/LTSP-PNP/LTSP-PNP1.pdfAnd 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) -
This post is deleted! -
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 -
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 -
@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,proxyThis 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.c32Here’s the TCPDump file of the communications.
test4.pcapNotice packet 41, ipxe.0 was given out but the laptop either didn’t accept it or somehow didn’t acknowledge it.
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…
-
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,proxyThe only difference is the removal of “ipxe.0” from the dhcp-boot= line.
Here is the TCPDump file: issue.pcap
-
@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.
-
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…
-
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" } -
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.
