🔐 Default credentials
These images ship with a demo credential - safe only on an isolated lab network:
admin password → 12345678, shipped expired: the first login forces a change
WiFi ships disabled and no image carries a PSK. Bake a real password at build time via .env, or change things post-flash with:
sudo bgrpiimage-setup password
sudo bgrpiimage-setup wifi enable "MyNet" "s3cret"
sudo bgrpiimage-setup can status
sudo bgrpiimage-setup can txqueuelen can0 1024
sudo bgrpiimage-setup ip eth0 static 10.0.0.5/24 10.0.0.1 1.1.1.1
🔄 Keeping a flashed device current
A device does not need reflashing for every release. Three things update
independently, and it is worth knowing which is which:
- Debian & Raspberry Pi packages
-
Automatic, inside the configured maintenance window, including a
reboot window for kernel updates. Nothing to do.
- Platform configuration
-
Everything this project generates - systemd units, the
config.txt overlays, the login banner, network and CAN
settings. Applied from a ~30 KB bundle published with each release.
- The base Raspberry Pi OS
-
Reflash. A release built on a newer Raspberry Pi OS
is refused by the updater rather than applied on top of a different
base.
Over SSH or on the console, as root:
sudo bgrpiimage-update check # is there a newer configuration?
sudo bgrpiimage-update plan # exactly what would change, changing nothing
sudo bgrpiimage-update apply # apply it
sudo bgrpiimage-update status # image version, configuration version, pending reboot
sudo bgrpiimage-update rollback # restore the files the last apply replaced
The operator helper can also replace itself, which is useful because
many releases only change it:
sudo bgrpiimage-setup update --self
What it will not do
The updater refuses more than it performs, and deliberately so. It never
touches users, passwords, sudo, PAM, sshd host keys, your stored WiFi
credentials, a static /etc/resolv.conf, or any
05-bgrpiimage-* network override you wrote yourself. It
stops rather than proceeding when:
- the bundle is not signed, or signed by a key this device does not trust
- the bundle is for a different variant, or older than what is installed
- the release was built on a different Raspberry Pi OS - that is a reflash
-
one of your own network overrides would silently swallow a setting the
release adds; it names the setting instead of applying half of it
-
the unattended-upgrades reboot window is open, so a scheduled reboot
cannot land mid-apply
Every bundle carries an Ed25519 signature over its manifest, checked
against public keys that ship inside the image, before anything else is
read. A checksum published next to a download only proves the transfer;
whoever can replace the bundle can replace the checksum beside it.
After applying, it reads back running state - which network file systemd
actually chose, whether every device-tree overlay exists, whether the
journal logged a parse warning - and only then records the new version.
The login banner shows the image version and, when they differ, the
configuration version applied on top of it.
Full reference:
Updating an installed system.
