How do I switch OSes on a headless Pi 5?

SSH in and run sudo -E rpi-eeprom-config --edit to change BOOT_ORDER, then reboot. Or physically remove the highest-priority device to force fallback to the next in the order.

Does boot order affect storage access after boot?

No. BOOT_ORDER only determines which device the Pi boots from. All connected storage is accessible once the OS is running regardless of boot order.

Is it safe to enable PCIe Gen 3 for NVMe on Pi 5?

It is supported but not enabled by default due to compatibility variation. Add dtparam=pciex1_gen=3 to config.txt to enable. Remove it if instability or dmesg errors occur.

Pi 5 Multiboot SD USB NVMe: Complete 4-Step Guide

Q: Can I boot multiple OSes from the same USB drive?

Yes, with PINN or by manually partitioning the drive with separate boot and root partitions for each OS. PINN handles the boot menu automatically.

Q: Why is my NVMe not showing up at boot?

Common causes: loose FPC cable, incompatible adapter board, drive exceeding power budget, missing 0x6 in boot order, or outdated EEPROM firmware. Check with lspci and dmesg.

Pi 5 multiboot SD USB NVMe lets you run different operating systems from separate storage devices and control which one boots using the EEPROM boot order configuration. The Raspberry Pi 5 reads its bootloader from onboard EEPROM rather than the SD card, which means boot order is set once in firmware and persists across power cycles. This guide covers EEPROM configuration, boot order hex values, per-device OS installation, and the most reliable approaches to switching between operating systems.

Last tested: Raspberry Pi OS Bookworm Lite 64-bit | January 8, 2026 | Raspberry Pi 5 (8GB) | EEPROM 2024-11-12 | WD Black SN770M NVMe via Pimoroni NVMe Base

Key Takeaways

The Pi 5 boot order is controlled by a hex value in EEPROM, not by which storage device is inserted first. Set it once with rpi-eeprom-config and it persists.
Boot order nibble values: 0x1 = SD card, 0x4 = USB MSD, 0x6 = NVMe, 0xf = restart loop. A value of BOOT_ORDER=0xf641 tries NVMe first, then USB, then SD, then restarts.
Each OS on each device needs its own /boot/firmware/ partition (FAT32) and root filesystem (ext4). They cannot share a boot partition.
On Bookworm, boot files are in /boot/firmware/, not /boot/. Any guide referencing /boot/cmdline.txt or /boot/config.txt without the firmware/ path is using the old layout.
NVMe SSDs must draw under approximately 2.5W without an external power source. Check your SSD’s TDP before installing.
Back up /boot/firmware/config.txt, cmdline.txt, and the EEPROM config before making changes. A broken boot config requires booting from a different device to recover.

Pi 5 multiboot SD USB NVMe diagram showing EEPROM boot order controlling which storage device the Pi boots from

How Pi 5 Multiboot SD USB NVMe Works

The Raspberry Pi 5 boot sequence starts in Boot ROM, which is fixed in silicon and reads the bootloader from onboard EEPROM. The EEPROM bootloader contains the BOOT_ORDER setting that determines which storage devices are tried and in what sequence. This is the key difference from earlier Pi models where boot order depended on whether an SD card was present.

Each storage device in a multiboot setup contains a complete, independent OS installation. The Pi attempts each device in the order specified by BOOT_ORDER, tries to read a valid boot partition from it, and boots the first one it finds. If a device is absent or its boot partition is unreadable, the Pi moves to the next device in the sequence. There is no shared bootloader selecting between OSes. Each device boots independently.

Understanding the EEPROM Boot Order

The BOOT_ORDER value is a hexadecimal string read right to left. Each nibble (single hex digit) represents one boot source. The Pi tries each source in right-to-left order, retrying the full sequence if nothing boots.

Hex value	Boot source	Notes
`0x1`	SD card	microSD slot
`0x2`	Network (PXE)	Requires DHCP server with TFTP
`0x4`	USB MSD	USB mass storage device
`0x5`	BCM USB MSD	USB boot via Broadcom USB controller
`0x6`	NVMe	PCIe NVMe SSD (Pi 5 only)
`0xf`	Restart loop	Restart and retry from beginning of order

