Raspberry Pi OS Release History: Debian Bases, EEPROM and Updates

Raspberry Pi OS is the Debian based operating system for Raspberry Pi computers. It began as Raspbian, a community rebuild of Debian wheezy for the original Pi's ARMv6 processor, and took its current name in May 2020. Each major release follows a Debian release; the current one, from 1 October 2025, is based on Debian 13 Trixie.

Only the newest major release gets every security fix, and Raspberry Pi tells you to reflash rather than upgrade in place across Debian bases. On a Pi 4, Pi 5 and their siblings, the bootloader lives in an SPI EEPROM on the board, so firmware has its own update path through rpi-eeprom-update. Below: every release by Debian base, the boot chain, EEPROM updates, secure boot, security changes release by release, and a routine for a homelab Pi that stays patched.

Key takeaways

• Seven Debian bases so far. The release notes mark each switch: Jessie (25 September 2015), Stretch (16 August 2017), Buster (20 June 2019), Bullseye (30 October 2021), Bookworm (10 October 2023) and Trixie (1 October 2025), after Raspbian's wheezy era.
• Raspbian first, new name in 2020. Raspbian's first full build finished in June 2012; Raspberry Pi called Raspberry Pi OS "the new name for Raspbian" in May 2020, and 64-bit went stable on 2 February 2022.
• Only the latest base gets every fix. Bookworm continues as legacy images (one is dated 6 October 2026), but Debian's regular Bookworm support ended on 11 July 2026.
• Reflash, do not dist-upgrade. For Bookworm, Raspberry Pi said an in-place attempt "will almost certainly end up with a non-booting desktop and data loss".
• Pi 4 and Pi 5 boot from an EEPROM. Updates arrive in the rpi-eeprom package and are written at the next reboot; Pi 5 class boards can use A/B partitions so an interrupted write cannot brick the board.
• Secure boot is permanent. It programs your public key hash into one time programmable memory on BCM2711 and BCM2712 devices, and cannot be undone.
• Defaults tightened in steps. SSH off (2016), no default pi user (2022), Wayland on Pi 4 and Pi 5 (2023), passwordless sudo off (2026).
• Current images ship an SBOM. The 6 October 2026 Trixie folder includes an SPDX 2.3 JSON bill of materials with 5,885 entries, next to a signature file.

What Raspberry Pi OS is, and how it grew out of Raspbian

Raspberry Pi's documentation describes Raspberry Pi OS as the free, official operating system for its computers, based on Debian and supporting more than 69,000 Debian packages. It follows "a staggered version of the Debian release cycle", with a new release about every two years. The stagger matters: Raspberry Pi OS ships a new base some weeks or months after Debian does, once the kernel, firmware and desktop have been ported.

2012: Raspbian, an unofficial hard float port

The first Raspberry Pi used a BCM2835 with an ARMv6 ARM1176 core, and Debian's official armhf port needs ARMv7 or later. The Raspbian FAQ describes Raspbian as "an unofficial port of Debian wheezy armhf" rebuilt to use hardware floating point on the Pi's ARMv6 CPU; the Foundation's earlier squeeze image used the soft float armel port, which left the floating point unit idle.

The Raspbian home page says the initial build of over 35,000 packages was completed in June 2012, and that Raspbian "is not affiliated with the Raspberry Pi Foundation". That split still exists: Raspberry Pi's software sources page lists raspbian.sources on 32-bit images and Debian's own debian.sources on 64-bit images, with raspi.sources for Raspberry Pi's packages on both.

The oldest entry in the Raspberry Pi OS release notes is dated 10 September 2013, and the Raspbian image archive starts in September 2013. Earlier 2012 images are not listed in either.

2020: the rename

On 29 May 2020, alongside the 8 GB Raspberry Pi 4, Raspberry Pi published an update post that called Raspberry Pi OS "the new name for Raspbian" and announced a beta 64-bit build. The first folder in the 64-bit image archive is dated 28 May 2020. The base was still Debian 10 Buster; only the name changed.

2022: 64-bit goes stable

