coco-pi.net

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

  1. Ensure reliable power/networking. Leave local OSD and stop other remote control clients/transfers. Open the Pi's System page.
  2. Read the current running build/date, board and required kernel filename. Pi4/400 uses kernel8-rpi4.img; Pi5/500 uses kernel_2712.img; Pi3B+ uses kernel8.img. Do not rename an incompatible kernel to meet the filename.
  3. Choose the correct kernel on your PC using Upload and verify kernel. You do not first upload it into an ordinary SD-files folder.
  4. Wait for complete staged verification. Uploading alone does not replace the active boot kernel. Check the reported size and SHA-256.
  5. 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.
  6. 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.
  7. 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

  1. Wait for display synchronization and normal network startup before deciding that boot failed. Record LEDs, any visible error, model and last update.
  2. 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.
  3. 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.
  4. 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.
  5. 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.