Images not properly expanding after update from Trunk

[wbtech]

We recently pulled down the latest FOG build (8038 as of the moment) and noticed our image partitions weren’t properly expanding. Our table had ext4 at the start followed by our swap partition and after image the ext4 didn’t expand to fill the drive. The image is marked as single disk resizable which has worked flawlessly in the past.

I don’t believe it’s a corrupted image as we’ve imaged about 1000+ machines with this image, but just to be sure, I captured a clean Ubuntu 14.04 and 16.04 image (via VirtualBox) and ran into the same problem.

I did notice during one of the deployments an error prior to PartClone starting stating “Error on Logical Partition”

If anyone has any suggestions, please send them my way.

Thanks,
Aaron

[Quazz]

Wait, they’re supposed to expand automagically? Here I was using scripts to expand it at first boot.

[wbtech]

Yessir, we have a pretty big deployment of Linux machines and up until recently they expanded without issue.

[wbtech]

I snapped some screenshots.

Here’s a machine imaged last week:

Here’s one from today:

[Wayne Workman]

@wbtech What version of FOG Trunk were you using before the update?

[wbtech]

@Wayne-Workman I can’t remember the exact version, but it would have been around the first week of May.

[wbtech]

@Wayne-Workman I just tried setting the image to only upload the ext4 partition and it failed shortly after an error came up. I was able to snag a quick screenshot.
It may be a totally unrelated issue, but I figured id report it either way.

[Sebastian Roth]

@wbtech Only a couple days ago Tom has tuned the recognition algorithm to better find windows boot partitions which we can’t resize or move. Seems like you found an issue with that. While I am sure @Tom-Elliott can fix this error you are seeing I am as well wondering about it saying Resizing extfs volume (/dev/sda5). On the pictures you posted sda5 is always swap. I am pretty sure we don’t resize (or even capture) swap partitions).

Can you please do a debug upload (schedule a normal upload but just before you click create task select the checkbox for debug mode) and run sfdisk -d /dev/sda before starting the upload job (using the command fog). Please take a picture and post here.

[wbtech]

@Sebastian-Roth Great, I’ll do whatever I can to assist!

On the partition thing, that’s my fault. I fired up the wrong vm where I had tried switching the ext and swap partitions to see if it would expand.

[Sebastian Roth]

@wbtech said:

On the partition thing, that’s my fault. I fired up the wrong vm where I had tried switching the ext and swap partitions to see if it would expand.

Ah well, good to know! Thanks for clarifying. I’ll wait till you upload the sfdisk picture then.

[wbtech]

@Sebastian-Roth Here’s a screenshot:

[Sebastian Roth]

@wbtech You need to hit ENTER twice first till you get to a proper linux shell. Then run the command sfdisk -d /dev/sda

[wbtech]

@Sebastian-Roth

[Sebastian Roth]

@wbtech Sorry but I need a bit more time. Will get back to you about this soon.

[wbtech]

@Sebastian-Roth Hey Sebastian, I know you guys are probably super busy, but I just wanted to check in and see if any progress was made on this? or if you need any more info from me.

[Sebastian Roth]

@wbtech Thanks a lot for posting again. Seems like I have lost sight of this. Will get back to you soon!

[Tom Elliott]

@Sebastian-Roth I think this is to be somewhat expected.

We only extend the drive for “additional” partitions if there’s more than one partition AND that partition is not the first partition (as we have to guess that the first partition is the boot volume.

I can probably fix this relatively easily on the upload, but it would require the upload be uploaded again. A suggestion, I suppose, would be to look at the file d1.fixed_size_partitions and remove the 1: that’s probably sitting there. I don’t think this will enable extending though as the d1.minimum.partitions AND the d1.partitions files would not have changed at all.

[Sebastian Roth]

@wbtech Sorry for the delay again. Just too many things happening right now.

The latest picture you posted, is that on a system where the partition layout seems fine when you look at it in the gui?? I don’t think this is the case if I get the maths correct: size = 16775168 sectors * 512 byte per sector / 1024 / 1024 / 1024 -> roughly 8 GB (sda5/swap seems to be half that size). This does not match any of the pictures you posted!

Unfortunately I need to ask you to do this again. Get up a system that has the partition layout displayed correct in the gui and schedule a debug upload. But before actually starting the upload run sfdisk -d /dev/sda. Then do the upload and pay attention to the part where it says “Setting up any additional fixed parts”. Do you still get the syntax error message?

You might want to upgrade to the very latest version just to make sure this is still happing with the latest trunk version.

PS: Will be away for a couple of days and won’t be able to respond till the 7th of July. I am really sorry this is taking such a long time. Hope we can find and fix this soon after I got back!

[wbtech]

@Sebastian-Roth Yeah, that’s the VM I build the images on. I apologize, I misread your request.

On the plus side, I just did an upgrade from the trunk and everything worked perfectly. I was able to capture and deploy an image and everything expanded properly.

I really appreciate the work that you guys put into FOG, it’s a phenomenal project! I owe you guys a beer!

[Sebastian Roth]

@wbtech said:

On the plus side, I just did an upgrade from the trunk and everything worked perfectly. I was able to capture and deploy an image and everything expanded properly.

Great to hear. So I guess you had a “buggy” version of the inits in place, something we already fixed along the way.

I owe you guys a beer!

I think this is number three or four on my list. Should start to think about getting on a plane to visit all those people at some point… haha.