Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives

Raspberry Pi 4 with Samsung 950 Pro NVME SSD
Raspberry Pi 4 with Samsung 950 Pro NVME SSD

The Raspberry Pi 4 is finally here and has a lot of exciting changes. One very major downside is that it doesn’t support true USB booting yet out of the box (like the 3 series did). The Raspberry Pi foundation states that it is being worked on and will be added back with a future update. No timeline has been given yet for that to happen but they state it’s one of their top priorities.

Most of my projects heavily depend on having good performing storage so sitting and waiting was not an acceptable solution. In this guide I’ll show you a workaround to use USB devices as your rootfs device and use a Micro SD card as bootloader only which gives us full SSD performance after boot! To see exactly how much of a performance difference this makes (spoiler: it’s gigantic) check out the Raspberry Pi Storage Benchmarks.

I highly recommend doing this on a completely new install. If you try to upgrade your old ones and something goes wrong there’s a good chance you might lose data. We will be modifying the boot partition, resizing partitions, etc. so don’t use a drive with any data on it unless you are positive you have all of the steps down!

Compatible USB Adapters

The Raspberry Pi 4 is proving to be picky about what SATA, M.2, etc. adapters will work in the USB 3.0 port. The USB 3.0 ports are the ones in the middle that are blue inside. The black ones are USB 2.0 and won’t give you the faster speeds the new Pi offers.

It’s very likely that some of these will be fixed via software and firmware updates and the Raspberry Pi Foundation has several open known issues related to USB 3. Until that happens though I will maintain a list here of known working ones and known problematic ones. It’s still very early in the release of the Pi 4 so we still have a lot to learn about which adapters work / don’t work. If you have working and nonworking adapters leave a comment and I’ll add it in this list.

If the adapters worked before on older Pis then one thing you can try is putting them in the black USB 2.0 ports. Obviously this is stupid because we all want the Pi 4 performance gains but if you end up needing to buy a new adapter this will give you a workaround until a replacement arrives!

Find USB adapter chipset

There are certain chipsets used in adapters that are known to be working/not working.

pi@raspberrypi:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

This is a lsusb dump of all my connected USB devices. I have bolded the line with the USB bridge device. We can see that the chipset is ASM1153E

Known Good Chipsets

  • ASMedia ASM115X (StarTech 2.5″ SATA, several others)

Known Working Adapters

Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesStarTech 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.0Verified working great by myself and others on Pi 4
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesOrico Transparent 2.5″ SATA to USB 3.0 Enclosure2.5″ SATA to USB 3.1Confirmed working by Ashjas in comments
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesELUTENG 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.0The ELUTENG is one of the known working 2.5″ SATA to USB 3.0 adapters for the Pi 4
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesCSL 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.0The CSL SL adapter is confirmed to be working by Krikitt in the comments. Available in Europe. Not available in US.
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesShinestar NVME to USB 3.0 AdapterM.2 NVME to USB 3.0This is the adapter I’m using in the picture at the top of the article. It is for NVME M.2 drives only (need different one for M.2 SATA).
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesQNINE M.2 SATA to USB 3.0 EnclosureM.2 SATA to USB 3.0I used this enclosure to benchmark M.2 SATA Lite-On and SanDisk drives — working great in 3.0 ports.
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesTanbin mSATA to USB AdaptermSATA to USB 3.0I used this mSATA to USB adapter for my Crucial M550 benchmark — working in 3.0 ports.
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesGeneric mSATA to USB 3.0 Adapter (fe2008)mSATA to USB 3.1Confirmed working in comments by Nico
Raspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesRaspberry Pi 4 USB Boot Config Guide for SSD / Flash DrivesCanakit Raspberry Pi 4 Power Supply (USB-C)USB-C Power SupplyCanakit has been making very reliable power supplies for several Pi generations now

Known Problematic Adapters (VERY COMMON)

Fix (some) USB Adapter Problems Using Quirks

Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.

To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.

Find Your Adapter

To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:

$ sudo lsusb
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.

If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:

