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, UGREEN USB Enclosure, 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 DrivesUGreen M.2 SATA to USB 3.1 EnclosureUGreen M.2 SATA to USB 3.1 EnclosureReported as working well in the comments by John H. Reinhardt with a ASM1051E chipset
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 (https://origin.jamesachambers.com/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.

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

  1. Avatar for billy

    Thanks for the excellent guide.

    I’ve re-purposed an old Crucial M4 120GB on the RPi4 using the ELUTENG adapter, and it just works.

    I was a bit unsure about using fdisk to resize the SSD, so installed gparted and did it that way, and once resized and rebooted the file system already filled the new partition size.

    The other thing I did was disable the SWAP file, by default its set to 100MB and with my RPi4 having 4GB of RAM I wanted to turn off swapping. Bye the way, does anyone use a daily TRIM command on the SSD?

    Overall the performance improvement over the micro SD is well worth it.

  2. Avatar for suddengunter

    Is there are a way to do this without making first boot from sd?
    I’ve got kingston u3 32gb sd card + 128gb sata3 ssd.
    tested your solution step by step – it works perfectly.

    But, if we using only /boot from sd – I want to use cheaper sd card, I’ve found some old sd cards in my stuff. But they are really old – one is of them is class2 2GB. I want to use it as boot.
    But I really do not want to load whole system from it for the first boot.

    When I install arch to my system from USB I use chroot to kinda “run something like it’s running in newly installed system”. Would it be possible to do it with SSD and SD from my laptop, then just plug them to raspberry and run?

    1. Avatar for jamesachambers

      Hey suddengunter,

      You absolutely can! I chroot into ARM Pi images from my x86_64 desktop to build my Ubuntu image (source code here). You need to have qemu-user-static installed (the later version the better, you’ll get less warning spam) and then you go like this:

      # Copy resolv.conf which will give us networking on the chroot
      sudo mkdir -p /mnt/run/systemd/resolve
      sudo touch /mnt/run/systemd/resolve/stub-resolv.conf
      sudo cat /run/systemd/resolve/stub-resolv.conf | sudo tee /mnt/run/systemd/resolve/stub-resolv.conf >/dev/null;

      # % Prepare for chroot by copying QEMU static binary to Pi
      # copy 64 bit binary
      # sudo cp -f /usr/bin/qemu-aarch64-static /mnt/usr/bin
      # or copy 32 bit binary
      sudo cp -f /usr/bin/qemu-arm-static /mnt/usr/bin

      sudo chroot /mnt /bin/bash << EOF apt update && apt dist-upgrade -y EOF
      Basically you will insert the storage into your laptop and chroot to your mount directory after copying a QEMU user mode static binary over so that the ARM code can run on your X86_64 laptop. Then you can do any configuration you want from there!

  3. Avatar for Tweaker

    It looks like the tutorial contains an error. You say to edit the cmdline.txt and then reboot. After the reboot edit the fstab. However when doing it that way, the Pi never came up again.
    Only when i edited cmdline.txt AND fstab and then rebooted it worked.

    By the way, mentioning only make+model of adapters is not sufficient i guess, as sometimes the used chip will change. Therefore it is better to also include the device ID.
    I can confirm that it is working with 11b0:6388 which is a Kensington SNA-DCH/U3 2.5″ SATA casing in which i placed a HDD (not SSD).

  4. Avatar for Timo

    Thanks for the guide! Apart from needing to add the ssh file to the sd card again before booting to ssd it worked great and was very easy to follow.
    Has anyone else had problems with Crucial MX500 drives? A year ago I couldn’t get a 1tb drive to work with a raspberry 3 and now wasted a couple of days with a 2tb mx500 and a raspberry 4. I’ve tried Startech and Sabrent adapters, with quirks enabled and without. The drive will get corrupted and the system will crash within minutes. Both drives work plugged into a macbook using the same adapters. No problems with Samsung and Sandisk drives on the raspberries.

    1. Avatar for jamesachambers

      Hey Timo,

      I have a couple of them and I haven’t had problems with them! In situations like these it’s almost always the power adapter. The SSD pulls power from the Pi so if the USB-C adapter isn’t on point things like this can definitely happen. Do you have access to any other USB-C chargers? You can even use a USB-C cell phone charger if you have one around (as a test, probably not a good idea to run it off that permanently).

      What other storage devices have you tested with? Does it work okay with MicroSD? Any other drives?

      1. Avatar for Timo

        I have used the official power adapter and the raspberry is running headless with no other devices plugged in. There should be plenty of power but I guess I could try with the old raspberry 3 power supply. Do the Crucial drives draw that much more power than competitors? No problems with the MicroSD card, Samsung or Sandisk ssd drives.

        1. Avatar for Timo

          Okay, just tried with the official 2.5A rpi power supply with a rpi 4 4GB connected to Crucial mx500 2tb drive using the Startech adapter. Couldn’t get the SSD performance script to finish before bash Input/output error.

  5. Avatar for Max

    Hi,

    I could not set up ssh for the second boot and after some fiddling I found out, that I needed to create the “ssh” file twice on the micro sd card. The “ssh” file on the external disk is not required since it’s ignored.

    I altered your (very good btw.) tutorial as follows:
    Preparing SSD -> only add “ssh” file to the micro sd
    First Boot (SD card only, SSD unplugged) -> Run “sudo touch boot/ssh” to recreate the ssh file deleted when booting for the second boot

    Also I can recommend the UGREEN enclosure:
    https://www.ugreen.com.cn/products/usb-c-hard-drive-enclosure
    ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb

    1. Avatar for jamesachambers

      Hey Max,

      I’ve experienced this too, and I know from some of the comments that others have as well. It’s definitely frustrating how thirsty the Pi is to consume those blank ssh files!

      I love your approach of using sudo touch to create the file. I will add that to the steps!

  6. Avatar for Tim L

    Just did this on my new R Pi4. Using an old 128Gb SSd in a Star tech enclosure.. Worked first time although the dist-upgrade has trouble with some JDK files. It will get there or give up.
    I have kept an original on an Sd card just in case.

  7. Avatar for Dave

    Excellent! Just installed everything on brand new RPi4 using Kingston 120GB SSD and StarTech adapter (per your suggestion).
    THANK YOU for posting this very helpful information on your website!
    Dave

    Category Test Result
    HDParm Disk Read 275.31 MB/s
    HDParm Cached Disk Read 187.09 MB/s
    DD Disk Write 152 MB/s
    FIO 4k random read 21069 IOPS (84279 KB/s)
    FIO 4k random write 10790 IOPS (43161 KB/s)
    IOZone 4k read 12168 KB/s
    IOZone 4k write 14165 KB/s
    IOZone 4k random read 12059 KB/s
    IOZone 4k random write 15307 KB/s

    Score: 5754

  8. Avatar for Cam

    is there something significant about “hexadecimal d34db33f ” to me, who doesn’t know hexadecimal or linux, it appears to be a random number, could I use d34db99f -changeing 33f to 99f instead?

    1. Avatar for jamesachambers

      Hey Cam,

      Great question! It’s a very old school hexadecimal string so you can only use the characters A-F and 0-9. You can use anything as long as it’s a hexadecimal string!

      The example you gave would work. You could use anything that doesn’t go past the letter F (any numbers 0-9 are okay)

      1. Avatar for Wes Peters

        It comes from the IBM Power architecture, which set all of it’s internal registers to the 32-bit hex value “deadbeef” on startup. d34db33f is apparently more “h4xx0r-ish.”

  9. Avatar for Steve Silvi

    Hello James,
    This tutorial is the most thoroughly explained and easiest to understand I have found. Thanks for your hard work in putting it together! After following all steps and then booting via my Corsair Voyager Slider 64GB USB 3.0 flash drive (inserted into one of the Pi 4 USB 3.0 slots), I am executing ‘apt -y upgrade && apt -y dist-upgrade’ in a terminal. The process has been running for over an hour and is at 61% complete at the “removing diversions” stage. Booting the Pi 4 with a Sandisk 64 GB SD card has never presented any problems upgrading the OS, which is usually completed in a few minutes. Any ideas why the upgrade is taking so long?

  10. Avatar for Timm

    Hey…
    i need some help. I don’t know what else i could do. I did every step the 2nd or 3rd time by now and it does not work.
    After it did not work with the Adapter i bought before finding your instruction, i bought “StarTech 2.5″ SATA to USB 3.0 Adapter”. Still no boot.

    When i replace the the SD Card PARTUUID with d34db33f the Pi will not boot.
    Initial boot of raspbian on the SD Card works like normal.

    Raspberry Pi 4 with 4Gb
    San Disk 256GB SSD
    StarTech 2.5″ SATA to USB 3.0 Adapter
    I used Win32DiskImager to write “2019-07-10-raspbian-buster-lite” to the SD and SSD.

    Thanks in advance!

    1. Avatar for Jim

      Timm,

      James’ instructions have you change the PARTUUID of the SSD drive, not the SD card.

      As long as the PARTUUID is different between the SSD drive and SD card, you might be ok, but you’d need to be extra careful that you are setting the fstab and cmdline.txt entries appropriately.

      cmdline.txt needs to point to the SSD drive
      / of fstab points to the SSD drive
      /boot of fstab points to the SD card

  11. Avatar for Kevin

    Working fine with a Sabrent EC-SS31. No Quirks required
    Benchmark results 3735, so its working

    Thanks for the great procedure
    k3tl

  12. Avatar for Bjørn Idar Kristiansen
    Bjørn Idar Kristiansen

    James, thank you for a great toturial!

    I get quite decent read/write with this setup (Samsung Evo 860 Pro 256GB SSD with IcyBox IB-AC603a-U3 2,5″) – Read/Write: 312MB/s/203MB/s, but booting up is significantly slower.
    It actually uses about 5 minutes to boot up… What can be the reason for this?

  13. Avatar for Jon

    Hi, Thanks for this very informative site.
    I have set up a raspberry pi 4, running raspbian, as a desktop system using a 500GB WS Blue SSD.
    I have run the performance benchmark several times for both a BENFEI adapter, which only runs with “quirks” (it uses a JMicron chipset) and also a Startech adapter, which runs without “quirks”.
    Surprisingly, the results for the Startech adapter are considerably slower (20% or more) for all tests, except to the “FIO” test, where the Startech adapter is several HUNDRED percent faster than the BENFEI adapter. The Starteck gives an overall score of around 5800, while the BENFEI gives a score of around 5200.
    Do these results make sense? Why do the “FIO” tests give such different results from the rest?
    Any help in understanding these results would be appreciated.
    Regards,

    Jon

  14. Avatar for Paul

    I used the Orico transparent enclosure, which was really slow without applying quirks. After I applied Quircks it worked fine and the response of my rPI4 has improved compared to the SD card

  15. Avatar for Jim Brewer

    First, James, thank you so much for this post! Very helpful!

    Just a headsup, I was just about to purchase the ELUTENG adapter, currently third in the list of known good adapters. Reading user reviews on Amazon, I ran across a review that said the adapter used to work great for booting PIs, but they’ve changed the adapter. The new one with the blue connector doesn’t work with PIs.

    So, I placed my order for the first one in the list instead.

    1. Avatar for Jim Brewer

      James, maybe we should skip what I just said about the ELUTENG adapter.

      The review I was referring to didn’t specify which PI model and didn’t specify whether they were truly “booting” from ssd or the sd card.

      Another person left a comment on that review that read “I purchased one of these before reading this review. It has a blue connector, but when I plug it into my USB 3.0 port on my Raspberry Pi 4, it works just fine. dd speeds are 326MB/sec reads and 346MB/sec writes to some Samsung SSD I had lying around. So maybe they manufacturer has changed things again and now it works fine?”

      So, maybe I’ll give the ELUTENG adapter a try.

      1. Avatar for jamesachambers

        Hey Jim,

        Thanks for the info! Recently 0x7878 said their Sabrent adapter was working too but he hasn’t replied back when I asked him to confirm using findmnt.

        With all of the kernel and firmware fixes that the Pi keeps getting for USB and UAS I suspect all of these adapters will probably work at some point (even if it’s a workaround they do in the kernel, like automatically applying quirks for certain models).

        Let me know if you try the Eluteng and what you find so we can pool everyone’s information together and continue to draw some conclusions about which adapters work the best!

        1. Avatar for Jim Brewer

          James, my Eluteng adapter arrived and I can confirm it reports the exact same chipset that you shared from your StarTech adapter.

          I haven’t tried the Eluteng adapter with my Pi 4 yet. I’ll let you know when I do.

          Brief Pi 3B+ test:

          I did run your benchmark twice this evening with my Pi 3B+ with a 240 GB ADATA SU800 SSD. Once was with a Rosewill USB 3.0 SATA drive enclosure, scoring 2892. And once with the Eluteng, scoring 2632.

          The drive hosts a “lived in” Raspbian Buster Desktop image. Both /root and /boot are on the drive and I never did anything special to tell the Pi 3B+ to boot from the SSD. …no sd card in the slot.

          The Rosewill enclosure is listed by lsusb -v as SimpleTech JMicron USB to ATA/ATAPI Bridge. I’ve had that a few years. It’s been working fine on the Pi 3B+.

          That drive in that enclosure did not work well on the Pi 4. The drive wouldn’t stay engaged long enough to set up. The warning that the drive had been disconnected without unmounting kept coming up rather frequently. Honestly, I think the drive/enclosure had done similar on a usb 3.0 port on Windows 10 occasionally. I look forward to trying the same drive with the Eluteng adapter on my Pi 4.

          1. Avatar for Jim Brewer

            ADATA SU800 SSD on Pi 4 using the ELUTENG adapter scored 5501 on your benchmark.

            That’s the same drive that mentioned in my previous comment, but I created a new partition and used rsync to copy the data from my NEXIN external drive I had set up a week or so ago using your instructions.

            The NEXIN 60G external SSD is also using the same chipset as both the Eluteng adapter and the StartTech adapter. I clocked 5090 on that drive this evening prior to switching drives.

            I’m just switching because I want the larger drive on the pi 4.

            I was able to mount both drives on the pi 4 to transfer the data. I encountered no issues during the entire process.

  16. Avatar for HansCees

    If you want to make backups here and there from sd-card

    make backup of sd card on ubuntu host
    sudo fdisk -l | egrep -i “disk|device” | egrep -v loop # find where the sd card is mounted
    sudo dd bs=4M if=/dev/sde of=/home/mememe/PI-images/bananas-201912-rasp+omv.img

    shrink backup image of your sd-card
    wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh
    sudo ./pishrink.sh bananas-201912-rasp.img bananas-201912-rasp-shrunk.img

    also, the image wil automagically expand itsself to all space on a new bigger sd-card

  17. Avatar for Zhong

    Hi, how should I do the steps again, if I have already changed the /boot/cmdline.txt ?
    I am trying to boot with seagate hdd. I think maybe I put the wrong partuuid in the /boot/cmdline.txt

    1. Avatar for Jim Brewer

      Zhong,

      If you created a backup copy of /boot/cmdline.txt, I would put your sd card in a reader on a pc and revert to the original file.

      Then, I would think the PI would boot using the original /root on the sd card. This would give you opportunity to inspect the partuuid of the hard drive using James’ suggestions, and then adjust /boot/cmdline.txt correctly.

      If you had not kept a copy of the original /boot/cmdline.txt file, there may be ways to get through, but as James had suggested, you might do better to just start over.

      Just my thoughts. I’m not the author of this post.

Leave a Comment

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

Type here..