Dnsmasq bios and uefi

[george1421]

Being the daring person I am,. I downloaded the source code for dnsmasq 2.76 to the Raspberry Pi. I checked and gcc was installed so I “thought” I was good to go. I compiled and installed dnsmasq 2.76. Everything went great until I tried to restart the dnsmasq service. The start command responded with an illegal command switch was used to launch the application. There was not indication to what or why just it wasn’t going to start.

After doing a bunch of digging and reverse engineering I found that a few options needed to be defined in the src/config.h file. More precisely.

#define HAVE_DBUS
#define HAVE_IDN
#define HAVE_CONNTRACK
#define HAVE_DNSSEC

As well as some required libraries:

sudo apt-get update
sudo apt-get install -y libdbus-1-dev libnetfilter-conntrack-dev libidn11-dev nettle-dev libval-dev dnssec-tools

Once everything was in place I ran the following command again:
sudo make install

then
sudo service dnsmasq restart

I started wireshark again and pxe booted the target laptop. This time I saw the dhcp discover, offer from both the router and the dnsmasq server, then dhcp request and finally the dhcp ack from the router. !! On the client it had booted to the point the iPXE kernel was initializing devices. (!!)

The rest of the settings didn’t change all I did for this pass is upgrade dnsmasq from 2.72 to 2.76 (the version reported to work with uefi firmware).

[george1421]

Here is a pcap of the proper UEFI PXE boot. This was captured from the FOG-Pi server perspective.

0_1475453397643_uefi_pxe_boot.pcap

While I haven’t been able to get into the iPXE boot menu as of now, I can say that the dnsmasq part appears to be working since the iPXE kernel makes it to the target. But right now the iPXE kernel tries to initialize the devices for about 5 minutes then reboots the computer. I still need to dig into that but so far its taken me 4 hours to get this far so enough for tonight.

[Sebastian Roth]

@george1421 Great work so far! The only problem I see is that your other DHCP server (which hands out the IP) also offers the next-server option (pointing to a different IP!). This does not seem to be a problem in the first round of DHCP as the iPXE binary is being loaded via TFTP properly but I am pretty sure you will run into this as soon as you get past the initializing devices… part of iPXE.

That said I am really wondering why it hangs. Have you tried the exact same ipxe.efi binary supplied to the client with a different DHCP server? From what I remember I never had different results when offering ipxe.efi with isc-dhcp vs. dnsmasq.

[george1421]

@Sebastian-Roth I also saw that too (dhcp server sending out the next-server). The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware. I could reflash it with DD-WRT but it hasn’t been a problem until now.

As for the 6230 hanging. If I remember right that series was the first to fully support network pxe booting in uefi mode. I need to check to see if there is a firmware update for that. I also plan on building an ipxe usb boot disk to check to see if its the ipxe kernel or something else. The last bit is I might try the old ipxe kernel that Tom added back into fog, the one for getting the Surface Pros to boot. I think my issue is with ipxe and not dhcp/dnsmasq at this time since the ipxe kernel is making it to the target computer.

[Sebastian Roth]

@george1421 said:

The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware.

Unfortunately a lot of home router devices seem to do this stupid thing. I still have no idea why! We have spent a couple of days helping people to make things work with those kind of router. It’s just a pain in the ass - sorry for that.

Keeping my fingers crossed that you can make it work. Just let me know if you need some more advice.

[george1421]

I started doing a bit more reverse engineering on what these bits of the dnsmasq configuration was actually doing.

If you turn off this section of the dnsmasq config, that also disabled udp port 4011 (dhcpProxy).

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

This causes the dhcp proxy function to fail and the device won’t boot.

If you turn off this section

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

The dnsmasq server will not send out the file name in the initial dhcp offer request. Which I found doesn’t matter. I could send out one name for the dhcp offer and another name in the proxy section. The proxy section always won. So in my current config I have the vendor class stuff turned off since it was not impacting what actually was downloaded from the tftp server.

pxe-prompt="Boot to FOG iPXE", 1
pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

So this is what I have for the part that actually sends the file to the booting client. I also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

