RPi 5 firmware update via `ha os boards raspberrypi firmware update` rewrites BOOT_ORDER to SD-first - Pi stops booting from NVMe

[msnapka]

Describe the issue you are experiencing

On a Pi 5 booting from NVMe, running ha os boards raspberrypi firmware update followed by a reboot caused the system to boot from a bootable microSD card that was present in the slot, instead of from the NVMe it had been running on previously.

There were no hardware errors and no LED flash codes - the Pi booted cleanly, just from the wrong device. After the update the active BOOT_ORDER was 0xf461 (SD → NVMe → USB), i.e. SD-first.

The fix was simply to remove the SD card and power on again - HAOS then booted from NVMe normally.

Why this is a boot-order change caused by the update (not a pre-existing config)

The same bootable SD card had been sitting in the slot the entire time the system was booting from NVMe normally, for a long period before the firmware update. If BOOT_ORDER had been SD-first (0xf461) all along, the SD would have won on every boot - but it never did; the Pi consistently booted from NVMe with that card in place.

After the firmware update, with nothing else changed, the same card suddenly took priority. The only thing that changed was the bootloader firmware. Therefore the effective boot order was NVMe-first before the update and SD-first (0xf461) after it - the update rewrote it.

This contradicts the assumption that HAOS / the firmware update does not modify BOOT_ORDER.

###Expected behaviour
A system booting from NVMe should continue to boot from NVMe after a firmware update. The update must preserve the existing BOOT_ORDER, or at minimum warn the user that the boot order will be reset and that any bootable medium in the SD/USB slot may take priority afterwards.

What operating system image do you use?

HAOS for RPi - installed via RPi Imager

What version of Home Assistant Operating System is installed?

18

Did the problem occur after upgrading the Operating System?

No

Hardware details

• Board: Raspberry Pi 5 (rpi5-64), Argon ONE V3 case, NVMe (Samsung SSD 970 EVO 500GB)
• Home Assistant OS: 18.0
• Home Assistant Core: 2026.6.4
• Bootloader before update: 2024-06-05 → after: 2026-05-11
• BOOT_ORDER observed after update: 0xf461 (default) — changed to 0xf416 as workaround

Steps to reproduce the issue

1. Pi 5 with HAOS booting from NVMe, with a bootable microSD also present in the slot, booting from NVMe consistently.
2. Run ha os boards raspberrypi firmware update.
3. Run ha host reboot.
4. System now boots from the SD card instead of NVMe (active BOOT_ORDER=0xf461, SD-first).

Anything in the Supervisor logs that might be useful for us?

not relevant

Anything in the Host logs that might be useful for us?

not relevant

System information

No response

Additional information

• No LED flash codes; clean boot from the wrong device. This is distinct from Home Assistant OS 18.0, raspbery pi5, LED Short flashes 9 times #4796 (SDRAM 9-flash failure).
• Related: rpi-eeprom-config --edit doesn't work on RPi 5 with NVMe #4574 (rpi-eeprom-config availability on HAOS / RPi 5 + NVMe).

[agners]

Hm, it seems that the current kernel/scripts are not able to read the boot order if this old RPi firmware is installed:

# rpi-eeprom-config
ioctl_set_msg failed:-1
bootloader_config

I guess the same would happen on Raspberry Pi OS. Not sure if we can fix this. Worst case this just needs a manual update and setting the boot order again.

[agners]

Root cause

The update doesn't actually rewrite BOOT_ORDER — it fails to migrate the existing config and falls back to the new image's default, which for the Pi 5 images is 0xf461 (SD-first).

The reason it can't migrate is that on the old (pre-2025-02-11) firmware the OS can't read the current EEPROM config at all. rpi-eeprom-update reads the live config from the blconfig nvmem device (/reserved-memory/nvram@0), since vcgencmd bootloader_config doesn't work on the Pi 5. The bootloader fills in that node's reg (the address/size of the config region) at boot. Older firmware writes it using #size-cells=1, but the current kernel DTB declares #size-cells=2, so the reg ends up malformed and the nvmem-rmem driver never creates the blconfig device:

# ls /sys/bus/nvmem/devices/
nvmem_cust0  nvmem_mac0  nvmem_otp0  nvmem_priv0     # no blconfig
# rpi-eeprom-config | grep BOOT_ORDER                 # (nothing)

With no readable config, the update flashes the new image with its baked-in default boot order — hence 0xf461.

This 32-bit→64-bit reg change is described in raspberrypi/linux@527d7643ec01: the firmware only started honoring the DTB's actual #size-cells as of EEPROM release pieeprom-2025-02-11. So a readable config — and a preserved BOOT_ORDER across updates — requires firmware ≥ that release. After updating to 2026-05-11 the blconfig device shows up again, which is why the boot order can only be read/fixed after the update.

Workaround after updating: rpi-eeprom-config --edit, set BOOT_ORDER=0xf416 (NVMe-first), then reboot.

It'd probably be worth having rpi-eeprom-update warn/refuse rather than silently apply the default when it can't read the current config.

---

Root-cause analysis done with Claude.

[msnapka]

Can we work around it and check if there are at least other bootable devices connected to the RPi like USB or SD?

Also at least a detailed warning about the risks and limitations would be of great help here.

In case of old firmwares with 2 or 3 bootable devices detected, there should be imho a blocking warning telling the user to clean up the mess or manually override the recommendation to not continue flashing.

[agners]

Ok, I did quite some tests, and it turns out that the display not working and the lost boot order on firmware update are connected: The 6.18.33 Linux kernel (shipped with HAOS 18.0) was not compatible with old firmwares. This got fixed in the more recent 6.18.34 release with raspberrypi/linux@ec0e437419f3.

I'll pull the HAOS 18 release from stable for Raspberry Pi 5 for now, the display issue as well as this seems unnecessary churn.

[agners]

This is fixed with the Raspberry Pi kernel bump #4814. It will be resolved with HAOS 18.1.