What Is systemd-growfs?
systemd-growfs is a service built into systemd (version 236 and later) that automatically expands a filesystem to fill the available space of its underlying block device at boot time. It is most commonly used with single-board computers, embedded systems, and industrial PCs where a golden image is flashed to an SD card, eMMC, or SSD and then needs to occupy the full capacity of that storage on first boot — without manual partitioning or resize2fs commands.
The mechanism works through a generator that systemd runs early in the boot process. It inspects the root filesystem (or any filesystem marked with the x-systemd.growfs mount option in /etc/fstab), determines the size of the parent block device, and issues an online resize request to the kernel. For ext4 this uses the EXT4_IOC_RESIZE_FS ioctl; for XFS it uses XFS_IOC_FSGEOMETRY and the associated grow operations; btrfs and other filesystems have their own kernel-side support.
How the Expansion Is Triggered
There are two common activation paths. The first is automatic: when the root filesystem is mounted and the kernel command line or fstab indicates growth is desired, systemd-growfs@.service runs and expands the filesystem. The second is explicit: adding x-systemd.growfs to a mount unit's options in /etc/fstab tells systemd to grow that specific filesystem once it is mounted.
| Filesystem | Grow Support | Notes |
|---|---|---|
| ext4 | Yes | Online resize via kernel ioctl; no unmount required |
| XFS | Yes | Must be mounted; grows to device end |
| btrfs | Yes | Device add/resize semantics differ; use btrfs filesystem resize |
| f2fs | Yes | Supported through the same generator |
| vfat/exFAT | No | Fixed-size by design; not growable |
The partition itself must also be expanded first. On a freshly flashed image, the partition table often defines a root partition smaller than the physical device. Tools such as growpart (from cloud-utils) or parted/sfdisk extend the partition, and systemd-growfs then extends the filesystem to match. Many distributions chain these together with a first-boot script or a systemd unit that runs growpart before the growfs service.
Use Cases and Applications
This pattern is extremely common in fleet deployments of industrial computers, thin clients, and edge devices. A manufacturer flashes one master image — say a 16 GB image — onto devices with 64 GB, 128 GB, or 1 TB SSDs. On first power-up, systemd-growfs (often paired with growpart) expands the root filesystem so the full storage capacity is usable for logs, databases, container images, or application data.
It is equally valuable in kiosk and digital-signage deployments, where devices are imaged in bulk and then field-installed. Without automated growth, every unit would need manual intervention to reclaim unused disk space, which is impractical at scale. The same applies to IoT gateways and industrial panel PCs running Linux, where unattended provisioning is the norm.
Best Practices
Keep the root partition's initial size modest so the image flashes quickly, then let growfs handle the rest. Ensure the kernel and initramfs include the necessary filesystem modules. Verify that systemd-growfs@.service is enabled and that your fstab uses the x-systemd.growfs option where appropriate. Test the full first-boot sequence on the actual target hardware, since partition-table quirks and eMMC vs. NVMe behaviour can differ. Always keep a recovery path — a serial console or SSH — in case the resize fails.
Thinvent Products Featuring This Technology
Thinvent's industrial computers, mini PCs, thin clients, and all-in-one PCs run Linux distributions such as Ubuntu and Thinux™ Embedded Linux that support systemd-growfs out of the box. Models like the IPC3 with Intel® Core™ i3-1215U processors and high-capacity SSDs can be provisioned with a single master image and expanded automatically on first boot, making large-scale, unattended deployment straightforward for OEMs, system integrators, and enterprises.
