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. -- Sent from my iPod. Please excuse my brevity.