On 2 February 2022, the 64-bit announcement opened the 64-bit edition to everyone. It explained why the 32-bit build had stayed the default: an armhf style build for ARMv6 "will run on every device we have ever manufactured, all the way back to 2011". It also gave the reasons to move. Many closed source applications exist only for arm64, and a 32-bit process on an 8 GB Pi 4 is limited to 3 GB of address space because the top 1 GB is reserved for the kernel.

Editions and architectures today

The introduction page lists three editions: with desktop, Full (with recommended applications) and Lite (command line only, for headless servers). It recommends 64-bit for Pi 3, 4 and 5 and 32-bit for the original Pi, Pi 2 and Pi Zero.

The boot folder reference shows the kernel split: kernel.img for BCM2835 boards, kernel7.img and kernel7l.img for 32-bit Pi 2, 3 and 4 class boards, kernel8.img for 64-bit, and kernel_2712.img, tuned for the BCM2712 in the Pi 5, Pi 500, Pi 500+ and CM5. lscpu reports armv7l on a 32-bit kernel and aarch64 on a 64-bit one.

Every Raspberry Pi OS release by Debian base

Raspberry Pi OS publishes many dated images per Debian base. The table lists each base, when Debian released it, when the first Raspberry Pi image on that base appeared, the kernel the notes record at or near the switch, and what changed in the desktop and system. Dates come from the Raspberry Pi OS release notes and the Debian releases page.

A few rows need a note. Wheezy was Raspbian's base before Debian finished it: Raspbian's first full build (June 2012) came almost a year before Debian 7's release in May 2013. Buster went the other way: the 20 June 2019 Raspberry Pi image, released for the Pi 4 launch, predates Debian 10's own release on 6 July 2019. And the "Debian support status" column is Debian's support for Debian's own packages. It is not a promise about Raspberry Pi's kernel, firmware or desktop packages, which come from Raspberry Pi's archive, or about the Raspbian rebuilds used by the 32-bit edition.

Point releases that changed security or boot behaviour

Between bases, Raspberry Pi publishes dated images. Most entries are bug fixes and desktop polish. These are the ones that changed security defaults or how the boot chain is maintained, as recorded in the release notes:

Security defaults moved about once a base. The boot chain also became a normal Debian packaging problem: since Bookworm, the kernel and GPU firmware come from Debian style packages that the same tools can inventory as the rest of the system.

What the pattern tells you

One base every two years, in odd numbered years, a few months after Debian, with a dated image every one to three months in between. Kernel series move inside a base: Bookworm started on 6.1 and its legacy images now carry 6.12.109, while Trixie moved from 6.12.47 to 6.18.50. The kernel source is the raspberrypi/linux repository, whose default branch was rpi-6.18.y when we checked. So "which Raspberry Pi OS am I on" is two questions: which Debian base, and which package set inside it. Step 2 of the walkthrough checks both.

How a Raspberry Pi boots

A Raspberry Pi does not have a PC style BIOS or UEFI firmware. The VideoCore GPU starts first and the ARM cores are brought up later. What happens before Linux depends on the board generation.

Older boards: bootcode.bin from the boot partition

On boards up to the Pi 3 family, the boot ROM in the SoC reads one time programmable (OTP) memory to see which boot modes are enabled, then looks for a file called bootcode.bin. The legacy boot flow page describes the BCM2837 sequence: check the primary SD card, then the secondary SD, NAND, SPI and USB, loading bootcode.bin "into the local 128K cache" and jumping to it. bootcode.bin then loads a start*.elf GPU firmware file, which reads config.txt, loads the device tree and the kernel, and releases the ARM cores.

That design means the whole boot chain on a Pi 3 is a set of files on a FAT partition. Update the files and you update the firmware. Corrupt the files and the board will not boot, but nothing on the board itself is damaged.

Pi 4 and Pi 5: a bootloader in SPI EEPROM

The boot EEPROM page lists the models that boot from an EEPROM: flagship boards since the Pi 4B, Compute Modules since CM4 (including CM4S), and the keyboard computers (Pi 400, 500 and 500+). The EEPROM boot flow page splits the process into two stages.