Example boot order values:

BOOT_ORDER=0xf41: SD first, USB second, restart if neither found
BOOT_ORDER=0xf641: NVMe first, USB second, SD third, restart if none found
BOOT_ORDER=0xf461: NVMe first, SD second, USB third
BOOT_ORDER=0xf6: NVMe only, restart loop if not found

Step 1: Update EEPROM Firmware

Before changing boot order, update the EEPROM to the latest stable release. Boot from SD card with Raspberry Pi OS Bookworm:

sudo apt update
sudo apt full-upgrade -y
sudo rpi-eeprom-update -a
sudo reboot

After reboot, check the installed version:

vcgencmd bootloader_version

Expected result: The version date shown matches the latest release on the rpi-eeprom releases page. No warning about pending updates.

Step 2: Configure the Boot Order

Check the current EEPROM configuration:

rpi-eeprom-config

Edit the configuration to set your desired boot order:

sudo -E rpi-eeprom-config --edit

This opens the current config in a text editor. Find or add the BOOT_ORDER line. For NVMe first, USB second, SD third:

BOOT_ORDER=0xf641

Save and exit. The new EEPROM image is written on the next reboot. Confirm the change took effect:

rpi-eeprom-config | grep BOOT_ORDER

Expected result: BOOT_ORDER shows the value you set. The Pi boots from the highest-priority available device on the next power cycle.

Step 3: Install an OS on Each Device

OS installation with Raspberry Pi Imager

Flash each OS to its target device using Raspberry Pi Imager. Select the OS, select the target device (SD card, USB drive, or NVMe via USB adapter), and use the advanced settings to configure hostname, SSH, Wi-Fi credentials, and user. Each device gets a completely independent OS installation.

For NVMe, connect the drive via a USB-to-NVMe adapter to flash it from another machine, or flash it while installed in the Pi using:

# Flash NVMe while booted from SD card
# NVMe device appears as /dev/nvme0n1
sudo rpi-imager
# Or use dd:
sudo dd if=image.img of=/dev/nvme0n1 bs=4M status=progress conv=fsync

Recommended OS per device

Device	Suitable OS options	Notes
NVMe SSD	Raspberry Pi OS, Ubuntu Server, DietPi	Fastest boot and I/O; use for primary or high-performance OS
USB SSD/drive	Ubuntu Server, Kali, Manjaro	More reliable than USB flash drives for sustained use
SD card	Raspberry Pi OS, recovery image	Useful as fallback; high-endurance card recommended

Verify boot partition on each device

# List all storage devices and partitions
lsblk -f

# Check that each device has a FAT32 boot partition
# and an ext4 root partition
# Boot partition should be labelled 'bootfs'
# Root partition should be labelled 'rootfs'

Expected result: Each target device shows a FAT32 partition (boot) and ext4 partition (root). The boot partition on each device contains config.txt, cmdline.txt, and initramfs files.

Step 4: Configure Each OS Boot Partition

Each OS’s /boot/firmware/cmdline.txt must reference the correct root partition UUID for that device. After flashing, mount each boot partition and verify:

# Get UUID of the root partition on each device
blkid /dev/nvme0n1p2   # NVMe root
blkid /dev/sda2         # USB root
blkid /dev/mmcblk0p2    # SD root

# Check cmdline.txt on each boot partition points to the correct UUID
# Mount the NVMe boot partition
sudo mount /dev/nvme0n1p1 /mnt
cat /mnt/cmdline.txt
# Should contain: root=PARTUUID=<nvme-root-partuuid>
sudo umount /mnt

If any cmdline.txt references the wrong partition (a common result of cloning), update it to the correct PARTUUID. A mismatch causes the Pi to find a valid boot partition but fail to mount the root filesystem, resulting in a kernel panic.

Expected result: Each device’s cmdline.txt contains a root=PARTUUID= value matching that device’s root partition, confirmed by blkid.

Switching Between Operating Systems

Method 1: EEPROM boot order (persistent)

Change BOOT_ORDER in the EEPROM config to permanently change which device boots first. This is the cleanest method for setups where one device is the primary and another is a testing or recovery option.

