FOG unable to capture/deploy resizeable images correctly.

[george1421]

@dambron When you look at the uploaded image size in FOG Image management, what is its file size compared to how much actual data is on the reference image hard drive?

If you were to capture that same reference image again, looking at the partclone screen does it say capturing in RAW mode?

[dambron]

@george1421

So normally the image sizes look correct, but I did monkey with a few things earlier today and I notice now that a few of my older images list “0.00 iB” and the image I’ve been working on also shows “0.00 iB”.

The size on the server is 16,107,628,413 bytes, so 16GB or so? The actual used disc space is about 33GB on the reference machine.

E: Also I’m like 99% sure it’s not capturing in RAW mode because I’m pretty sure that takes a looooong time compared to a normal capture., and I probably would have noticed.

[Sebastian Roth]

@dambron In this case where you only have one single partition we seem to have an issue in the capture scripts. It shouldn’t mark it as fixed partition. I think we have another user who reported this last week but I have not had the time to further debug this.

I was hoping that George might be right about it not properly detecting this as a NTFS partition but as the image on the server is around 16 GB it’s not likely to be captured as raw.

Please do me a favor, schedule another capture task on your master but this time tick debug option. Start it up and when you get to the shell run blkid -po udev /dev/sda1, take a picture and post here.

[dambron]

@Sebastian-Roth

I will do that right now, but just to be clear, this was happening earlier today when the image was a Win10 installation with the recovery partition in place as well. I will post the results of the debug shortly.

Thanks so much.

[dambron]

@Sebastian-Roth

The results of the command

[Sebastian Roth]

@dambron You need to hit ENTER twice to get to the shell and only then run the command below mentioned.

[dambron]

@Sebastian-Roth

My bad, here you go.

[Sebastian Roth]

@dambron Ok, thanks. Looking good so far. I will take a look at the scripts tomorrow and see what I can find.

[Sebastian Roth]

@dambron Ah well, why go to bed if digging through the script code is just so much fun… Please schedule another debug capture task. When you get to the shell run the command fog to start the capture as usual but in debug mode you need to manually step through pressing ENTER for every action. When you see the line Saving original partition table..... take a picture of the screen and post that picture here.

[dambron]

@Sebastian-Roth

Here is the screenshot of the stepped process for capturing this image.

[Sebastian Roth]

@dambron Ok, that all seems fine so far. I still can make heads or tails of this. Can you please do the debug capture again and step through till you see the message Processing Hard Disk: /dev/sda and then take a picture again.

As well please post the contents of /images/<IMAGENAME>/d1.original.fstypes here.

[dambron]

@Sebastian-Roth said in FOG unable to capture/deploy resizeable images correctly.:

@dambron Ok, that all seems fine so far. I still can make heads or tails of this. Can you please do the debug capture again and step through till you see the message Processing Hard Disk: /dev/sda and then take a picture again.

As well please post the contents of /images/<IMAGENAME>/d1.original.fstypes here.

Processing Hard Disk: /dev/sda

d1.original.fstypes

/dev/sda1 ntfs

I feel bad for making you dig through all this but I really appreciate the time you’ve taken. If worse comes to worse I can always have my team change their process to always pull the image off of the smallest drive size we deploy on site to avoid this in the future, but honestly I’m just so curious as to why this isn’t working now. I feel like it was working previously, but maybe I just never ran into this particular situation.

[Quazz]

There was a bug in the inits that would cause issues with recording the wrong info about “fixed size partitions”. I believe 1.5.6 (just released!) contains the fix though. You’ll have to recapture the images though.

It was fixed in this PR, no? (the PR isn’t labelled that well, but basically the code hadn’t been updated in that file, but now we just read the info instead of running the same tests twice) https://github.com/FOGProject/fos/pull/24

The other user hasn’t reported back yet, but give 1.5.6 a go and let us know!

[dambron]

@Quazz

Wow so that’s funny, I was just following another thread about editing the inits but it was from 2017 or so. I randomly stumbled upon it while trying to find more information on my issue.

So, do you know if there is any way to update the inits without performing the 1.5.6 version update? I suppose I could wait until the weekend since we do half day Fridays all summer and then deploy and make sure everything is working, but I feel like it’s kind of a dicey time to be pushing an update (especially since it will be the first time I’m doing it on my own!).

[Quazz]

@dambron The script grabs the init from this url https://fogproject.org/inits/init.xz

Put it in /var/www/fog/service/ipxe

[dambron]

@Quazz said in FOG unable to capture/deploy resizeable images correctly.:

@dambron The script grabs the init from this url https://fogproject.org/inits/init.xz

Put it in /var/www/fog/service/ipxe

You are the greatest. I will let you know how it goes!

[Sebastian Roth]

@dambron Yeah, Quazz is totally right. We have updated the init files and I totally forgot to ask you to try out the most current ones (32 bit and 64 bit). Hope this will fix the issue for you.

[dambron]

@Sebastian-Roth said in FOG unable to capture/deploy resizeable images correctly.:

@dambron Yeah, Quazz is totally right. We have updated the init files and I totally forgot to ask you to try out the most current ones (32 bit and 64 bit). Hope this will fix the issue for you.

Thanks so much to both of you. I replaced the init file and everything is now working properly. Many thanks for your time and efforts.