sudo dmesg | grep usb

 [    0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
 [    0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 [    0.828597] usb usb3: Product: DWC OTG Controller
 [    0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
 [    0.828644] usb usb3: SerialNumber: fe980000.usb
 [    0.830051] usbcore: registered new interface driver uas
 [    0.830182] usbcore: registered new interface driver usb-storage
 [    0.836488] usbcore: registered new interface driver usbhid
 [    0.836511] usbhid: USB HID core driver
 [    0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
 [    1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
 [    1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
 [    1.154281] usb 1-1: Product: USB2.0 Hub
 [    1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
 [    1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [    1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [    1.333026] usb 2-1: Product: ASM105x
 [    1.333048] usb 2-1: Manufacturer: ASMT
 [    1.333071] usb 2-1: SerialNumber: 123456789B79F

This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.

Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge

Our adapter’s ID is: 174c:55aa

Applying Quirks

To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt. Type:

sudo nano /boot/cmdline.txt

We are going to add the following entry into the very front of cmdline.txt:

usb-storage.quirks=XXXX:XXXX:u

In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):

usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.

Verifying Quirks

Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:

sudo dmesg | grep usb
 [    1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [    1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [    1.332983] usb 2-1: Product: ASM105x
 [    1.333006] usb 2-1: Manufacturer: ASMT
 [    1.333028] usb 2-1: SerialNumber: 123456789B79F
 [    1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [    1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [    1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
 [    1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
 [    1.336611] scsi host0: usb-storage 2-1:1.0

This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see storage benchmark section near the end).

USB Boot Instructions

There are a lot of steps to follow to set everything up properly. If you make a mistake the first time don’t spend too much time trying to correct it or figure out what you did wrong. It’s usually faster to burn the images again and reconfigure again rather than try to figure out which step you might have made a typo on. It’s much easier the second time!

Prepare SD Card

Download the latest Raspbian release from https://www.raspberrypi.org/downloads/raspbian/. Both Lite or Desktop versions will work. Win32DiskImager (Windows) or balenaEtcher (Linux, Mac OS X, Windows) are highly recommended to burn the images.

Note: Don’t attempt to use raw dd commands to write the images. Too many silly things can go wrong that are checked for/fixed by the recommended programs. Do yourself a big favor and use one of the recommends to avoid spending a ton of time troubleshooting basic imaging problems!

Preparing SSD

We are going to burn a second identical copy of Raspbian to the SSD. This ensures everything the Pi needs to boot is there so we can use the SD card as a bootloader but our actual system will be on our nice fast SSD drive.

Note: Make sure you create the empty file named “ssh” on the boot partition of both drives if you are headless or don’t have a mouse/keyboard attached so you can ssh in on the first boot.

First Boot (SD card only, SSD unplugged)

Insert your freshly imaged SD card into the Pi and connect the power. Sign into the Pi for the first time.

Don’t do an apt-get upgrade/dist-upgrade or any additional configuration yet. Just stick with the instructions until we have finished configuration (especially since if something goes wrong you may have to start over and any other setup you did will be lost).

Once the Pi has finished booting and you have signed in for the first time plug in your SSD to your Pi’s USB 3.0 ports. The USB 3.0 ports are the ones that have the blue plastic inside instead of the black plastic (the black ones are USB 2.0 ports).

Change PARTUUID

We need to change the PARTUUID of our SSD’s partitions so the Pi doesn’t get confused about what device to boot from. Right now the partitions on both the SD card and the SSD are an exact match and we need them to be different so we can tell the Pi to boot specifically from our SSD’s partition.

We are going to use fdisk to change the SSD’s PARTUUID to the hexadecimal d34db33f to make our SSD easy to identify. Use the following:

$ sudo fdisk /dev/sda

 Welcome to fdisk (util-linux 2.33.1).
 Changes will remain in memory only, until you decide to write them.
 Be careful before using the write command.
 Command (m for help): p
 Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
 Disk model: ASM105x
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0x6c586e13
 Device     Boot  Start       End   Sectors   Size Id Type
 /dev/sda1         8192    532479    524288   256M  c W95 FAT32 (LBA)
 /dev/sda2       532480 500118191 499585712 238.2G 83 Linux
 Command (m for help): x
 Expert command (m for help): i
 Enter the new disk identifier: 0xd34db33f
 Disk identifier changed from 0x6c586e13 to 0xd34db33f.
 Expert command (m for help): r
 Command (m for help): w
 The partition table has been altered.
 Syncing disks.

That’s it. Let’s verify our change using blkid:

$ sudo blkid

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="6c586e13-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="6c586e13-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="d34db33f-01"
/dev/sda2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="d34db33f-02"

Your /dev/mmcblk0 and /dev/sda devices should now be different from each other. The SD card’s ID is 6c586e13 and the SSD’s PARTUUID is now

Update /boot/cmdline.txt

We are going to change cmdline.txt to point to the SSD for booting instead of the SD card. First make a backup of your existing cmdline.txt file with the following command:

sudo cp /boot/cmdline.txt /boot/cmdline.txt.bak

We’ve now created a backup you can restore if something goes wrong. If you need to restore your backup plug the SD card into a computer/device and replace cmdline.txt with cmdline.txt.bak that we made above. Now your Pi should boot normally again.

Open up /boot/cmdline.txt using nano or your favorite text editor:

sudo nano /boot/cmdline.txt

The existing file will look like this:

console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

We are going to change the root=PARTUUID section to point to our new 0xd34db33f PARTUUID like the following:

console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

Make the change and double check the line is what it should be,then press Ctrl+X to save our changes.

Note: cmdline.txt should be one long solid line with no breaks — don’t add any line breaks or the system won’t boot and you’ll need to restore the backup we made earlier!

Test SSD

We are now ready to test booting from the SSD. Restart your Pi by issuing a

sudo reboot

The first boot with your SSD can be slow due to running fsck on the drive. If you have a really large SSD it can take surprisingly long to check all that space. Once the check completes it will mark the drive clean and skip the disk check from now on. It can take over a minute or two sometimes for really big drives so give it at least that much time before assuming it didn’t work.

After signing in we can verify that the SSD is being used like this:

$ findmnt -n -o SOURCE /

 /dev/sda2

Verify that partition has switched over as shown below to /dev/sda2 (SSD) instead of /dev/mmcblk0p2 (SD card).

Update /etc/fstab

We are now ready to edit the /etc/fstab file to point to our updated drive. To edit the file type:

sudo nano /etc/fstab

Your current file will look like this:

$ cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=6c586e13-02  /               ext4    defaults,noatime  0       1
sudo nano /etc/fstab

Your current file will look similar to this (PARTUUID varies based on your Raspbian image version):

cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=6c586e13-02  /               ext4    defaults,noatime  0       1

We want to change the root ( / ) partition (PARTUUID ending with -02) to load our SSD’s PARTUUID instead of the SD card. Replace the 2nd partition’s PARTUUID field on the last line in the file with the d34db33f label we applied earlier with fdisk. After making the change my /etc/fstab file looks like this:

proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=d34db33f-02  /               ext4    defaults,noatime  0       1

Press Ctrl+X to tell nano to save our changes. Now type sudo reboot to restart the Pi.

Note: We want to leave the first partition (/boot) on the SD card. If you change this to the SSD then apt will update your SSD instead of the SD card so they won’t be used during boot! Remember that we are using the SD card as a bootloader and that is why the firmware updates (such as start.elf, etc) should go there instead of the SSD’s boot partition (which is never used).

Resizing Filesystem

By default the partition on the SSD / Flash drive will only be 1.8G. The Pi expands this automatically on micro SD drives but we will need to do it ourselves for a SSD / Flash drive. To do this we need to expand the partition and then resize the file system.

First let’s open fdisk and print the partitions:

pi@raspberrypi:~ $ sudo fdisk /dev/sda
 Welcome to fdisk (util-linux 2.33.1).
 Changes will remain in memory only, until you decide to write them.
 Be careful before using the write command.
 Command (m for help): p
 Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
 Disk model: ASM105x
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0xd34db33f
 Device     Boot  Start     End Sectors  Size Id Type
 /dev/sda1         8192  532479  524288  256M  c W95 FAT32 (LBA)
 /dev/sda2       532480 4390911 3858432  1.9G 83 Linux

There is the line we need. Our start value for /dev/sda2 (rootfs) is 532480. Next we need to remove and recreate the partition as a larger size.

If you make any mistakes during this command just close fdisk by pressing q. The changes won’t be written to disk. If you mess up any of the commands the drive will no longer boot and you’ll have to start over again so be careful!

Command (m for help): d
 Partition number (1,2, default 2): 2
 Partition 2 has been deleted.
 Command (m for help): n
 Partition type
    p   primary (1 primary, 0 extended, 3 free)
    e   extended (container for logical partitions)
 Select (default p): p
 Partition number (2-4, default 2): 2
 First sector (2048-500118191, default 2048): 532480
 Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-500118191, default 500118191): 500118191 
 Created a new partition 2 of type 'Linux' and of size 238.2 GiB.
 Partition #2 contains a ext4 signature.
 Do you want to remove the signature? [Y]es/[N]o: N
 Command (m for help): w
 The partition table has been altered.
 Syncing disks.

If everything went well then type “w” and press enter. Otherwise press “q” to quit and try again. Once you enter “w” the changes will be permanently written to disk!

Now reboot the system. Type “df -h” to view the current disk:

pi@raspberrypi:~ $ df -h
 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       1.8G  1.3G  415M  76% /
 devtmpfs        1.8G     0  1.8G   0% /dev
 tmpfs           2.0G     0  2.0G   0% /dev/shm
 tmpfs           2.0G  8.5M  1.9G   1% /run
 tmpfs           5.0M  4.0K  5.0M   1% /run/lock
 tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
 /dev/mmcblk0p1  253M   52M  201M  21% /boot
 tmpfs           391M     0  391M   0% /run/user/1000

We can see our disk is still 1.8G even after resizing the partition. That’s because we still have one more step! We need to resize the filesystem to fill our new partition space. For this we will use “sudo resize2fs /dev/sda2”:

sudo resize2fs /dev/sda2
 resize2fs 1.44.5 (15-Dec-2018)
 Filesystem at /dev/sda2 is mounted on /; on-line resizing required
 old_desc_blocks = 1, new_desc_blocks = 15
 The filesystem on /dev/sda2 is now 62448214 (4k) blocks long.

Now let’s check df -h again:

pi@raspberrypi:~ $ df -h
 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       235G  1.3G  224G   1% /
 devtmpfs        1.8G     0  1.8G   0% /dev
 tmpfs           2.0G     0  2.0G   0% /dev/shm
 tmpfs           2.0G  8.5M  1.9G   1% /run
 tmpfs           5.0M  4.0K  5.0M   1% /run/lock
 tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
 /dev/mmcblk0p1  253M   52M  201M  21% /boot
 tmpfs           391M     0  391M   0% /run/user/1000

And that’s it! You will now be using all of your space on your drive.

Update Pi using apt

Now that we’ve updated fstab it is safe (and highly recommended) to update your Pi’s software. Type “sudo apt-get update && sudo apt-get dist-upgrade” to update the system and firmware.

Your system will now be running completely from your USB drive! To verify this, run the command “findmnt -n -o SOURCE” / to ensure your root partition has switched over as shown below to /dev/sda2 instead of /dev/mmcblk0p2.

Verify SSD Performance

You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

This will give you a score you can compare to the other Raspberry Pi Storage Benchmark results and make sure that you are getting an equivalent speed to your peers with the same device!

Conclusion

The Samsung 950 Pro NVME drive in the featured picture scored a 9189 on the Raspberry Pi Storage Benchmark. The previous all-time record score on a Pi 3B+ was 3561. The performance gains are very real and very dramatic.

For me getting this performance is well worth having to waste a micro SD card just to be a bootloader. I am largely after the USB 3.0 bus and gigabit ethernet performance improvements and using this method I am able to achieve the performance I was after without waiting an indeterminate amount of time for the feature to be added back in!

Although there are ongoing compatibility issues and we lack the super easy native USB booting support we had before I’m more than willing to go through the growing pains to finally get rid that ancient USB 2.0 bus! Just make sure if you are planning to build a system you plan your adapters and parts accordingly.

227 thoughts on “Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives”

  1. Avatar for Dennis Aker

    I have followed your procedure and everything is working great. To this time I have been making backups using Win32 disk image on a pc then copping them back to a single Micro SD Card. I have tried copying the SSD drive img to a micro SD and booting from that but my PI 4 does not boot. With this new split boot system how do you recommend doing system backups?

    1. Avatar for jamesachambers

      Hey Dennis,

      The key part with the split system is that very little of the micro SD partition is being used. In fact, the only thing it contains are the bootloader files. It isn’t necessary to backup anything on this drive except maybe your config.txt and cmdline.txt if you have some customizations.

      Basically, I’d just set any system backups to get the rootfs partition and ignore the SD card partition since there’s no data stored on it that isn’t replaced automatically by a new reimage!

      1. Avatar for Dennis Aker

        Thanks for the reply,
        My PI is being used solely to run Home Assistant witch I seem to make changes often and also do backups frequently. My concern is my human error and also hardware failure of my one SSD drive. What I would like to be able to do is copy the the entire system back to 1 SD drive in case of some unknown error.
        Thanks!!
        Dennis

  2. Avatar for Steve Guy

    I got the “QNINE M.2 SATA to USB 3.0 Enclosure” listed above (wrong picture, btw) and I was having all sorts of problems with it. I was getting errors in Windows and it was hopeless trying to get it to boot the pi. Thankfully, I decided to try switching out the USB 3 micro cable another one I wasn’t using. Fixed it immediately. Check your cables, people.

  3. Avatar for Jeff

    Two questions:

    What is the result of NOT changing the /etc/fstab file? I switched back to the old boot from SD card for a bit to do a benchmark of this, and when I had just the SD card installed, I edited the cmdline.txt and the fstab file to their states when they were configured for the SSD. When I connected the SSD back up and rebooted, I noticed that I didn’t have the “rootfs” desktop shortcut, which I assume is the SSD’s copy of the root folder. I then checked the /etc/fstab file and found that it was unchanged. I edited it again, and now both the boot and rootfs shortcuts are back. My assumption is that the /etc/fstab file needs to be edited on the SSD’s file structure, and since I edited it initially with only the SD card installed, the file on the SSD was unchanged. It all worked, and the findmnt command indicated the SSD drive before i fixed the file on the SSD. Again – not a big deal from my end, since I got it fixed, but I am curious what the effect would have been if I had left it that way.

    Secondly, I am interested in trying this with another SSD and SD card with Ubuntu 19.10 installed. Would the process be basically the same? I ran into some roadblocks in getting the SD card flashed correctly with the Ubuntu image, but once I resolve that I would like to try this. (I got the flash to work once, but decided I wanted to try a different desktop and I haven’t been able to get the flashed image(s) to boot in the Pi4 since that initial success).

    Thanks!

    Just curious – would the above process (or some variation

    1. Avatar for jamesachambers

      The result of not changing /etc/fstab is that your kernel firmware upgrades from apt will go to the wrong device and won’t be used when the Pi is booting up. These updates are the files on your boot partition like start*.elf, bootcode.bin, etc. and are loaded in the very early bootloader stage.

      You want the updates to go to the SD card boot partition (/dev/mmcblk0p1) so that these updated firmware versions get used. If you don’t change /etc/fstab file it will mount the SSD’s /boot partition (which isn’t used during the bootloader process) and updates from apt-get dist-upgrade will go to that partition instead of your SD card partition.

      The world won’t end because of this as long as your Pi is booting correctly, but you also won’t be getting any of the fixes for the bootloader / GPU firmware elf files / etc. that may improve performance/fix bugs/reduce power consumption and you definitely don’t want to miss out on them!

      1. Avatar for Jeff

        Thanks! I did fix it – it only ran that way for half a day (idle) before I realized my mistake.

        Did you have any thoughts on the other half of the question (moving an Ubuntu installation to SSD)? I am still working on getting the SD card version working, as I think I killed the SD card by cancelling (ctrl-c) a dd operation. I bought a new card and I am working on that one now, but waiting for flash to finish.

  4. Avatar for zeronet.io

    On RPi-four B the process was much simplier:
    1. connect USB drive into RPi USB3 port
    2. boot raspbian (10 buster) go to rpi menu, Accessories, SD card copier. Select drives and tick to generate new UUIDs
    3. once finished, open terminal and run:
    lsblk
    that would give you idea about name of the root “/” partitions on both drives. In my case it was partition 7 so i ran:
    sudo sed -i “s/mmcblk0p7/sda7/g” /etc/fstab
    sudo sed -i “s/mmcblk0p7/sda7/g” /boot/cmdline.txt
    reboot
    and i am now booting from USB drive and no partition resizing was needed.

  5. Avatar for Scootz

    The product link for “Shinestar NVME to USB 3.0 Adapter” is not correct. That URL delivers you to product “ELUTENG USB3 SATA Adapter 2.5 Inch SATA to USB 3.0 Cable”

  6. Avatar for Jeff

    I am struggling with the Sabrent adapter that is listed as non-working, and I just wanted to find out if I can get it working with the quirks.

    I modified the cmdline.txt file to ONLY add the quirks function (didn’t modify to make it boot off the SSD). I am using a 120GB PNY SSD.

    The problem I run into is that it refuses to boot with the drive connected to either the USB2 or USB3 ports. The boot process stops, with an error message in the verbose boot list stating:
    [FAILED] Failed to mount /boot.
    see systemctl status boot.mount for details.
    [DEPEND] Dependency failed for Local File System
    ….
    You are in emergency mode. After logging in….

    Cannot open access to console, the root account is locked.
    See sulogin(8) man page for more details.
    Press enter to continue

    If i press enter, it states:
    Starting default target
    You are in emergency mode… (same notes as above)

    Without the adapter connected, it boots fine, and if i plug adapter in after boot, it works fine.

    Could the problem be that the SSD isn’t loaded properly with the files? Only one partition shows up on the SSD (just linux partition) – there is no windows partition. I used the rsync command to copy all the files from the SD card to the SSD.

    Any suggestions out there?? I have a StarTech adapter on order, but it wont arrive for 2 days – I just wanted to get this set up as much as possible before it arrives, but I am stumped.

    I previously used the SD card copier utility on the Pi4 to clone the SD to the SSD (and this appeared to copy the windows partition to the drive). When I did this, I was using a different Sabrent adapter that was identified as an Innostor adapter (it has multiple interfaces to handle all the different HDD configurations).

    Thanks for any help!

    1. Avatar for Jeff

      Update: I cloned the SD card to the SSD again, and after doing so, I was able to get it working.

      I can get it to boot from SSD when plugged into the USB2 ports with no quirks enabled, and in order to get the connection to boot from SSD when connected to the USB3 port, I had to enable the quirks. Speed with USB2 was 2179. Speed with quirks on USB3 was 4769.

      1. Avatar for jamesachambers

        Hey Jeff,

        I’m glad you were able to get it! 4769 isn’t that bad for having quirks enabled, I think my Samsung 850 Pro dropped from 6000+ all the way down to the low 4000s when I turned the quirks on.

        However, if you’re using the Sabrent adapter, you have to turn the quirks on or it won’t work as you found!

        1. Avatar for Jeff

          I am still curious about the failure mode I was initially experiencing (with the failure to mount the /boot). That was a different failure mode than I experienced after trying to use the Sabrent without quirks (and after cloning the card with the SD Card Copier). The second failure led to a very slow loading of the various [OK] checks during the boot process, and a LOT of eventual [FAILED] messages. Does there need to be a windows/dos partition on the SSD for all this to work??

          1. Avatar for Jeff

            And I should add that this PNY drive cost me about $20. It has really improved performance. I was getting constant freezes as the green LED on the pi would come on solid for 5-10 seconds at a stretch, making the desktop mostly unresponsive – especially using Chromium. That is essentially gone now.

            Thanks for this post – it was VERY helpful!

  7. Avatar for yoshida

    Hi,

    Is it possible that the “Edit /etc/fstab File” section’s example is wrong? If I read the text, I understand, that I have to change the UUID of the boot partition only, from the USB drive’s UUID, to the sd card’s UUID. But the exmples shows differently.

    1. Avatar for admin user

      Yoshida, I agree.

      In step 8, James states “We want to change the /boot partition (ending with -01) to load our Micro SD cards PARTUUID instead of the USB drives. To do this simply replace the PARTUUID field on the line that has /boot in it with the PARTUUID from mmcblk0p1. After making the change my /etc/fstab file looks like this”

      — but – the examples seem to have the ID of the SSD and SD reversed.

      And – both partitions have the same PARTUUID. It’s confusing.

      Or, am I misunderstanding something here?

        1. Avatar for jamesachambers

          Hey admin user,

          Sorry about that. I rewrote the entire section after reading your comment and rechecking the article and it’s much easier to follow now since it’s broken out into sections with details instead of one big numbered list. Thanks for the feedback!

          1. Avatar for admin user

            thanks! your clarifications now have me successfully booting from SSD – much appreciated updates made the difference!

            if you wanted to do a tutorial about encrypting that SSD (and booting it afterwards), I’m all ears – otherwise that is my next self-assigned mission.

            I really appreciate you taking the time to lay this out in detail.

    2. Avatar for radek

      Agree with Yoshida.
      In original fstab, both partition pointed to SD card. From text I understand, that I left PARTUUID for boot partition to SD card and change second partition to USB drive.
      But in example, both partition are change to USB drive. Whats correct please?

  8. Avatar for admin user

    please give more details regarding step 2: Prepare SSD / Flash Drive – Image your SSD or Flash Drive. Make sure you create the empty file named “ssh” on the boot partition of both drives.

    Since I cannot boot from the SSD, what is the specific procedure for imaging the SSD? Is is a clone of the SD?

    I would appreciate much more detail, or maybe it is simpler than I realize…

    1. Avatar for admin user

      ok, I figured it out (I think) – start from SD, hold shift, when asked to recover, select the SSD and the image is copied there.

      will continue forward and see how things pan out – thanks for this guide – it’s better and more through than any other guide for booting the Raspberry Pi4 from SSD that I have found so far.

      My next challenge will be to encrypt the SSD, but still boot from it securely!

        1. Avatar for radek

          Hi, please can you descrive step 2, I still dont understand. I have RPi4 (without monitor and keyborad) – using only SSH. And brand new SSD (SATA) without partition.
          So in 1. step I flash Raspbian on SD card (using Ethcher), but what can I do in step 2 with SSD? Flash raspbian (with Etcher) also?
          Thanks for adivise!

          1. Avatar for admin user

            Hi Radek,

            The way I got Raspbian installed on the SSD was:

            (1) install NOOBS on the SD using my (non-RPi) computer.
            (2) connect mouse, keyboard, monitor, (but NOT the SSD) to the Pi.
            (3) boot the Pi from the SD. Choose Raspbian version and configure, allow installation to proceed.
            (4) after all updates, etc, shut down and power off the Pi.
            (5) connect the SSD to the USB3 port.
            (6) power up the Pi.
            (7) hold down SHIFT when the message is displayed on the monitor
            (8) because NOOBS sees more than one volume attached, you are given the option of where to install Raspbian.
            (9) choose your SSD and allow installation to proceed.

            All of these nine steps above will get you through steps 1 & 2 of James’ article. From this point you can pick up at step three of his instructions.

            1. Avatar for zasaintr

              After installing raspbian OS by NOOBS, there is a confirmation message with an OK button and when pressed it reboots.
              How can we continue with step 3 (Boot / Update Raspberry Pi – Start up your Raspberry Pi with only the SD card in the slot. After the Pi finishes booting up plug in your SSD / Flash drive.) when the ssd is already plugged in? remove the power supply? remove the ssd prior pressing OK?

          2. Avatar for admin user

            Hi Radek,

            I was wrong. You definitely flash raspbian to the SSD. Ignore my instructions – they don’t work.

            I used balenaEtcher.

            Apologies – it’s all a learning experience…

  9. Avatar for Wes Peters

    I got the Tanbin mSATA to USB 3.0 interface today. Plugged in a 64GB mSATA from SwissBit, stuffed it in the Pi, and BOOM. I don’t think it was power, the power peaked at 1.2A and my little power brick can happily provide almost 5a at 5.1V. It won’t boot with the Tanbin in, and inserting it while running crashes the Pi every time. It works OK on my MacBook. Very frowny face, since I have a dozen 64B mSATA modules just looking for an actual use.

  10. Avatar for ashjas

    Hi, i got to have it working for:
    ORICO 2.5” Transparent Type-C Hard Drive Enclosure Type-C to SATA3.0 for SSD/HDD, USB3.1 Gen2 10Gbps UP to 4TB

    Firstly, i went ahead with the usb-quirks option with this enclosure, which also worked, but when i benchmarked, the score was around 6K.

    Then i removed the usb-quirks options, and that too worked, and also much faster than with quirks options, 8.5K score!

    So i confirm that,the orico enclosure with Type-C USB3.1 Gen2 version, model: 2139C3-G2 works out of the box, now quirk tweaking required.

    Thanks for this awsome post btw.

    1. Avatar for jamesachambers

      Those are great scores!

      I just did some testing on my Samsung 850 Pro and my score dropped from 6200 to about 3800 when I turned the quirks on.

      I’m updating the Raspberry Pi benchmarks to show what adapters people are using and also if they have the quirks on or not. It should make tracking the differences much easier!

  11. Avatar for Kevin

    Re Sabrent cables: I can confirm that the Pi will not boot if connected to a USB3.0 port.

    Neither will it boot if connected via a cheap $5 eBay “powered” hub.

    In both cases UAS is not operable.

    Connecting via a StarTech hub enables the Pi to boot – but still no UAS.

    Changed to a StarTech cable, via the StarTech hub, and all is OK – and UAS works.

    1. Avatar for jamesachambers

      Hey ninosr,

      Yes. For Ubuntu you will write the image to both a SD card and a SSD. Then you go into /boot/firmware/cmdline.txt and change root=/dev/mmcblk0p2 to root=/dev/sda2 and then reboot. It will then boot the root partition from the SSD (it should reset the password back to ubuntu/ubuntu).

      1. Avatar for Thanh

        Hi jamesachambers
        My is as below
        pi@raspberrypi:~ $ sudo blkid
        /dev/mmcblk0p1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”9F2D-0578″ TYPE=”vfat” PARTUUID=”5e3da3da-01″
        /dev/mmcblk0p2: LABEL=”rootfs” UUID=”efc2ea8b-042f-47f5-953e-577d8860de55″ TYPE=”ext4″ PARTUUID=”5e3da3da-02″
        /dev/sda1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”9F2D-0578″ TYPE=”vfat” PARTUUID=”5e3da3da-01″
        /dev/sda2: LABEL=”rootfs” UUID=”efc2ea8b-042f-47f5-953e-577d8860de55″ TYPE=”ext4″ PARTUUID=”5e3da3da-02″
        /dev/mmcblk0: PTUUID=”5e3da3da” PTTYPE=”dos”

        mmcblk0p2 & sda2 are identical ;-}

  12. Avatar for Simon

    My fstab file does not have partuuids in it. I’ve managed to run a script to change the partuuids so there different but now im stuck.

Leave a Comment

Your email address will not be published. Required fields are marked *

Type here..