At this point, I would stop modifying the image files by hand and do one clean test from scratch.

Fresh Windows install Verify BitLocker / Device Encryption is Fully Decrypted Leave the default Windows partitions alone for this test Do not edit BCD / boot entries Disable the FOG client before capture if it is installed Sysprep and shut down Create a new image definition in FOG Capture it again as Single Disk - Resizable Deploy that new image without modifying any files in the image directory

Right now, the modified image is not a clean test anymore. The latest error shows Partclone is attempting to deploy p3 and then failing, which also explains why the restored partition shows as RAW.

This is how I have captured and deployed images on various HP models.

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

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