Solved "Could not open inode XXXXXX through the library..." Windows 10 Sysprep Capture
- FOG Version: 1.3.5
- OS: Ubuntu 16.04 LTS
- Service Version:
- OS: Windows 10 Professional
I have been testing creating a Windows 10 Professional image to get a clean universal image that doesn’t include the provisioned Windows store and apps. I have an unattend.xml file that executes a setupcomplete.cmd, which executes a slmgr call and sets the FOG client to automatic start then reboots the machine. Using powershell I remove all provisioned windows apps (Get-AppxProvisionedPackage -Online | Remove-AppxProvisionedPackage -Online) and installed windows apps (Get-AppxPackage -AllUsers | Remove-AppxPackage), and sysprep the machine (virtualized as i intend to use the image for different hardware). I set the host to capture the image and it comes up with the following error regarding opening an inode (MAC/IPs removed):
There is no error from sysprep and the machine (without capture) boots and finishes install as it is supposed to. I haven’t been able to find much on this error, and was wondering what I can do to capture this image?
NOTE: This only occurs if I perform the aforementioned removal of windows apps.
@kafluke I also was experiencing this same issue. I had deleted a bunch of data as well before trying to pull the image (ran disc cleanup wizard). I ran the exact commands you did, and it fixed the issue. Thank you and Quazz for this assistance. This forum really helps in every way with this awesome product.
@Quazz I saw a post by you in another thread and took your advice. I ran all these commands and it’s capturing now:
dism /online /cleanup-image /startcomponentcleanup dism /online /cleanup-image /restorehealth sfc /scannow chkdsk C: /f
@kafluke You may have to defragment the drive and/or run chkdsk on it if you’ve deleted a significant amount of data.
@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.
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.
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 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
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.
x23piracy last edited by x23piracy
@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
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.sh
If 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.sh
Now 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.sh
Telling git to checkout the
masteris 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.
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.
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 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 last edited by
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 was getting this same error with Windows 7. I changed the image to raw and it instantly started pulling the image on reboot.
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?
x23piracy last edited by x23piracy
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.
@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.