In the pxe-service line. The first value correlates to the Architecture Type in this document: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General

By creating unique pxe-service lines your dnsmasq server will send out the proper boot file based on the transmitted architecture type in the dhcp request. So far in testing with the 6230 undionly.kpxe is sent in bios mode and ipxe.efi is sent in uefi mode. I’m still hitting a wall in uefi mode where it initializes devices for about 5 minutes then reboots. But the right iPXE kernel is being sent to the target computer. I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

[Wayne Workman]

@george1421 said in Dnsmasq bios and uefi:

also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

Wow…

[george1421]

@Wayne-Workman Considering what is currently being packaged with modern linux distributions is dnsmasq 2.72 (Sep 2014) is over two years old, its about time they did drop the old syslinux syntax requirements. One of many improvements I’ve seen so far.

[edit] Just reviewing the change log for 2.76 this jumps out in regards to file names:

	    Subtle change in the semantics of "basename" in
	    --pxe-service. The historical behaviour has always been
	    that the actual filename downloaded from the TFTP server
	    is <basename>.<layer> where <layer> is an integer which
	    corresponds to the layer parameter supplied by the client.
	    It's not clear what the function of the "layer" 
	    actually is in the PXE protocol, and in practise layer 
	    is always zero, so the filename is <basename>.0
	    The new behaviour is the same as the old, except when
	    <basename> includes a file suffix, in which case
	    the layer suffix is no longer added. This allows
	    sensible suffices to be used, rather then the
	    meaningless ".0". Only in the unlikely event that you
	    have a config with a basename which already has a
	    suffix, is this an incompatible change, since the file
	    downloaded will change from name.suffix.0 to just 
	    name.suffix

[Sebastian Roth]

@george1421 said:

I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

Would you be able to service this exact same ipxe.efi binary using isc-dhcp just to see if it makes a difference? My guess is no but you never know.

[george1421]

@Sebastian-Roth I think my next step is to first update the bios on this computer from A11 to A15. The change log for these updates many uefi updates and hardware (nic and such) firmware updates. I want to make sure I’m not chasing something that has already been addressed. I have 2 issues with getting this done: 1) This computer runs Zorin (ubuntu variant) and the firmware updates are windows based. I have a WinPE flash drive at work that we use to update the computer bios at work. I need to make a copy so I can use it to update this 6230. 2) This is my wife’s computer, if I break it I will never hear the end of it. So I need to be spot on with the upgrade if you know what I mean.

[george1421]

@george1421 I was finally able to update that 6230 from firmware A11 to A15. Without changing my FOG-Pi / dnsmasq setup the 6230 now pxe boots in uefi mode (whoot!!). The kernel stayed at initializing devices for about 15 seconds, I started to panic after 8, I figured it was hung and reach for my FOG GRUB usb boot drive. When I turned around the 6230 was sitting at the FOG iPXE Menu. I timed it again and it was bout 15 seconds to init the devices and display the FOG iOXE menu. I was able to quick register the system and everything worked fine.

Below is my final dnsmasq configuration for dual booting bios (legacy) and uefi systems on dnsmasq version 2.76

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI, ARM_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
 pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
# PXEClient:Arch:00007
 pxe-service=BC_EFI, "Boot UEFI PXE-BC", snp.efi
# PXEClient:Arch:00009
 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

dhcp-range=192.168.112.24,proxy

According to the change log for dnsmasq there are issues with certain uefi firmware for displaying the dnsmasq boot menu so for uefi firmware dnsmasq will just pick the first matching service entry that matches the arch type, as long as there is only one and only matching service. You will not see this menu displayed for uefi firmware, where for bios you will see the menu entry for 1 second.

I did note in the iPXE bootloader that it did say duplicate next server values presented (or something like that). And that is in line with what we were seeing in the earlier pcap where both dnsmasq and the soho router were sending conflicting next-server values.

Here is the pcap of my last and working test. Note: I see I left the snp.efi kernel configured in dnsmasq too!!.

0_1475719888587_output.pcap

[george1421]

