Yep, There's two bugs here. I'll make this one the 'resize' bug and raise another for the growpart failure once I've worked out what is going on there.
My initial thoughts was to have cc_resize_fs.py check the existing filesystem to see what its limits were and then resize to the smaller of those limits or the partition size - rather than failing horribly. But it doesn't appear to be entirely trivial to work out what the maximum filesystem size is - even though mkfs.ext4 tells you when the filesystem is created. In my use case we've just launched terabyte disks on the Brightbox Cloud. Launching those with an ubuntu image created using default mkfs.ext4 parameters is what is causing these faults. (Note that they are not the standard images, but are built with live-build in a similar manner). ** Summary changed: - growpart and resize2fs fail with very large disks + resize2fs fail with very large disks ** Summary changed: - resize2fs fail with very large disks + resize2fs fail with very large disks from small source image -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/955272 Title: resize2fs fail with very large disks from small source image To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/955272/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
