It’s a good precaution either way! Yes, I’m able to boot into the iPXE menu on the 10.0.0.1 network. We only have the one network so we’re good there.

Lets start out by doing a little investigation. If the git method was used then look in /root directory file a directory called fogproject if its there change into that directory cd /root/fogproject. Now we are NOT going to upgrade the FOG server just yet. So issue this command sudo git pull if you get a success you just updated the fog installation program to the latest version. For now lets stop there to see what you have and if you can update the installer files. If that /root/fogproject directory doesn’t exist or you get an error when the git command is executed. then the tar method was probably used.

@george1421 Thank you! That fixed our issue. Much appreciated.

@fatbunny I think I would take this approach. Recreate your master image using the smallest disk possible. Make sure the root lvm volume is the last one allocated on the disk. Capture with FOG it will still capture as RAW. Then using a post install script that detects either the image name or linux issue the LVM commands to extend the lvm volume to the size of the (new) disk and then extend the root lvm volume to the size of the lvm disk. Its a bit strange on how to handle it, but it should work. The basic idea is to create your source image as small as possible then expand it post deployment.

I found a solution. I am using WinNTsetup4 which I run from winPE and it works. I don’t know what else he does but it works so I won’t look. Thank you for helping me !

@george1421 I’m good now. Thanks

@T-thorel Ok you passed the dhcp issue and pxe boot issue. Now the issue is with the iPXE program that creates the FOG iPXE menu. Typically when we see this error it is because your building network switch is using Spanning Tree protocol but not one of the fast spanning tree protocols. A test for this can be to find a dumb/cheap/unmanaged switch and place it between the pxe booting computer and then building network switch. If the computer pxe boots correctly into the FOG iPXE menu then you will need to get with your networking/infrastructure group and have them enable one of the fast spanning tree protocols like portfast, RSTP, MSTP, fastSTP, or what ever your switch manufacturer calls it. This setting will need to be enabled on every user facing port where you need to pxe boot. The issue is that FOG boots too fast. It will give up trying before spanning tree starts forwarding data on the network interface (~27 seconds after the link light is turned on).

I know this is kind of old, but I had this same issue yesterday. I fixed it by running the installer and upgrading. I think it would have been fixed by simply re-running the installer if I didn’t have to upgrade. I was only one version behind. I’ve notice most issues with Fog can be fixed this way.

@Sebastian-Roth Makes sense to me. Solved for me

@george1421 So now it finaly Works ! I am so Thankfull I am now running some Deploys and Captures as a Test but so far it has the 5.6.18 Kernel and gets no Nic errors. Just as an fyi the -o in your Command should be a Captial -O otherwise it creats just a .txt file and runs in an Format error at pxe boot. But Again Thank you for the Support

@Malte-Will said in Setting up trusted SSL certificate: @Sebastian-Roth I solved the problem. In the end, the last thing i forgot was to change the ip of the fog server to the fqdn in the ipxe file. Could you please explain in more detail, which ipxe file do you mean? /opt/fog/.fogsettings first line? ipaddress=… We also needed to set the WEB HOST setting in the FOG Configuration to the FQDN. Done. My problem is that after my CA was changed and ipxe was rebuild; iPXE still trying to connect to the bare IP not to the FQDN.

@f-15s-mtd You will need to change every switch/port that has a device that you want to pxe boot on. This is an access layer issue not something related to the FOG server or switch to switch communication. The problem is in the “last mile” so to speak. ref: https://community.cisco.com/t5/other-network-architecture/enable-portfast-on-all-ports/td-p/324511 read down the post because there are switch global commands that you can use.

@Greg-Plamondon Well that bit of code is held over from the WinXP days and worked in Win7. It no longer works in Win10. I’ve left that in the code because it shows you how you can poke things into the windows registry from linux (which should not normally be possible). If you are working on drivers and importing them look at this tutorial. The short read is that you need to use the pnputil.exe command in your setupcomplete.cmd file to load the hardware specific drivers during winsetup. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed?_=1596483356960

@smoooo If you are going to use two network adapters (recommended) before you install fog, know the linux name of the nic that will be your imaging network interface. Make sure you have static IP address mapping done on the imaging network interface. When you install FOG it will ask you which interface do you want to use. Make sure you name it correctly. Also FOG gets angry if you change the IP address of the imaging network interface after FOG is installed. So have your network configuration complete before you install FOG.

Windows 10 captured from other host same model with fog and manual also windows 10 with bootable USB

I realize this post is a bit old, but I wanted to thank everyone for their suggestions and give our experience to back up what has been said in this topic already. We experienced an image that should have been about 120gb, but was showing in FOG as the full 500GB hard drive. After referencing this thread, it fixed the issue. The steps we took are below in order: Verified that the PC didn’t have a second drive or second large partition it was capturing Verified that bitlocker encryption was OFF using the command prompt command “manage-bde -off C:” Ran Disk Cleanup (to get rid of old unused files) Ran Tools > Check to scan for hard drive errors (may require reboot to fix) Ran Tools > Tools > Optimize and defagment Capture Image again Once we did those steps, the newly captured image only takes up the actual amount used on the hard drive.

set the IP adress of the fog serveur instead of the name “fogserver” at the install of the smartinstaller and enjoy

you need to use a WinPE image instead of Windows installer iso, I had the same issue while trying to use the installer iso. Make a WinPE image and redo the steps.

I may have read your post too quickly, so if after you confirm the settings according to the wiki page, you still have issues we can debug using a packet capture. If the fog server and the pxe booting computer is on the same subnet, please use this tutorial to capture the best quality pcap. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue The pcap will show us what the target computer is being told to do. If your pxe booting compute is on a different subnet then install wireshark on a witness computer (second computer not part of the pxe booting process). Use the wireshark capture filter of port 67 or port 68 to only capture the pxe boot. Post the pcap to a file share site (like google drive) and either post the link in the thread or IM me the link and I will take a look at what the client is being told.

Thank you! I clicked the update button but didnt wait long enough it seems. Sorry for bothering you with this trivial stuff, thanks for the help. Sébastien