Failure to expand shrunken resizeable image from Linux machines

[Tom Elliott]

@sebastian-roth I agree, but data is hard to come by, and I don’t think we can come up with every case potential.

[george1421]

@xipher said in Failure to expand shrunken resizeable image from Linux machines:

@george1421 Close to my findings wherein the first partition (sda1) will grow proportionally, but the rest… no go.

If you create the same layout but have the root partition where you currently have the boot partition, it will grow the root and ‘work’ as it seems it would be intended.

If you were to make a home partition in the same place, it would grow but not the boot or root… etc

IMO In the case of Mint with the lvm. I would consider the /boot and [swap] partitions to be fixed in size. This would equate the System partition of Windows. In my ignorance I would have expected the disk layout to match the source image and have 15GB of air left in the target disk. Since LVM partition is copied as raw and both the /boot and [swap] were fixed.

My goal here was to see if I could come up with a way to extend the lvm disk.

[Tom Elliott]

@george1421 There’s already functions in place for the hopeful integration of LVM extending through fog (as well as imaging) though I’ve not made any major effort in actually getting this working. You’re more than welcome to have a go at it. The same resizing functions should work similarly. Would you be willing to re-update your init’s to the absolute latest using the same wget commands and seeing if things are a bit better for you?

[george1421]

@tom-elliott said in Failure to expand shrunken resizeable image from Linux machines:

I’ve tried for all I’m worth, but I’m only one man, sorry.

Tom, to be honest, as I posted before about 90% of the deployments are MS Windows, with about 8% Mac and the rest other bits (my feels like numbers). With MS doing its Win10 crap hopefully more will start to migrate to Linux based desktops. When issues arise you jump on them with both feet. The key is knowing about the issues to fix.

[george1421]

Just thinking about this. If it was me and I planned on deploying Linux client OS to target machines, I would not choose to use LVM (with expanding partitions or not). The issues is that FOG / partclone can only capture / deploy the image as raw. This is a slowest way of deploying the image. I would use native partitions on the disk.

Right now deploying that captured LM partition will take about 28 minutes to finish. The native partitions are much faster.

[Xipher]

@george1421 For my needs, I’m totally dropping LVM and agree, LVM really doesn’t seem to have a place in images at the moment.

[Sebastian Roth]

Thanks to @Tom-Elliott again for coming up with a fix so quickly! I am marking this solved then. But I still think having a testcase suite would be really good as we could make changes to the awk code, run the testcases and just be sure to not have it broken for other known cases. I think we could collect data from the community fairly easy as the information is already there (in d1.partitions that people have lying around on their FOG servers by the dozens)…