@Kureebow I’ve had this happen to me before. These are the two cases that I’ve seen:

1 - I captured an image in UEFI and the computer that I was deploying it to was in Legacy mode. I also had the inverse of this, where I captured in Legacy and was trying to deploy to UEFI.
2 (the most common for me) - Some sort of RAID or volume management device is enabled in the UEFI. I only use HP so I don’t know what it would be called on Dell, but on HP there is an option that I have to disable “Configure Storage Controller for VMD”.

@CoNickt @avh2025
Not all usb ethernet adapters are created equal. I would usually say to just bite the bullet and get the vendor specific adapter but it looks like you already did that. I have usb and usb-c adapters that work fine but different uefi firmwares behave differently. i.e. Microsoft surface just has to have its surface branded adapter for native boot to work. HP will work sometimes with the dell or lenovo pxe capable usb-c adapters. We also recently got 2 different hp laptop models where one had to use snponly.efi and the other was fine with ipxe.efi. I maintain a table of models and which adapters work with what we have. Lots of things do just work once you have a collection of usb adapters. Unfortunately, it’s an issue of hardware vendors adding proprietary limitations, but luckily between fog and ipxe you can typically get it working pretty smooth.

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.

@bond007fink @jayrehme
I do a monthly update to my image (single disk resizable) with the latest updated added to the iso I use to install. So I’m using the November iso with the December updates embedded for win 11 24H2 x64 and I had no issues with resizing.

So it may be a config issue on your end or it could be a more specific use case due to a windows upstream change.
Can you give a little more information on the hardware you’re capturing from and what your settings are on the image definition in fog?
I can try to recreate to some extent.

Quick Update (19/12/2025):

Hi Everyone,

I’ll probably open another topic for this in the coming weeks, as it probably deserves it’s own thread for bug reports and feature requests etc (mostly need to convince myself to write it, but also wanted to double check which category such a thread should go under, is tutorials fine?), but I’ve created an ansible role to help with the installation and configuration of fog.

Notably it will help with creating a secureboot valid setup with shim like above. It should implement most of the important functions of the fog installer, and can also automatically perform a lot of the steps in the guide above for you.

I figured I’d drop it here on the forum somewhere in case it’s helpful for others. More detailed usage information will be added to the readme or the new topic. Naturally I’ll link to a new topic here once I get around to making it.

The role is currently hosted on my forgejo instance here: https://forgejo.cwavs.xyz/Cwavs/ansible-role-fog

@Bristow-0 You can clone the repo, and run the installer from the branch you want to work from. When you install FOG (either downloading the files or running it through git), it will create a settings file that will be read during subsequent install attempts to fill out the default answers.

My Fog version : 1.5.10.1734 over Ubuntu 22.
It just looks like double-quotes escaping problem…

Hi Again guys

I have some news about this problem.
I found a work around.

I change the file d1.fixed_size_partitions deleting the recovery Windows partition. This change generated and error when I made the deploy image in Client PC.
But if I cancel the job in the CLI fog server and reset the client machine after fog show the error
It boot ok.

I’ll continue reading …
Thanks

@mmoore5553 Understood and appreciate the return with new information.

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

@romprager The simple answer is depends on the iso image and what OS will boot from the ISO image.

I do have several how tos in the forum that shows how to net boot several different installers.

https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@rodluz I know you were talking to the other person, but if you like you can send me the kernels for testing.

@Tom-Elliott Hi Tom,

Thank you, that clarifies a lot. I now understand that hostSecTime represents the expiration time, not the creation time, which fully explains the consistent +30 minute offset I was seeing. That part now makes sense and resolves my question.

The only remaining actual issue I’m trying to understand is the snapin behavior: in several cases, snapins did not execute on some hosts. I don’t see any errors in the logs. Only that the snap-in task doesn’t start, but I will work on this and gather some more data. Thank you!

@Tom-Elliott Yep, I caught that workaround in the earlier post. I moved the image folder from /images/dev to /images, but still resulted in the same error.

One thing I noticed this morning, is that the image capture process is hanging at 99% on the task page, as in for at least 45 minutes. Not sure if that is a symptom or the cause.

The previous post was suspect of a very recent init version – but i’m on the most recent dev-branch.

Thank you!

Thank you george1421 that 's was the solution.
I was troubleshooting remotely, and the technician on site insisted that images had already been downloaded onto it.

I understand your point of view, but I also have to remain anonymous to my colleagues.

Solved !

@george1421 noted. When I was initially testing, I did not know this and it took some digging in the forums to find this tidbit of knowledge. Given that having separate storage groups stops replication between the nodes in my mind it makes most sense to have a more distributed setup of normal servers at each site to handle all of my requirements. Thanks for the input!

@Sebastian-Roth Can I bother you with this quick question ^^^