Fujitsu T939 Tablet not PXE Booting
-
@Sebastian-Roth As mentioned earlier I am currently running my DNS/DHCP services on a Windows 2008 r2 server. I am upgrading this server during our Christmas break prior to Microsoft’s End Of Life for this OS. So, if I am reading the instructions correctly - they only pertain to Server 2012 r1 and newer. I know it talks about 2008, but regardless I don’t want to bang my head on my desk getting this to work on a DC that will be retired in 3 months.
I don’t want to make a lot of unnecessary changes if waiting for my new DHCP/DNS Domain Controllers are the better option. Currently this is only affecting one machine but always looking ahead as this will be a problem for anyone refreshing their computers who haven’t already modified their environment to support dual boot situations.
-
@michaeloberg said in Fujitsu T939 Tablet not PXE Booting:
As mentioned earlier I am currently running my DNS/DHCP services on a Windows 2008 r2 server.
Right, forgot about that. Then I’d suggest you first try setting option 67 to
ipxe.efijust to see if the Fujitsu T939 PXE boots fine in UEFI mode. If it does you might look into what I said about dnsmasq earlier! Please tell us which Linux OS and version you have.Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth said in Fujitsu T939 Tablet not PXE Booting:
Then I’d suggest you first try setting option 67 to ipxe.efi just to see if the Fujitsu T939 PXE boots fine in UEFI mode
This is also my recommendation. If it works then we can work on how to make your configuration work dynamically. The fix for the dynamic settings is about 10 minutes worth of work.
-
And just like that - the simple change of Option 67 to ipxe.efi, the Fujitsu T939 is imaging!
My version of Linux is Ubuntu 16.04.6.
I was unable to boot my old Fujitsu T938s with this change to the DHCP setting, when I switch it back to undionly.pxe then of course it works. So thank you thus far, now my question is what should I do next keeping in mind I will be upgrading my Domain Controllers in December.
Thanks again!!!
Mike
-
@michaeloberg said in Fujitsu T939 Tablet not PXE Booting:
I was unable to boot my old Fujitsu T938s with this change to the DHCP setting, when I switch it back to undionly.pxe then of course it works.
Sounds good!
My version of Linux is Ubuntu 16.04.6.
16.04 is quite old and doesn’t have the UEFI capable version of dnsmasq included - only has version 2.75 but you need at least 2.76. But there is an option for you. Thanks to George we have a great manual on compiling the right version of dnsmasq by hand: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq#Compiling_dnsmasq_2.76_if_you_need_uefi_support
-
@michaeloberg said in Fujitsu T939 Tablet not PXE Booting:
And just like that - the simple change of Option 67 to ipxe.efi, the Fujitsu T939 is imaging!
IF this is just a one off situation you can manually manage dhcp option 67 between ipxe.efi and undionly.kpxe until you can move to a 2012+ dhcp server. If you had to manage multiple uefi systems or a new dhcp server is over 6 months away then I would say go ahead and compile 2.76 and set it up on the fog server. There is no harm in dnsmasq running on the fog server to supply the pxe boot information only. If there was no fog server then there would be no pxe booting anyway so there is no penalty for setting it up. But since you have only one system and its now imaged, just manually manage dhcp option 67 for now.
-
@Sebastian-Roth Sorry to bother again, I am stepping though the instructions to Compile dnsmasq2.76 but am stalled out on step 6.
It instructs me to “Find this section”
/* #define HAVE_LUASCRIPT /
/ #define HAVE_DBUS /
/ #define HAVE_IDN /
/ #define HAVE_CONNTRACK /
/ #define HAVE_DNSSEC */When I was initially stepping through this I found it, but did a keyboard combo of sorts and now cannot find it. I got called away to the administration office and when I returned the Putty session expired. I logged back in, started again at step 5 by entering in sudo vi src/config.h and this is what I have:
Last login: Mon Sep 23 07:29:15 2019 from 10.2.0.39
mike@fog-server:~$ sudo vi src/config.h
[sudo] password for mike:~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
“src/config.h” [New DIRECTORY] 0,0-1 AllI will admit I am a Linux novice - hopefully I didn’t screw this up. I can do a full VM restore if necessary, just looking for advise from this point. I really wish I could negotiate a service contract with FOG whereas I would pay an annual maintenance fee for updates, troubleshooting, etc so I don’t have to bother you fine folks that help the ignorant
Thanks again in advance!
Michael
-
@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. -
@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
-
@michaeloberg Start at step 4 when you loose the connection on a SSH shell:
cd dnsmasq-2.76 sudo vi src/config.h ... -
@Sebastian-Roth OK did that, and get the following Error (I am assuming I choose Edit anyway, but want to be sure)
-
@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
Dand start editing it over or just press theRto recover the edits saved in this this file . -
@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_DNSSECI 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
-
@michaeloberg Switching to chat for now. Check the speech bubble in the top right of the forum.
-
-
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 ... ...Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@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.
-
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
-
@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.
-
@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.
