@rodluz I tried a manual installation of the updated init.xz as outlined in your instructions, and there was no change. I also upgraded my FOG server and reinstalled your experimental XCP bzImage from earlier in this thread but did not see any change in VM behavior after doing so.

Out of curiosity, @BPSTravis, what hardware are you running XCP-ng on? I know it’s virtualized, but maybe there’s some CPU feature I have disabled in BIOS on my XCP hosts or something like that?

Also, thanks for your patience. I’m only available to work on this once or twice in the middle of the week as I’m part-time with this organization.

@lucamathuse Hi. I have faced similar situation on HP. I think your computers are going into recovery because the BIOS hasn’t updated its boot entries. So it still thinks it should load the old OS.

From the steps, I saw you fiddling with the Boot entries. I’m not familiar with that method, but at least on my computers, I don’t need to change anything. Just a sysprep -> Shutdown and capture.

Have you actually tried investigating whether the data has been copied to your disk? Do you see the boot directory? You should be able to drop into the CMD from that recovery or advanced option and investigate that.

I have deployed Windows 11 while the image type was Windows 10, and never needed to change anything.

@lucamathuse
I don’t remember if it’s related to Win11 we have this in our postdownload script :

if [ -n "$hd" ]; then if [ "$hd" = "/dev/nvme0n1" ] ; then partsys=$hd'p2' partdata=$hd'p3' else partsys=$hd'2' partdata=$hd'3' fi

We use Virtualbox, install classic WIndows 11, disable Bitlocker, and capture with FOG with image set to “Multiple Partition Image - All Disks”
My folder capture :

d1.mbr d1p1.img d1p2.img d1p3.img d1p4.img d1.partitions d1.size

Maybe try capture debug to see which partition FOG get during your capture

@Tom-Elliott Hi, has there been any development with this?

I’m facing a situation that’s not quite identical but very similar in my 1.6.0-beta.2297.

I already posted to the Forum with the details I thought were relevant, but noticed my FOG status is showing the same messages that are posted here.

@lucasgfaj have you turned off secure boot?

@heix75 Thanks a lot for reply!
I use a medical lab program that stores clients data and examinations results almost all day. Of course I take incremental SQL backups.
So if something breaks I would like to have a recent PC backup to only restore SQL.
I used Macrium for that and now I use UrBackup which is open source but not widely used and I wonder if Fog would be a better solution.

@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.

@KMEH Hi,

I tried your method and it only partially worked. It reached the FOG menu correctly after enrolling the key, but the problem arises when I try to perform a quickreg or deploy an image. In both cases, I get the following error (it starts working again when I disable Secure Boot)fog uefi error.png

my version is 1.5.10

@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)

Hello @jrajra,
I got this to work on my instance using ShredOS by doing the following:

Log in to your Fog web portal Go to “Fog Configuration” Click the “iPXE New Menu Entry” button Enter the following details:
* Menu Item=ShredOS
* Description=Boot and Shred (AutoNuke)
* Menu Show with=Not Registered Hosts
* Parameters= kernel https://${fog-ip}/shredos/boot/shredos console=tty3 loglevel=3 shredos_exclude_boot_disc="yes" nwipe_options="--autonuke --nowait --method=zero --noblank --nousb --PDFreportpath=noPDF --autopoweroff" boot Log into your Fog Linux server Open the terminal Run the following commands: mkdir /iso mkdir /var/www/html/shredos wget -O /iso/ShredOS.iso https://github.com/PartialVolume/shredos.x86_64/releases/download/v2025.11_28_x86-64_0.40/shredos-2025.11_28_x86-64_v0.40_20260204.iso sudo mount -t iso9660 -o loop /iso/ShreadOS.iso /var/www/html/shredos chmod -R 777 /var/www/html/shredos

Doing these steps should create a “New Menu Entry” for ShreadOS and specify to shred upon boot, don’t write a completion file, & then turn off the device. (For safety in our environment, I have this option only appear if the device is not registered.)
It then downloaded the ShreadOS file from Github & then mounted the iso as an accessible boot file in the Fog URL. (You can manually download the file & put it in the “/iso” folder instead if you want.)

I have tried this with dban as well, but that only worked for old BIOS based computers. This one on the other hand works for UEFI computers.
I also found this article that might help you: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
I hope this helps you,
Preston

@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!

Can I specify in FOG which hard drive to clone to? For example, using the serial number? That could be stored in the host entry

@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.