Who resizes the data-partition?

[macro]

We have a Debian image that we build with mkosi for UEFI. We convert this image with docker-mender-convert.sh and tried both configs debian-qemu_x86-64_config and generic_x86-64_hdd_config.

With both converted images, we have the issue of the data-partition not being grown to full size when simulating in QEMU. I discovered that systemd-firstboot can not start, because, apparently, /etc is moundet as read-only. Systemd-firstboot complains about not being able to set /etc/machine-id, as described in this ticket: systemd-firstboot service won't have any chance to run when booting with 'ro' · Issue #5562 · systemd/systemd · GitHub

As far as I’m aware, Mender completely overwrites / reconfigures the bootloader who sets the kernel parameters. However, I also found that the error about /etc being RO persists even when you remove ro from the kernel parameters.

But in any case, with or without ro, there is the report by systemd-growfs: “successfully resized “/data” to 128.0M bytes” – which indicates to me that, contrary to my believes, it is not systemd-firstboot who invokes growfs?

Anyways, growfs ignores that the virtual drive is larger, both when you enlarged it with qemu-img resize or when you use another qemu-machine to dd the menderized image onto a larger drive. lsblk, however, does successfully detect that the actual block-device is larger than the partitions.

This is why I assume that in our setup something must be relatively broken. Sorry for the chaos, but it seems we have multiple bugs at once.

Summarizing, my main questions are:

1. Why does mender-grub set the ro parameter?
2. Why might /etc still be detected to be read-only by systemd when you remove ro?
3. Why is our data-partition not grown to fill the whole block device?

I would be thankful for some tips where so search for errors.

Our systemd-version is 249, the underlying base system is Debian 11.

[kacf]

Since you are using mkosi, it probably means that grub is not installed, which means that mender-convert’s grub.d integration will be turned off. I wonder if this would not work better if it was on, especially the part about the unexpected ro filesystem.

Can you try making sure that the below packages are installed? And try to force grub.d integration to on by using MENDER_GRUB_D_INTEGRATION=y.

• grub-efi-amd64-signed
• grub-common
• grub2-common
• shim-signed

[macro]

I forgot to mention: Our buildscript and mender-convert script are almost completely identical with the ones published by mender here: mender-convert/generate-image.sh at master · mendersoftware/mender-convert · GitHub

I’ve installed said packages through the provisioner service and set the MENDER_GRUB_D_INTEGRATION flag in the config passed via mender-docker-convert. Unfortunately, the behavior is still unchanged.

The awkward thing is that growfs is executed in any case and never grows the partition to anything larger than 128MB, no matter how large the drive is.

[macro]

We more or less solved the machine-id issue. It is apparently some sort of problem with systemd:

Bug #1508766 “/etc/machine-id not created if missing” : Bugs : systemd package...

That’s good news. Now only the problem of growfs growing only to 128MB persists