@george1421 Last and final comment. Just for grins, I move the original Raspian Jessie version of dnsmasq (v2.72) back in place and restarted dnsmasq. With 2.72 running and the same configuration as before the Dell 6230 failed to pxe boot in UEFI mode, but would boot in bios (legacy) mode. So if you are going to use dnsmasq AND require pxe booting uefi systems you must upgrade dnsmasq to 2.76 or it will fail.

[KnightRaven]

@george1421

Hi,
I was just wondering if you actually got this to work in proxy mode? I have tried and can seem to get it to UEFI boot in proxy. I tried setting dnsmasq to serve as DHCP for a moment(and unplugged from rest of network) with just my test client and Fog/PXE and that worked. Was able to get to Fog menu.

Using dnsmasq 2.76 and just pulled latest fog rc36.

Do I need to compile something differently that I’m not seeing(it’s posible I missed something)? Or does it just not work in proxymode at this time?

thanks,
Jason

[george1421]

@KnightRaven Yes dhcpProxy mode works very well as long as you have 2.76 version of dnsmasq.

Post what your ltsp.conf files is here. I’ll take a look.

Also from the fog server command prompt key in dnsmasq -v and post the output here

[KnightRaven]

@george1421
~ $ dnsmasq -v
Dnsmasq version 2.76 Copyright 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

[george1421]

@KnightRaven OK what I want you to do (speaking as a moderator now) please create a new thread on this issue. and also include the contents of your /etc/dnsmasq.d/ltsp.conf file. We’ll carry on the discussion there.

But your dnsmasq version should/will work for what you want to do.

[KnightRaven]

@KnightRaven
ltsp.conf file…
0_1481838650169_ltsp.conf

I’m about to be out for the day so I may not get a chance to test for a few weeks. The file may also be a bit ugly but i tried to leave as much of the original info in and just updated info as needed.

[KnightRaven]

@george1421

oops. saw too late. Will open new thread.

[george1421]

@KnightRaven Yeah, I see the issue right away. When you are back on this project create a new thread and we can work through what needs to be done. You are missing a few lines that make the uefi bit work.

[xutianhong]

hi, when saw dnsmasq maillist http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q2/011379.html

3q for https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-using-grub2 & https://www.ibm.com/developerworks/community/blogs/a2674a1d-a968-4f17-998f-b8b38497c9f7/entry/uefi-grub2?lang=ru

the problem may not in dnsmasq, when update to version 2.76. uefi boot can see grub>

My env is all in VMware Workstation 12 Pro 12.0.0 build-2985596
NAT mode
192.168.136.200 to dhcp server centos7.3
192.168.136.226 to cobbler( tftpserver & dnsmasq ) centos7.3
dhcp to cobblerctos73(legacy bios)
dhcp to uefi(efi)

1. 136.200 install dhcpd
   conf file like blow

dns-update-style interim;

subnet 192.168.136.0 netmask 255.255.255.0 {
     option routers             192.168.136.2;
     option domain-name-servers 192.168.136.2;
     option subnet-mask         255.255.255.0;
     range dynamic-bootp        192.168.136.240 192.168.136.250;
     default-lease-time         21600;
     max-lease-time             43200;
}

2. 136.226 install centosbase dnsmasq then upgrade to 2.76 from souce, see
   https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq#Compiling dnsmasq 2.76 if you need uefi support

#define HAVE_DBUS
#define HAVE_IDN
/*#define HAVE_IDN_STATIC*/??? this line not need? cuz my centos73 not support this when do make
#define HAVE_CONNTRACK
#define HAVE_DNSSEC

then dnsmasq conf file like blow

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/var/lib/tftpboot

# 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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
#dhcp-boot=net:BIOS,pxelinux.0,,192.168.136.226
#dhcp-boot=net:UEFI32,grub/grub-x86.efi,,192.168.136.226
#dhcp-boot=net:UEFI,BOOTX64.efi,,192.168.136.226
#dhcp-boot=net:UEFI64,grub/grub-x86_64.efi,,192.168.136.226

# The boot filename, Server name, Server Ip Address
dhcp-boot=pxelinux.0,,192.168.136.226

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting UAT Autoinstall Client", 1

