Posts made by 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.

@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

@tom-elliott

Ran the two commands in your prior post as root:

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

Recaptured all 3 images, then casted them to the test system one after the other and recorded the results.

Didn’t re-run the installer or anything else, system wasn’t rebooted, etc, pretty much just replaced the init per the above command provided, recaptured, recast.

I could try providing a VM image of one of the systems I’m capturing from that exhibits the issue? Could provide the actual images too.

@tom-elliott Sorry it took so long, I put the new init in, but the results were identical sadly :C

Also, totally agree on the SWAP partition issue, its a change I’ll make on the client to capture.

Ok, want to break down the results in the same sort of output I’m seeing used here for the source and destination of each attempt

Destination is always a 75gb machine which is always a bigger disk. The ‘smaller disk’ restore issue I think is already identified?

This is the ‘custom’ partitioned layout I was using yesterday which caused a problem:

Source:

Destination:

This is the ‘default’ layout Mint Mate 18.2 produces from its installer when LVM is selected:

Source:

Destination:

This is the ‘working’ solution wherein the root partition is the first partition on the drive:

Source:

Destination:

Something I noticed on all the machines though was that the SWAP partition ONLY mounted on the LVM destination machine…!? All other attempts without LVM lead to the destination machine not mounting its swap, really weird…

Hope this helps understand what I’m running into and I’ll try the patched init today, though I have to run off for a bit at the moment, sorry!

@tom-elliott I’ll give it a shot today

Going to post up the screenshots of the output in the same style everyone else is first though to try and help explain and identify the original issue better, want to try and make sure everyone is on the same page by using the same style of output.

OK, so, after a fair bit of testing and retesting, here is what I’ve found out.

First of all, the following image gallery I created of the issue explains things well:

---

http://imgur.com/a/2PAWT

---

The TL;DR version is this:

LVM breaks things something /fierce/ with Mint’s default layout. If you choose to use LVM and don’t set a custom partition layout, what you get from the 18.2 installer is whats in the screenshot and it will not expand properly.

Having the root partition anywhere but as the first and primary partition of the drive makes things break. In my case, the SWAP partition was always first in my images.

Having the root partition as the first and primary partition makes the expansion work, almost 100%, it left some space but its good enough for right now.

Important Note: In my testing tonight I ended up using FOG 1.5 RC5 since I /just/ rebuilt in tonight to do this testing. Prior testing was performed on FOG 1.4.4 which for me was producing stranger results than these.

Is this intended functionality?

@george1421 The whole ‘going to a smaller disk’ thing seems to be in relation to offsets being passed that exceed the ‘physical’ dimensions of the drive being restored to, see this prior gallery for the errors related.

http://imgur.com/a/LLH0m

@tom-elliott

I was using a 100gb disk in my VM environment when I was testing the 50gb captured drive.

I’m recreating my test environment now virtually, though I do have the following pictures from a more ‘meat-space’ environment I was working with today…

http://imgur.com/a/M6lu1

That was testing a 128gb drive to a 320gb drive, the picture on the bottom shows the settings for the image.

Sorry that they’re actual pictures, the system doing the images is not connected to the network, internet, etc and I didn’t have a flash drive to bring back with me at the time.

@george1421 keen to hear what you find! I’ll take some pictures of what I run into myself, source material and what I get in the end.

Also, didn’t mean to sound off color with the Windows comment, just genuine curiosity if I had the wrong idea on things, bad tone on my part.

@george1421 all drives are AOK, SMART checked, etc, I’ve tried it after building a dozen or so images now and probably pulled it down a hundred times across a plethora of devices, from SSD’s to good ol’ spinning rust.

I’ve tried to create custom partition schemes that are just big enough to build the image for capture, I’ve tried to leave it using 100% of the drive

I have a VM infrastructure at home when I’m working on this there to try and resolve the issue, but no access to one when working on the problem in the field.

The only commonality at the moment is that it’s Linux Mint 18.2 x64 being captured, and always with a swap at the start of the drive, then two logical partitions on a single extent after that.

@george1421 your Windows centric response actually begs a question.

Since I’m deploying Linux images, is there less support for doing this than there is for Windows?

I’ve built images with and without using lvm on the captured host, thinking it was that, but now I’m starting to think that the support for this feature and people talking about it are deploying Windows, not Linux…?

Not sure what else to provide to assist with this, I’ve moved on from testing with VM images to mass physical image testing, however when I capture from a ‘live’ physical machine then cast the image to another machine with a larger drive, there is still no expansion performed…

Was thinking FOG would be my silver bullet, but I’m totally at a loss for what I’m doing wrong after reading everything I can on the subject, as far as I can tell it’s a bug? Unintended functionality failure…?

It’s very frustrating to image a few systems with renewed confidence that a change I’ve made might have resolved it, only to see a partition barley a few gb in size, almost 100% used, and 99% of the drive free and not partitioned

@tom-elliott I captured every step this time, here is a small album of a screenshot for each step in the imaging process from before, to during, to after

http://imgur.com/a/LLH0m

@tom-elliott Not sure I follow, sorry!

I didn’t see the output you were looking for during the process, I did capture just about the whole thing in the rest of the pictures included in the link below the picture of my prior reply.

I’m not /super/ familiar with FOG yet…

@tom-elliott I think this is what you are looking for?

Here’s a little folder with more errors I captured during the process…

https://rareroute.com/files/

Here is the output after recapturing this morning per your request:

[root@localhost images]# cat /images/Minttest1/d1.fixed_size_partitions
:2:5
[root@localhost images]# cat /images/Minttest1/d1.partitions
label: dos
label-id: 0xb67edb1f
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 102760448, type=83, bootable
/dev/sda2 : start= 102764542, size= 2091010, type=5
/dev/sda5 : start= 102764544, size= 2091008, type=82
[root@localhost images]# cat /images/Minttest1/d1.minimum.partitions
label: dos
label-id: 0xb67edb1f
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 11838052, type=83, bootable
/dev/sda2 : start= 102764542, size= 2091010, type=5
/dev/sda5 : start= 102764544, size= 2091008, type=82
[root@localhost images]# cat /images/Minttest1/d1.original.fstypes
/dev/sda1 extfs

Server

• FOG Version: 1.4.4
• OS: CentOS 7 X64

Client

• Service Version: ?
• OS: Linux Mint 18.1

Description

I’ve been trying to capture an image of this system (it has about 5~gb of used space on a 50gb drive) and then cast it back to two more systems, one with a 30gb drive, one with a 100gb drive.

The image I captured is marked resizeable, and during the capture the drive is successfully shrunk to about the same 5gb of space thats on it, however when its ‘cast’ back onto any system, the drive is not expanded, it stays shrunk leaving massive amounts of free space.

Even if I edit the “fixed size partitions” to tell it that the partition in question shouldn’t be a fixed size, it won’t realize it.

So far every linux capture/cast I’ve tried has worked this same way, none of them ‘re-expand’ to fill the ‘free space’, I’ve tried with and without using LVM on the machines I’m capturing from, etc.

I’ve got no idea what I’m doing wrong here… I’m going to venture that this is some sort of bug?