Public bug reported:
piboot-try intermittently fails to validate/promote a newly staged
kernel/firmware update on Raspberry Pi 5 (Ubuntu 26.04, aarch64), with
two different failure signatures observed across two separate attempts
of the same update. Both times the system correctly and safely fell back
to the known-good boot assets (current/), so there is no data loss or
unbootable state — but the update never successfully promotes.
Environment
Hardware: Raspberry Pi 5
OS: Ubuntu 26.04 LTS (aarch64), installed via the official Raspberry Pi Ubuntu
image
Boot mechanism: piboot A/B tryboot scheme (/boot/firmware/current/,
/boot/firmware/new/, autoboot.txt with tryboot_a_b=1)
Update method: sudo apt update && sudo apt -y upgrade, followed by a manual
reboot
Filesystem: root on mmcblk0p2 (ext4), boot partition mmcblk0p1 (FAT32, label
system-boot)
Steps to reproduce
Run sudo apt update && sudo apt -y upgrade on a system with a kernel/firmware
update pending.
Reboot.
Bootloader stages the update into /boot/firmware/new/ and attempts a tryboot
test per the A/B scheme.
Expected behavior
The new boot assets are tested via tryboot, piboot-try-validate.service runs
successfully once the system reaches a working state, and the update is
promoted from new/ to current/.
Actual behavior
The tryboot test fails before validation can occur, and the system
automatically (and correctly) falls back to current/ on the next boot, marking
/boot/firmware/new/state as bad. This happened twice in a row, via sudo
piboot-try --reset-new + reboot, with two distinct failure causes:
Attempt 1 — local-fs.target dependency timeout
systemd[1]: dev-disk-by\x2dlabel-system\x2dboot.device: Job .../start failed
with result 'timeout'
systemd[1]: Dependency failed for local-fs.target - Local File Systems.
systemd[1]: Dependency failed for piboot-try-reboot.service
systemd[1]: piboot-try-reboot.service: Job piboot-try-reboot.service/start
failed with result 'dependency'
systemd[1]: Dependency failed for piboot-try-validate.service
systemd[1]: piboot-try-validate.service: Job piboot-try-validate.service/start
failed with result 'dependency'
systemd[1]: systemd-journal-flush.service: Failed with result 'timeout'
The boot partition device unit timed out waiting for mmcblk0p1 to become
available, which cascaded into local-fs.target failing. The partition
did become available a few seconds later (fsck and mount succeeded
shortly after), but local-fs.target remained marked failed for the rest
of the boot, which appears to have also blocked ssh.service and
docker.service/containerd.service from ever starting (no journal entries
for either unit that boot), even though the system otherwise reported
Startup finished.
Attempt 2 — D-Bus not available when piboot-try-reboot tried to trigger the
reboot
reboot[976]: Failed to connect to system scope bus via local transport: No such
file or directory
systemd[1]: piboot-try-reboot.service: Failed with result 'signal'
systemd-udevd[790]: Failed to remove file descriptor "config-serialization"
from the store, ignoring: Connection refused
This time the boot partition mounted fine, but piboot-try-reboot.service
(which needs to invoke a system reboot to enter tryboot mode) failed to
connect to the system D-Bus at the point it tried to do so.
Additional notes
sdhci-brcmstb 1001100000.mmc: error -EINVAL: invalid resource (null) appears in
dmesg on both failing and fully healthy boots, so it appears to be an
unrelated, benign message (likely tied to the onboard SDIO/WiFi controller,
mmc1) rather than the cause of either failure.
Given the two failures have different root causes (a slow device timeout vs. a
D-Bus availability race), this looks like a timing/ordering issue in the
piboot-try/flash-kernel boot-time tooling rather than a hardware fault — worth
checking the Requires=/After= ordering for piboot-try-reboot.service and
piboot-try-validate.service against local-fs.target and
dbus.service/dbus.socket.
Both times, the fallback-to-known-good behavior worked correctly and the system
remained fully usable afterward.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: flash-kernel (not installed)
ProcVersionSignature: Ubuntu 7.0.0-1014.14-raspi 7.0.6
Uname: Linux 7.0.0-1014-raspi aarch64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: arm64
CasperMD5CheckResult: unknown
CloudArchitecture: aarch64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: config-disk (/dev/mmcblk0p1)
Date: Sun Aug 23 13:46:43 2026
ProcEnviron:
LANG=C.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: flash-kernel
UpgradeStatus: Upgraded to resolute on 2026-05-22 (93 days ago)
** Affects: flash-kernel (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-bug arm64 resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2164854
Title:
piboot-try keeps failing and failing back to the known good state
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2164854/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