dhcp-range=192.168.136.200,proxy


#legacy bios options
pxe-service=X86PC,"Legacy",pxelinux,192.168.136.226

#vmware workstation 12 EFI options
pxe-service=BC_EFI,"BC_EFI",bootx64.efi,192.168.136.226

3. I find many other doc, all can’t work, till this two, see
   https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-using-grub2
   https://www.ibm.com/developerworks/community/blogs/a2674a1d-a968-4f17-998f-b8b38497c9f7/entry/uefi-grub2?lang=ru

it’s use pxe to boot diskless linux, when finish 1&2, I can see grub>. So ….

Tftproot is /var/lib/tftpboot

1. Mkdir tftproot/boot/grub(in cobbler it already have)

2. Vim tftproot/boot/grub/grub.cfg blow this

set timeout=5
menuentry 'Linux diskless' --class os {
     insmod net
     insmod efinet
     insmod tftp
     insmod gzio
     insmod part_gpt
     insmod efi_gop
     insmod efi_uga
     # dhcp, tftp server in my network
     set net_default_server=192.168.136.226
     # auto dhcp setup did not work for me, no idea why
     # net_bootp
     # ok let's assign a static address for now
     net_add_addr eno0 efinet0 192.168.136.246
     echo 'Network status: '
     net_ls_cards
     net_ls_addr
     net_ls_routes
     echo 'Loading Linux ...'
     linux (tftp)/boot/vmlinuz inst.ks=http://192.168.136.226/cblr/svc/op/ks/profile/rhel73-x86_64
     echo 'Loading initial ramdisk ...'
     initrd (tftp)/boot/initrd.img
}

3. grub2-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --fonts=“unicode” -o /var/lib/tftpboot/bootx64.efi boot/grub/grub.cfg
4. systemctl restart dnsmasq.

Just power up uefi.

Dhcpd log blow

May 20 23:46:05 localhost.localdomain dhcpd[844]: DHCPDISCOVER from 00:0c:29:87:09:d5 via ens33
May 20 23:46:06 localhost.localdomain dhcpd[844]: DHCPOFFER on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:46:08 localhost.localdomain dhcpd[844]: DHCPREQUEST for 192.168.136.246 (192.168.136.200) from 00:0c:29:87:09:d5 via ens33
May 20 23:46:08 localhost.localdomain dhcpd[844]: DHCPACK on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:48:36 localhost.localdomain dhcpd[844]: DHCPDISCOVER from 00:0c:29:87:09:d5 via ens33
May 20 23:48:37 localhost.localdomain dhcpd[844]: DHCPOFFER on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:48:40 localhost.localdomain dhcpd[844]: DHCPREQUEST for 192.168.136.246 (192.168.136.200) from 00:0c:29:87:09:d5 via ens33
May 20 23:48:40 localhost.localdomain dhcpd[844]: DHCPACK on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:50:08 localhost.localdomain dhcpd[844]: DHCPDISCOVER from 00:0c:29:87:09:d5 via ens33
May 20 23:50:09 localhost.localdomain dhcpd[844]: DHCPOFFER on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:50:09 localhost.localdomain dhcpd[844]: DHCPREQUEST for 192.168.136.246 (192.168.136.200) from 00:0c:29:87:09:d5 via ens33
May 20 23:50:09 localhost.localdomain dhcpd[844]: DHCPACK on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33
May 20 23:50:26 localhost.localdomain dhcpd[844]: DHCPREQUEST for 192.168.136.246 from 00:0c:29:87:09:d5 via ens33
May 20 23:50:26 localhost.localdomain dhcpd[844]: DHCPACK on 192.168.136.246 to 00:0c:29:87:09:d5 via ens33

Dnsmasq log blow

