@El-Fogito ok lets get our hands a little dirty to debug this issue.

Schedule another image capture on this troubled server. Pick a target computer that is available for you. Before you schedule another capture tick the debug checkbox then schedule the deployment.

On the target computer you will see several screens of text that you must clear with the enter key. Eventually you will be dropped to the FOS Linux command prompt. At the command prompt try to ping the troubled fog server.

now lets try to mount the images/dev share. On the target computer issue the following commands

mkdir /ntfs
mount  10.20.10.38:/images/dev /images 

If the mount is successful then issue a ls -la /images this should show the content of the /images/dev directory on the fog server.

umount /images

If everything is good then you can single step through the deployment by keying in fog at the fos linux command prompt.

@El-Fogito Hmmm everything looks good. I should have verified this question first but is 10.20.10.38 the IP address of the correct fog server?

Is the target computer on the same subnet as the fog server?

The print out of your troubled fog server told me that things are setup as they should be and you didn’t create an unknown configuration.

@alessandro19884 said in HP Z8 Fury G5 Workstation Desktop PXE boot:

Update:
I’ve also follow this instruction:

Just to verify did you follow the instructions to rebuild ipxe? I’m finding it suspicious that the autoexec.ipxe file wasn’t found. That is something that should be compiled into ipxe. (fwiw: pictures speak better than words because we can see that its failing in ipxe (at least this time) ). The FOG delivered ipxe files has its own script built in and doesn’t use autoexec.ipxe (akin to DOS’ autoexec.bat file from 30 years ago).

@bmick10 Just to be clear recompiling and installing the updated version of iPXE address your init.xz stop issue?

@alessandro19884 This issue is tricky in that it could be iPXE or FOS linux that is failing. I don’t think this has anything to do with your disk subsystem on the target computer. Its not to that point yet in the booting process.

Lets first rebuild iPXE to the latest version because it could be the hand off from iPXE to FOS linux. Use these instructions to recompile iPXE on your fog server. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

The second part is lets update the FOS Linux kernel to the latest. In the Web UI under FOG Configuration -> Kernel update. Update to the latest version of version 6 of linux kernel.

I would do one of the above at a time so we can identify what was actually at fault.

@El-Fogito will you post the output of the following commands executed on the fog server. You may need to execute the sudo su - command to allow you to run all of these commands.

df -h

ls -la /images

showmount -e 127.0.0.1

cat /etc/exports

Where it is failing is the fos linux engine (OS running on the target computer), it connects to the FOG server using NFS as ‘root’. For some reason this connection is being blocked. Lets see the configuration so we can know what to test next.

@bmick10 a quick google-fu search of the error shows your ubuntu install is missing a needed library to completely compile the updated version if iPXE.

sudo apt-get install -y liblzma-dev

@bmick10 said in Fog stops at init.xz...18% and other percentages:

So it will load to Fog stops at init.xz…and different % each time.

This sounds like an iPXE issue, where its not loading FOS Linux’s virtual hard drive completely for some reason. Lets start out by having you rebuild/compile the latest version if iPXE using these instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Lets see if there is an update to iPXE that solves this issue.

@maximefog said in Deploy Image:

it is mandatory to register the workstation

This is not a requirement under certain conditions. There is a method I call “load and go”. It is a process that system builders use where once they load the OS on the target computer they never see the computer again. In this method you can not use the FOG Client for any of its function. The install process must be self contained or use a FOG post install script to make the install time adjustments to the target computer. Using this method you do not need to register the computer with FOG. Once the image is deployed to the target computer FOG forgets it ever saw this target computer. Once you have the master image setup as needed you deploy the image from the FOG iPXE menu “Deploy Image” menu. You never have to touch the FOG web ui for image deployment.

@jenesis I’m going to say that since this is a hardware security device its not possible to pxe boot it. I can see the device manufacturer using the hardware security key as part of its integrity control to ensure its OS hasn’t been tampered with.

But I would not rely on my guess alone. I would contact the company’s support team and ask if the software can be pxe booted. If yes, then we can probably get it to boot via iPXE. You also want to ensure you are not in violation of the manufacturers EULA by pxe booting something you shouldn’t.

@jenesis The quick answer is maybe you can, but also maybe no.

There are some iso images you can convert to ipxe boot. Lets first start by getting the name of the software you want to pxe boot. What is the name of the software?

