Comment 11 for bug 2003816

From cloud-init perspective, we have seen this too in our CI/CD integration runs on both GCP and Azure lunar daily images which allows cloud-init to resize2fs /dev/root on first boot, but also re-invokes resize2fs a second time to assert cloud-init can be re-run all boot stages without having to reboot[1] This 2nd run of cloud-init invokes resize2fs /dev/root a second time.

This failure is resize2fs a second time due to checksums is seen only on Azure lunar daily images containing linux-azure=5.19.0.1010.9 and e2fsprogs=1.47.0. e2fsprogs=1.47.0 was introduced in Azure daily lunar images on image version 23.04.202303170 (image version 23.04.202303170 allows multiple calls to resize2fs /dev/root without checksum errors)

GCP: CI/CD runners in cloud-init also started failing jobs on Mar 17th as well, presumably across the same image build update and introduction of esfsprogs=1.47.0 in lunar.

Our internal daily test runners track this failure signal well from daily image builds for Azure[2] and GCP lunar[3] giving us a good signal the the failure symptom below. We can ensure

 'cloudinit.subp.ProcessExecutionError: Unexpected error while running '
 'command.\n'
 "Command: ('resize2fs', '/dev/root')\n"
 'Exit code: 1\n'
 'Reason: -\n'
 "Stdout: Couldn't find valid filesystem superblock.\n"
 'Stderr: resize2fs 1.47.0 (5-Feb-2023)\n'
 ' resize2fs: Superblock checksum does not match superblock while '
 'trying to open /dev/root\n'

references:
[1] cloud-init integration test which triggers multiple resize2fs /dev/root calls https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/test_upgrade.py#L91-L105
[2] https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-lunar-azure/
[3] https://jenkins.canonical.com/server-team/view/cloud-init/job/cloud-init-integration-lunar-gce/