5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 PXE(ens33) 00:0c:29:87:09:d5 proxy
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 tags: UEFI64, ens33
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 next server: 192.168.136.226
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 broadcast response
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 sent size:  1 option: 53 message-type  2
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 sent size:  4 option: 54 server-identifier  192.168.136.226
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
5月 20 23:46:05 cobbler dnsmasq-dhcp[1499]: 1607759066 sent size: 17 option: 97 client-machine-id  00:56:4d:15:7a:51:36:e6:8f:fd:fe:4d:c4:27...
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1607759066 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1607759066 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 PXE(ens33) 00:0c:29:87:09:d5 proxy
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 tags: UEFI64, ens33
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 bootfile name: bootx64.efi
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 server name: 192.168.136.226
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 next server: 192.168.136.226
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 sent size:  1 option: 53 message-type  5
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 sent size:  4 option: 54 server-identifier  192.168.136.226
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
5月 20 23:46:08 cobbler dnsmasq-dhcp[1499]: 1726852750 sent size: 17 option: 97 client-machine-id  00:56:4d:15:7a:51:36:e6:8f:fd:fe:4d:c4:27...
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 PXE(ens33) 00:0c:29:87:09:d5 proxy
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 tags: UEFI64, ens33
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 next server: 192.168.136.226
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 broadcast response
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 sent size:  1 option: 53 message-type  2
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 sent size:  4 option: 54 server-identifier  192.168.136.226
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
5月 20 23:48:36 cobbler dnsmasq-dhcp[1499]: 430386701 sent size: 17 option: 97 client-machine-id  00:56:4d:15:7a:51:36:e6:8f:fd:fe:4d:c4:27...
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 430386701 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 430386701 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 vendor class: PXEClient:Arch:00009:UNDI:003016
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 PXE(ens33) 00:0c:29:87:09:d5 proxy
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 tags: UEFI64, ens33
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 bootfile name: bootx64.efi
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 server name: 192.168.136.226
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 next server: 192.168.136.226
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 sent size:  1 option: 53 message-type  5
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 sent size:  4 option: 54 server-identifier  192.168.136.226
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 sent size:  9 option: 60 vendor-class  50:58:45:43:6c:69:65:6e:74
5月 20 23:48:40 cobbler dnsmasq-dhcp[1499]: 549480385 sent size: 17 option: 97 client-machine-id  00:56:4d:15:7a:51:36:e6:8f:fd:fe:4d:c4:27...
5月 20 23:50:08 cobbler dnsmasq-dhcp[1499]: 278376755 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:50:08 cobbler dnsmasq-dhcp[1499]: 278376755 vendor class: anaconda-Linux 3.10.0-514.el7.x86_64 x86_64
5月 20 23:50:09 cobbler dnsmasq-dhcp[1499]: 278376755 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:50:09 cobbler dnsmasq-dhcp[1499]: 278376755 vendor class: anaconda-Linux 3.10.0-514.el7.x86_64 x86_64
5月 20 23:50:26 cobbler dnsmasq-dhcp[1499]: 2725144841 available DHCP subnet: 192.168.136.200/255.255.255.0
5月 20 23:50:26 cobbler dnsmasq-dhcp[1499]: 2725144841 vendor class: anaconda-Linux 3.10.0-514.el7.x86_64 x86_64

Tftp log blow

5月 20 23:46:09 cobbler in.tftpd[2257]: RRQ from 192.168.136.246 filename bootx64.efi
5月 20 23:46:09 cobbler in.tftpd[2258]: RRQ from 192.168.136.246 filename bootx64.efi
5月 20 23:48:41 cobbler in.tftpd[2285]: RRQ from 192.168.136.246 filename bootx64.efi
5月 20 23:48:41 cobbler in.tftpd[2286]: RRQ from 192.168.136.246 filename bootx64.efi
5月 20 23:48:58 cobbler in.tftpd[2287]: RRQ from 192.168.136.246 filename /boot/vmlinuz
5月 20 23:49:04 cobbler in.tftpd[2288]: RRQ from 192.168.136.246 filename /boot/initrd.img

***Now, the uefi boot is done.
It’s not perfect.
Cuz in grub.cfg we need write nextserver ip & host ip,
And grub2-mkstandalone command write grub.cfg in bootx64.efi, cuz I change boot/grub/grub.cfg it’s. not working.
So now I working to grub lib, want find way to solve this 3 problem.

If anybody working with grub/grub2, can give me some idea? thank you very much.***