BMCoCo-Pi 0.1.0rc3 · Linux console and model downloads; Windows planned.
Updates, backup and recovery
Before updating
Save guest work using the guest's supported storage. A saved configuration
does not save running RAM. Back up the card's bmcoco content, especially
owner ROMs, writable images and profiles, to separate PC storage. Include
startup.txt and display-0.txt / display-1.txt when preserving host choices.
Wait until file writes finish before shutdown or removal. Do not repartition
or reformat merely to install a kernel update.
This website has no published kernel downloads yet. When available, use only a release that explicitly supports your exact Pi model and review its release notes/checksums. A compatible kernel filename alone does not prove the bundle is right for your board or that a changed boot-firmware set is installed. If release notes require a complete bundle, follow that separate procedure; the Web kernel updater does not replace firmware, presets or owner media.
Update through the Pi's Web UI
- Ensure reliable power/networking. Leave local OSD and stop other remote control clients/transfers. Open the Pi's System page.
- Read the current running build/date, board and required kernel filename.
Pi4/400 uses
kernel8-rpi4.img; Pi5/500 useskernel_2712.img; Pi3B+ useskernel8.img. Do not rename an incompatible kernel to meet the filename. - Choose the correct kernel on your PC using Upload and verify kernel. You do not first upload it into an ordinary SD-files folder.
- Wait for complete staged verification. Uploading alone does not replace the active boot kernel. Check the reported size and SHA-256.
- Choose Review and Apply verified kernel. Read the target, full checksum, rollback and reset warnings, then confirm. Wait for explicit verified promotion/already-installed success; do not infer success from a lost page.
- After verified promotion, use the separately confirmed Reboot Pi button or reboot locally when ready. Apply never automatically reboots. If your display chain needs manual synchronization, retain that procedure.
- Allow guest startup plus the automatic Ethernet delay and DHCP, reload the page and verify the expected running build/date. Staged or active-file metadata is not proof that the new kernel has actually booted.
Do not power-cycle during upload/Apply, repeat Apply blindly, start a competing updater or delete stage/rollback files while a transaction is unresolved. Installing an already-active image verifies it and preserves the old rollback; it does not require an extra reboot just to change nothing.
If a reply is lost
A disconnected page does not prove that no files changed. Retain the same source file and transaction information; reconnect using the UI's recovery state rather than starting a new conflicting upload. Complete active-file readback is required to establish the outcome. If unclear, stop, preserve the card and seek help with source/build/date, transaction result and symptoms. Never attach ROMs, full private card images or credentials to a report.
Recovery if the Pi no longer boots
- Wait for display synchronization and normal network startup before deciding that boot failed. Record LEDs, any visible error, model and last update.
- Do not erase the only copy of owner media/profile data. Remove power/card only when no write is in progress; if that cannot be established, seek help.
- On the PC, back up readable contents before repair. Keep a separate known- good same-model kernel/bundle and its checksums. The updater's rollback is a recovery file, not an automatic boot fallback.
- Restore only a known-good, verified compatible kernel to its documented boot filename while the Pi is off, retaining the failed candidate separately. A future guided restore button is not currently available. If boot assets are also wrong, a complete same-model recovery bundle may be needed.
- If rebuilding the card is necessary, use a spare card where possible. Restore owner content selectively after the baseline boots; do not restore a corrupt configuration or writable image blindly.
Never change EEPROM firmware, flash an OS card or run generic disk-repair/erase commands as an unexplained first response to an emulator error.
Guide edition: November 2, 2026.