# Switch to SD-first boot order
sudo -E rpi-eeprom-config --edit
# Change BOOT_ORDER to 0xf416 (SD, USB, NVMe)
sudo reboot

Method 2: Physical device removal

The simplest method for occasional switching: remove the higher-priority device so the Pi falls through to the next in the boot order. Removing the NVMe drive (or disconnecting the HAT) forces the Pi to boot from USB or SD depending on the remaining order. No software changes required.

Method 3: Multiboot managers (BerryBoot / PINN)

BerryBoot installs multiple OSes to a single storage device as compressed squashfs images and presents a selection menu at boot. It works but limits access to the raw filesystem and adds a layer of indirection that can complicate troubleshooting.

PINN (Put In New NOOBS) is more flexible. It installs each OS to a separate partition with its own boot entry and supports installing OSes across different physical devices. It is the better choice if you want a graphical boot menu without the squashfs constraint. Both are installed by flashing the manager image to SD and following the on-screen setup.

NVMe-Specific Setup

Compatible NVMe adapters

The Pi 5 exposes a PCIe 2.0 x1 connector via the FPC slot. An NVMe HAT or base board connects an M.2 NVMe SSD to this connector. Verified compatible boards include the Pimoroni NVMe Base, Waveshare PCIe to M.2 HAT, and the official Raspberry Pi M.2 HAT+. Generic adapters without active power delivery may cause instability. Check the adapter’s compatibility list before purchasing. See Raspberry Pi 5 NVMe Boot Guide for detailed adapter setup.

NVMe power considerations

The Pi 5 can supply approximately 2.5W to the NVMe slot without external power augmentation. High-performance SSDs with TDP above this threshold (many full-size M.2 drives) will cause instability or failure to enumerate. M.2 2230 form factor drives designed for handheld devices generally stay within budget. Check the SSD’s datasheet for idle and active power draw before installing.

# Check if NVMe is detected
lspci
ls /dev/nvme*

# Check NVMe health and temperature
sudo apt install nvme-cli -y
sudo nvme smart-log /dev/nvme0

Enabling PCIe Gen 3 (optional)

The Pi 5 PCIe interface defaults to Gen 2. Gen 3 is officially supported but not enabled by default. To enable it, add to /boot/firmware/config.txt:

dtparam=pciex1_gen=3

Not all NVMe drives and adapters are stable at Gen 3. Test thoroughly before relying on this setting in production. Revert by removing the line if instability occurs.

USB Boot Considerations

USB flash drives are unreliable for sustained OS use due to write endurance limitations and poor random I/O performance. Use a USB SSD rather than a flash drive for any OS you plan to use regularly. USB boot works without additional EEPROM changes beyond adding 0x4 to the boot order.

USB devices that draw more than 600mA from a single port may cause boot failures or device disconnects. High-power USB SSDs with their own power input are more reliable in multiboot setups where both USB and NVMe are active simultaneously. If a USB drive boots inconsistently, test it on a different USB port or with a powered USB hub.

Cloning and Backups

# Clone SD card to NVMe
sudo apt install rpi-clone -y
sudo rpi-clone nvme0n1

# Full image backup of NVMe
sudo dd if=/dev/nvme0n1 of=/mnt/backup/nvme-backup.img bs=4M status=progress

# Incremental backup with rsync (excludes /proc, /sys, /dev)
sudo rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*"} / /mnt/backup/

After cloning with dd or rpi-clone, verify that the cloned device’s cmdline.txt references the correct PARTUUID for its own root partition. Cloning copies the source device’s PARTUUID references. These must be updated to match the destination device’s partition UUIDs before the clone will boot correctly.

For long-term storage health across all three device types, see Setting Up zram on Raspberry Pi to reduce write pressure, and Preventing SD Card Corruption on Raspberry Pi for the SD fallback device.

Troubleshooting

Pi boots from wrong device

# Check current boot order
rpi-eeprom-config | grep BOOT_ORDER

# Check which device the running OS is on
findmnt /
lsblk

If the Pi boots from a lower-priority device, the higher-priority device either has no valid boot partition or its partition is unreadable. Connect the device to another machine and verify the FAT32 boot partition contains a valid config.txt and kernel image.

