Hi @efbCREED — a couple of things are going on here, and the good news is the behavior you’re seeing may not be broken at all.

First, your capture is filtering out where the boot filename actually lives.

Because you’re using pxe-service= menu entries in proxy mode, dnsmasq does the handoff in two steps:

1. The initial ProxyDHCP offer on port 67 carries the PXE menu (in the vendor-encapsulated options) and a boot-server list — it deliberately does not include the boot filename (option 67). That’s exactly the “four handshake-y parameters” you’re seeing.
2. The client then sends a Boot Server Discover and the actual filename comes back on UDP port 4011.

Your filter was port 67 or 68, so it never captured 4011 — which is very likely where the file is (or should be) going. Re-run with:

tcpdump -i eno1 -v port 67 or port 68 or port 4011

That will tell us whether the filename is being served on 4011 and the client just isn’t completing the exchange, or whether it never gets there.

Second, I’d simplify the config. Your file mixes two different handoff mechanisms (dhcp-boot and pxe-service), and the four dhcp-vendorclass lines you defined are never actually referenced — the pxe-service lines use dnsmasq’s built-in arch keywords instead, so those vendorclass lines aren’t doing anything.

The config we recommend for proxyDHCP drops the menu approach and matches on architecture directly. This puts the correct filename right in the port-67 offer (so it’s trivial to verify with the tcpdump you’re already running) and chains iPXE → FOG’s boot.php once iPXE is loaded:

# /etc/dnsmasq.d/ltsp.conf   (adjust <server-ip> throughout)

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-range=<server-ip>,proxy
dhcp-no-override

# Detect the client's PXE architecture (DHCP option 93)
dhcp-match=set:bios,option:client-arch,0
dhcp-match=set:efi32,option:client-arch,6
dhcp-match=set:efibc,option:client-arch,7
dhcp-match=set:efi64,option:client-arch,9

# Detect when iPXE itself is asking (DHCP option 175)
dhcp-match=set:ipxe,175

# Serve the right network boot program per architecture
dhcp-boot=tag:bios,undionly.kpxe,,<server-ip>
dhcp-boot=tag:efi32,ipxe.efi,,<server-ip>
dhcp-boot=tag:efibc,ipxe.efi,,<server-ip>
dhcp-boot=tag:efi64,ipxe.efi,,<server-ip>

# Once iPXE is running, hand off to FOG
dhcp-boot=tag:ipxe,http://<server-ip>/fog/service/ipxe/boot.php

A few notes:

• Use undionly.kpxe for BIOS, not .kkpxe. The kk variant is only needed on the handful of older NICs that need the UNDI stack kept resident — undionly.kpxe is the right default.
• The tag:ipxe line must come after the per-arch lines. dnsmasq applies the later match, so this ensures a machine that’s already running iPXE gets sent to boot.php instead of being handed the .efi again (which would loop).
• Make sure those files actually exist under /tftpboot (undionly.kpxe, ipxe.efi) — they ship with FOG, but worth confirming.

After you drop this in, restart dnsmasq and PXE-boot a client with the tcpdump above running. You should now see the filename land in the port-67 offer for the client’s architecture. If you still get nothing, paste that full capture (67/68/4011) here and we’ll take it from there.

Which firmware is the client — legacy BIOS or UEFI? That narrows down which line above should be firing.

@Alun Thank you and added to documentation and within the installer to try to more cleanly account for this.

@jmeyer So this issue is fixed on the latest now is what you’re saying?

@jmeyer Can you please get me some more information?

1. Is /etc/kea a real, populated directory? Right owner/perms?
   ls -ld /etc/kea; ls -la /etc/kea

2. What’s the OS, and is a MAC layer confining kea-dhcp4?

Debian/Ubuntu:

cat /etc/os-release | head -2; aa-status 2>/dev/null | grep -i kea; dmesg 2>/dev/null | grep -i 'apparmor.*kea' | tail

RHEL/Fedora:

cat /etc/os-release | head -2; getenforce; ausearch -m avc -ts recent 2>/dev/null | grep -i kea | tail

Plus the tail of the install error log around the DHCP step (/opt/fog/log/error_*.log or wherever the run pointed $error_log).

@jmeyer I’m trying ot take a look, but kea is a new thing since isc-dhcp has been deprecated and is nearing its potential EOL.

So we moved toward KEA as the dhcp server, and while it has been added, I can attest I don’t have enough methods of testing.

I suspect the issue is related to different OS baselines:

(e.g. Fedora/RedHat stores config in /etc/kea, but Debian/ubuntu is deciding to store in /etc/kea-dhcp-server - or something I don’t know, just trying to show the issue)

I’m working on trying to validate in the background.

@Valer Thanks for the report and the writeup, that’s a good catch. You’re right about the cause. Debian 13 dropped the sysv-rc-conf package since it’s fully on systemd now, so the installer chokes trying to apt-get it. We never actually use that tool on a systemd system anyway, it only ever got called on the old non-systemd paths, so it was just dead weight on Trixie.

