@Tom-Elliott Thank you, Tom. The init version is now 2025xxx. I’ll test soon to confirm the SSD info is showing in logs.

Hiya @george1421. First, thanks for your time thus far and thank you for the background/context. I truly was not aware the way we are using FOG was an edge case so I appreciate the extra help.

I can confirm I’ve put the bzImage you provided in place but continue to hit the same screen. Taking a step back, here is some additional context from my end:

This is a new deployment and new environment. I am using dnsmasq for DNS and DHCP on a server, “soko01” at 10.20.192.11 The rest of the servers of this type are still pointed at a MaaS instance so I have some chain loading going on in dnsmasq to target one server, “trial194” that I am attempting to capture a FOG image from. The rest are still pointed at MaaS. MaaS lives on soko02 at 10.20.192.12 FOG lives on soko03 at 10.20.192.13

Here is my dnsmasq conf

########################## ### maas configuration ### ########################## dhcp-match=set:pxearch0,option:client-arch,00:00 dhcp-match=set:pxearch7,option:client-arch,00:07 dhcp-match=set:pxearch10,option:client-arch,00:10 dhcp-match=set:pxearch9,option:client-arch,00:09 dhcp-match=set:pxearch8,option:client-arch,00:08 dhcp-match=set:pxearch13,option:client-arch,00:13 dhcp-match=set:pxearch0c,option:client-arch,00:0c dhcp-match=set:pxearch0e,option:client-arch,00:0e dhcp-match=set:pxearch1f,option:client-arch,00:1f dhcp-match=set:pxearch20,option:client-arch,00:20 dhcp-match=set:pxearch11,option:client-arch,00:0b dhcp-boot=tag:maas,tag:pxearch0,lpxelinux.0,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch7,bootx64.efi,0.0.0.0,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch10,http://10.20.192.12:5248/images/bootx86.efi,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch9,bootx64.efi,0.0.0.0,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch8,bootaa64.efi,0.0.0.0,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch13,http://10.20.192.12:5248/images/bootaa64.efi,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch0c,bootppc64.bin,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch0e,pxelinux.0,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch1f,boots390x.bin,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch20,s390x_partition/maas,soko02,10.20.192.12 dhcp-boot=tag:maas,tag:pxearch11,http://10.20.192.12:5248/images/grubaa64.efi,soko02,10.20.192.12 ######################### ### fog configuration ### ######################### # FOG PXE (soko03 / 10.20.192.13) # Detect iPXE dhcp-userclass=set:ipxe,iPXE dhcp-vendorclass=set:ipxe,iPXE dhcp-match=set:ipxe,175 # FOG stage 1 (only if NOT already iPXE) dhcp-boot=tag:fog,tag:!ipxe,tag:pxearch0,undionly.kpxe,soko03,10.20.192.13 dhcp-boot=tag:fog,tag:!ipxe,tag:pxearch0e,undionly.kpxe,soko03,10.20.192.13 dhcp-boot=tag:fog,tag:!ipxe,tag:pxearch7,snponly.efi,10.20.192.13,10.20.192.13 dhcp-boot=tag:fog,tag:!ipxe,tag:pxearch9,snponly.efi,10.20.192.13,10.20.192.13 # iPXE stage: set BOTH bootfile AND next-server dhcp-boot=tag:fog,tag:ipxe,http://10.20.192.13/fog/service/ipxe/boot.php,soko03,10.20.192.13 # A MaaS-provisioned host dhcp-host=set:maas,set:front,90:5a:08:77:62:02,10.20.193.193,trial193.front.sepia.ceph.com # A FOG-provisioned host dhcp-host=set:fog,set:front,90:5a:08:77:63:36,10.20.193.194,trial194.front.sepia.ceph.com

The autoexec.ipxe file I am serving

root@soko03:/var/www/html/fog/service/ipxe# cat /tftpboot/autoexec.ipxe #!ipxe dhcp chain http://10.20.192.13/fog/service/ipxe/boot.php || shell

Here is the screen I am getting right before the DDP package error
iKVM_capture3.jpg

Which signals to me that it’s getting the bzImage file okay. If I load http://10.20.192.13/fog/service/ipxe/boot.php, it looks normal.

What should I check next?

@gchartrandCRL I’m glad that worked! You should be able to keep using snp.efi with your previous machines.

@Infojoe They are one in the same lol and you’re welcome.

@george1421 I have installed fog with DHCP server but DNS doesn’t work at all (no dns server appear on windows client) so I’m stuck.
It’s my first time installing DHCP and DNS on Debian so I think I made mistakes.
DHCP work fine.

edit : It’s fixed. I forgot to add “option domain-name” and “option domain-name-servers” in dhcpd.conf

For the script, I think it must be simple to set FOG as DHCP server at startup if after 10 min no IP is given from a DHCP server then set server to static IP and start DHCP and DNS services.
And then reverse this at shutdown.
Maybe this can be done manually first.

edit : Here is the first script.
I have create files ending with .dhcp for conf for external DHCP/DNS and file ending with .static for conf for local DHCP/DNS.
It looks to work fine.

