Dear Maintainer,

On launching a Debian 8.7 Marketplace AMI on AWS with a root volume larger 256GiB
growpart will fail to resize the root partition.

control: reassign -1 cloud-utils

Hi Steffen,

I was able to reproduce the bug and the logs follows as attachments.
This report being reassigned because it is not a bug on "cloud-init"
itself, but on "cloud-utils", as "growpart" is part of the later.

I think this may be related to the the "util-linux" version on Jessie,
as the problem is not present on Stretch (and the cloud-utils versions
on Jessie-Backports, used in the AMI, and Stretch are the same).
Anyway, I'm not sure and couldn't find the root cause yet, but this is
a known problem for at least a few months[1][2].

Any help in this regard is appreciated.

Regards,
Tiago.

[1]: https://stackoverflow.com/q/39920638
[2]: https://github.com/andsens/bootstrap-vz/issues/359

Since this is one of the top hits for this bug and it is still not resolved, I wanted to contribute an update of the state of things.

This bug still exists in Debian 10 (buster), but the limit seems to have changed from 250GB to 2TB. It appears to be fixed upstream. I'll show how I came to these conclusions so others can reproduce my findings.


This issue is the same in buster as was reported in CentOS 8 here: https://bugs.centos.org/view.php?id=17372


The error message I am receiving with a 10TB disk is "NOCHANGE: partition 2 is size 4293963776. it cannot be grown"

After a bit of searching, I found the repo from which the responsible code appears to originate:
https://github.com/canonical/cloud-utils/blob/master/bin/growpart#L390

max_end is set on line 356, which comes from dump_mod (all line numbers are from the repo linked above).

dump_mod comes from dump_out on line 343

dump_out comes from line 328, which comes from sfdisk, which comes from the linux-util package.

I have a test system which had a 10TB drive with three partitions (EFI, boot, root) on partitions 1, 2, and 3, respectively. Partition 3 was 4293963776 sectors, starting at 1003520 and last-lba was 21474836446.

I took a look at the /usr/bin/growpart on a fully patched buster system and found that it was truncating max_size as if it was msdos formatted (mine isn't, it is gpt).  This does not match what I am seeing on GitHub. I commented out the section in the script on my system that limited the size and it worked! The partition became 10TB.

So I believe this is fixed upstream and I'd love to help get the patched version accepted into buster. If anyone can let me know how I can help make this happen, please let me know.

Hi,

Thanks for the information.

Well, easy, just send a patch, and someone (probably me) will add it to
the current package, then ping the Stable release team to ask if they
find it acceptable for Buster.

Cheers,

Thomas Goirand

If there is a desire to only fix this >2TB disk bug and not the others, I've extracted the patch for the 2TB limit and am attaching it here.

Cheers,
Adam

Dear Debian cloud team,

Could you guys read the patch, at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868875#33

Do you think it should be merged ASAP, and then ask for cloud-utils to
be unblocked?

Release is coming, we'd better fix this quickly if we need to, and I
don't feel like doing it without a 2nd opinion on this. Your thoughts?

Cheers,

Thomas Goirand (zigo)

The patch looks right, and it matches the fixed version that's in bullseye.  I
didn't actually test a patched version of cloud-utils 0.29 though.

It seems like a straightforwrd fix, if you think it's worth a stable update.

Ross

Oh, I miss-read the bug, I thought it was for fixing cloud-utils in
Bullseye. Ok then, I'll see if I can this fixed in Buster. Thanks for
looking into it.

Cheers,

Thomas Goirand (zigo)

Hi,

IIUC we can mark this as done in Version: 0.31-1, which includes
upstream commit 98b048f9d2f4319689d46507537587d391e41332, am I right?

See: https://github.com/canonical/cloud-utils/commit/98b048f9d2f4

Cheers,

Paride