1. First stage, in the boot ROM. The SoC reads OTP. If allowed, it checks the SD card for recovery.bin, a minimal program that only reflashes the EEPROM. Otherwise it loads the second stage from SPI EEPROM, and if that fails it waits for recovery.bin over USB.
2. Second stage, from the EEPROM. The loader initialises clocks and SDRAM, reads its configuration, and walks BOOT_ORDER, trying SD card, network (DHCP and TFTP), USB mass storage, NVMe and other modes until one yields firmware it can run.

The firmware configuration page says SD card comes first by default and raspi-config can change the order. On the Pi 5 the change goes further: the boot folder reference says it uses no .elf files at all, because its firmware is self contained in the EEPROM. A Pi 4 still loads its start4*.elf GPU firmware from the boot partition.

config.txt, the device tree and overlays

The config.txt page describes the file as the Pi's replacement for a BIOS: "The GPU reads config.txt before the Arm CPU and Linux initialise." It uses a plain property=value format with a 98 character line limit. Changes take effect after a reboot, and vcgencmd get_config shows the active values.

Hardware is described to the kernel with a device tree. The boot folder holds .dtb files for each model and an overlays folder of partial trees for optional hardware such as sound boards. According to the reference page, the firmware loader scans the parameters and overlays named in config.txt, applies them to the base tree, and hands the merged tree to the kernel. That is why a single line such as dtoverlay=audremap can move analog audio pins: the overlay edits the hardware description before Linux ever sees it.

Where the files live: /boot/firmware since Bookworm

Bookworm moved the boot partition's mount point. The 10 October 2023 release notes record the boot partition's mount point moving from /boot to /boot/firmware, and the config.txt page confirms that Raspberry Pi OS now reads the file from /boot/firmware/. Scripts and guides that edit /boot/config.txt still work on older images and silently do nothing useful on Bookworm and Trixie. Bookworm also added an initramfs by default, and the reference page notes that Trixie sets the auto_initramfs keyword by default.

How bootloader EEPROM updates are delivered and checked

The rpi-eeprom repository contains the scripts and binaries for the rpi-eeprom package. Its README lists the supported models: Pi 4 Model B, Pi 400, CM4, CM4S, Pi 5, Pi 500, Pi 500+ and CM5. Images for BCM2711 boards live in firmware-2711 and images for BCM2712 boards in firmware-2712.

default and latest

The boot EEPROM page describes two channels. default is the factory default image, updated for critical fixes and hardware support and periodically for features already tested in latest, which updates more often. Switch in raspi-config under Advanced Options, Bootloader Version.

In the BCM2712 release notes, the 25 September 2026 build was promoted to default that day; the BCM2711 notes show a 23 September build promoted on 27 September. October 2026 latest entries for the Pi 5 disable HTTP redirects in HTTP boot "for safety", treat unexpected HTTP responses as errors, and add preliminary support for an anti rollback version in OTP. If you rely on HTTP boot, read them before switching to latest.

How an update actually happens

The rpi-eeprom README describes the normal path. rpi-eeprom-update runs as a systemd service at boot. It compares the installed EEPROM version with the newest image in the selected channel and, if newer, stages it so that recovery.bin flashes it at the next reboot (or the bootloader updates itself on BCM2711). The documentation adds that the service migrates your current bootloader configuration into the new image automatically.

New images arrive as ordinary package updates. When apt full-upgrade installs a newer rpi-eeprom package, the next boot can apply a new bootloader. That is convenient, and also a reason to know it happens: an unattended package upgrade can change the bootloader on the next reboot.

The commands from the documentation:

# Show the running bootloader version
vcgencmd bootloader_version

# Check whether an update is available in the selected channel
sudo rpi-eeprom-update

# Stage the update, then reboot to apply it
sudo rpi-eeprom-update -a
sudo reboot

# Cancel a pending update before rebooting
sudo rpi-eeprom-update -r

# Show the running bootloader configuration
rpi-eeprom-config

To stop automatic updates, the documentation offers sudo systemctl mask rpi-eeprom-update. A cleaner option when several operating systems or SD cards share a board is the FREEZE_VERSION setting in the bootloader configuration, which makes the update service skip automatic updates.

A/B updates on Pi 5 class boards