I pushed a fix to working-1.6. It leaves the package off the list on Debian 13 and up, and it also strips it out of a cached .fogsettings so an in-place upgrade doesn’t drag it back in. Older Debian keeps installing it like before so nothing changes there.

If you want to get moving before you pull the update, you can either grab the latest working-1.6 and rerun the installer, or just open /opt/fog/.fogsettings and delete sysv-rc-conf from the packages line, then run the installer again. Either one gets you past it.

Let me know if you hit anything else on Trixie.

@Cpasjuste if you have github you likely have ability to have copilot to help read the repo and help you build the README if you find it lacking.

Just thoughts, but thanks for this.

@kratkale What you see in the text field are place holders, just example views, if you were to hit update/save, those things aren’t what will be set.

THe reason you see “(varies)” is because the hosts in the group have some things where their host Primary Disk is set, but not all hosts have the same values.

As for your odd snapin issues please try these commands on the Database:

delete from snapinAssoc where saSnapinID <= 0;
delete from snapinTasks where stSnapinID <= 0;

As for the domain join issue:

The “captured” host should not be joined to the domain until after the image has been captured.

The error you were seeing was joining domain “Code = 87”

That is not FOG writing an erroneous error, but rather the error from the Domain controller directly.

This may mean your environment is expecting to be set to a specific OU within the domain?

https://forums.fogproject.org/topic/11971/unable-to-join-domain-error-87

This is an old (albeit similar) topic with the same type of error you had seen so maybe it’s fix may help your fog client as well?

This, of course, isn’t strictly necessary, since your snapin method appears to be working anyway.

As always, please update to the latest and greatest as it should help with the prevention of odd jobs just getting created as well. After you clean up things of course.

Thank you!

@vanfifty1 I feel like this was something you produced on GIthub as well, is this correct?

I’m just wanting to link things. As it’s usually usually me doing all the development now-a-days again, (but thank you AI) I can try to have Claude take a look.

I’m currently working on 26H1 update download at least thru a vm, but just wanted to give a heads up.

@kratkale Is it possible DHCP IPs are all used up and the device that fails doesn’t have a proper IP address to be able to even communicate with your FOG Server?

It is very odd that one machine works where another seems to fail.

Nope, because 401 isn’t the same as that’s a client side error saying “we failed to prove we can talk to the fog server.”

@kratkale I’m unsure if I follow:

So if you reset encryption data, things will start and continue to work, but fresh after imaging it does not?

@kratkale This has now been pushed.

@kratkale I’m having it do a sort on “name” then by start time (newest first) if there’s a tie.

I think it is because the snapinLink is what you see as the name, and that link built by sorting by the IDs rather than the names.

For the active tasks table I figured sorting by the time adds a level of understanding so you always know who was the newest one to the party (so to speak).

@kratkale said in Windows 11 | 65x HP Z2 Tower G1i | UPDATE -:

I mean, why do I need to connect to the web interface? I don’t have to do anything there during the update, do I?

The URL you see is because the installer doesn’t know if (or not) there’s a Schema Update.

It always shows that on every install. If you don’t want to see that, now that FOG is installed, you can just run your installer with:

sudo ./installfog.sh -y

If there is a schema update, this will do the update for you automatically, if not, the doesn’t matter, the main update just goes through the normal process.

@vanlam You may need to ensure the fog server at 192.168.13.99 is running NFS appropriately?

@kratkale The problem is Snapins are not a basic feature:

They require the FOG Client + knowledge of what a snapin is and does (at a base level)

The “basic” for FOG is imaging at its core.

Snapins are a way of getting the machine to do additional things: install software, run a script (or set of scripts) etc… - Please note I’m not saying it’s not a useful feature, just saying that it’s more than a “Basic” thing.

You can do a curl request to schedule a snapin task which might be better, though you would need to know what MAC Address to use for the host in question.

@kratkale You can, but it falls under “Advanced Tasks”.

@kratkale what do you mean? The ui refactor is intentional. This is just progressing to make it more inline.

@pilipp_edv there was a bug introduced. This has been corrected and will be released on the 15th automatically. You can switch to dev-branch to get that fix in the meantime. Thank you.

@kratkale Also just pushed code I hope should address the issue with Multicast Task race condition which I think is the problem you’re seeing.

Basically when the multicast task starts to clear out it updates the reliant tasks to complete, but it’s doing this before your machine gets to do it’s checkout process which makes it show as “complete” but then when it tries to clear itself out, it’s already clear causing it to say there is no task available to complete causing the message you’re seeing.

I’ve added code to hopefully get around that if you’re willing to test?

Also the latest working-1.6 has the Sun/Moon now and you can have dark mode (if you’re one - like me - who doesn’t want burned cornea’s )