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

[foggerj]

Server

• FOG Version: 1.3.5
• OS: Ubuntu 16.04 LTS

Client

• Service Version:
• OS: Windows 10 Professional

Description

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.

[foggerj]

Update: I was able to get the image to capture after changing the image setting from Single disk - Resizeable to Raw Image.
Now I suppose my question is - what effect will this have on my image and its deployability?

[Tom Elliott]

RAW is not the “fix”.

You’re doing something that’s pulling data out almost literally right before the disk is closed before reboot. I’d start by fixing that.

[george1421]

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.

[Wayne Workman]

I think the disk is bad or going bad. Try on a different system with a different disk.

[x23piracy]

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

[foggerj]

@x23piracy

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.

[John L Clark]

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

[x23piracy]

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

[mdean]

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?

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