Dnsmasq bios and uefi
-
@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.
-
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.
-
@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…
-
@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
-
@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.
-
@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 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!!.
-
@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.
-
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 -
@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 -
@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 inotifyThis 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. -
@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
ltsp.conf file…
0_1481838650169_ltsp.confI’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.
-
oops. saw too late. Will open new thread.
-
@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.
-
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)- 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; }
- 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
- 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
-
Mkdir tftproot/boot/grub(in cobbler it already have)
-
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 }
- 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
- 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.***
- 136.200 install dhcpd
-
@xutianhong of just use refind which is meant to automatically use EFI?
-
@Tom-Elliott hi, i just google what is rEFInd. dose rEFInd support BIOS/EFI pxeboot?
-
@xutianhong I’m not sure I follow. Grub and rEFInd are exit types, to leave pxe and boot to HDD.
-
If you’re simply trying to boot an iso, ipxe supports this natively.