# Configuration actuelle echo "Etat DNS local :" systemctl is-active bind9 echo "Etat DHCP local :" systemctl is-active isc-dhcp-server echo "" loc(){ # Configuration DHCP local echo "DHCP local" # Configuration if [ -e /etc/network/interfaces.static ] then echo "Copie interfaces" cp /etc/network/interfaces.static /etc/network/interfaces else echo "interfaces.static not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.static ] then echo "Copie resolv.conf" cp /etc/resolv.conf.static /etc/resolv.conf else echo "resolv.conf.static not found" exit 1 fi # Services systemctl start bind9 systemctl start isc-dhcp-server } ext(){ # Configuration DHCP externe echo "DHCP externe" # Configuration if [ -e /etc/network/interfaces.dhcp ] then echo "Copie interfaces" cp /etc/network/interfaces.dhcp /etc/network/interfaces else echo "interfaces.dhcp not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.dhcp ] then echo "Copie resolv.conf" cp /etc/resolv.conf.dhcp /etc/resolv.conf else echo "resolv.conf.dhcp not found" exit 1 fi # Services systemctl stop bind9 systemctl stop isc-dhcp-server } # Demande de Configuration while true; do read -p "Voulez vous passer en DHCP externe ou en DHCP local? (e:externe l:local) " el case $el in [Ee]* ) ext; break;; [Ll]* ) loc; break;; * ) echo "Please answer yes or no.";; esac done

@raul I have an Ansible role which does something akin to what you’re trying to do here:
https://forgejo.cwavs.xyz/Cwavs/ansible-role-fog it might be worth taking a look and seeing if it helps give you any ideas on how to solve your problem. Happy to answer questions about it.

@Tom-Elliott Really for the purposes of user tracking. It is helpful for us to keep track of who is deploying and capturing. This is purely for transparency and accountability. I can instruct my team to always register devices they are imaging but I cannot force it.

EDIT: Is there a way to force full reg prior to image deployment? Like a prereq for deployment.

Ok so I now have a second system with the EXACT same issue. I purchased a Dell Precision 7875 which has 2 on-board nics. I updated our dhcp server to issue an IP address for one of the two NICs. With the system connected to that interface I PXE booted the system. The first stage of the fog shows as it notices the system is not registered and asking whether I would like to register the system. Yet once I say do full registration that’s it it will not proceed further.

So similar to the issue that I’ve raised prior with multiple NICs and @george1421 suggested I PXE booted the system again but went into DEBUG mode. Well as it appears the unused MAC address is now showing up on the interface that I had configured to connect to the network. Seeing that I did not assign an IP address to the second mac address the system would not proceed any further. The odd thing is that BOTH interfaces show up having the same mac address. It seems that there’s an issue with the FOS with newer Dell systems with multiple NICs.

If I disable one of the two NICs in the BIOS, and do the re-imaging process everything works fine…

Really looking for a fix for this…

Cheers

Jason Naughton

@siarkowski I believe I have found the cause of this.
A while back, right after the version you reverted too, we added an improved queueing system. It was a simple syntax error (the wrong $task->id vs $task->get('id') ).

This should also greatly improve the experience of the imaging task queue (see also https://github.com/FOGProject/fogproject/issues/736 and https://github.com/FOGProject/fogproject/issues/691) I thought I also wrote a post somewhere in the forum walking through the updated process that fixed some longstanding date math issues, but I can’t find that now.

Point being, if you would be so kind as to update to the latest dev-branch version and see if it fixes the issue, that would be very helpful.

@george1421 Thank you for this suggestion. This disabling of “fastboot” worked PERFECTLY! I interrupted the OOBE with Shift + F10 and got the command line window. I shutdown using the “shutdown.exe -s -t 0” command you suggested. Then after booting up, the FOG capture task I had already started took over and it captured 100% as it should have.

Essentially, I had forgotten to disable fastboot like I normally do on EVERY computer I have. So when it “rebooted” it technically wasn’t rebooting the device since fastboot is a misguided absurd hibernation feature Microsoft developed. The error I got was nearly identical to the one in the original post.

Thanks so much for this suggestion George and all!

9d53d15e-eb10-4045-9c90-31f6c156aa7d-image.png

I know this is an ancient topic, but I wanted to make sure I updated anybody who was interested in a docker image to my new one.

please check my post here

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

@eliaspereira This should be fully fixed in the stable release of 1.5.10.x coming on the 15th of this month and in the dev-branch as of now.
I thought it was already fixed back in September, and it has been working in 1.6 since then but we just got a report of a related issue here https://forums.fogproject.org/topic/18081 which I believe I just fixed.

@tian @DBailey635 @eliaspereira Apologies for missing this post. This was fixed in August-ish of last year, see also:
https://github.com/FOGProject/fogproject/issues/736

I found this searching for a post I wrote about it, as I’m pushing another fix for this for a bug just found in 1.5.10.x

If you update to the latest dev-branch (or what will be stable on the 15th of this month) or give the working-1.6 branch aka 1.6-beta a try, you’ll find the queuing problems fixed.

@Tom-Elliott

Great news!

I updated my server to Debian Bookworm, restarted the Fog installation, and the accent problem disappeared. Awesome!

Thanks for your help and happy new year 2026, all the best for the FOG project!

@Florent Thanks Florent. Hopefully it does!

The issues I’ve listed here do seem to only affect older models of Dell, however UEFI (despite having the word unified in the name) varies wildly by vendor, and even within Vendors, so I wouldn’t be surprised to learn there are similar or different issues affecting newer Dells or even non-Dell machines.

That said, based on my experience at work. I can’t say I’ve seen too many machines have the number of bizarre issues as I have seen with the older Dell PCs we have.

As with all things, I’d suggest testing it on some of the machines common in your fleet of computers and seeing what works and what doesn’t.