"Could not open inode XXXXXX through the library..." Windows 10 Sysprep Capture
-
Our reference image has these packages removed and FOG captures the image just fine on single disk resizable.
@x23piracy just posted this tutorial this AM: https://forums.fogproject.org/topic/9877/windows-10-pro-oem-sysprep-imaging that may give you some guidance.
Also know that on win10 shutdown isn’t really a shutdown, rather its an enhanced sleep mode. You can’t manually shutdown win10 and successfully capture it. To capture it correctly you must have sysprep power off the device.
-
I think the disk is bad or going bad. Try on a different system with a different disk.
-
Hi,
do you let the sysprep process shutdown the machine?
I would not recommend uninstalling the store and even the calculator app.If you really want to get quit the new calculator install this:
http://winaero.com/blog/get-calculator-from-windows-8-and-windows-7-in-windows-10/FYI the new calculator has a problem if you like to paste numbers with a dot inside, for example 38.500,50€
Without the dot:
Our employees needs that in the customers center. therefore i removed new calc and installed the windows 7 calculator to our images
Removing the store may could give you problems with system, if you dont like your users to use it better lock it down with gpos:
Computer Configuration -> Administrative Templates -> Windows Components -> Store -> Turn off the Store application
http://www.urtech.ca/2015/09/solved-how-to-disable-the-store-app-in-windows-10/EDIT: Locking the store down or blocking store apps doesnt work in Win 10 Pro Edition anymore this only work with Enterprise. hmmpf
Regards X23
-
I will be reviewing the link to your tutorial that @george1421 posted below, thank you for the input! We do not want users on the network using the windows store and seeing as Microsoft ‘locked down’ Windows 10 Pro in a push to get people on Enterprise, eliminating it from the base image became the decision. Your calculator implementation is a good idea. I also did not realize that the Windows 10 ‘shutdown’ isn’t the ideal state (thanks @george1421!) for capturing the sysprepped image.
-
@foggerj I am getting the same type of message with one i am doing. I was able to capture the image without all the updates as a test, but when I fully updated windows, and all flash player updates and antivirus updates it fails. The last thing we did is run Disk Cleanup to remove the windows.old from the image. I then get the error “Could not open inode XXXXXXX through the library” I am in the process of rebuilding the image again and not running Disk Cleanup to see what happens.
-
Hi,
going over Major Updates, Sysprepping and removing Appx is not a good idea.
Clean Install from Current Versions ISO, do your stuff and then image.FYI do not embed third party Antivirus in your Image, just stay with its Agent and deploy Antivirus after image deployment.
Myself had never problems with the shutdown initated by the sysprep process.Before you sysprep try to run chkdsk, if chkdsk was ok run sysprep but don’t use option /reboot or /shutdown just use /quit, then manually shutdown your machine with shutdown -s -t 0 -f, then try to image.
Regards X23
-
We are having the same issue receiving this error, our plan was to have a gold image that we create in a VMware VM to update quarterly then clone it to another VM to sysprep and capture.
We’re only doing windows updates and the fog client on the image so there should be nothing to interfere (additionally we disable defender and the tile modeler service prior to sysprep).
However, it only works the first time the sysprepped image is captured.The second cloning it works fine and boots up with no issue if you let it pass PXE boot after sysprepping, but the image wont capture (except in raw format like foggerj noted). ~ This is fine with us as it only adds 10min to the image process, but would also like to know if there is any ill effects other than that?
-
I was getting this same error with Windows 7. I changed the image to raw and it instantly started pulling the image on reboot.
-
Are you all using the same version as the OP? 1.3.5? If so, you might want to go to the RC series where in 1.4.1 I fixed an issue in certain cases (I believe related to this) and in RC series I’ve addressed another smaller issue that was found.
-
I am on the current 1.4.4 version, I ended up just recreating the VM since we had figure out what needed to be installed on the base image.
-
@tom-elliott
Hello Tom, I am using the latest stable version (1.4.4) and seeing something similar when trying to clone with the “shrink partition” method. Maybe it’s something inside partclone itself…? -
I’m on 1.4.2. I am not cloning VM’s, I am cloning a physical machine. I am wondering if it has some bad sectors on the hard drive. I did a check disk and everything came back clear but that makes sense to me if the raw one does a sector by sector.
I am going to image this image to another machine and then try to pull the image from that one as single disk resizable and see if that is what it is. The raw image is taking up way to much space on my server.
-
Can we get one of you guys to install the RC9 release of FOG 1.5.0 to see if the issue has already been addressed? The process is this to update to an RC release.
If you don’t have the local install files, use git to pull them down using this process.
sudo -i git clone https://github.com/FOGProject/fogproject.git /opt/fogproject cd /opt/fogproject git checkout dev-branch cd bin ./installfog.shIf you already have the git install files on your fog server then do this
sudo -i cd <where_ever_your_install_files_are> git checkout dev-branch cd bin ./installfog.shNow when its time to switch to the stable branch
once fog 1.5.0 stable has been releasedyou will do this:sudo -i cd <where_ever_your_install_files_are> git checkout master cd bin ./installfog.shTelling git to checkout the
dev-branchormasteris the key to switching to an RC release.I must warn you that upgrading to 1.5.0 is a one way street. If you upgrade you can't roll back to 1.4.4 because of the gui changes. So consider this well. 1.5.0 RC9 is stable and works well. You shouldn't have any concerns about updating. -
@george1421 like george is telling, don’t fear of trying the RC’s, i also work with RC9 in a productive environment
I have done all the basic stuff (capture, deploy, snapins, active directory join and so on) Feel free to make a backup of your fog instance before going to RC’s -
I got the same error on Windws 7 machines trying to clone them using Resizable. Single disk Multiple Partition worked fine and since they were all the same systems it worked out for me, though still curious why Resizable was having issues.
I’m on latest RC as per usual. (1.5.0-RC9), although it was a few RC’s back when this happened I believe.
edit: I should note that these weren’t prepared in the ‘usual way’, that is to say, I first deployed W7 to them and then installed updates and created an additional user and such. No sysprep either.
-
I fear this will be a real bummer to figure out! Reading through the posts I see this happening in various different scenarios. FOG version 1.3.4, 1.4.4, RCX, you name it. As well I read about VM and physical machine and then there are syspreped and non-syspreped setups. Possibly an MS update is doing this to us (partclone but anyway)?? Is anyone able to spin up a test setup:
- FOG 1.5.0 RC9 (so we see this is still happening in the latest version)
- Windows 10, all updates installed
- VM or physical shouldn’t matter
-
After replacing the hard drive on a different laptop of the same model, success. I was able to image the repaired laptop with the raw image and then capture the same image off of the repaired laptop as a resizable image.
Now I have a different model that starts to do the resizable image, gets started, but quits half way through. I am trying the raw image now to see if that works.
-
I was messing with the other model of laptop that was now giving me issues. It was dying at random points of the capture. It was actually overheating. I grabbed a different laptop of the same model and it worked like a charm.
So, all of my capture issues so far have seemed to be hardware related.
-
-
@Sebastian-Roth I have been updating all my older images and as part of the process I am removing the windows update files to make the images smaller. This triggered this same error. I tried your wget command to get the new inits but that didn’t solve my issue. I’m on the latest dev-branch as of the time of this post.
