FOG unable to capture/deploy resizeable images correctly.

[dambron]

So I have been using FOG for quite a few years, although normally with support from a much more experience Linux administrator than myself, so please bare with me. Recently we had a large restructuring where I work and now I’m dealing with a much “broader” set of hardware, and this has caused a few image related issues. Previously all of my deployments were captured on 256GB SSD’s and then deployed either to the same, or on very rare occasion to a 500GB magnetic drive. I haven’t in years gone from something larger in drive size to something smaller. Well, now that is happening. I trained a coworker on FOG and the first thing he did was create an image on a 500GB drive and then try to deploy it to a 256GB SSD. The procedure fails and tells you that the target partition size is smaller than the source. I’ve tried it myself and even when selecting “Single Disk- Resizable” and “Everything” it captures the image fine, but is not actually able to distribute to a smaller drive than 500GB. I also tried deleting all recovery/secondary partitions inside Windows 10 and capturing/deploying it again but the same result happened. The image captures fine, but then tells me the target partition is smaller than the source.

Any advice or tips would be appreciated, and of course I can provide detailed logs, I just need to know where to look for them, because I am fairly clueless right now.

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

[Sebastian Roth]

@dambron said:

I’ve tried it myself and even when selecting “Single Disk- Resizable” and “Everything” it captures the image fine, but is not actually able to distribute to a smaller drive than 500GB.

Can you please post the contents of the following three text files of this image (/images/<IMAGENAME>/ on your FOG server): d1.fixed_size_partitions, d1.minimum.partitions and d1.partitions

[dambron]

Sure! So this is the latest iteration of the image, where I deleted all other partitions on the disk so it’s just the single partition.

d1.fixed_size_parititions

:1

d1.minimum.partitions

label: dos
label-id: 0x7bb39a2f
device: /dev/sda
unit: sectors

/dev/sda1 : start=      206848, size=   975588864, type=7, bootable

d1.partitions

label: dos
label-id: 0x7bb39a2f
device: /dev/sda
unit: sectors

/dev/sda1 : start=      206848, size=   975588864, type=7, bootable

Thanks for the quick response.

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