@joyboy11111 OK well you just got the big prize of debugging this issue then.

As Sebastian said, schedule a debug deploy/capture (doesn’t matter which). Schedule a new task, but tick the debug check box before you hit the schedule task button.

PXE boot the computer, after several screens of text (plus the error about network adapter) you will be dropped to a linux command prompt.

At the FOS Linux command prompt key in lspci -nn | grep -i net I’m going to suspect that it will not return anything. Then issue a command to scan the USB lsusb and post the results here. If that doesn’t results in a value, then we go back to windows.

In windows I need to know what the hardware ID of that USB device is. I need the vend and device ID, you can get this in the control panel (this route may be quicker than the schedule task path from above)

@joyboy11111 Yes there is, in that directory from your previous picture, key in file bzImage it will print out the version.

@cyannella Ok since it was once working we can get it going. It was so close.

1. Reboot the fog server just to be sure.
2. When the fog server comes back up access the linux console and key in ip a s and post the results here.
3. Now confirm what you have configured for dhcp options 66 and 67 (if you did not enable dhcp server profiles). Post screen shot of the dhcp server settings here, redact what you need but if you have internal (non-public) addresses leave them since no one can use that data against you.

If the above doesn’t line out, we’ll have you load wireshark on a witness computer (3rd computer connected to the same subnet as the target computer to listen to the dhcp process). If the fog server and target computer are on the same subnet then we can use the FOG server to collect this info.

@joyboy11111 Strange because when I go in I can see the updated kernels.

NOTICE: I just noticed I put the box around the ARM processor version and not the intel x64 processor. Understand the graphic is wrong, but the intent was to show you the items existed in my FOG server menu.

There is a manual process to download the updated kernels. You can get them from here: https://fogproject.org/kernels/

Save the 64 bit version as bzImage
Save the 32 bit version as bzImage32

Remember case iS important

The files go into /var/www/html/fog/service/ipxe directory on the fog server. Rename the existing files then copy these new ones in place.

@joyboy11111 Switch over to the FOS Linux kernel of 5.6.18 and that will/should address any driver issue with newly minted hardware. You can do that in the web ui under FOG Configuration -> Kernel. Update both the 32 bit and 64 bit kernels. If that still is not working go into debug mode again on the target computer and enter uname -r if it doesn’t report 5.6.18 then something happened with the kernel update process.

@cyannella I thought we had a tutorial on this but I can’t seem to find it at the moment so let me give you a quick what to change to fix it.

Edit the following files.
/opt/fog/.fogsettings
/tftpboot/default.ipxe

Replace the incorrect IP address with the right address for the fog server.

Then in the webui FOG Configuration->FOG Settings then hit the Expand All button. Search that page for the old address and replace with the correct address.

Look at Storage-> Default storage node and fix the IP address in there.

Lastly back in the FOG Server linux console, rerun the fog installer. That will pick up the address you saved in the .fogsettings file and fix up the reset of the install for you.

@cyannella said in Tablet Can't PXE Boot Win 10 Tablet:

tftp://10.71.24.139/default.ipxe… ok
http://10.0.2.15/fog/services/ipxe/boot.php… connecting
then hangs. The web server is on .139
I need both the tftp and http to be found on the same VM.
Where is it picking up the incorrect IP for .15?

OK now we are getting somewhere. Did you change the IP address of the fog server after FOG was installed? Or do you have a second nic card in this server?

@fry_p The error message is related to a USB3 controller/device. I have seen this error before, but I think the resolution was a firmware or linux kernel update. I have a newer one off kernel if you want to see if that clears this error. Understand the right path is firmware fist then FOG kernel second.

@fry_p Is the firmware up to date on those lenovos?

@cyannella said in Tablet Can't PXE Boot Win 10 Tablet:

There are no other WDS servers on site that I know of.

If after you correct your dhcp setting and you are still getting that strange boot file name, I will give you instructions on how to use wireshark to find a quick answer to the above question. But lets not go there unless needed.

@cyannella said in Tablet Can't PXE Boot Win 10 Tablet:

I setup the fog server on 66
and the boot file undionly.kpxe on 67

Ok this is the first issue if the target tablet is a uefi system, this file name needs to be ipxe.efi.

Since you have a windows 2012 or later dhcp server then you can/should follow this guide on setting up policies in the dhcp server to automatically supply the correct boot file name based on the target computer. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@cyannella What device is your dhcp server?

Also did you have another netboot device (server) setup in your environment like a WDS server or such?

@cyannella said in Tablet Can't PXE Boot Win 10 Tablet:

I’m receiving a Bootx64.efi is missing when I pxe boot from the tablet.

Is this a new FOG install? The reason why I ask is that bootx64.efi is not the right boot file name. I find its interesting that its also calling for bootx64.efi because that is an efi boot file name.

What exactly do you have configured for dhcp options 66 and 67?

@vemoya said in FOG Dashboard not updating:

I would like to delete the image from the server but what is the path to the image folder?

These RAW data files are kept in the /images directory on your fog server. In that directory you will find subdirectories that match your image names. You can remove this directory and its files with the rm command.

I will give you a very useful but very dangerous command because you can break your FOG server if you misuse it. The command is sudo rm -rf /images/<directory_name> Just replace <directory_name> with your image name and it will be gone, no questions asked.

