Error 'Could not open inode 'XXXXXX" through the library'

[Sebastian Roth]

@Jarl2-0 We got an answer! Someone is interested to look into this, analyse metadata and try to fix the issue. But he also suggested to defrag the disk before doing the resize (capture)! Could be a workaround till we figure this out. Please give it a try and report back.

[Sebastian Roth]

@Jarl2-0 I thought I’d set up a test machine to replicate the issue but I am very short on time at the moment and therefore would ask you to create a metadata dump to send to the developer to look into. Quoting from his mail:

I am interested in really fixing the issue, but I need to have a full picture of the metadata. This will not contain any user data, though the file names will be visible. Nevertheless this will be a big file which you will have to upload to a server for me to download (it will not fix in an email attachment).
To extract the metadata image, do (as root) :
ntfsclone -mst -O - /dev/xxx | gzip > metadata.gz (replace xxx by the partition name, like sda2)
If you have a powerful computer, you will get better compression by using “xz -T0” (without the quotes) instead of gzip.
This will require the partition to be consistent, you may have to do a chkdsk on Windows beforehand. If you cannot, you may add the extra option --ignore-fs-check but I might not be able to reproduce the issue.

Please let me know if you need space to upload that metadata file somewhere but I guess you have google drive or dropbox or something like that. Please send me the link (in a private chat message if you like) and I will forward it to the developer. Thanks in advance.

[rj7658]

I am having the same issue as described here. I was running FOG version 1.4.0 first few tries. I upgraded to version 1.5.0 to see if it helped. I tried check disk and defrag using built in windows tools. I did manually resizing my image using Disk Management and Windows couldn’t complete the resize if I drop free space lower than 30%. The Image size of Windows is 37.9G and couldn’t shrink below 58.4G. I dont like the idea of using a non-resizable disk because it adds the extra step of extending the volume manually, BUT it does work.

If I had to guess, Microsoft is writing something out there that FOG can’t move and is in conflict with the leaving only 2G of free space.

[george1421]

@rj7658 Another solution (which we used before fog supported resizable disks) where to create the reference image in a VM with the disk smaller than the smallest size we had in our environment. So at the time we created our reference image on a 40GB virtual disk. Captured and deployed with FOG, then in the setupcomplete.cmd piped some commands into diskpart to expand the disk to the size of the target hard drive.

You could use a similar concept by creating your reference image on an artificially small hard drive, capture with FOG single disk resizable, then when FOG deploys to a target system it will expand to the size of the target hard drive.

[Sebastian Roth]

@rj7658 Thanks for bringing the issue up again. As you see in my last post I had contact to one of the developers already and he offered to look into it. Would you be able to setup a test machine to try and replicate the issue and provide debug data as described in my last post?

[Sebastian Roth]

@rj7658 @george1421 @Jarl2-0 Ok, got some news here. Contacting the developer about this again and he told me that others have reported an issue as well and provided debug meta data to look at.

Here are the two commits kind of related to that issue:
https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/f334c1fdc397d92d2bb4aa9cf75b75dbb33eff40/
and
https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/1f8b751341944545eceb6037176f288843eb7b26/

@Tom-Elliott Any chance we could add that new version / or the patches to our FOS image without too much hassle? Or should we just wait till the fix is upstream? I really wonder that we have seen those errors a couple of times months ago and now it is all quiet again.

Hint for everyone: Defragging the disk might help even without the patches.

[Tom Elliott]

@sebastian-roth I’ve made a patch that includes these fixes. I’m currently building the new init’s which will take quite a long time, but I have uploaded the patch to our fos repository. Sorry it will take a while to get some inits built.

[Tom Elliott]

Inits have been uploaded.

If you want to give them a try:

wget --no-check-certificate -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget --no-check-certificate -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

[Szeraax]

@tom-elliott @Sebastian-Roth Hahaha, we just ran into this as well. Can image 1703. Can image 1709. Can’t image once removed the windows.old via running Disk Cleanup as administrator and selecting the “Previous Windows installstion(s)” (about 28gb of data) option for removal. Do you need anything else to help diagnose this issue? Or just testers to report?

Will try chkdsk + defrag tomorrow. When it doesn’t work, I’ll try to apply your init and report.

[Szeraax]

Also of note: upgrading to 1709 RESET our fast boot option and we had to disable it again.

[Szeraax]

@tom-elliott I decided to do your fix before checkdisk, defrag, or resize. Is now capturing an image!

[Szeraax]

@tom-elliott Image did capture correctly. Can you explain to us newbs what was A) wrong and B) the fix? Just out of casual curiousity, so not a big deal if you don’t want to type it out.

Right now, my guess is that the disk cleanup to remove old windows installations did something funky that may have moved certain stuff that fog didn’t expect to change and now it sometimes thought certain things were in bounds but actually aren’t and your fix gets the correct new location. But that’s TOTALLY baseless.

[Sebastian Roth]

@szeraax said in Error 'Could not open inode 'XXXXXX" through the library':

I decided to do your fix before checkdisk, defrag, or resize. Is now capturing an image!

Great to hear. Sounds like the fix actually is working! Awesome.

[Tom Elliott]

I don’t know what the problem was. All I did was patch the ntfs-3g files with the suggested fixes from Sebastian and rebuilt the inits with the changes.

[Szeraax]

@sebastian-roth I agree! Well done sir. Do you care to explain what was happening? Or is to too long that you don’t even want to sum up?

[Sebastian Roth]

@Szeraax As I am not the developer of the ntfs-3g stuff I can only guess on what exactly was wrong. We try to resize the partition / filesystem to a size relativly close to the actual size of the data for capturing a resizable image and this seems to be a kind of peculiar case where things can go wrong more easily. I don’t know why this issue can be triggered by removing old Windows install data though.

[Szeraax]

@sebastian-roth Cool cool. thanks!

[TaTa]

@Sebastian-Roth @Tom-Elliott Huge thanks for the fix. 1709 is uploading after updating init and init_32.

[scoude]

This post is deleted!

[scoude]

@Sebastian-Roth @Tom-Elliott

Hi everybody,

With my new FOG 1.5.9, I have the same problem after removing the old windows installation (=> 20H2), exactly the same as described in this post ! Was the fix init.xz included in the latest version 1.5.9 ?