Posts made by george1421

@tom OK this isn’t getting us to the answer. Not your fault, I think “fog” is helping us by hiding the answer.

Can you go to the FOG webgui and look at the FOG Configuration->FOG Settings. Then in FOG Settings look at these values:
FOG_TFTP_PXE_KERNEL (suspect is wrong) should be bzImage
FOG_TFTP_PXE_KERNEL_32 (probably right)

@george1421 Just for clarity this is what we see in the pcap

Note that packet 56 asking for bzImage412 and then in packet 58 the FOG server says 302 not found.

@tom Well that wasn’t what I expected (it looks good).

Lets try one more URL call: http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=<mac_address_of_target_computer>

@george1421 So far we found in the pcap that the client is trying to download bzImage412 and the fog server is replying with file not found.

@tom Look at your IM (chat bubble) on the FOG tool part. I have a few questions

@tom Looking at it now

@kandresen Which part was it? Just for those that might find the thread in the future.

@michaeloberg Here please follow this process.

sudo -i
apt-get update
apt-get install git
git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
git checkout master
cd /opt/fogproject/bin
./installfog.sh

@kandresen Your post you are missing the pxe service settings.

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

IF that doesn’t work then we may have to override your real dhcp server which is potentially sending out a boot file. We may have to do this.

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

If the above solution doesn’t work for you then we will need to capture the communication going on between the client computer, dhcp server and the fog server. We’ll go down that path if the above sections don’t work.

@kandresen Secure boot is a Microsoft thing. Short answer is secure boot is not available for FOG or most non-MS softwares.

If you are using Dells you can re-enable secure boot & TPM using CCTK in the setupcomplete.cmd file at the end of Windows Setup.

@tom Ok then we can rule out something happened to the FOS image during or after the upgrade since the keys match.

@george1421 Wait, I remember another situation just like this, where the OP was sending pxelinux.0 or any of the undionly.0 files as dhcp option 67 {boot-file} and it would run just fine but blow up while it was downloading the init.xz. This sure seems to fit that situation.

@tom These next steps are shotgunning in several directions.

1. Do you have any other models we can try. Like an older latitude or even a desktop. I’m interested to see if we can get FOS to boot at all.

2. Lets assume that FOS is corrupted. From the fog server linux console, navigate to /var/www/html/fog/service/ipxe and then lets run the md5sum command and compare your images to mine.
   1 md5sum bzImage dfba0a3d8b0e8652857c69c45393465a
   2 md5sum bzImage32 87d61b318f111434f880e0d4b500e539
   3 md5sum init.xz edbd5936f81144d1afb888f4b8712de5

3. If we put the pxe booting computer on the same subnet as the FOG server, we can use the fog server to listen in on the pxe booting process of the target computer. (I’m not sure this one is going to tell us much, but again your pxe booting process is not typical either). Follow the instructions here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue upload the pcap to a google drive or dropbox and I’ll take a look at it. Either post the link here or send me an IM and I will review it off-line. Use the provided instructions except use this tcpdump string. tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 or port 80 because I want to see what is going on with the init.xz download, which uses http.

@kandresen OK then if you are using 2.76+ then please use my configuration file. It will automatically switch between the flavors of firmware. That config confirm works. We may have to tweak it if you have an abnormal network (where your dhcp server is telling one bit of information and we need to override it with dnsmasq).

@tom ok just to rule out a routing/router issue can you try and move the pxe booting client to the same subnet as the FOG server? I know I’m grasping at straws here, but it should but working… We have to find out where the issue isn’t at this point.

@tom OK watching your video frame by frame (well almost). I see your fog server is on 192.168.2.196 but your pxe client computer and dhcp server are on 10.141.32.x/24 Is this expected?

Unfortunately the video doesn’t show me where its getting bzImage from (just off the top of the screen)

There is a bug in FOG 1.4.4 that needs to be patched with a hot fix. The hot fix has been applied to the dev branch of 1.5.0, but its not in 1.4.4.

Here is the process to manually apply the patch:

1.Open a linux command prompt on your FOG server.
2. Key in the following command:
sudo wget -O /var/www/fog/lib/fog/plugin.class.php https://raw.githubusercontent.com/FOGProject/fogproject/6717f382177e714c1bd22eb11627133cfd4e0ebe/packages/web/lib/fog/plugin.class.php
3. Remove the plugin
4. Reinstall the plugin
5. Add in your plugin settings and save

Your ltsp.conf file looks ok.

Just for the sake of argument, could you try my ltsp.conf from this post: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6

Just replace the <fog_server_IP> with the IP address of your fog server and then restart dnsmasq.

[EDIT:] But before you try it, can you tell me what version of dnsmasq you have installed. The older ones than 2.76 need a few fixes plus they don't support uefi and bios images auto select at all

# 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

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>

# 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:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>

# 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 and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

dhcp-range=<fog_server_ip>,proxy

@Wayne-Workman any ideas since you have been working with the API more than most?

@tom Can we make the statement that all latitudes have the issue, or all computers have the issue?

While this is just a wild (strange) idea, do you have an unmanaged switch you can place between the pxe booting computer and the building network switch? This really doesn’t sound like a spanning tree issue, but it just might. Those 7240s are pretty quick.