The most damaging failure is power loss while the EEPROM is being rewritten. The documentation describes A/B updates as protection against exactly that: the EEPROM is split into two partitions, one of which is committed and boots by default, and updates are written to the other, leaving the committed one "untouched until the new image has been written in full and checked". It is available only on the Pi 5, CM5 and the Pi 5 keyboard computers, and it supports a tryboot rollback test before committing. One caveat from the same page: while A/B updates are enabled, tools that write to the EEPROM directly, such as flashrom, no longer work.

Immediate updates and the minimum version check

The README also describes an immediate mode: RPI_EEPROM_IMMEDIATE_UPDATE=1 in /etc/default/rpi-eeprom-update writes the EEPROM while the system runs, through rpi-eeprom-ab on A/B enabled BCM2712 boards or flashrom elsewhere, and power must not be lost during the write. On the Pi 4 the SPI pins are shared with analog audio, so this needs extra config.txt lines; on CM4 and CM4S, usbboot is the recommended path.

Newer boards also refuse old images. The factory programs a minimum bootloader version into each board, exposed at /proc/device-tree/chosen/rpi-min-boot-ver, and by default an older candidate image is refused. The releases page warns: "Old releases may fail to boot on newer hardware revisions." Ubuntu's Raspberry Pi download page notes from the other side that some Ubuntu releases need a minimum EEPROM date on Pi 4 and Pi 5.

Recovery when the bootloader is broken

The documented fix for a board that will not boot is to reflash the bootloader with Raspberry Pi Imager: on a spare card choose Misc utility images, Bootloader, and the boot mode you want, write it, boot the Pi from it, and wait for a steady green LED flash and a green screen. Warning: this erases the card. Use an empty card and check the device Imager shows before you confirm.

Signed boot and secure boot on Pi 4 and Pi 5

Raspberry Pi offers two related features. Signed boot (SIGNED_BOOT=1 in the EEPROM configuration) tells the bootloader to load the OS only from a boot.img ramdisk and verify it against boot.sig. Secure boot makes that permanent by programming a key hash into OTP.

What the chain of trust looks like

The security architecture page describes three stages:

1. Boot ROM. Immutable code with a Raspberry Pi public key "burned into silicon". It reads the hash of your RSA 2048 bit public key from OTP. On BCM2712, your key also signs the EEPROM bootloader itself.
2. EEPROM bootloader. Verified with Raspberry Pi's key; it then checks your public key against the OTP hash.
3. Kernel and OS. The bootloader loads boot.img (kernel, initramfs, device tree and, on BCM2711, the GPU firmware) and verifies boot.sig with your key before running it.

The usbboot secure boot guide lists what changes once the key hash is programmed: only images signed with your private key boot, the EEPROM configuration must be signed too, and you cannot downgrade to a bootloader without secure boot support. It can also permanently disable VideoCore JTAG. In bold it warns: "This operation cannot be undone and the key hash cannot be changed." Lose the private key and that board can never take a new OS image.

The documented provisioning flow connects a board in USB boot mode and runs rpiboot, with steps written for Compute Modules. Check the provisioning documentation for your exact board before planning around it.

Secure Boot Provisioner

For more than a handful of devices, Raspberry Pi publishes the Secure Boot Provisioner (rpi-sb-provisioner), which it describes as still in active development. It offers three modes:

The architecture page is direct about the dependency between the two halves. Encryption without secure boot does not protect the key in OTP from someone with root access, and secure boot without encryption leaves data readable if the storage is removed. It also notes that Raspberry Pi OS does not support encrypted root filesystems by default.

What secure boot does not do

Secure boot proves the code that started the board came from the key holder. It says nothing about whether the packages in that signed image are current. A signed image with a two year old library is a verified, vulnerable image, and for a homelab that is the more common risk, handled by updates and inventory rather than by OTP.

What changed for security across releases

Pulling the release notes, news posts and documentation together, these are the security relevant defaults and when they changed.

SSH off by default (November 2016)

The 25 November 2016 image disabled SSH and prompted for a password change when SSH was on with the default password. The SSH documentation still says "By default, Raspberry Pi OS disables the SSH server." Enable it in raspi-config or in Imager's Remote Access settings, where you can choose public key authentication.

The default pi user removed (April 2022)

