Automatic partition resize prevents unlocking of encrypted root partition

[J-B Vosteen]

1. Tell us your cloud provider

None (it is an Ubuntu Server image running on a Raspberry Pi 4b)

2. Any appropriate cloud-init configuration you can provide us

None

I modified the Ubuntu Server image so the root partition is encrypted. Since the Raspberry Pi 4b does not have hardware acceleration for AES I use adiantum for encryption. To take full advantage of its advertised performance gains, I used '--sector-size 4096' with cryptsetup. A requirement for this parameter to work is that the containing partition is aligned, at its start and end, to sector counts evenly divisible by 8.

When unlocking the partition, cryptsetup does apperently check if partition boundaries are evenly divisible by 8. On the first boot this is true, for any consecutive it is not. To me it seems cloud-init resizes the root partition (through growpart) to the maximum size possible. Sadly by doing so it interferes with the peculiar alignment requirements of cryptsetup.

It would be great if the root partition could end at an 1MiB boundary after resize.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: cloud-init 22.2-0ubuntu1~22.04.3
ProcVersionSignature: User Name 5.15.0-1015.17-raspi 5.15.53
Uname: Linux 5.15.0-1015-raspi aarch64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: arm64
CasperMD5CheckResult: unknown
Date: Mon Oct 3 14:31:03 2022
PackageArchitecture: all
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)
user_data.txt: Error: [Errno 13] Permission denied: '/var/lib/cloud/instance/user-data.txt'

[James Falcon (falcojr)]

I'll raise an issue over on the cloud-utils issues page[1] to add some kind of alignment flag to growpart and then if that merges, we can add a growpart config option in cloud-init to use it. However, growpart will grow the underlying partition, but in order to take advantage of the increased size, the filesystem itself also needs to be resized. That can only happen once the encrypted partition has been unlocked. Cloud-init can only do that if it has access to a key to unlock the partition during early boot, which would have to be baked into the image being launched[2].

Unless you plan on modifying an image in this manner, I think your best bet is to simply disable growpart via userdata[3]:

#cloud-config
growpart:
  mode: off

[1]: https://github.com/canonical/cloud-utils/issues
[2]: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_growpart.py#L383
[3]: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart