<snip > A: Because it messes up the order in which people normally read text, especially the archives of mailing lists. Q: Why is Top-posting such a bad thing? I apologize in advance for the potentially-dumb comments/questions. _ Do you really need the Vendor Class Identifier option included in the "if option arch" conditions? _ Do you really need the Vendor Class Identifier option at all? It makes it play better with other devices that also use DHCP option 43, or something like that. Nope, I got desperate troubleshooting and searching the web for other solutions. Others were using just "PXEClient" which may have worked with legacy boot but not EFI. _ If you use Vendor Class Identifier, can you (or, are you allowed to) simultaneously choose a (boot)filename for each Client System Architecture Type? _ If you use Client System Architecture, can you (or, are you allowed to) simultaneously choose a (boot)filename for each Vendor Class Identifier? _ The "pxelinux.configfile" arguments are pointing to specific directories, not to files. Is this correct? Could this be some kind of mix-up between "pxelinux.configfile" and "pxelinux.pathprefix" (options 209 and 210, respectively)? Hey this is how debian is doing it according to their Bugzilla, and I got my configuration file originally from clonezilla's DBRL project. _ In "option arch = 00:09", there is a "PXEClient:Arch:00007" statement. Isn't this some kind of arch conflict? Yeah but we aren't using 00:09 yet, but I guess we will later. http://tools.ietf.org/html/rfc4578 _ Is the "else if" syntax correct in your particular dhcp tool(s) / case? For example, perhaps you actually need "elsif"? It works. ISC DHCP 3.1 I think. Look I think the problem and why the basic configuration doesn't work is we have one TFTP server (NAS), one DHCP Server for PXE (Linux), and two other DHCP severs. The PXEClient tells the boot rom to ignore other DHCP requests. I'm just going to get WDS/System Centre taking over the first stage of the boot and if I have to work backwards in Wireshark to find out what was going wrong here, should I want syslinux EFI to start up first at a later time. WDSLinux will have to suffice in the interim. Does it have support for EFI, probably not it's a 16 bit dos style com file right? Regards, Ady. _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux
> <snip > > > > Nope, I got desperate troubleshooting and searching the web for other > solutions. > Others were using just "PXEClient" which may have worked with legacy > boot but not EFI. > > > _ If you use Vendor Class Identifier, can you (or, are you allowed > > to) simultaneously choose a (boot)filename for each Client System > > Architecture Type? > > > > _ If you use Client System Architecture, can you (or, are you > > allowed to) simultaneously choose a (boot)filename for each Vendor > > Class Identifier? > > > > _ The "pxelinux.configfile" arguments are pointing to specific > > directories, not to files. Is this correct? Could this be some kind > > of mix-up between "pxelinux.configfile" and "pxelinux.pathprefix" > > (options 209 and 210, respectively)? > > Hey this is how debian is doing it according to their Bugzilla, and I > got my configuration file originally from clonezilla's DBRL project. > > > > _ In "option arch = 00:09", there is a "PXEClient:Arch:00007" > > statement. Isn't this some kind of arch conflict? > Yeah but we aren't using 00:09 yet, but I guess we will later. > > http://tools.ietf.org/html/rfc4578 > > > _ Is the "else if" syntax correct in your particular dhcp tool(s) / > > case? For example, perhaps you actually need "elsif"? > > It works. ISC DHCP 3.1 I think. > > Look I think the problem and why the basic configuration doesn't work > is we have one TFTP server (NAS), one DHCP Server for PXE (Linux), > and two other DHCP severs. The PXEClient tells the boot rom to ignore > other DHCP requests. > > I'm just going to get WDS/System Centre taking over the first stage > of the boot and if I have to work backwards in Wireshark to find out > what was going wrong here, should I want syslinux EFI to start up > first at a later time. WDSLinux will have to suffice in the interim. > Does it have support for EFI, probably not it's a 16 bit dos style > com file right? > > > Regards, > > Ady. > > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >You seem to be taking (copy$paste) parts and pieces from different resources. You also seem to be assuming that all those resources are somewhat officially confirmed (proved) to be working, both individually and mixed together. Additionally, this email thread is getting slightly harder to read and to follow. FWIW, a (closed) bug report in Debian doesn't mean Debian officially accepted / adopted it as a generic working solution. Also, the fact that one user managed to make it work doesn't mean that the posted information is accurate. AFAIK, not only that Debian has not published any official information about dhcp configuration with syslinux.efi, but also there is no such official documentation about Debian and network-booting UEFI clients (whether with syslinux.efi or with any other UEFI bootloader), and the same goes to Debian derivatives that follow Debian closely (this does not include Ubuntu). AFAIK, at this time you will find no distro / project with official documentation about network-booting syslinux.efi; certainly no official dhcp configuration mixing {l,}pxelinux.0 with syslinux.efi. As for the "arch 9 vs. arch 7" conflict, my comment was not in regard to the (conflicting) documentation. I mean it regarding your own conditional. You are starting with "if arch = 9" and then you react with a VCI stating that "arch = 7"; it doesn't make sense to me. Regarding the "ISC DHCP 3.1" syntax, you "think" it works? I would suggest simplifying your dhcp config and your network setup. Once the basic UEFI case(s) are working, you could then add complexity. I would also suggest searching for official documentation (e.g. about ISC DHCP 3.1 syntax, commands, config...), instead of almost-randomly copy&pasting from different resources that are not proven-to-work (specially when they are mixed altogether in a soup). Perhaps someone else in this Syslinux Mailing List might be so kind and post some dhcp config for UEFI clients that are known / proved to be working. Regards, Ady.
Ady: You seem to be taking (copy$paste) parts and pieces from different resources. Luke: Nope. The configuration works fine with PXE 2.01 clients, it's the UEFI PXE 3.2 that is having issues with the dhcp requests. The gospel is the Intel PXE 3 spec I'm RTFMing now. No copy and paste, I just started with someone elses configuration file that claims to support UEFI - or at least hopes to in the future. Ady:You also seem to be assuming that all those resources are somewhat officially confirmed (proved) to be working, both individually and mixed together. Additionally, this email thread is getting slightly harder to read and to follow. As for the "arch 9 vs. arch 7" conflict, my comment was not in regard to the (conflicting) documentation. I mean it regarding your own conditional. You are starting with "if arch = 9" and then you react with a VCI stating that "arch = 7"; it doesn't make sense to me. Luke: It's trivial Arch 9 isn't used here yet, it's a typo it only ever sent out the Arch 7 one. I am using wireshark to confirm what the DHCP is sending out and receiving in both cases. The problem PXE-E99 is reported to be caused by MTFTP Failure (Dell our vendor & others) or Jumbo Frames on the Lan (IBM/Microsoft blogs). A different error usually reports incompatible DHCP options. Ady: Regarding the "ISC DHCP 3.1" syntax, you "think" it works? Luke: I test the configuration works, and RTFM the Syslinux docs. If it didn't work the dhcpd wouldn't start up. The configuration I inherited was less structured. I verify it works with a network analyser. DHCP requests are not that hard to read in wireshark now are they? DHCP Options should be defined in the global section, and used only in a class, scope,group. I am using site options for PXELinux (which work the default) and Vendor options for extra TFTPBoot options. The Vendor Class thing you took an issue with is to non-PXE devices that use DHCP option 43 to ignore the request. Ady: I would suggest simplifying your dhcp config and your network setup. Once the basic UEFI case(s) are working, you could then add complexity. Luke: Been there done that. I'm going to read the PXE 3.2 spec and work backwards and make fully compliant requests. Even your own website warns some legacy PXE 2.0 option roms don't like PXE requests that are not fully complaint the specs, and are just using bootp style options (next server and filename + syslinux configuration).See the big long string of Vendor options required for some 2.0 PXE roms provided on Syslinux website and the html doc files: " DHCP Config - Encapsulated option dhcp-class-identifier "PXEClient"; option vendor-encapsulated-options 09:0f:80:00:0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74:0a:07:00:50:72:6f:6d:70:74:06:01:02:08:03:80:00:00:47:04:80:00:00:00:ff;" If the "conventional TFTP" configuration doesn't work on your clients, and setting up a PXE boot server is not an option, you can attempt the following configuration. It has been known to boot some configurations correctly; however, there are no guarantees: I'll have to see if dhcp-isc can add the "ff" at the end of what I'm sending out as per the specs, or encode my own vendor options OR install an intel PXE sever. Luke: I believe the path option you told me to use instead of configuration file is for the ROOT path or the path to APPEND to ALL filenames in Syslinux configuration files. This does not let you have a common configuration, but different root directories for EFI32,EFI64,Legacy BIOS pxe clients. I intend to use that to configure the root path later for use with lpxelinux.0 to be http://my.server.ip/tftpboot Ady: I would also suggest searching for official documentation (e.g. about ISC DHCP 3.1 syntax, commands, config...), instead of almost-randomly copy&pasting from different resources that are not proven-to-work (specially when they are mixed altogether in a soup). Luke: it makes perfect sense to me what it's all doing. I'm actually thinking that I might just bite the bullet and set up an intel PXE server instead of DHCP, but what I probably will do is emulate what works. See what options MS System Centre Configuration Manager is using with MTFTP turned off to make the DHCPD send the same responses. Ady:Perhaps someone else in this Syslinux Mailing List might be so kind and post some dhcp config for UEFI clients that are known / proved to be working. Luke: Yes, that's why I posted ;) The other issue here, if you read the link to the ibm document, is that you are going to need extra configuration when you don't have your tftpd on the same server as the pxe/dhcp server sending a bootfile - you may require extra configuration that I'm lacking. I'll try and set up a MTFTP server now just to prove a point that it can work if you specify where the MTFTP server is. PXE 3.0 has a MTFTP discovery process built in that defaults to on that you may need to turn off. I'll set up a MTFTP atftpd server see if it appeases it. Links: http://osdir.com/ml/network.dhcp.isc.dhcp-server/2003-01/msg00287.html Why use vendor class option: http://www.symantec.com/business/support/index?page=content&id=HOWTO7071 http://www-01.ibm.com/support/docview.wss?uid=swg21247032 Option 60 not set, option 43 not set didn't work - so I did try it simply first. Will reverse engineer this: http://ccmexec.com/2013/05/configmgr-2012-uefi-and-pxe-boot-support/ http://support.microsoft.com/kb/259670/en-us Microsoft says what breaks UEFI boot. Using bootfile name instaed #67 - instead of filename in dhcpd.conf #60 = Client Identifier (set to "PXEClient") #66 #67 = Boot Server Host/File Name https://jprudente.wordpress.com/2014/02/18/troubleshooting-pxe-booting/ more on the above. I'll update the list when I fixed it with the working configuration ok :)
Luke, I'd suggest start with a simpler setup and then start building back out slowly to find what doesn't cooperate. On Fri, Nov 28, 2014 at 5:26 AM, Ady <ady-sf at hotmail.com> wrote:> Perhaps someone else in this Syslinux Mailing List might be so kind and > post some dhcp config for UEFI clients that are known / proved to be > working.The following is a relatively simple config that is functioning. VMware Workstation only uses ISC DHCPD 2 so the syntax is simpler. If it were ISC-DCHPD 3, I'd probably go with the following instead of the per-host spec: option arch code 93 = unsigned integer 16; if option arch = 00:06 { filename "e3/bootia32.efi"; } else if option arch = 00:07 { filename "e6/bootx64.efi"; } else if option arch = 00:00 { filename "pxelinux.0"; } Please note I have each architecture booting into a different directory with symlinks on my machine to allow file reuse. -- -Gene allow unknown-clients; default-lease-time 1800; # default is 30 minutes max-lease-time 7200; # default is 2 hours subnet 172.21.1.0 netmask 255.255.255.0 { range 172.21.1.128 172.21.1.254; option broadcast-address 172.21.1.255; option domain-name-servers 172.21.1.2; option domain-name localdomain; default-lease-time 1800; # default is 30 minutes max-lease-time 7200; # default is 2 hours option netbios-name-servers 172.21.1.2; option routers 172.21.1.2; } host 7x { hardware ethernet 00:0C:29:38:6B:6E; filename "e6/bootx64.efi"; next-server 172.21.1.1; # option vendor-encapsulated-options d2:1B:68:74:74:70:3A:2F:2F:31:37:32:2E:32:31:2E:31:2E:31:2F:74:66:74:70:2F:65:36:2F:00:FF; }