@pilipp_edv said in general questions about storage / master storage nodes:

After that, I configured the windows DHCP servers in the other locations to point to the main FOG server.

FWIW: You can (should) point the remote dhcp server to the remote storage node so the clients doesn’t need to transfer the ipxe boot image across your wan. The storage node will instruct the clients to “check in” with the fog master node.

The part you are missing is the FOG server plugin “Location”. With the location plugin you first identify your different locations. Then assign storage nodes to the “location” then assign existing client computers to the location. As you full register new clients there will be an added prompt for location during registration. This plugin pulls all of the bits together to make the clients find the proper storage node.

@Bhav duplicate thread here: https://forums.fogproject.org/topic/17521/not-booting-to-pxe-uefi

@Bhav Just for clarity, do you have an isolated imaging network or are you trying to image on your business network?

If you have an isolated imaging network then you should have configured FOG to setup a dhcp server. The configuration will work for both bios and uefi computers.

If you plan to image on an existing business network, then your primary dhcp server needs to be configured to support pxe booting.

So lets start with how do you plan on imaging?
Second if you are planning on imaging using your business network, what device is your current dhcp server?

@rdfeij For the record, what computer hardware do you have?

@luilly23 To follow on with what luilly23 said. If you have the original 7010 from 10 years ago, that was the first version of Dell desktops that supported UEFI mode. BUT if you tried to pxe boot in uefi mode iPXE would hang at initalizing devices because of a bug in the Dell 7010 uefi firmware that was never fixed by dell. In this case you must use bios mode and undionly.kpxe to boot.

If you have the modern version of the Dell 7010 and it says no boot device found… The actual problem depends on where you see the error. I’m going to guess this error is when you first turn on the computer and tries to pxe boot. In this case your dhcp server is not sending an IP address or pxe boot info to the client computer. If this is truely the “new” 7010 then your boot file will be ipxe.efi or snponly.efi. If you put a functioning windows computer on the same subnet as your dhcp server, does it get an IP address? That will tell us if your dhcp server is working. Also with that windows computer verify what device is your dhcp server.

@MonsterKaos There are 3 issues (well really 4 issues) that is probably impacting your deployment.

1. You have really new hardware, but you are running an old version of FOG.
2. Your version of iPXE (the boot loader that provides the FOG Menu is old (this is probably causing the no connection methods.
3. Your version of the FOS Linux kernel (you haven’t got this far yet) is probably too old.
4. You are missing some of the enhancements to the FOS Linux OS that interface with NVMe drives. Just be aware if you have issues deploying to nvme drives you should probably upgrade to FOG version 1.5.10 and then upgrade to the branch version of 1.5.10. This is not a mandatory upgrade unless you have issues deploying your image.

For issues 2, I have instructions on how to compile the latest version of iPXE here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Your fog server will need to have internet access to get the latest source code for iPXE. This should address the no configuration methods.

For issue 3, in the fog ui go to fog configuration-> kernel update. Download the latest kernel 6.x series to get support for the newest hardware.

Lets see where that works for you with deploying images.

@EuroEnglish I’m finding it hard to believe that there is a connection of having win11 on the computer that is causing this behavior. When the fog menus are being displayed, we are running iPXE boot loader. This in a way is an OS by itself. The OS on the target computer is not even known about at this point in the booting process.

The only thing I can think is that the format or disk structure is now allowing iPXE to fully initialize correctly.

Could you make this test for us? If you have 2 computers of the same model (make sure that bit locker is disabled on both systems) and secure boot is disabled.). One with win11 and one with win10. Verify they both behave the same way as you mentioned above.
On the win11 computer remove the hard drive/nvme drive. Boot into the FOG iPXE menu. Does it still have the slow speed?
Move the hard drive from the win10 computer to the win11 computer. Does the system act slow or normal?

@professorb24 said in How to use fog with two different VLANs:

Yes, I can ping the 192.168.54.X network.

This is positive. OK hopefully last question, what is device the dhcp server on the 54.x subnet? Is it the fog server on the 52.x subnet or something else?

@professorb24 from 192.168.52.X can you ping devices on 192.168.54.X. If yes then you have network routing setup.

Once you pass full routing, what is your dhcp server for 192.168.52.X and 192.168.54.X?