CM4: concurrent failing re-occuring bootstrapping attempts

[EndOfTheSpline]

Hello,

I've been very excited when I found this repository because it seems like exactly what I was looking for - but I'm having some difficulty getting it to run.

Setup

• RPi 5 with 16 GB RAM and a 32BG SD-Card as provisioning host
  • original 27W power supply
  • running vanilla Raspberry Pi OS Trixie, flashed yesterday with the RPI Imager
  • apt-get update && apt-get -y full-upgrade performed as first step
• RPi CM4 IO Board with a 12V power supply attached to it
• RPI CM4 2 GB RAM 8GB eMMC as the target.
• An USB-A to microUSB cable connected between the IO board and the power supply
• rpi-sb-provisioner 2.1.1
  • downloaded from GitHub, installed with dpkg -i
  • installed libjsoncpp25 from the Debian bookworm repository
• Configured for eMMC and family=4
• naked provisioning (for the time being - eventually I'd like to go for secure boot, but I want to get the basics done first)
• The most recent Pi4 firmware is selected (2025-11-05)
• A pi-gen generated image (which shouldn't matter at this point)

Issue

I set the CM4 onto the IO board, attach the power supply and the USB cable to my Windows computer/the RPi without the provisioning installed. rpiboot loads successfully and completes with just rpiboot or rpiboot -d recovery.

As soon as I install rpi-sb-provisioner, even if I disable it giving the command from the README (sudo systemctl mask --runtime rpi-sb-triage@.service), it'll run the bootstrap command (which I suppose is the aforementioned fastboot?) again and again, even though the bootstrapping is still in progress. This behaviour happens whether the service is disabled or not, so there's not really a change as far as I can tell.

The logs are all more or less the same:

bootstrap-failed.log
bootstrap-success.log

The one thing I notice when running rpi-sb-provisioner (which did not happen before I've installed it when I've tried it with just rpiboot) is that according to dmesg -wH, the USB device keeps connecting/disconnecting:

dmesg.log

Looking at the log files, it seems to spawn one new process every five-or-so seconds. Every attempt that runs after the previous successful attempt ran seems to proceed, the others fail. It's usually every fourth:

[S] 001-002: 2025-11-26 03:57:13 + DEBUG=
[F] 001-003: 2025-11-26 03:57:16 + DEBUG=
[F] 001-004: 2025-11-26 03:57:20 + DEBUG=
[F] 001-005: 2025-11-26 03:57:25 + DEBUG=
[S] 001-002: 2025-11-26 03:57:31 Second stage boot server done
[S] 001-006: 2025-11-26 03:57:38 + DEBUG=

This behaviour seems to be somewhat consistent whether I power cycle the power supply, or disconnect/re-connect the USB from the RPi 5. I've tried different USB slots, and cables, but the result seems more or less the same.

I just can't seem to get it to work and would appreciate any help.

[EndOfTheSpline]

I've just tried a few more things, but the results were the same:

• Flashed the SD card of the RPi5 with bookworm and tried 2.1.1
• Compiled the current master branch (21a5042) on the same (bookworm) OS (using --force-depends to install the resulting deb)

I had kind of hoped that the latest commit might be related to this issue, but it seems this was not the case :(

[tdewey-rpi]

it'll run the bootstrap command (which I suppose is the aforementioned fastboot?) again and again, even though the bootstrapping is still in progress.

This is expected behaviour. Prior to the bootstrap service running, it has no way of knowing which of the 4 USB descriptors the device publishes is correct - so we launch a bootstrap for all of them, and let the correct endpoint win.