The 4 April 2022 image removed the pi user. The 7 April 2022 announcement said a known username "could potentially make a brute-force attack slightly easier", and that some countries were legislating against default credentials. The first boot wizard became mandatory; headless users preset an account in Imager or with a userconf.txt file holding a username and hashed password. A rename-user script handles existing installs.

64-bit images and 64-bit time

On 64-bit images, Debian packages come from Debian's own arm64 archive and receive Debian's security updates directly; the 32-bit edition depends on Raspbian's rebuilds. The Trixie announcement also highlighted Debian's move to 64-bit time values so dates do not overflow in January 2038, which matters mainly for 32-bit systems.

Wayland by default (October 2023 and October 2024)

The Bookworm announcement explained the security gain: under X11 applications can exchange information through the display server, while a Wayland compositor isolates them from each other. Wayland became the default on Pi 4 and Pi 5 with Bookworm, and the labwc compositor became the default on all models in October 2024.

Passwordless sudo off (April 2026)

The 13 April 2026 Trixie image disabled passwordless sudo by default. Raspberry Pi's operational security guide recommends requiring a password for sudo. If you set up a Pi before that image, check whether your account still has a NOPASSWD rule.

Signing keys and SBOMs for images

The 24 November 2025 notes published a new downloads signing key fingerprint. Current image folders, such as the 6 October 2026 Trixie folder, contain the compressed image, SHA-1 and SHA-256 checksums, a .sig signature, an .info file and a .sbom.xz file. We downloaded that SBOM: an SPDX 2.3 JSON document created on 6 October 2026 with 5,885 package entries, covering the Debian packages and individual kernel modules from the 6.18.50+rpt-rpi-2712 kernel (modules carry no version). The .info file names Raspberry Pi's pi-gen build tool and lists every dpkg package, such as alsa-utils 1.2.14-1+rpt1; the +rpt suffix marks packages Raspberry Pi has patched.

How long each release gets updates, and how to move to a new base safely

The support model

Raspberry Pi does not publish fixed end of life dates per base in the sources we checked. What it does publish:

• The newest base gets everything. The operational security guide says only the most recent major release gets all the latest security fixes, and recommends moving to each new one.
• The previous base continues as legacy, for now. The oldstable release notes show Bookworm images dated 15 September and 6 October 2026 with kernel 6.12.109, and the oldstable image folder lists 2026-10-06-raspios-bookworm-arm64.img.xz.
• Debian's dates bound the Debian packages. The Debian releases page gives three years of full support plus two of LTS. Bookworm's regular support ended on 11 July 2026 with LTS to 30 June 2028; Trixie runs to 9 August 2028, LTS to 30 June 2030. The 32-bit edition's packages are rebuilt by Raspbian rather than taken from Debian, so check that fixes actually arrive on your architecture.

So a Bookworm Pi in October 2026 still gets Raspberry Pi kernel and firmware builds and Debian LTS updates, but is no longer on the line that gets every fix. Bullseye and older should be rebuilt.

Why in-place upgrades are discouraged

Debian supports upgrading a running system; Raspberry Pi does not, for its images. The Bookworm post reminded readers that Raspberry Pi has always advised re-imaging for a major version, and offered no upgrade procedure. The Trixie post says Raspberry Pi does "not recommend or support" upgrading a running Bookworm image. Bookworm alone changed the boot mount point, kernel packaging, networking and audio, and an in-place upgrade would have to reproduce each change exactly as a fresh image does, on a path nobody tests.

A safe migration plan

1. Inventory what you run: dpkg --get-selections, enabled systemd services, crontabs, changes under /etc, and any container or compose files.
2. Back up data and configuration to another machine, and test that you can read the backup.
3. Flash the new base to a different card or SSD, keeping the old card untouched as your rollback.
4. Rebuild configuration from your notes rather than copying old /etc files over new defaults.
5. Restore data, start services one at a time, test, then retire the old card.

The Trixie post adds an option for newer boards: a Pi 5, 500 or 500+ on wired Ethernet can boot the Imager embedded in its bootloader and install a new image over the network.

Step by step: flash, preset access, check firmware and keep it patched

This walkthrough assumes a Pi 4 or Pi 5 running as a headless homelab server on the current Trixie base.

