Summary
bootc-generic-growpart.service fails on every boot when the root filesystem is
on an md (software RAID) device. It derives the partition number by reading
/sys/class/block/<name>/partition, which an md device does not have.
Not fatal — the rest of the system comes up and works — but the unit is
permanently failed, so systemctl is-system-running reports degraded on every
such machine.
Versions
bootc 1.16.10
- Base image
quay.io/fedora/fedora-bootc:44
- Installed with Anaconda (
anaconda-iso from bootc-image-builder), kickstart
below
Reproducer
Kickstart fragment — RAID1 root and RAID1 /boot, with a plain (non-RAID) ESP
on the first disk:
clearpart --all --initlabel --disklabel=gpt
ignoredisk --only-use=sda,sdb
part /boot/efi --fstype=efi --size=600 --ondisk=sda
part raid.11 --size=2048 --ondisk=sda --fstype=mdmember
part raid.12 --size=2048 --ondisk=sdb --fstype=mdmember
raid /boot --level=RAID1 --device=boot --fstype=ext4 raid.11 raid.12
part raid.21 --size=16384 --ondisk=sda --fstype=mdmember
part raid.22 --size=16384 --ondisk=sdb --fstype=mdmember
raid / --level=RAID1 --device=root --fstype=ext4 raid.21 raid.22
The install itself succeeds and the machine boots normally.
Observed
× bootc-generic-growpart.service - Bootc Fallback Root Filesystem Grow
Loaded: loaded (/usr/lib/systemd/system/bootc-generic-growpart.service; static)
Active: failed (Result: exit-code)
Process: 1014 ExecStart=/usr/libexec/bootc-generic-growpart (code=exited, status=1/FAILURE)
bootc-generic-growpart[1014]: Backing device: /dev/md126
bootc-generic-growpart[1018]: cat: /sys/class/block/md126/partition: No such file or directory
systemd[1]: bootc-generic-growpart.service: Main process exited, code=exited, status=1/FAILURE
Layout at the time:
md126 : active raid1 sda3[0] sdb2[1]
2094080 blocks super 1.2 [2/2] [UU] -> /boot
md127 : active raid1 sda2[0] sdb1[1]
16759808 blocks super 1.2 [2/2] [UU] -> /sysroot
$ systemctl is-system-running
degraded
$ systemctl list-units --state=failed --no-legend
● bootc-generic-growpart.service loaded failed failed Bootc Fallback Root Filesystem Grow
Expected
Either grow the array's underlying member partition, or recognise that the
backing device is not a partition and exit successfully with a log line saying
growing was skipped. A permanently failed unit on an otherwise healthy machine
makes degraded useless as a signal.
Related
The same /sys/class/block/<name>/partition assumption appears in bootupd,
where it is fatal rather than cosmetic: an install with the ESP itself on mdraid
fails at bootupctl backend install with
Failed to read /sys/class/block/md125/partition. That is
#947, open since December
2024. This report is the non-fatal sibling, and is worth noting only because two
independent components make the same assumption.
Workaround
Size the root array explicitly in the kickstart rather than relying on
--grow, so nothing is lost by growpart not running.
Context
Found while verifying whether a bootc install onto an mdraid root works end to
end. It does, including booting from the surviving disk after detaching the
first one — this unit is the only thing left failing.
Summary
bootc-generic-growpart.servicefails on every boot when the root filesystem ison an md (software RAID) device. It derives the partition number by reading
/sys/class/block/<name>/partition, which an md device does not have.Not fatal — the rest of the system comes up and works — but the unit is
permanently failed, so
systemctl is-system-runningreportsdegradedon everysuch machine.
Versions
bootc 1.16.10quay.io/fedora/fedora-bootc:44anaconda-isofrom bootc-image-builder), kickstartbelow
Reproducer
Kickstart fragment — RAID1 root and RAID1
/boot, with a plain (non-RAID) ESPon the first disk:
The install itself succeeds and the machine boots normally.
Observed
Layout at the time:
Expected
Either grow the array's underlying member partition, or recognise that the
backing device is not a partition and exit successfully with a log line saying
growing was skipped. A permanently failed unit on an otherwise healthy machine
makes
degradeduseless as a signal.Related
The same
/sys/class/block/<name>/partitionassumption appears inbootupd,where it is fatal rather than cosmetic: an install with the ESP itself on mdraid
fails at
bootupctl backend installwithFailed to read /sys/class/block/md125/partition. That is#947, open since December
2024. This report is the non-fatal sibling, and is worth noting only because two
independent components make the same assumption.
Workaround
Size the root array explicitly in the kickstart rather than relying on
--grow, so nothing is lost by growpart not running.Context
Found while verifying whether a bootc install onto an mdraid root works end to
end. It does, including booting from the surviving disk after detaching the
first one — this unit is the only thing left failing.