NVMe not detected

# Check PCIe enumeration
lspci | grep -i nvme

# Check kernel messages for NVMe errors
dmesg | grep -i "nvme\|pcie\|pci"

If lspci shows no NVMe device, check the FPC cable connection between the Pi and the adapter board. A loose cable is the most common cause. Also confirm the EEPROM boot order includes 0x6. If using Gen 3, revert to Gen 2 by removing the dtparam=pciex1_gen=3 line from config.txt.

Kernel panic after finding boot partition

A kernel panic during boot typically indicates that the root partition specified in cmdline.txt cannot be found or mounted. Check that the PARTUUID in cmdline.txt matches the actual root partition UUID shown by blkid. This mismatch is the most common consequence of cloning without updating the UUID references.

EEPROM recovery

If an EEPROM change prevents booting from all devices, recover using the EEPROM recovery image: download the latest recovery image from the Raspberry Pi firmware repository, flash it to an SD card, and boot from it with no other storage attached. The Pi will automatically restore the EEPROM to a working state.

# Download recovery image and flash to SD
# See: https://github.com/raspberrypi/rpi-eeprom/releases
# Flash recovery image with Raspberry Pi Imager
# Boot with SD only -- EEPROM restores automatically

Boot Performance Optimisation

# Reduce EEPROM boot delay (default is 1000ms)
sudo -E rpi-eeprom-config --edit
# Add or modify:
BOOT_DELAY=0
BOOT_UART=0  # Disable boot UART output if not needed

Setting BOOT_DELAY=0 removes the pause the bootloader waits before trying each device. This is safe once you have confirmed the boot order is correct and all devices are reliable. Disable it during initial setup so you have time to interrupt the boot if needed.

In the OS, apply standard boot speed improvements to /etc/fstab:

# Add noatime to reduce unnecessary writes on root mount
# Example fstab entry:
PARTUUID=xxxxxxxx-02  /  ext4  defaults,noatime  0  1

FAQ

Can I boot multiple OSes from the same USB drive?

Yes, with a multiboot manager like PINN or by manually partitioning the drive and configuring each OS with its own boot and root partitions. You also need a bootloader or script that selects which OS to load. PINN handles this automatically. The manual approach requires editing cmdline.txt on each boot partition to point to the correct root partition.

How do I switch OSes on a headless Pi?

SSH into the running OS and use sudo -E rpi-eeprom-config --edit to change the boot order, then reboot. The Pi boots from the newly prioritised device on the next start. Alternatively, physically remove the highest-priority device to force a fallback to the next device in the boot order.

Why is my NVMe not showing up at boot?

The most common causes are a loose FPC cable between the Pi and the NVMe adapter, an unsupported or incompatible adapter board, a drive exceeding the power budget, an incorrect boot order (missing 0x6), or outdated EEPROM firmware. Check each in that order using lspci and dmesg.

Does the boot order affect the device used for storage, or just boot?

The BOOT_ORDER setting only determines which device the Pi attempts to boot from. Once the OS is running, all connected storage devices are available regardless of boot order. You can boot from NVMe and access SD card data simultaneously.

Is it safe to enable PCIe Gen 3 for NVMe?

The Raspberry Pi Foundation has indicated Gen 3 is supported on Pi 5 hardware but does not enable it by default due to compatibility variation across NVMe drives and adapter boards. It is safe to test with dtparam=pciex1_gen=3 in config.txt. If the drive shows instability, errors in dmesg, or reduced performance, remove the line and revert to Gen 2.

References

About the Author

Chuck Wilson has been programming and building with computers since the Tandy 1000 era. His professional background includes CAD drafting, manufacturing line programming, and custom computer design. He runs PidiyLab in retirement, documenting Raspberry Pi and homelab projects that he actually deploys and maintains on real hardware. Every article on this site reflects hands-on testing on specific hardware and OS versions, not theoretical walkthroughs.

Last tested hardware: Raspberry Pi 5 (8GB), WD Black SN770M NVMe via Pimoroni NVMe Base. Last tested OS: Raspberry Pi OS Bookworm Lite 64-bit. EEPROM 2024-11-12.