resindataexpander: expand data part to max usable size on MBR

[jakogut]

MBR formatted disks are only capable of 32-bit addressing of sectors,
limiting disk usage to 2 TB. In cases where the full disk cannot be
utilized, expand the data partition to fill the usable space, and print
a message.

Change-type: patch
Signed-off-by: Joseph Kogut [email protected]

Related to: #2241

[resin-jenkins]

Can one of the admins verify this patch?

[alexgg]

Could you also please make separate previous commits to:

• Fix all previous shellcheck errors
• Reformat to use tabs instead of spaces (I use the following vim setting)

:set filetype=sh noexpandtab shiftwidth=4 tabstop=4 autoindent

[jakogut]

@balena-ci rebase

[jakogut]

@alexgg Good review, sorry I didn't catch those things before pushing!

[jakogut]

@balena-ci rebase

[jakogut]

@balena-ci rebase

[jakogut]

@alexgg Do we want to close this in favor of failing to resize the data partition on MBR partitioned disks > 2 TB? If so, I can rebase and push the shellcheck fixups separately.

[alexgg]

@jakogut separating the linter fixes is a good idea. With regards to this PR, I think the fix is a technical improvement, but it does not help the user realize they are using a DT with an MBR partition and that disks bigger than 2TB are not supported.
At least without the fix they would realize as the disk is unusable, while with the fix they might finish up in production with the wrong DT.
Maybe a middle ground is to apply the fix but to add a check that warns the user about the situation? I haven't thought through how this check would work though. Might be an arch call discussion.

[jakogut]

@balena-ci rebase

[jakogut]

@resin-jenkins retest this please

[ab77]

@jakogut @alexgg just wondering if this is blocked by anything?

[alexgg]

@ab77 it's just the discussion above about this patch not helping - the user has the wrong DT and the sooner they realize the better. So if we are going to expand anyway to make it work we better find a way to warn the user. We don't want this on a production device on the field.

[ab77]

@alexgg so this is superseded then by the new generic-amd64 DT?

I am the user by the way, at least one of them :)

[alexgg]

@ab77 yes, the generic-amd64 has a GPT partition table so it's the alternative for x86 architectures. In ARM, it would probably be generic-aarch64. I only expect to see >2TB in the server space, not on the embedded space for some years at least. Anyway, all new DTs should be GPT.

[ab77]

@alexgg perfect, do you have a sense when we will have a generic-amd64 image to deploy?