Error when capturing image



  • Hi,

    I don’t understand why but for one of my image, unable to caprture it, see error
    0_1506517751371_WP_20170927_15_02_27_Pro.jpg
    0_1506517758587_WP_20170927_15_06_42_Pro.jpg

    what can I dot to resolve it ?
    Computer works fine, sysprep is ok…

    Thanks
    Matthieu



  • 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 ;)




  • Moderator

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



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


  • Moderator

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



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


  • Moderator

    @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 C: drive (probably the biggest). Collect that partition number

    5. Mount the c: drive to that mount point you just created. mount /dev/sdaX /mnt/win where X is the partition number of the C: 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.


  • 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…



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


  • Developer

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



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


  • Developer

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



  • @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
    0_1506588069868_WP_20170928_10_23_31_Pro.jpg

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



  • @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…



  • @tom-elliott 1.5-RC9, last update working


  • Senior Developer

    @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 afai remember there was an error like this below 1.4.4? @tom-elliott ?
    hehe his sig is telling us:

    Bild Text

    Update!


  • Senior Developer

    @matthieu-jacquart What version of FOG are you running?



  • @x23piracy no, unfortunatly same error following these steps :(


Log in to reply
 

489
Online

39192
Users

10844
Topics

103205
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.