@trent_potter Yes you figured it out. Sysprep is a Windows utility, it has nothing to do with FOG. It is always recommended to sysprep before capturing an image.

@Tom-Elliott
I did not update yet to 1824, but i did SELECT * FROM HISTORY;

MariaDB [fog]> SELECT * FROM history; +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | hID | hText | hUser | hTime | hIP | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | 1 | [2026-04-01 08:33:55] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 08:33:55 | 10.10.3.116 | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ 1 row in set (0.000 sec)

the new session i create are not shown, and dont work until i run the maintenance queries

then it shows in history table:

MariaDB [fog]> SELECT * FROM history; +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | hID | hText | hUser | hTime | hIP | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ | 1 | [2026-04-01 08:33:55] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 08:33:55 | 10.10.3.116 | | 2 | [2026-04-01 09:10:37] MulticastSession ID: 1 NAME: test has been successfully updated. | fog | 2026-04-01 09:10:37 | 10.10.3.116 | +-----+----------------------------------------------------------------------------------------+-------+---------------------+-------------+ 2 rows in set (0.000 sec)

@devle I’ve made a couple of edits, though I still cannot replicate the problem you’re seeing.

You shouldn’t see the errors any more (just saying), though I don’t know if these things will fix whatever problem you’re seeing.

@Tom-Elliott All good the last update fixed the issue!

@BLT I don’t necessarily have a timeline for the final release but I did just release an experimental kernel with a newer nic driver. It may work for you if you want to give it a try.

@Infojoe And a real question : How can I mark this as “solved” ?

My workarounds for update on Debian Trixie are:

A)
git checkout master ; git pull
userdel fogproject
cd bin ; ./installfog.sh

or
B)
apt install lastlog2
git checkout master ; git pull
ln -s /usr/bin/lastlog2 /usr/bin/lastlog
cd bin ; ./installfog.sh

Peter

@george1421 I probably found the reason of disSYNC of fog password and FOG settings. My old fog generated password included an & char (password looked like q&Y**********) but after some updates I found q&#38#38#38…********** in FOG_TFTP_FTP_PASSWORD and Storage Management Password.

To solve thi issue , I used https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password bit first I changed password in /opt/fog/.fogsettings.

Then update

update FOG_TFTP_FTP_PASSWORD update Storage Management Password, delete fogproject user (debian 13 installer bug lastlog vs. lastlog2) rerun installfog.sh

Now kernel update (tftp access) is working again.

As a workaround, we’re doing deploy in these Appliances by Schedule Deploy Tasks, as it bypass the authentication screen. But i would be interesting if we could do deploys without this need.

I think this is an issue envolving this kind of nic hardware (Intel I226-V). I opened an issue (18125) where I have some appliances for pfsense, they have got four NICs with this kind of hardware, and we are not getting successfull to deploy an image because it’s not processing authentication, even typíng correct user and password.

Yes, you are right!
I can confirm that it is still functional.
Install clean Windows 11 + drivers + all the updates -> configure windows as you like it -> sysprep -> shutdown -> Image -> Deploy.

Although, I have searched the answer for the main question, to sysprep or not, for years!
What I mean, is that if you sysprep, some of the Windows settings and configuration will be wiped out during the sysprep, so you cannot configure image 100% ready and need some manual steps after the cloned pc (deployed) boots up.
Of course those manual configurations can be automated (by a script or some other way), but still, it would be nice that image can be setup without sysprepping if it is not needed anymore in Win10/11.

I have tested hundreds of PC-s in domain environment without sysprepping - they work flawlessly, no issues with Domain, WSUS or other things, but I am little bit worried, that if some issues arise, e.g some weird errors then I must reinstall all the deployed pc-s with sysprepped images…

Can somebody confirm?

Yes, I understand, that without sysprep, all the PC-s deployed from the same image will be using same SID, but is it bad somehow?
Can someone confirm that for Intune it is also OK?
Domain doesn’t care, WSUS either, but what else might break?

@Tom-Elliott

So I tested current release, and it seems you were able to fix it. It registers new hosts correctly now. However, you still have errors in sed used to enable USB_HCD_USBIO in iPXE compilation to fix non-working keyboard mentioned here: https://forums.fogproject.org/topic/17870/fog-ipxe-menu-no-input/

You have TAB in your sed, but it doesn’t work correctly. So lines number 80-82:

sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+//#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h sed -i 's+//#undef USB_EFI+#undef USB_EFI+g' config/usb.h

should be:

sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h sed -i 's+#define USB_EFI+#undef USB_EFI+g' config/usb.h

TAB after define and undef makes difference and current iPXE release have different syntax. They have:

#define USB_EFI //#define USB_HCD_USBIO #undef USB_KEYBOARD

So we need to uncomment define USB_HCD_USBIO, switch undef USB_KEYBOARD to define and switch define USB_EFI to undef.

@astrugatch we have firewalld but you can make the adjustments… some ports have been changed from the initial setup due to network restrictions.

- name: FOG_Services short: FOG Server network rules description: >- For FOG Server to handle boot, image and various tasks on workstations sources: - SUBNET_IPS allow_icmp: - echo-request - echo-reply services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

@pcnr I noticed this issue so many years a go. It may be issues refering undionly.kpxe file. You can find some solutions from this forum about this. In my case I did following:

Make a backup of /tftpboot/undionly.kpxe to undionly.kxpe.bak; Copied /tftpboot/undionly.kkpxe to undionly.kpxe.

So at next time, this stuck problem was solved.