Fujitsu T939 Tablet not PXE Booting

[george1421]

@michaeloberg What is the Host OS on the fog server. Its pretty strange that your distros repo doesn’t have 2.76 unless you are running an older host OS.

And to answer your question about step 6, that should be in the base directory where you extracted the dnsmasq tar ball into. sudo find / -name dnsmasq* should give you some hints too.

[michaeloberg]

@george1421 The Host OS is Unbuntu 16.04.06.

When I log into the system it shows the following:

Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-66-generic x86_64)

• Documentation: https://help.ubuntu.com
• Management: https://landscape.canonical.com
• Support: https://ubuntu.com/advantage

144 packages can be updated.
36 updates are security updates.

New release ‘18.04.2 LTS’ available.
Run ‘do-release-upgrade’ to upgrade to it.

Last login: Mon Sep 23 09:26:54 2019 from 10.2.0.39

Again I am a novice to Linux so I am not sure - will this upgrade me to the latest release of Ubuntu? When I typed in sudo find / -name dnsmasq* it displayed the following:

mike@fog-server:~$ sudo find / -name dnsmasq*
[sudo] password for mike:
find: paths must precede expression: dnsmasq-2.76.tar.gz
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec|time] [path…] [expression]
mike@fog-server:~$

Thanks in advance,

Michael

[Sebastian Roth]

@michaeloberg Start at step 4 when you loose the connection on a SSH shell:

cd dnsmasq-2.76
sudo vi src/config.h
...

[michaeloberg]

@Sebastian-Roth OK did that, and get the following Error (I am assuming I choose Edit anyway, but want to be sure)

[george1421]

@michaeloberg From the error message you where/are editing that file in another session and it left the swp file behind. This is in line with your session timing out. You can either manually delete the swp file D and start editing it over or just press the R to recover the edits saved in this this file .

[michaeloberg]

@george1421 What a case of the Monday’s…

I found the section:
/* #define HAVE_LUASCRIPT /
/ #define HAVE_DBUS /
/ #define HAVE_IDN /
/ #define HAVE_CONNTRACK /
/ #define HAVE_DNSSEC */

And I put the cursor directly above the commented section but cannot figure out how to paste the following:

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

I tried to do a CTRL V and --INSERT-- showed up and I have no idea where it paste or even if it did. I am so lost…

Michael

[Sebastian Roth]

@michaeloberg Switching to chat for now. Check the speech bubble in the top right of the forum.

[michaeloberg]

@Sebastian-Roth

[Sebastian Roth]

We got dnsmasq compiled and legacy systems PXE boot properly. But UEFI had an issue as seen in the picture. Kind of strange as I didn’t see proper information the the logs.

@michaeloberg When you get back with more time take a look at the logs (sudo tail -f /var/log/syslog) when booting up the UEFI client. You should see information as mentioned here: https://forums.fogproject.org/topic/13113/dell-optiplex-7050-and-uefi-boot-failed

...
... vendor class: PXEClient:Arch:00007:UNDI ...
...

[george1421]

@Sebastian-Roth I would have to wonder if dnsmasq is working as expected -or- secure boot is enabled on the target computer?

I think I might want to start with a pcap to see if all of the players are behaving like we expect: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If the fog server and target computer are on the same IP subnet then we should get a clear picture of the pxe booting process. If the proper iPXE boot loader gets sent then we’ll have to focus on why iPXE isn’t starting or see if our FOS Linux usb boot method works. I don’t like to go with the usb boot options because of the down sides of doing it that way.

[michaeloberg]

@george1421 @Sebastian-Roth

Good morning gentleman,

Not sure if this helps but I did some experimenting this morning (Windows side of things).

After Sebastian installed dnsmasq onto my FOG server we disabled Option 66 Boot Server Host Name and Option 67 Bootfile Name on my Domain Controller that hands out DHCP. As Sebastian mentioned the legacy client fired right up and the UEFI boot client had the “Warning Boot Failure” error.

So below is the information I have and hopefully it makes sense.

When I disable option 66 & 67 on my DHCP server the Legacy client boots - UEFI client does not

When I leave option 66 & 67 on my DHCP server they both boot: Legacy boots off FOG - UEFI boots off my DHCP server with ipex.efi as my boot file in Option 67:

Beautiful - but not sure if this is how it is suppose to work (dnsmasq in conjunction with Windows DHCP)???

Again feedback appreciated and hopefully this didn’t add confusion. As of right now to the blind eye everything works - all computers, BIOS options, etc. Are further modifications needed or is it OK to run this way?

Thanks,

Michael

[george1421]

@michaeloberg As long as the fog server and pxe booting client are on the same subnet, with dnsmasq running I would like to see a pcap of that booting process where it takes us to that error screen. You have proven that ipxe,efi will boot on that workstation, we just need to understand why its not getting that information from dnsmasq.

[Sebastian Roth]

@michaeloberg Interesting workaround you cam up with! Using dnsmasq for legacy BIOS machines (undionly.kpxe) and Windows DHCP for UEFI ones (ipxe.efi). While it seems to work properly I am fairly sure this will be failing one or the other time because both send out PXE boot information and this is known to cause trouble.

As George said, would be good to get the packet dump (pcap) to understand what’s going on. For that you’d disable option 66 & 67 on your Windows DHCP, install tcpdump on your FOG server and capture the packets while PXE booting the legacy BIOS host first and when it waits at the iPXE menu try booting the UEFI machine too and stop the packet dump just after that ran into the error.