Step 1: flash with Raspberry Pi Imager

Use Raspberry Pi Imager. The install guide walks through choosing the device, the OS and the storage, then opens a Customisation tab. Set:

• Hostname and localisation.
• User. A lowercase username and a strong password. The guide notes that the username must be lowercase letters, numbers, underscores and hyphens.
• Remote Access. Enable SSH and choose public key authentication. Imager prefills your existing public key if it finds one, or you can browse to it.

Warning: writing an image erases the target device. Imager asks you to confirm; read the device name it shows. If you write an image by hand instead, identify the device first and check it twice:

# Linux: list block devices and confirm which one is the card you just inserted
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

# Verify the download before writing it (compare with the .sha256 file from the same folder)
sha256sum -c 2026-10-06-raspios-trixie-arm64.img.xz.sha256

Only after confirming the device path, by size and model, should you write to it. Writing to the wrong device destroys whatever is on it, including your workstation's own disk.

Step 2: first boot, confirm what you are running

cat /etc/os-release          # Debian base: VERSION_CODENAME=trixie
cat /etc/rpi-issue 2>/dev/null  # Image and pi-gen build that produced this install, if present
uname -r                     # Running kernel, for example 6.18.50+rpt-rpi-2712
dpkg --print-architecture    # arm64 or armhf
cat /proc/device-tree/model  # Exact board model

Step 3: check firmware and the EEPROM

vcgencmd version                 # GPU firmware build
vcgencmd bootloader_version      # EEPROM bootloader build date
sudo rpi-eeprom-update           # Is a newer bootloader available in your channel?
rpi-eeprom-config                # Current bootloader configuration (BOOT_ORDER and others)

If an update is available and you are on mains power you trust, stage and apply it:

sudo rpi-eeprom-update -a
sudo reboot

After the reboot, run sudo rpi-eeprom-update again; it should report BOOTLOADER: up to date. On a Pi 5 you can also enable A/B updates through raspi-config so a future interrupted update cannot leave the board unbootable.

Step 4: update packages

sudo apt update
sudo apt full-upgrade

The updating guide recommends full-upgrade over upgrade because Raspberry Pi OS changes package dependencies more often than Debian does. It also says normal firmware updates arrive through the raspi-firmware package, and that rpi-update, which installs pre-release kernels and firmware and on Pi 4 and Pi 5 also updates the EEPROM, is for developers and testers only. If you ran it by mistake, the guide's fix is sudo apt install --reinstall raspi-firmware and a reboot.

Step 5: enable unattended upgrades

Debian's unattended upgrades guide covers the package. Install and enable it:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades   # answer yes to automatic stable updates

The default configuration installs Debian security updates. Raspberry Pi's own packages, including the kernel, firmware and rpi-eeprom, come from archive.raspberrypi.com, whose Trixie Release file declares Origin: Raspberry Pi Foundation and Codename: trixie. If you want those packages updated automatically as well, add a matching line to the Unattended-Upgrade::Origins-Pattern section in a local file, as the Debian guide suggests for local changes:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Origins-Pattern {
        "origin=Raspberry Pi Foundation,codename=${distro_codename},label=Raspberry Pi Foundation";
};

Check the exact origin and label strings on your own system first; they differ between the Debian, Raspbian and Raspberry Pi archives:

apt-cache policy | grep -E "o=|l=" | sort -u
sudo unattended-upgrade --dry-run --debug 2>&1 | grep -i "allowed origins"

Two cautions. Kernel and firmware updates take effect only after a reboot, so either schedule one (the shipped configuration has an Automatic-Reboot option) or check /var/run/reboot-required regularly. And because rpi-eeprom updates can change the bootloader at the next reboot, decide deliberately whether a remote board should take them automatically or whether you would rather set FREEZE_VERSION and update by hand.

Step 6: tighten SSH and sudo

With a key installed, turn off password logins over SSH:

sudo tee /etc/ssh/sshd_config.d/10-no-passwords.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF
sudo sshd -t && sudo systemctl reload ssh

Keep a second session open while you test. Then confirm no leftover passwordless rule exists:

