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
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:
- Why does mender-grub set the
- Why might /etc still be detected to be read-only by systemd when you remove
- 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.