# Who resizes the data-partition? **URL:** \ **Category:** General Discussions\ **Created:** [September 24, 2022, 8:41am UTC](https://hub.mender.io/t/who-resizes-the-data-partition/5274 "2022-09-24T08:41:28Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![macro](https://avatars.discourse-cdn.com/v4/letter/m/ba8739/32.png) [@macro](https://hub.mender.io/u/macro)\ **Post date:** [September 24, 2022, 8:41am UTC](https://hub.mender.io/t/who-resizes-the-data-partition/5274/1 "2022-09-24T08:41:28Z")
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](https://github.com/systemd/systemd/issues/5562) 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. ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [September 28, 2022, 5:53am UTC](https://hub.mender.io/t/who-resizes-the-data-partition/5274/2 "2022-09-28T05:53:13Z")
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` ---
**Author:** ![macro](https://avatars.discourse-cdn.com/v4/letter/m/ba8739/32.png) [@macro](https://hub.mender.io/u/macro)\ **Post date:** [September 28, 2022, 10:21am UTC](https://hub.mender.io/t/who-resizes-the-data-partition/5274/3 "2022-09-28T10:21:00Z")
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](https://github.com/mendersoftware/mender-convert/blob/master/scripts/test/generate-image.sh) 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. ![Screenshot from 2022-09-28 12-19-58](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/5/59a31459091c4769c1bb9d9cc3c92300ea1689d6.png) ![Screenshot from 2022-09-28 12-18-51](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/e/eb88ee9ff2a0577ca94907617767e84fb5b47bf9.png) ---
**Author:** ![macro](https://avatars.discourse-cdn.com/v4/letter/m/ba8739/32.png) [@macro](https://hub.mender.io/u/macro)\ **Post date:** [September 28, 2022, 2:20pm UTC](https://hub.mender.io/t/who-resizes-the-data-partition/5274/4 "2022-09-28T14:20:06Z")
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...](https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766)** > > If /etc/machine-id is missing at boot, systemd does not create it. > > I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. > > I'm likewise unsure why it doesn't work, but this... That’s good news. Now only the problem of growfs growing only to 128MB persists