sudo grep -rn NOPASSWD /etc/sudoers /etc/sudoers.d/ || echo "no NOPASSWD rules"

Raspberry Pi's operational security guide also recommends a host firewall and covers UFW for that.

Step 7: keep a record of what the image contained

Keep the .sbom.xz and .info files from the folder of the image you flashed. They describe the image on its build day; after months of updates, regenerate an inventory from dpkg -l when you need a current one.

Raspberry Pi OS, Ubuntu and Debian's own images compared

The Ubuntu figures are from Ubuntu's Raspberry Pi download page, which also lists Ubuntu Core 24 as an immutable option "supported until 2036". The Debian image details are from raspi.debian.net and its tested images page.

In short: the vendor OS is the low friction path for Pi specific hardware and the desktop; an LTS distribution gives a published five year window if you check EEPROM compatibility; pure Debian keeps a Pi 3 or Pi 4 class board identical to your other Debian servers.

Common mistakes

• Treating apt full-upgrade as a major upgrade, or editing bookworm to trixie in the sources files. The first never changes the base; the second is the unsupported in-place upgrade. Reflash and restore.
• Editing /boot/config.txt on Bookworm or Trixie. The live file is /boot/firmware/config.txt.
• Using rpi-update as a routine update tool. It installs pre-release kernels and firmware, and on Pi 4 and Pi 5 it updates the EEPROM too. Use apt.
• Forgetting the EEPROM exists. A Pi 4 that has not had apt updates for a long time also has an old bootloader. Check vcgencmd bootloader_version.
• Flashing an old bootloader onto a new board. Newer board revisions can refuse or fail to boot old EEPROM images. Use the images from the current rpi-eeprom package.
• Programming secure boot on a hobby board to try it out. The key hash in OTP is permanent. Keep the private key safe, or do not enable it.
• Treating unattended upgrades as complete. Without a matching origin line, Raspberry Pi's kernel and firmware packages are not included, and kernel fixes need a reboot either way.
• Leaving a 32-bit Bullseye or older Pi on the network. Its Debian base is past the end of Debian's free LTS, and it is not on Raspberry Pi's current line.

FAQ

What version of Debian is Raspberry Pi OS based on?

Debian 13 Trixie, since 1 October 2025. The Bookworm based release is still offered as a legacy image. VERSION_CODENAME in /etc/os-release tells you which you have.

When was Raspbian renamed Raspberry Pi OS?

In May 2020. Raspberry Pi's update post of 29 May 2020 described Raspberry Pi OS as "the new name for Raspbian", alongside a beta 64-bit edition. The base was still Debian 10 Buster at the time.

Can I upgrade Raspberry Pi OS Bookworm to Trixie without reinstalling?

Raspberry Pi does not recommend or support it. Back up, flash a clean Trixie image, and restore your data and configuration.

How long is Raspberry Pi OS supported?

Only the newest major release gets all the latest security fixes. The previous one continues as legacy images (Bookworm images were still built in October 2026), with no fixed end date in the sources we checked, so plan to move to each new base within its first year.

How do I check and update the Raspberry Pi 4 or Pi 5 bootloader?

Run vcgencmd bootloader_version to see the installed version and sudo rpi-eeprom-update to see whether a newer one is available. To apply it, run sudo rpi-eeprom-update -a and reboot. Updates are normally applied automatically at boot by the rpi-eeprom-update service after apt installs a newer rpi-eeprom package.

What is the difference between the default and latest bootloader?

default is the factory default image, updated for critical fixes and for features that have been tested in latest. latest updates more often with new fixes and features. Most users should stay on default; switch in raspi-config under Advanced Options, Bootloader Version.

Does the Raspberry Pi support secure boot?

Yes, on BCM2711 (Pi 4 family) and BCM2712 (Pi 5 family) devices. It programs the hash of your RSA 2048 public key into one time programmable memory so the board boots only images you signed. It cannot be undone, and the documented provisioning flow targets Compute Modules over USB.

Why was the default pi user removed?

Raspberry Pi removed it in April 2022 because a well known username could make brute force attacks slightly easier and because some countries were introducing laws against default login credentials on connected devices. You now create an account in the first boot wizard, in Raspberry Pi Imager, or with a userconf.txt file.

