tryboot automatic rollback behavior after failed kernel upgrade

The tryboot feature cannot provide genuine, unattended rollback safety for kernel upgrades in its default state. It is a bootloader-level mechanism for switching configurations, not a system-wide atomic update tool. Without a coordinated A/B root filesystem or snapshotting mechanism, tryboot alone is a manual recovery tool rather than an automated safety net.

Analysis of Rollback Behavior

The tryboot flag instructs the bootloader to attempt booting from an alternate configuration. However, the following gaps prevent it from functioning as an automatic rollback system for standard Raspberry Pi OS updates:

• Lack of Automatic Detection: The bootloader does not inherently know if a kernel "failed" (e.g., a kernel panic). It only knows if the boot process was interrupted or if the tryboot flag was set. To automate this, a hardware watchdog timer must be configured to trigger a reboot if the system fails to reach a "healthy" state.
• No Default A/B Partitioning: Standard Raspberry Pi OS packaging does not populate a secondary boot partition. The alternate configuration must be manually staged by the operator or a custom script.
• Root Filesystem Mismatch: This is the most critical failure point. tryboot switches the kernel and boot config, but not the root filesystem. If a kernel upgrade also updated /lib/modules or critical userspace libraries, rolling back the kernel via tryboot will result in a version mismatch, likely leading to a failure to mount the rootfs or a failure to load essential drivers.

Requirements for an Unattended Pipeline

To transform tryboot into a functional part of an unattended upgrade pipeline, you would need to implement the following tooling:

1. A/B Root Partitioning: Use a tool like RAUC or a custom LUKS/LVM snapshot system to ensure the root filesystem version matches the kernel version being booted.
2. Watchdog Integration: Configure the BCM2835/2711 hardware watchdog. The system must "kick" the watchdog only after a successful boot and a verified health check (e.g., SSH availability or a specific service start).
3. Transaction State Coordinator: A wrapper for dpkg or apt that:
   • Backs up the current boot config to the alternate slot.
   • Sets the tryboot flag.
   • Reboots and waits for the health check to clear the flag upon success.

Verification Commands

To verify your current bootloader configuration and check if tryboot is active, use:

# View current bootloader configuration
vcgencmd bootloader_config

Note: If you are using a custom rootfs overlay or a read-only filesystem, please specify the implementation, as this changes how the transaction state must be coordinated.