@toalalife Hi there! Sorry for the late reply. I’ve been on holiday and I forgot to check up on this. That is interesting. There are a couple of things I can think of to double check/try off the top of my head.

That particular error happens when iPXE can’t execute the binary, usually because either an architecture mismatch (e.g arm64 on x64) or because secboot fails to verify. Given that disabling secboot fixes it, I’m leaning towards that. (https://ipxe.org/err/2e0080)

So I would say you should double check that your kernel is signed. If you’ve updated them you’ll have to resign the kernel to ensure it keeps working.

The other would be to double check that the shim command is being invoked at some point prior to boot.php being chained. There’s a none zero chance that if you’ve updated FOG, it may have overwritten the modified default.ipxe

Other than that, if you could try and record the boot process I’d be happy to take a look and see if I can spot anything out of the ordinary, I’m also happy to take a look at your kernel or any ipxe scripts etc if you want me to double check if they’re signed or bootable.

As a final note, I don’t think I see iPXE loading the initrd.xz file there, which contains the ram filesystem that FOG uses on boot. I could be misremembering the boot process (I can’t recall if it’s normal for it to not do that if the bzImage fails to verify, or if it loads it prior to bzImage), but if that’s failing to load it might also be worth checking that out, though it shouldn’t have to be signed!

@mashina I used a Windows bootstick to go into recovery and checked. All partitions are there but C:\ or the one that would be C:\ is RAW.
I modified my golden image files to “fix” the problem I’ve been having and here’s the output of the modified files:

Directory output:

total 5.7G -rwxrwxr-x 1 fogproject fogproject 4 Apr 7 13:44 d1.fixed_size_partitions -rwxrwxr-x 1 fogproject fogproject 1.0M Apr 7 12:18 d1.mbr -rwxrwxr-x 1 fogproject fogproject 697 Apr 7 13:18 d1.minimum.partitions -rwxrwxr-x 1 fogproject fogproject 59 Apr 7 13:44 d1.original.fstypes -rwxrwxr-x 1 fogproject fogproject 0 Apr 7 12:18 d1.original.swapuuids -rwxrwxr-x 1 fogproject fogproject 697 Apr 7 13:17 d1.partitions -rwxrwxr-x 1 fogproject fogproject 697 Apr 7 13:18 d1.shrunken.partitions -rwxrwxr-x 1 fogproject fogproject 15M Apr 7 12:18 d1p1.img -rwxrwxr-x 1 fogproject fogproject 767 Apr 7 12:18 d1p2.img lrwxrwxrwx 1 root root 12 Apr 7 13:42 d1p3.img -> d1p3.img.000 -rwxrwxr-x 1 fogproject fogproject 5.6G Apr 7 12:27 d1p3.img.000

As you can see I used I symlink to attempt a fix of d1p3.img.000 and maybe that was my demise.

d1.partitions:

label: gpt label-id: 99934977-65D0-41C6-B5E0-92E8085EC24F device: /dev/nvme0n1 unit: sectors first-lba: 34 last-lba: 500118158 sector-size: 512 /dev/nvme0n1p1 : start= 2048, size= 409600, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=740FC648-717D-439E-9AC9-224A270007E2, name="Basic data partition", attrs="GUID:63" /dev/nvme0n1p2 : start= 411648, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=45621D9E-3DD9-4D22-9D25-BCCDE3D0D714, name="Microsoft reserved partition", attrs="GUID:63" /dev/nvme0n1p3 : start= 444416, size= 498042880, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F20FBC57-04B6-4522-9D20-33998BF119F9, name="Basic data partition

d1.original.fstypes

/dev/nvme0n1p1 vfat /dev/nvme0n1p2 raw /dev/nvme0n1p3 ntfs

d1.fixed_size_partitions

1:2

The changes I made resulted in partclone not breaking off after d1p2 and saying it’s done. Now it starts deploying d1p3 and stops after around 80% and gives me this error screen. I tried accessing the log they mentioned but it doesn’t exist on my FOG server.

WhatsApp Image 2026-04-08 at 17.06.31.jpeg

I could try and fix this for days but how do y’all capture an image so that it doesn’t break or get captured in a wrong way? I just want a clean image of Windows 11.

@hariskar

I didn’t really catch the described use case…
But anyway, if application stores something in the database, then the database need to be backed up, of course. Fully and incrementally also (separate logic).

If you use application that stores data in the same machine where it is installed, better would be to configure it to store data on the remote database, e.g on specific database server or some other way.
You can create network drive or other remote storage and point your database files there - if needed to be separate (for each PC).

This way you have all the data in the same place, and you can make backups of this server or drive more easilly.

Backuping entire PC with database in it - this can be done, but why?
It feels strange.

Example:
Lets say, employees in your company are working with important documents.
Do you really want to backup of entire PC (with os and applications and data), instead of storing those documents on secure and reliable remote storage?
Better solution is to simply make network location (local or in cloud) and let the users to store documents there - so the documents would not be lost if some pc dies.
If PC dies, then you simply replace the pc and deploy ready to use system image.

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

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

Hi, this is a known issue when using NVMe, as you’ve probably already discovered. I’m not sure whether FOG 1.5 supports using serial numbers to target disks, but someone from the team may be able to confirm that. FOG 1.6, however, does support targeting disks by serial number.

I ran into the same situation. As a workaround, I customized my init.xz to use the PCI path instead, since those appear to be more persistent.

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

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

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!

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