Newly flashhed Ubuntu not launching

Canonical Ubuntu Ubuntu OS issues
1

[SOLVED] RUBIK Pi 3 reboot loop ~14s into Ubuntu 24.04 boot — cause is brcmfmac Wi-Fi driver, not RPMB/UFS

TL;DR

If your RUBIK Pi 3 silently hard-resets partway through Ubuntu boot (no panic, no oops, no call trace) and you’re staring at scary RPMB ReadCounterPkt failed / ufs_error_log: 252 messages in the UEFI log — those UEFI messages are almost certainly not your problem. They appear on healthy boards too.

In my case the board reset the instant the Broadcom Wi-Fi driver loaded firmware. Booting with modprobe.blacklist=brcmfmac,brcmfmac_wcc,brcmutil gave an immediate clean boot to a login prompt.

Do not reach for RPMB key provisioning, --allow-fusing, or --finalize-provisioning to fix this. Those are irreversible and irrelevant here.

Symptoms

Board: RUBIK Pi 3 (QCM6490), Ubuntu 24.04 (ubuntu-24.04-preinstalled-server-arm64+rubikpi3), kernel 6.8.0-1064-qcom. Powered by the official 12V/3A supply.

UEFI/XBL serial log showed all of this on every boot:


ufs_error_log: 252

RPMB ReadCounterPkt failed, Result = 6

MountRequiredFatPartitions: OsTrialBootStatus read failed, status = 0xE

TransitionNhlosFromPostUpdateToBoot: Failed to read OsTrialBootStatus. Status 0xE

Could not find 'BootOrder' variable

tz_armv8_smc_call failed, TzStatus = 0xFFFFFFFF, SmcId = 0x32000105

Failed to start featenabler_a TA, status = 14

LoadImageFromPartitionUsingGuid Failed: 14

DtPlatformLoadDtbBlob qclinux_fit.img Loading Failed status=0xE

UEFI reached GRUB 2.12 fine. The kernel then booted a long way — root filesystem mounted, systemd-fsck-root passed, systemd PID 1 came up and started dozens of units — and then the board hard-reset back to UEFI at ~14.5s, over and over.

The red herrings that cost me hours

Chasing the UEFI messages is the trap. Specifically:

  • RPMB ReadCounterPkt failed, Result = 6 and ufs_error_log: 252 are benign here. I found a Critical Link MitySOM-QC6490 thread with a boot log matching mine line-for-line, on hardware that turned out to be fine. Their conclusion was also “not RPMB, not provisioning.”

  • qcom_scm: qseecom: untested machine, skipping is expected. QSEECOM needs a per-machine allowlist entry in qcom_scm.c and QCM6490/RUBIK Pi simply isn’t listed. Harmless.

  • It is not a watchdog bite. The log itself says watchdog: Hard watchdog permanently disabled — it can’t bite when it’s disabled. So don’t go hunting watchdog workarounds.

  • UFS provisioning was a dead end. I ran provision_1_3.xml more than once with no improvement. Thundercomm’s own docs say to skip UFS provisioning on QLI ≥ 1.3 anyway.

  • It wasn’t a GRUB/UUID/partition problem. From the grub> prompt, ls (hd6,gpt3) correctly reported ext*, label writable, and search --fs-uuid resolved the root UUID fine.

  • The ~50 partitions on the UFS LUN are normal. hd5 showing gpt1–gpt51 is just the standard Qualcomm layout (XBL, ABL, TZ, hyp, modem/NON-HLOS, devcfg, dsp, plus A/B slot duplicates). Not a sign of a bad flash.

How I actually found it

The key move was capturing the full UART log to a file instead of watching it scroll. A short/truncated capture is what kept pointing me at the wrong place — an earlier partial log ended at Begin: Loading essential drivers ..., which made it look like an initramfs or USB/XHCI failure.

With a 60-second capture covering two complete reset cycles, the last line before every reset was identical:


[ 14.548189] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9

Worth noting: there is an xhci_hcd 0000:01:00.0: failed to load firmware renesas_usb_fw.mem: -2 error earlier in the log at ~7.9s, and I initially suspected USB. But the board survives another 6.6 seconds past that error, so it isn’t the trigger. Timestamps matter — don’t stop at the first scary-looking error.

The fix (single boot, to confirm)

At the GRUB menu press c for a command line (or e to edit the entry), then:


linux (hd6,gpt3)/boot/vmlinuz-6.8.0-1064-qcom root=UUID=<your-root-uuid> ro console=ttyMSM0,115200n8 modprobe.blacklist=brcmfmac,brcmfmac_wcc,brcmutil pci=noaer pcie_aspm=off

initrd (hd6,gpt3)/boot/initrd.img-6.8.0-1064-qcom

boot

Substitute your own root partition and UUID — find them with ls and ls (hdX,gptY) at the grub> prompt.

Result: zero resets, multi-user.target and graphical.target reached, cloud-init completed all stages, SSH host keys generated, and a ubuntu login: prompt on serial.

Making it permanent

The above is one boot only — power-cycle and you’re back in the loop. Once logged in:


echo 'blacklist brcmfmac' | sudo tee /etc/modprobe.d/blacklist-brcmfmac.conf

echo 'blacklist brcmfmac_wcc' | sudo tee -a /etc/modprobe.d/blacklist-brcmfmac.conf

echo 'blacklist brcmutil' | sudo tee -a /etc/modprobe.d/blacklist-brcmfmac.conf

sudo update-initramfs -u

Belt-and-braces, also add it to the kernel cmdline in /etc/default/grub:


GRUB_CMDLINE_LINUX_DEFAULT="console=ttyMSM0,115200n8 modprobe.blacklist=brcmfmac,brcmfmac_wcc,brcmutil"

then sudo update-grub and reboot to verify it survives a power-cycle.

Caveat: this disables Wi-Fi

Blacklisting is a workaround, not a cure — you lose Wi-Fi. The underlying fault looks like a missing or mismatched firmware/NVRAM file for the BCM4345/9 (43456) SDIO part in /lib/firmware/brcm/ — typically the brcmfmac43456-sdio.bin, the board-specific .txt NVRAM file, or the CLM blob. Worth checking:


ls -la /lib/firmware/brcm/ | grep -i 43456

dmesg | grep -i brcmfmac

If anyone has the correct brcmfmac43456-sdio firmware + NVRAM set for RUBIK Pi 3 on Ubuntu 24.04, please post it — I’d rather fix Wi-Fi than leave the driver blacklisted.

Takeaways for anyone debugging a silent reset on this board

  1. Capture UART to a file over multiple full boot cycles. Scrolling terminals and short captures actively mislead here.

  2. Find the last line before the reset and check its timestamp. Then confirm it’s the same line every cycle.

  3. A silent reset with no panic/oops/call trace points at a driver or power/SoC-level event, not a filesystem or config problem.

  4. Ignore the UEFI RPMB/featenabler/TZ noise unless you have real evidence tying it to your failure.

  5. Never reach for irreversible steps (RPMB key provisioning, --allow-fusing, --finalize-provisioning, bConfigDescrLock=1) to chase a boot loop. qdl refusing to write secdata without --allow-fusing is it protecting you — leave it that way.

Hope this saves someone else the afternoon it cost me.