So I ended up building a new FOG server and this time everything worked as it should. Not sure what was causing the old server to act that way, but even after manually downloading and saving the new files, it still showed the old version.
@sebastian-roth After calling Dell support, it seems there was something wrong with the laptop that was being used to test. I re-configured the UEFI to defaults, purged the default config of RAID to AHCI, and have rebuilt my images using the smaller drives on the newer laptops.
I am now able to capture and deploy as expected. Thanks to everyone for your assistance with this! We can consider this thread resolved.
@jj-fullmer As long as you have that bzImage5618RT3 kernel queued up could you test what we are talking about in this thread: https://forums.fogproject.org/post/140103 I may have inadvertently fixed the requreiment to switch the computers from Raid-on mode to ahci to image with FOG. I know this might be a Dell specific setting, but its related to the Intel RST disk controller in raid mode. I think the lenovo systems should also have a similar setting because its an INTEL thing not a computer manufacturer thing.
Edit: Ignore this request, the 5510 I have has a sata disk in it. I just tested the kernel with a 7280 with an NVMe disk and the linux kernel does not work with this disk structure. So we are still no where in regards to a solution to this.
@quinniedid Ok, looks like this is not due to the picture you used but a general issue with displaying the image on the HP ProBook 445 G2. So far I have not found any hint on other people reporting this issue to iPXE and I would suspect this to be kind of an endeavor to figure out even with the help of iPXE developers. Though you can still report it on github or the forums.
The easier way is just using the workaround that George came up with. Not fancy but way less effort than figuring this one out I suppose.
@cmurray139 I’m going to close one eye and squint with the other to read between the lines here…
I read this as: I have a fog server on a dedicated imaging network. This server has no connection to the outside world. I just purchase new hardware that I can’t image because the FOS Linux kernel is too old. How can I manually install the later version of the FOS Linux kernel that supports my new computers?
If I guessed right then you need to get the kernels from here: https://fogproject.org/kernels/ Download Kernel.TomElliott.184.108.40.206 and save it as bzImage32 (watch your case) and Kernel.TomElliott.220.127.116.11 save it as bzImage. Now move these to the FOG server into /var/www/html/fog/service/ipxe directory replacing the files in that directory. You might want to rename the existing files just in case you need to back track to the older kernels. Now just pxe boot the target computers and see if the updated kernels do what you need.
Now I also have to say since you specifically called out storage devices on these target computer, go into the bios (firmware setup) and make sure that the disk controller mode is ahci and not raid or raid-on. This will cause all version of the FOS Linux kernel to not be able to detect the storage device behind the disk controller.
@george1421 Thanks, After downloading the more recent kernel since it worked, I proceeded this way because I encounter problems directly via the server interface.
We can now use fog on our newer machines.
more I think udp-receiver is actually dying at this stage and not delivering the rest of the data.
What if we are running out of memory on FOS Linux partition. Where we bumped it up from 127MB to 275MB for the larger inits? This 3rd partition isn’t that large though. My C drive partition is 25GB, but I rarely multicast while imaging. I do remember we had to make the FOS Linux drive for one user before we upped it to 275MB but I can’t remember the circumstance.
Something else we need to be mindful of / is this is an untested image from the perspective of multicasting. This is the first uefi image to the first uefi target computer the OP has. The previous ones have all been bios based.
If I remember correctly when the multicast task starts, it actually spins up one udpsend task for each partition. I wonder if that task is terminating on the server not the target computer. But again why only for uefi systems…
@fog_client Hello, its good to know these devices have that raid mode switch. Good job finding it in the bios. If you only have one drive in these computers you can leave it in ahci mode and be happy. Windows will not see any performance loss in this mode.
@kkthnxbb Thanks for posting the video. Looks like the crash happens exactly at the point where iPXE hands over to the Linux kernel. I stepped through the video and saw it showing ok for both bzImage and init.xz. While it could be a problem with the Linux kernel as well I would expect the issue to be in iPXE.
Do I get this right, migrating the VM from ESXi 6.5.0 to ESXi 6.7.0 fixes the issue for you?
Let’s try to go back to an earlier iPXE version. Which version of FOG did you use before 1.5.9? You can download older iPXE binaries on github using this URL: https://github.com/FOGProject/fogproject/tree/1.5.8/packages/tftp (just put in whichever version you had before, 1.5.8 or 1.5.7 or …). You don’t need to download all the binaries. Just grab ipxe.efi and put that into /tftpboot/ directory on your FOG server. Then boot up the VM again.
You might want to pay attention to the iPXE version string printed when it starts just to make sure the switch of the binary actually worked.
@Chris-Whiteley The default for a current install of FOG is still 4.19.x series because that is the last / latest LTS version of the linux kernel. When the kernel developers release the next LTS version of the linux kernel (supposedly to be 5.10.x) then the FOG Developers will make that standard.