Raspberry Pi Foundation does not support upgrading Raspberry Pi OS in place, so the supported answer is a clean flash. That trade is wrong when the Pi you are holding has a year of configured services on it.
Here is the Bookworm to Trixie path end to end: the archive keyring that has to be reinstalled before apt will trust the new release, the second apt sources file that has to change as well, and the checks that tell you whether to upgrade this Pi or rebuild it.
Before You Start: Back Up and Check Your Downtime
A partial backup still beats none, though neither rescues a botched release swap once dpkg is halfway through it. Copy everything you care about off the SD card onto a separate disk, not onto the same card. For a restorable system snapshot rather than a plain file copy, Timeshift is already on Raspberry Pi OS and walks you through a restore point in a few screens.
Three quick checks tell you whether the upgrade is safe to attempt, and they all run in one SSH session:
free -h df -h / grep -E 'PRETTY_NAME|VERSION_CODENAME' /etc/os-release
The free memory line matters because package unpacking is memory-hungry in stages, and a card that looks half empty in a file browser can still starve the upgrade partway through. Anything under 500 MB free on the root filesystem is risky. The os-release grep confirms which Bookworm point release you are on, which is your reference point for everything below.
Set aside 30 to 60 minutes where nothing else is using the Pi. The reboot at the end is the only hard commitment, but the upgrade itself is a long unattended stretch, not a five-minute task.
Step 1: Resolve Pending Updates on the Current Release
Bring Bookworm itself fully up to date first. The goal is a system where every package already sits at the newest version the current release offers, so the only variable left in the later steps is the release swap itself and not a pile of pending package updates stacked on top of it.
| State required before the swap | How to reach it |
| Bookworm fully upgraded | sudo apt full-upgrade -y in step 1 completes with a clean prompt |
| New firmware already active | sudo reboot if kernel or firmware was among the updated packages |
sudo apt update sudo apt full-upgrade -y
Note the use of full-upgrade rather than upgrade: full-upgrade is the variant that removes or replaces packages when dependencies require it, which is exactly the situation you get as a release approaches the end of its life. If this step touches the kernel or the firmware, reboot before continuing. The Foundation’s own note on the next release repeats this: an upgrade started from a stale package set is where most of the reported breakage begins.
The command in step 1 is the one you run while still on Bookworm. Every later command assumes that upgrade finished cleanly.
Step 2: Install the New Archive Keyring First
Trixie repository metadata is signed with newer keys, and the keyring already on a Bookworm install predates that change. Without the newer keyring, apt fails partway through the upgrade with a sqv returned an error code (1) message and a missing signing key, and there is no good recovery path from that state once the release swap is half-done. Run this before touching any repository files:
Run the keyring reinstall before touching any repository file, or the upgrade fails after the swap has already started.
sudo apt install --reinstall raspberrypi-archive-keyringIf the keyring was already current, apt tells you so and finishes without changes. Either outcome is fine to proceed on.
Step 3: Skip rpi-update on a Stable Upgrade
The rpi-update command pulls the newest firmware from the development branch, not from the stable repository, which pairs badly with a stability-focused release upgrade. The stable firmware your system needs has already arrived through apt full-upgrade in step 1, and no further firmware action belongs here.
If you specifically want the development firmware for troubleshooting a hardware issue, that is a separate deliberate decision you should make on its own, not a step in this procedure.
apt full-upgrade Stable firmware, supported, what this procedure assumes rpi-update Development-branch firmware, unsupported pairing with a release upgrade Step 4: Re-point apt Sources from Bookworm to Trixie
apt reads repository definitions from /etc/apt/sources.list and from every file ending in .list or .sources under /etc/apt/sources.list.d/. The Bookworm codename is written into all of them, so the fix is a case-sensitive substitution of the codename in every repository definition, with a backup written before you edit anything:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo cp /etc/apt/sources.list.d/raspi.list /etc/apt/sources.list.d/raspi.list.bak sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/raspi.listThe cp commands cost nothing and give you exact file restores if trixie is not yet reachable or you need to back out cleanly. If you have added third-party repositories in sources.list.d/, this sed pass does not touch them. List the directory and review each remaining file manually:
ls -la /etc/apt/sources.list.d/ grep -r bookworm /etc/apt/ || echo "no bookworm references left"That grep is the safety net, not the sed commands.
Any leftover Bookworm reference anywhere under /etc/apt/ is a repository apt will still consult, and it will either 404 against the retired release or silently pin your packages to versions that no longer belong to your new release. Get the grep to print the all-clear message before you continue. Newer Bookworm and every Trixie install can also carry deb822-format .sources files, so run the same check against those if present.
Step 5: Run the Upgrade and Keep Your Configurations
Refresh the package cache so apt reads the Trixie metadata, then run the full upgrade across the release:
- Read the package summary before confirming, watch for removals you did not expect
- Answer Yes to automatic service restarts, answer keep-your-config to dpkg prompts
sudo apt update sudo apt full-upgradeApt presents a summary of installs, upgrades, removals, and held packages before it does anything. On a lite Bookworm install this is typically several hundred packages rather than a handful, so read the summary once to confirm nothing critical is being removed, then confirm.
Partway through, apt asks whether services may be restarted automatically during the upgrade rather than asking you to approve each one as it appears. Choose Yes. The interruptions it would otherwise create arrive at unpredictable moments and slow the run for no benefit.
When dpkg reaches a configuration file you have modified while the repository also carries a newer default, it asks whether to keep your version or install the maintainer version.
Keep your own configuration. The maintainer version is the generic Trixie default, while yours encodes whatever you customized this Pi for.
If a choice later turns out to matter, dpkg records prior versions under /var/backups/, so nothing is lost permanently.
The bulk of the 30 to 60 minutes lands in this step. Let it run to a clean prompt rather than interrupting partway through.
Step 6: Clean Up, Reboot, and Verify
Remove dependencies that no release references and clear the downloaded package archive:
Reboot before the cleanup pass, because unattended removal has stopped Pis from coming back in earlier release transitions.
sudo apt autoremove -y sudo apt cleanOne specific ordering note rather than a generic caution: run autoremove after the reboot rather than bundling it into the upgrade command. Writeups from earlier Pi release transitions describe devices that stopped rebooting when autoremove ran in the same pass as the upgrade and removed something the boot process still needed. Reboot first, confirm the system comes back, then clean.
The reboot itself follows:
sudo rebootOnce the Pi is back on the network, confirm what release it is actually running. The command is lsb_release -c, which prints the codename:
lsb_release -cThe codename field replaces bookworm with the new release name. If you want the full descriptive string as a second reading, run the same os-release grep from the opening checks and compare it to what you saw before the upgrade started.
If a raspi.list.bak is still sitting in sources.list.d/ or you are moving from .list files to the deb822 format, sudo apt modernize-sources tidies the remaining transition pieces and leaves apt reading one consistent repository format from that point on.
If Something Breaks: Known Failure Modes
A clean exit code from apt is not the same as a working system. Spot-check the services you run before declaring victory. The failure modes below recur on this upgrade path, and each has a concrete cause:
- Missing Signing key from sqv during apt update. The keyring step was skipped or failed silently. Reinstall raspberrypi-archive-keyring, then wait for the package index refresh to pass cleanly.
- A 404 on a repository URL during apt update. Some file under /etc/apt/ still references Bookworm. Runner: apply the same sed pass to that file, and the recursive grep should return the all-clear message on its next pass. Third-party .list files you added yourself are the usual culprits, since the sed pass only handles the default Raspberry Pi files.
- The Pi fails to reboot after the upgrade. Reports from earlier release transitions traced this to autoremove running in the upgrade pass and removing something the boot chain required. The ordering in step 6 already avoids this: reboot first, autoremove after.
- The desktop fails to start on the full-sized image. The desktop variant needs the Wayland and X stacks to transition as a unit, which the lite upgrade command does not carry. That longer desktop command is documented on the Raspberry Pi forums for anyone who needs it, and it is the one case where the lite and desktop upgrades genuinely diverge.
Keep the .bak files from step 4 until you have one clean boot and one confirmed service start on the new release. Then delete them and the sources transition is closed.
Conclusion: Upgrade or Clean Install
With the codename confirmed and the package cache pointing at the current release, the upgrade is done, and the remaining work is verification rather than the release swap itself. Run the services you rely on and read their logs, because a package update that completes without error can still shift a behavior your setup depended on.
Whether this was worth it comes down to what was installed. A lightly used Pi is a thirty-minute re-flash and a known-good image, which is the Foundation’s documented recommendation. A Pi running a service stack you have tuned over months is a different calculation, and the upgrade preserves all of that work in place for the cost of a supervised hour.
Where you fall on that trade is a decision only your service list can make, and the table below lays both paths out side by side:
Criteria Clean Install In-Place Upgrade Foundation support Supported path Not supported Preserves configs and packages No. Restore from backup Yes Risk profile Deterministic, known-good image Variable with installed software Time to a working system Flash plus data restore 30 to 60 minutes plus verification For build ideas on the release you just landed, the Raspberry Pi project roundup on this site is the natural next read.