@nil If you are interested in helping start out by writing a tutorial in the tutorial forum. Then once others have a chance to prove it out it will be converted to a wiki page.

Thank you for helping the FOG Project move forward by adding new options for installing FOG.

@nil Do you have a complete working solution now?

If so I think it would be very valuable if you could write a tutorial on the setup from beginning to running, since you have advanced knowledge of how the LXC containers work together.

@sebastian-roth Sorry I missed the part about LXC container. While this is now a bit off topic, I built another FOG VM last night and I happened to notice that on the network adapter tab there was a checkbox for “firewall” that was enabled by default. Because of the color scheme proxmox uses it looks like the option is disabled (gray) even though the box is checked. I don’t know what this option does at the moment, but it sounds like proxmox itself can restrict network access to a VM. I need to look a bit deeper into this option.

If the showmount command is not providing results then NFS is not working right on the computer. You can run showmount command against a remote computer too, just replace the loopback address with the address of the remote computer running NFS.

@george1421 The code works as expected now. I used your shortened fog.updateregbarcode that just echos the variable into the text file on the C; drive.

@devrick I found the first problem in that I gave you some bad intel. I need to update that old post about hinfo. For security the developers changed how that file can be called to prevent data leakage. As soon as I saw the output file from the wget command I knew what was wrong.

The way the FOS Linux calls it is in this line:
https://github.com/FOGProject/fos/blob/8d310f51d7d945c5dc1685eb6698d1aed8634dc7/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L8

With real values:
curl -Lks -o /tmp/hinfo.txt --data “sysuuid=bob&mac=d6:29:3b:0e:fc:16” “http://192.168.112.116/fog/service/hostinfo.php” -A ‘’

With the variables
curl -Lks -o /tmp/hinfo.txt --data “sysuuid=${sysuuid}&mac=${mac}” “${web}/service/hostinfo.php” -A ‘’

It did return what was expected into hinfo.txt.

I had to spin up a new FOG server because the centos and ubuntu servers were reconfgured for nfsv4, So now I need to build a new windows VM and capture that image onto the new FOG server to test how well the deploy script runs. I’m confident we will be able to access the other tags too.

# cat hinfo.txt 
[[ -z $mac ]] && export mac='d6:29:3b:0e:fc:16'
[[ -z $ftp ]] && export ftp='192.168.112.116'
[[ -z $osid ]] && export osid='9'
[[ -z $storage ]] && export storage='192.168.112.116:/images/'
[[ -z $storageip ]] && export storageip='192.168.112.116'
[[ -z $img ]] && export img='Baseimage1'
[[ -z $imgFormat ]] && export imgFormat='5'
[[ -z $imgType ]] && export imgType='n'
[[ -z $imgPartitionType ]] && export imgPartitionType='all'
[[ -z $imgid ]] && export imgid='1'
[[ -z $PIGZ_COMP ]] && export PIGZ_COMP='-6'
[[ -z $shutdown ]] && export shutdown='0'
[[ -z $hostearly ]] && export hostearly='1'
[[ -z $pct ]] && export pct='5'
[[ -z $ignorepg ]] && export ignorepg='1'
[[ -z $winuser ]] && export winuser=''
[[ -z $port ]] && export port=''
[[ -z $fdrive ]] && export fdrive=''
[[ -z $hostname ]] && export hostname='uefibooter'
[[ -z $hostdesc ]] && export hostdesc='Created by FOG Reg on January 9, 2021, 12:46 am'
[[ -z $hostip ]] && export hostip=''
[[ -z $hostimageid ]] && export hostimageid='1'
[[ -z $hostbuilding ]] && export hostbuilding='0'
[[ -z $hostusead ]] && export hostusead=''
[[ -z $hostaddomain ]] && export hostaddomain=''
[[ -z $hostaduser ]] && export hostaduser=''
[[ -z $hostadpass ]] && export hostadpass=''
[[ -z $hostadou ]] && export hostadou=''
[[ -z $hostproductkey ]] && export hostproductkey=''
[[ -z $imagename ]] && export imagename='Baseimage1'
[[ -z $imagedesc ]] && export imagedesc=''
[[ -z $imageosid ]] && export imageosid='9'
[[ -z $imagepath ]] && export imagepath='Baseimage1'
[[ -z $primaryuser ]] && export primaryuser='JonDoe'
[[ -z $othertag ]] && export othertag='MyTag1'
[[ -z $othertag1 ]] && export othertag1='MyTag2'
[[ -z $sysman ]] && export sysman='QEMU'
[[ -z $sysproduct ]] && export sysproduct='Standard PC (i440FX + PIIX, 1996)'
[[ -z $sysserial ]] && export sysserial='Not Specified'
[[ -z $mbman ]] && export mbman=''
[[ -z $mbserial ]] && export mbserial=''
[[ -z $mbasset ]] && export mbasset=''
[[ -z $mbproductname ]] && export mbproductname=''
[[ -z $caseman ]] && export caseman='QEMU'
[[ -z $caseserial ]] && export caseserial='Not Specified'
[[ -z $caseasset ]] && export caseasset='Not Specified'
[[ -z $type ]] && export type='down'

@devrick Ok let me power up my dev environment again. I did some bad things to my Centos server working on nfsv4 so I could not image with it. Let me start up the ubuntu server and see if I left that in a sane state to debug your code. I know the code should work correctly.