Manually performed partitioning changes get reverted on reboot

Hello,

After speaking with some folks, we realized the resizefs or growpart modules are growing back the partitions on every reboot.

However, it should do so only when /var/lib/cloud/instance changes. In my case it never changed, I was using the same MAAS machine all the time. There could be a bug in the way it the instance value to previous values, causing it to think it is a new machine every time I reboot.

Cloud-init is the one performing the resize and MAAS images are based off the Ubuntu cloud images, it is more an issue with cloud-init and the cloud images than MAAS.

Hi Rodrigo,

Thanks for using cloud-init, and for filing this bug report!

> After speaking with some folks, we realized the resizefs or growpart modules are growing back the partitions on every reboot.

Yes, this is expected behaviour.

> However, it should do so only when /var/lib/cloud/instance changes.

What is the basis for this statement? Looking at the docs for growpart[0] and resizefs[1], they both document that they run "always" (i.e. every boot). Looking at the code, this has been the case since 2013 and 2012 respectively.

If you are looking for a way to disable the growpart behaviour, you may want to look at /etc/growroot-disabled in the docs[0].

I don't believe there's any cloud-init work here, so I'm going to mark this as Incomplete. Please feel free to set it back to New, with an explanatory comment, if you disagree!

Thanks!

Dan

[0] https://cloudinit.readthedocs.io/en/latest/topics/modules.html#growpart
[1] https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resizefs

You can disable this using cloudinit-userdata

For juju:

lathiat@optane ~$ cat userdata.yaml
cloudinit-userdata: |
  growpart:
    mode: off
lathiat@optane ~$ juju model-config userdata.yaml
lathiat@optane ~$

For MAAS, refer to here: https://discourse.maas.io/t/customizing-maas-deployments-with-cloud-init/165 - it's only possible with the MAAS CLI and not through the MAAS UI - if you want it to work with the MAAS UI I thin you need to edit the yaml templates on the MAAS machine but that's not really supported I don't think.

From what I observed when using this myself, MAAS seems to grow the filesystem to the actual configured size during deployment without cloud-inits help during boot (which is when it is often done for 'cloud' VMs). So disabling it should still get you the correct size, and prevent it growing into the rest of the partition.

As a hacky alternative if you can't disable growpart with the above steps - if you add another partition after the root filesystem, it will no longer grow into that space. So you could add for example a blank un-used partition taking up either a little space or the entire rest of the device. And then delete that and put whatever partitions you wanted there post-deployment.

Sounds like this is indeed an issue in MAAS then. MAAS should turn off growpart, since we know how big the disks are already and can set up the right partition size during installation.

Rodrigo, you can work around this bug by creating /etc/growroot-disabled. If that file is present, cloud-init won't resize the partition.

Moving cloud-init task to invalid, no bug/work for cloud-init.

Thanks folks, I was able to workaround the problem.

I agree that MAAS shoulnd't be resizing in this particular situation and growpart should be disabled by default.

MAAS would need to conditionalize this because in some cases you would want that behaviour, say deploying a Windows image, where it is dd based. On reboot you want cloudbase-init to resize the partition, something that curtin cannot do for Windows.

See comment #10 for solution direction.

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3422