"Could not open inode XXXXXX through the library..." Windows 10 Sysprep Capture

datastream

I was getting this same error with Windows 7. I changed the image to raw and it instantly started pulling the image on reboot.

Tom Elliott

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.

mdean

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.

Paulo.Guedes

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

datastream

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.

george1421

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 released you will do this:

sudo -i
cd <where_ever_your_install_files_are>
git checkout master
cd bin
./installfog.sh

Telling git to checkout the dev-branch or master is 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.

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

Quazz

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.

Sebastian Roth

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

datastream

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.

datastream

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

@datastream See update here: https://forums.fogproject.org/topic/11207/error-could-not-open-inode-xxxxxx-through-the-library

kafluke

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

Quazz

@kafluke You may have to defragment the drive and/or run chkdsk on it if you’ve deleted a significant amount of data.

kafluke

@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

rogalskij

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

"Could not open inode XXXXXX through the library..." Windows 10 Sysprep Capture

201

11.6k

17.1k

154.6k