Error when capturing image

[Tom Elliott]

@x23piracy I don’t know if the SIG is actually updated. It tells us, but if he doesn’t update it it could be anything really.

[Matthieu Jacquart]

@tom-elliott 1.5-RC9, last update working

[Matthieu Jacquart]

@x23piracy I tried to update my signature (Fog 1.5-RC98 and Debian 8.9) but there’s an error message “username too long” so I can’t save modifications, I don’t know why…

[Matthieu Jacquart]

@tom-elliott @x23piracy Ok so I continue tests and this problem is not due to win10 upgrade to 1703 as I thought previously
I just tried this morning to deploy image and then upload it (without update) and same error

Last time I upload this image was in Nov 2016, and there were no problem, but this time no way to do it

[Sebastian Roth]

@matthieu-jacquart said in Error when capturing image:

Last time I upload this image was in Nov 2016, and there were no problem, but this time no way to do it

Thanks for reporting this! We have seen this issue several times lately and I am pretty lost with this. From what you are saying I get that in your case nothing changed except upgrading the FOG server. It that correct?? If yes we can start looking into what changed in the ntfsresize code…

[Matthieu Jacquart]

@sebastian-roth That’s correct, I deployed this image and then just want to upload it once again just after and it fails.
Just one thing, I made a sysprep before upload so I’m going to test without sysprep, just deploy/shutdown/upload directly

[Sebastian Roth]

@Matthieu-Jacquart Yeah, let us know how you got without sysprep. I just noticed the version string in your screen shot saying ntfsresize v2016.2.22 (libntfs-3g) and I am wondering if there we actually saw a newer version at all. Do you remember which FOG version you were using back in November 2016?? Maybe check /home on the server where all the backups of the web interface files end up when re-running the installer…

Off topic: I sent a message to the HP guys weeks ago and never got an answer from them. Sorry but I guess there is nothing much we can do about it.

[Matthieu Jacquart]

@sebastian-roth Sorry but I’m totally unable to give fog version at Nov 2016 (backup delete since a long time…). If Tom can tell us, usually I always use last version.
And that’s funny (or not…) but this problem appears on these HP X2 210 hybrid ! Good news is, we’ve just receive G2 version to test, and no problem with fog kernel, bzImage works great (while I still have to use your modified kernel for G1).
But inode error happens on the 2 versions (G1 and G2).

[Matthieu Jacquart]

So finally it’s related to sysprep. If deploy and immediatly upload, it’s ok. With sysprep, it fails.
No problem on other image with sysprep to upload…

[george1421]

@matthieu-jacquart I can give you some hints on how to debug sysprep.

1. If you sysprep (on your reference image and have sysprep power off computer) (actually its best if you do this on a virtual machine so you can use snapshots. Take a snapshot before you sysprep!!). Power on the virtual machine run it until you get the windows can’t continue message.

2. Then on fog server schedule a debug capture or deploy it doesn’t matter, but then pxe boot the virtual machine into FOS debug mode.

3. Make a directory /mnt/win

4. Issue the lsblk command to find which partition is the drive (probably the biggest). Collect that partition number

5. Mount the drive to that mount point you just created. mount /dev/sdaX /mnt/win where X is the partition number of the drive.

6. Now navigate to /Windows/Panther there are error log files in there that will tell you what happened. This is all command line stuff so you need to exercise your fingers before starting.

Some hints on sysprep with Win10

1. Make sure you don’t have 2 or more unattend.xml files on your reference image.
2. Make sure you only place the unattend.xml file in c:\windows\panther folder.
3. When you call sysprep make sure you define the full path to the unattend.xml file (not really needed if the unattend.xml is in the panther folder to begin with, that is the first place it searches).
4. If you place the unattend.xml file some place else like the legacy c:\windows\setup\sysprep the error log files will be in there instead of c:\windows\panther.

[Matthieu Jacquart]

@george1421 Hi, I’ll try this tomorrow.
Usually I put unattend.xml in c:\windows\sysprep folder and specify full path when I run command
Just to be sure, what means

Power on the virtual machine run it until you get the windows can’t continue message

Because even if capture task fails, windows boot well after sysprep, I have no error.

[george1421]

@matthieu-jacquart OK maybe I misunderstood your error too. I though that sysprep was the cause of your failure?

Power on the virtual machine run it until you get the windows can’t continue message

This means in english this time. Start the computer after sysprep. OOBE will run but you will see an error if OOBE can’t complete. At this point you can not proceed with the deployed image. Power it off and schedule a debug task on fog. The debug task will allow you to connect to the hard drive of the failed computer and inspect the log files.

If you placed sysprep in the c:\windows\setup\sysprep directory look at the log files in there as well as panther. When I last did that one of the error files said it couldn’t locate the unattend.xml file so it stopped. I spend the better part of a weekend trying to understand why my Win10 1703 image would not deploy where I used the same process with earlier version of Win10 and it worked no problem.

[Matthieu Jacquart]

@george1421 Ok, so I think it’s a misunderstood, my sysprep works well (shutdown, reboot, oobe integration, everything is fine).
But if I sysprep my image, I have a fog error when trying to capture image. After that, comptuer rebbot without any problem.
And If no sysprep, capture is ok.

[george1421]

@matthieu-jacquart Ah OK. Question: Do you allow sysprep to power of the PC?

[x23piracy]

@george1421 https://forums.fogproject.org/post/102368

[Matthieu Jacquart]

Ok I reinstall WIn10 from scratch and after sysprep I can upload image, it was certainly a bug on my previous win 10 installation, topic can be closed

[ashledombos]

Hello,

excuse-me for awakening a quite old post, I’m not asking for help but adding some contribution in case of someone else has same problem. I also had yesterday the same message when trying to capture a syspreped Windows 10 pro 1709 image (with Virtual Box)

I tried several basic steps suggested in this post, but the thing that simply worked for me was tu upgrade fog server… (It was not updated since two or three months)

I can’t reproduce the issue, but it can be a step to try before recreating a new Windows sysprep image