Is SSH enabled by default on Raspberry Pi OS?

No. SSH has been disabled by default since the 25 November 2016 image. Enable it in raspi-config, in the configuration tool, or in Raspberry Pi Imager's Remote Access settings before you flash, ideally with public key authentication.

Should I use the 32-bit or 64-bit Raspberry Pi OS?

Use 64-bit on a Pi 3, Pi 4, Pi 5 or Zero 2 W. It receives Debian's arm64 packages directly, handles more memory per process, and runs software published only for arm64. Use 32-bit on the original Pi, the Pi Zero and Pi 2 boards: the first two cannot run a 64-bit kernel at all, nor can early Pi 2 revisions, and Raspberry Pi recommends 32-bit for all three.

A Raspberry Pi in a homelab rarely runs only the operating system: it runs containers, Python services, Node.js dashboards and home automation code, each with its own open source dependencies that apt does not update. The bootloader, firmware and Debian packages on the Pi still have to come from Raspberry Pi and Debian, so the fit here is indirect, but the software you build and deploy onto the board is where the steps below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not scan firmware, manage devices or update Raspberry Pi OS; the EEPROM, kernel and Debian packages come from Raspberry Pi and Debian through the steps above. Where it helps is the software around the board: the repositories and container images you build for it, and SBOM files such as the one Raspberry Pi publishes with each image, which safeguard scan --sbom can read and match against vulnerability databases.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On the workstation where you build the containers and services that run on your Pi, that is the route for scanning those repositories and images, or the image SBOM you downloaded in step 7, before anything is deployed to the board.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node.js dashboard or home automation service you run on a Pi, where the vulnerable dependency is in your repository and apt full-upgrade will never touch it.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, that connection lets you ask which of them contain a given component and version, which is the question you need answered when a library used by several of your Pi services turns up in an advisory.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Raspberry Pi OS release notes, 64-bit
• Raspberry Pi OS release notes, 32-bit
• Raspberry Pi OS legacy (oldstable) release notes
• Raspberry Pi OS legacy 64-bit image folder
• Raspberry Pi OS 64-bit image archive
• Raspberry Pi OS Trixie image folder, 6 October 2026 (image, signature, SBOM, info file)
• Raspbian image archive
• Raspberry Pi news: An update to Raspberry Pi OS Bullseye (7 April 2022)
• Raspberry Pi news: Raspberry Pi OS (64-bit) (2 February 2022)
• Raspberry Pi news: Latest Raspberry Pi OS update, May 2020
• Raspberry Pi news: Bookworm, the new version of Raspberry Pi OS
• Raspberry Pi news: Trixie, the new version of Raspberry Pi OS
• Raspbian home page
• Raspbian FAQ
• Debian releases
• Raspberry Pi documentation: Raspberry Pi OS introduction
• Raspberry Pi documentation: Manage software and firmware updates
• Raspberry Pi documentation: Boot EEPROM
• Raspberry Pi documentation: EEPROM boot flow
• Raspberry Pi documentation: Legacy boot sequence
• Raspberry Pi documentation: Firmware configuration
• Raspberry Pi documentation: Boot folder and device tree reference
• Raspberry Pi documentation: What is config.txt
• Raspberry Pi documentation: SSH
• Raspberry Pi documentation: Install using Imager
• Raspberry Pi documentation: Software sources
• Raspberry Pi documentation: Security architecture
• Raspberry Pi documentation: Operational security
• Raspberry Pi documentation: Secure Boot Provisioner
• rpi-eeprom repository and README
• rpi-eeprom releases page
• rpi-eeprom BCM2711 release notes
• rpi-eeprom BCM2712 release notes
• usbboot secure boot recovery guide
• raspberrypi/linux kernel repository
• Raspberry Pi Imager repository
• Raspberry Pi archive Release file for Trixie
• Debian wiki: UnattendedUpgrades
• Ubuntu for Raspberry Pi download page
• Raspberry Pi Debian images
• Raspberry Pi Debian tested images

Last reviewed: 24 October 2026. Raspberry Pi OS images, kernels and bootloader releases change every few weeks; check the release notes and the rpi-eeprom release notes before planning an upgrade.