Error after sysprep and capture (FOG related)

[jemerson93]

Hi all,

Getting the following error after capturing an image. Tested sysprep and boot (without FOG capturing) and it booted fine. If I sysprep, then capture and then boot, I get this… “Windows could not finish configuring the system. To attempt to resume configuration, restart the computer”.

Any insight on what is causing it? Current version of Windows 10 I am testing for this is 1903. Unattend script is the same I’ve used for 17s and 18s.

FOG Version: 1.5.6
Kernel Version: 4.19.36 for bzImage and bzImage32

[Wayne Workman]

@jemerson93 Read the sysprep section here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

[jemerson93]

@Wayne-Workman said in Error after sysprep and capture (FOG related):

@jemerson93 Read the sysprep section here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Hi Wayne,

I have FOG Service disabled in the golden image and all of the individual images afterwards. I have the service set to start on first login on a custom script we have run to do various tasks (delete sysprep folder, change power settings, start fog, etc)

The issue is that my unattend script and capture works fine on Windows 10 1809. It’s specifically 1903 that is causing this issue and I can’t seem to pinpoint why. It has something to do with FOG capturing the image (as I mentioned if I sysprep and then boot, it’s fine)

It isn’t the service starting to early though.

Any other ideas?

[jemerson93]

@Wayne-Workman said in Error after sysprep and capture (FOG related):

@jemerson93 Read the sysprep section here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

So I finally got it to capture but a new weird issue. It captured the entire drive instead of the usual 12GB - 13GB. The only other difference I was testing on this was using a writeback cache on Proxmox instead of no cache. Would that cause it by any chance to capture the entire size of the drive?

[Sebastian Roth]

@jemerson93 said in Error after sysprep and capture (FOG related):

The only other difference I was testing on this was using a writeback cache on Proxmox instead of no cache. Would that cause it by any chance to capture the entire size of the drive?

Probably not. Have you made sure BitLocker is disabled? Did it say NTFS or RAW in the blue partclone window when capturing?

[jemerson93]

@Sebastian-Roth said in Error after sysprep and capture (FOG related):

@jemerson93 said in Error after sysprep and capture (FOG related):

The only other difference I was testing on this was using a writeback cache on Proxmox instead of no cache. Would that cause it by any chance to capture the entire size of the drive?

Probably not. Have you made sure BitLocker is disabled? Did it say NTFS or RAW in the blue partclone window when capturing?

No bitlocker and file system is NTFS. It is also currently stuck on syncing… after re-deploying a test to a VM

[jemerson93]

@Sebastian-Roth said in Error after sysprep and capture (FOG related):

@jemerson93 said in Error after sysprep and capture (FOG related):

The only other difference I was testing on this was using a writeback cache on Proxmox instead of no cache. Would that cause it by any chance to capture the entire size of the drive?

Probably not. Have you made sure BitLocker is disabled? Did it say NTFS or RAW in the blue partclone window when capturing?

Okay, the syncing finished.

New error…

[jemerson93]

Also, when it does expanding drive dev/vda4, it states fixed size. I wonder if this would have a correlation to it taking the entire drive.

[Sebastian Roth]

@jemerson93 Usually when the “update database” fails you get an error in the apache and/or PHP-FPM logs. See my signature on where to find the logs and post here.

when it does expanding drive dev/vda4, it states fixed size.

Quite possibly yes! Can you please post the contents of the following files you find in the image directory on your FOG server: d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions

[jemerson93]

@Sebastian-Roth said in Error after sysprep and capture (FOG related):

@jemerson93 Usually when the “update database” fails you get an error in the apache and/or PHP-FPM logs. See my signature on where to find the logs and post here.

when it does expanding drive dev/vda4, it states fixed size.

Quite possibly yes! Can you please post the contents of the following files you find in the image directory on your FOG server: d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions

Hi Sebastian,

I’ll be able to get you this information in the morning. I still haven’t downloaded and replaced the Kernel’s you mentioned to fix my other issue either (with the unallocated space with nvme drives). Trying to work through all issues Thanks for the help.

[jemerson93]

@Sebastian-Roth

Hi Sebastian,

I just wanted to add something. Before your post I was attempting to sysprep and capture with a different unattend file. Please see my information below.

I have 2 different unattend scripts that are mostly similar. For UEFI images (gpt partition, it creates 4 partitions (4 being set to extend) and the legacy creates 2 partitions.

I have issue with it capturing the entire drive with the UEFI script. I tested with the MBR script (Legacy) and it captured it fine again and only 11.2GB.

[jemerson93]

Hi Sebastian,

I am going to work on getting the information you requested. I’m still running into this issue (same for legacy systems (MBR)).

[jemerson93]

Hi Sebastian,

With all of the other posts I had up, this was related to my unattend script and completely unrelated to FOG. This is resolved!

Thank you for the help.