@george1421 OK, finally, was able to capture the image successfully. This partition /dev/sda4 apparently was the recovery partition so all efforts prior to this (IE hibernation settings, and running chkdsk on the os volume were not the issue). What fixed the issue was running:
ntfsfix -d /dev/sda4
Suggestion: would it be a good idea to test these dirty flags prior to running the lengthy imaging process so that perhaps we don’t have to do so much guesswork.
@george1421 So yes I just ran that again… says it was processed successfully. Same as before. I will see if that -d did anything else
@george1421 ok ran ntfsfix /dev/sda4 came back as good.
Re-ran FOG and it still complained with same error… Not sure what else it could be.
@george1421 Attempted to run through this article: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
@george1421
Ok so when I attempted to run fsck -t ntfs /dev/sda4 I got not found…
So I ran it as fsck -t ntfs dev/sda4 and it worked but didn’t seem to do anything or there were no errors Tried to run fog still an error. Very puzzling.
@george1421 I am waiting for this next iteration of capture finishes. Its at 80%
@george1421 Sysprep is set to shutdown. Also the settings for Ram Disk were already at 275000, and the capture resize was changed from 7 to 10.
@george1421
Thanks for the update, so the partclone error only specified the issue of the OS having dirty shutdown flags.
@george1421 I have 400GB free Space (600GB size) (I initially thought it might be a space issue as well, however, this is not the case.
Yes using Single Resizable disk mode. Trying Single Disk not resizable - Did the same error… The suspect seems to be this unclean shutdown issue… I booted and verified prior to the capture that the chkdsk was clean and without error.
@george1421
So yes if I go into /images I can see the test file. I can also see the mac directory
Here is the debug mode.
Exports file again:
@george1421 - Its seems that it has been successful in writing some files. Not sure what the issue is. I did the debug prior to the message / post and no errors that I could see outside the one that is in the screenshot.
Seems the capturing process is running and writing the files as root.
I tried to change as fogproject.root before image is complete, but curious why its now doing this.
@george1421
I have been successful in capturing 2 other images so far… Not sure why permissions would change. I will try to run in debug.
No space issues that I see, not sure why its seeming to complain about space.
@george1421
Yes your Tutorial is spot on.
One thing I have observed though, is if you reinstall Fog (I did this morning troubleshooting the Secure boot post) I noted that the exports file is replaced with default. I lost all my settings from prior. I had to append the file.
Ok so if anyone gets this error specifically this is seemingly due to Secure Boot being enabled in Proxmox when doing a windows 11 install. I had to disable Secure Boot:
https://jhartman.pl/2021/11/08/proxmox-7-cant-boot-to-uefi-home-assistant-and-other-uefi-images/
Getting this error when attempting to capture a windows 11 machine.
OK Confirmed its all working as expected. The Ultimate solution was the duplicate fsid=x issue.
Perhaps flag the wiki document on installing additional storage pools to ensure that the fsid=x value is not duplicated from a copy and paste.
@george1421
OK sorry, I just noted that the capture never completed… its starting over again.
Going to watch to see what happens.