Cant PXE Boot = PXE-T01: File not Found
-
Hi Guys,
allow me to ask some general questions before my “real” question:
- After a Normal Fog install i should be able to get to the iPXE Boot Menu right out of the Box using the Legacy or UEFI PXE boot, right?
- What is the tftpboot location on FOG 1.4.4, is it just /tftpboot beside the other folders such as /home, /etc, /bin…?
- Why does the DHCP not need the “filename:undipxe.k/pxelinux.0” Option?
So today i wanted to play around with fog but unfortunately i did not succeed in doing so.
I tried to install the latest stable fog v1.4.4 on a fresh install of Debian 9.3(VM on ESXI). I set up an isolated network for testing.I downloaded it from sourceforge using wget, i did unzip it using tar and then i ran ./installfog.sh
The setup went through without any errors. After install i could login without a problem on http://ip/fog/management
Then i tried to PXE Boot a client. First i tried UEFI Boot. It didnt tell me anything. Then i tried Legacy and it told me “PXE-T01: File not Found”
i searched the net but i couldnt find a solution. What i found out so far:
- DHCP is up and running, the Client gets an IP
- TFTP seems to be the issue. I dont have a /tftpboot folder with all the binaries - do i have to build them myself? I thought the FOG installscript provided them?
the tftp-hpa config says:
TFTP_USERNAME=“tftp”
TFTP_DIRECTORY=“/srv/tftp” (this folder is empty…it should say /tftpboot, right?)
TFTP_ADDRESS=“0.0.0.0:69”
TFTP_OPTIONS=“–secure”The Web-GUI says:
FOG_TFTP_PXE_KERNEL_DIR: /var/www/fog//service/ipxe/
inside there are files like bzimage, init.xz, etc.did something fail during install?
Thanks in advance for your help.
-
After a Normal Fog install i should be able to get to the iPXE Boot Menu right out of the Box using the Legacy or UEFI PXE boot, right?
Not necessarily. If FOG is doing DHCP and there isn’t another dhcp server operating with the same broadcast domain, then yeah you can pxe boot out of the box once fog is installed. This is the only case where it works ‘out of box’. All other scenarios require additional configuration somewhere.
What is the tftpboot location on FOG 1.4.4, is it just /tftpboot beside the other folders such as /home, /etc, /bin…?
The iPXE binaries are placed into
/tftpboot
automatically by the installer.Why does the DHCP not need the “filename:undipxe.k/pxelinux.0” Option?
No idea. the
.0
thing was a bug in the old dnsmasq versions - which has since been fixed by dnsmasq’s maintainer Simon Kelly. It’s interesting that you even ask this, because this suggests you have DHCP running on another server somewhere besides the FOG server.As for all the other stuff - just start over. I have no idea where you went wrong, and don’t want to waste time trying to figure out what went wrong. There’s nothing important in your broke VM, so just delete the VM and make a new one. Also, use git this time instead of sourceforge. Instructions here: https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG
Here’s a full video showing a Debian 8 setup that will also work with Debian 9: https://wiki.fogproject.org/wiki/index.php?title=Debian_8 -
First of all thank you very much for your fast answer. I really appreciate that.
Ok yes you are right. Its not worth wasting time.
I tried two times again with a complete fresh install but it didn’t work. The installfog.sh script always stopped at “setting up and starting dhcp…failed!” after this nothing more happened. The log always said something about “Start LSB: failed”
I then installed debian 8 and with first try everything worked as expected. Now there is the /tftpboot directory containing all the necessary files and the boot menu comes up either booting UEFI or Legacy.
But somehow it seems like fog is not the thing i need or i cannot use it right…
I wanted to get a Linux Boot menu that looks a little bit like this:- Install Windows
- Windows7x64
- Windows8.1x64
- Windows10x64
- Boot Rescue/Antivirus Disks
- Kaspersky
- Bitdefender
- System diagnostics
- MEMTEST
… and so on
- MEMTEST
So actually i thought i could capture a reference PC and then deploy the image without doing host registration and stuff like that. The reason is that there is no domain and there will never be one. Right now we are using WDS but i wanted to try out some Linux based thing and somehow it came to my mind that cloning should go faster and the System would be completely ready after cloning. But if fog can only be used after host registration and then assigning an image over the web gui then this seems not to be the right thing to go with.
I just want to boot to the pxe menu, select the OS to be installed on the host and that’s it. Hoepfully after 20 Min everything is done and the system is ready to use and it’s important that both UEFI and LEGACY Boot work…
Using the WDS it is alot about tweaking the answerfiles and stuff like that. I hope you get my point.
Do you think i should only use iPXE and try to chainload into WDS?
Thanks in advance for your help.
- Install Windows
-
@404 You can do something similar but not exactly.
FOG does have a Deploy menu on the FOG iPXE boot menu. From the Deploy, you can select an image to send to target systems without needing to register the target system first. A hardware remanufacturer may use this route if they never planned on seeing the target system again. If the system was going to remain on your campus then I would suggest going the registration route because you have some post imaging capabilities not available when you just quick image a system. FWIW: registration has nothing to do with AD.
You can create submenus in FOG, actually iPXE if you hand code the submenus. Its not that difficult if you read up on iPXE and then create the menus in fog and test them for structure by using this url path on your fog server http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=000000000001
-
@404 As you can see in Wayne’s message signature he’s got an automatic test environment that does daily installs on several different distros/versions (including debian 9) and we don’t see any issue there at the moment. If you are still keen to find the issue please post your install logs here.
For the other things like “what can FOG do/don’t do” I’d ask you to open a new thread and ask your specific questions. We try to keep things sorted a bit here so other people can follow if they have the same issue. For those people it’s not helpful if several different issues are being discussed in one thread.
-
@Sebastian-Roth Ok, i get your point. Sorry about that.
Could you tell me where i find those install logs. I would love to share them and find a solution
Thank you.
-
@404 No worries. Just trying to keep things a bit sorted.
In the same directory where you have the
installfog.sh
script a subdirectoryerror_logs/
is created… you should find two log files there. Upload both and we’ll have a look. -
ok, here we go
https://mega.nz/#!5EgC1RZZ!BOfPySnN9QyL40H4bqTTVe9vPoRQsIJ7T-DGrO_QcrY
https://mega.nz/#!8MwRiRAK!-lx9bMjRzG0_EwoPixuhxcm9bjdOoZ5JD77QEjDCGQkI couldn’t upload my files here directly to the forum so i just put them up on mega.nz
Thanks for your help
-
Moved this to bugs, because I confirmed the problem in master branch.
@Sebastian-Roth I just tried doing an install on Debian9 with 1.4.4. If you specify the installer to setup dhcp, it fails when trying to start the dhcp server. And because the /tftpboot directory is setup after dhcp is, that doesn’t get done.
I’ve been digging into the problem, it’s IPv6 related as far as I can see right now. Here’s the error:
Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed!
Snippet from
journalctl -xe
:root@Debian9:/# journalctl -xe Dec 30 14:14:34 Debian9 dhcpd[22356]: Dec 30 14:14:34 Debian9 dhcpd[22356]: Dec 30 14:14:34 Debian9 dhcpd[22356]: Not configured to listen on any interfaces! Dec 30 14:14:34 Debian9 dhcpd[22356]: Dec 30 14:14:34 Debian9 dhcpd[22356]: If you think you have received this message due to a bug rather Dec 30 14:14:34 Debian9 dhcpd[22356]: than a configuration issue please read the section on submitting Dec 30 14:14:34 Debian9 dhcpd[22356]: bugs on either our web page at www.isc.org or in the README file Dec 30 14:14:34 Debian9 dhcpd[22356]: before submitting a bug. These pages explain the proper Dec 30 14:14:34 Debian9 dhcpd[22356]: process and the information we find helpful for debugging.. Dec 30 14:14:34 Debian9 dhcpd[22356]: Dec 30 14:14:34 Debian9 dhcpd[22356]: exiting. Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed! Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: failed! Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1 Dec 30 14:14:36 Debian9 systemd[1]: Failed to start LSB: DHCP server. -- Subject: Unit isc-dhcp-server.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit isc-dhcp-server.service has failed. -- -- The result is failed. Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state. Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
This is
systemctl status isc-dhcp-server
:root@Debian9:/etc/dhcp# systemctl status isc-dhcp-server ● isc-dhcp-server.service - LSB: DHCP server Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2017-12-30 14:14:36 CST; 11min ago Docs: man:systemd-sysv-generator(8) Process: 22339 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE) Tasks: 1 (limit: 4915) CGroup: /system.slice/isc-dhcp-server.service └─22351 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf Dec 30 14:14:32 Debian9 dhcpd[22350]: Wrote 0 leases to leases file. Dec 30 14:14:32 Debian9 dhcpd[22351]: Server starting service. Dec 30 14:14:34 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv4 server: dhcpd. Dec 30 14:14:34 Debian9 dhcpd[22356]: Wrote 0 NA, 0 TA, 0 PD leases to lease file. Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed! Dec 30 14:14:36 Debian9 isc-dhcp-server[22339]: failed! Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1 Dec 30 14:14:36 Debian9 systemd[1]: Failed to start LSB: DHCP server. Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state. Dec 30 14:14:36 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
Snippet from the bottom of my fog error log:
Dec 20 19:59:42 Debian9 systemd[1]: Starting The PHP 7.0 FastCGI Process Manager... Dec 20 19:59:42 Debian9 systemd[1]: Started The PHP 7.0 FastCGI Process Manager. isc-dhcp-server.service is not a native service, redirecting to systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable isc-dhcp-server Job for isc-dhcp-server.service failed because the control process exited with error code. See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details. ● isc-dhcp-server.service - LSB: DHCP server Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2017-12-20 20:00:12 CST; 2s ago Docs: man:systemd-sysv-generator(8) Process: 21889 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE) Tasks: 1 (limit: 4915) CGroup: /system.slice/isc-dhcp-server.service └─21901 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf Dec 20 20:00:10 Debian9 dhcpd[21906]: than a configuration issue please read the section on submitting Dec 20 20:00:10 Debian9 dhcpd[21906]: bugs on either our web page at www.isc.org or in the README file Dec 20 20:00:10 Debian9 dhcpd[21906]: before submitting a bug. These pages explain the proper Dec 20 20:00:10 Debian9 dhcpd[21906]: process and the information we find helpful for debugging.. Dec 20 20:00:12 Debian9 isc-dhcp-server[21889]: Starting ISC DHCPv6 server: dhcpd6check syslog for diagnostics. ... failed! Dec 20 20:00:12 Debian9 isc-dhcp-server[21889]: failed! Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1 Dec 20 20:00:12 Debian9 systemd[1]: Failed to start LSB: DHCP server. Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Unit entered failed state. Dec 20 20:00:12 Debian9 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
Here’s the output of
ip addr
:root@Debian9:/# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:67:a2:b4 brd ff:ff:ff:ff:ff:ff inet 10.0.0.39/24 brd 10.0.0.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe67:a2b4/64 scope link valid_lft forever preferred_lft forever
Output of
ifconfig
root@Debian9:/# ifconfig ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.0.39 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 fe80::5054:ff:fe67:a2b4 prefixlen 64 scopeid 0x20<link> ether 52:54:00:67:a2:b4 txqueuelen 1000 (Ethernet) RX packets 163559 bytes 232881890 (222.0 MiB) RX errors 0 dropped 231 overruns 0 frame 0 TX packets 44237 bytes 4542466 (4.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 46 bytes 1794 (1.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 46 bytes 1794 (1.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
This is my
dhcpd.conf
file:root@Debian9:/etc/dhcp# cat dhcpd.conf # DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample # This file was created by FOG #Definition of PXE-specific options # Code 1: Multicast IP Address of bootfile # Code 2: UDP Port that client should monitor for MTFTP Responses # Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests # Code 4: Number of seconds a client must listen for activity before trying # to start a new MTFTP transfer # Code 5: Number of seconds a client must listen before trying to restart # a MTFTP transfer option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; use-host-decl-names on; ddns-update-style interim; ignore client-updates; # Specify subnet of ether device you do NOT want service. # For systems with two or more ethernet devices. # subnet 136.165.0.0 netmask 255.255.0.0 {} subnet 10.0.0.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range dynamic-bootp 10.0.0.10 10.0.0.254; default-lease-time 21600; max-lease-time 43200; option routers 10.0.0.1; option domain-name-servers 208.67.222.222; next-server 10.0.0.39; class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "undionly.kkpxe"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/ipxe.efi"; } class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "ipxe.efi"; } class "SURFACE-PRO-4" { match if substring(option vendor-class-identifier, 0, 32) = "PXEClient:Arch:00007:UNDI:003016"; filename "ipxe7156.efi"; } class "Apple-Intel-Netboot" { match if substring(option vendor-class-identifier, 0, 14) = "AAPLBSDPC/i386"; option dhcp-parameter-request-list 1,3,17,43,60; if (option dhcp-message-type = 8) { option vendor-class-identifier "AAPLBSDPC"; if (substring(option vendor-encapsulated-options, 0, 3) = 01:01:01) { # BSDP List option vendor-encapsulated-options 01:01:01:04:02:80:00:07:04:81:00:05:2a:09:0D:81:00:05:2a:08:69:50:58:45:2d:46:4f:47; filename "ipxe.efi"; } } } }
-
Figured it out. In Debian 9, you have to put the interface name into this file:
/etc/default/isc-dhcp-server
When I looked at mine, it looked like this:
INTERFACESv4="" INTERFACESv6=""
So I changed it to read like this:
INTERFACESv4="ens3" INTERFACESv6=""
Then I had to remove the pid file:
rm -f /var/run/dhcpd.pid
Then, I could finally start the dhcp service:
systemctl start isc-dhcp-server
-
@wayne-workman ok perfect, thanks for your fast reaction. I will give it a try…
So this way it should only start the DHCPv4 and ignore the v6 stuff, right?I will try to install the isc-dhcp-server first and set this up. Then i will run the installfog.sh an see what happens
Thanks
-
@404 Well, what I’d suggest for now is to run the fog installer as normal. After it fails, go edit that one file, delete the pid file, then re-run the installer again. It should succeed the second time. FOG has to carefully configure the dhcp server so that multiple architectures are supported. We’re going to write a patch here shortly to fix this in working branch.
-
@wayne-workman Thanks heaps for looking into this! Reading through a couple of old posts on the internet I kind of came to the same conclusion that it’s an issue with a missing/wrong
/etc/default/isc-dhcp-server
parameter.Hmmmm, I am wondering how we are going to fix this. Why is it working in debian 8? I’d actually expect debian (dpkg) to generate
/etc/default/isc-dhcp-server
properly! -
@sebastian-roth said in Cant PXE Boot = PXE-T01: File not Found:
Hmmmm, I am wondering how we are going to fix this.
Maybe a sed command that uses a variable. This would only match if it’s empty:
interface="ens3" sed -i "s/INTERFACESv4=\"\"/INTERFACESv4=\"$interface\"/g" /etc/default/isc-dhcp-server
-
@Wayne-Workman Yeah sure we can just force it. But I am wondering why this is the case. Searching more I found this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815319
So the issue has been around for a fair bit of time. But I still haven’t figured out if this is just an issue with the debian specific start scripts or if it’s actually a newer isc-dhcp-server version doing the env variable check… then fails if it’s not set - very poor I find.
-
Interesting… the bug report just posted ends with stating that this is fixed in version
4.3.5-1
. In the logs posted I see version4.3.5-3
being installed. Possibly a regression?Edit: Here we go I think: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862680
Although I really like debian I am still not sure if this is something we should fix. Maybe we do and next time debian is doing something different again…?!
-
This is a pretty simple fix, so I don’t see why not. If the debian team fixes it later, great. When they fix it, the sed command will stop matching. just my opinion. I think we should make the installer work on the mainstream distributions - even with their problems to an extent.
-
Seems like the newer isc-dhcp-server version does start as IPv4 and IPv6 DHCP server if no interface is given in
/etc/defaults/isc-dhcp-server
. As we don’t have any IPv6 definition in our config it fails to start. One way to fix this would be to add IPv6 defintion but as I don’t think this will be of much use to any of our FOG users I’d better follow Wayne’s idea on fixing/etc/defaults/isc-dhcp-server
.Fix is pushed in
working
branch. So here is another reason to push for the next release. -
@sebastian-roth said in Cant PXE Boot = PXE-T01: File not Found:
So here is another reason to push for the next release.
I think we are ready for another RC.