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 Tman

    When booting from SD card, I can mount my USB3-connected SSD just fine. But when I follow this guide, change cmdline.txt and reboot, the pi does not start (I let it sit for 5 minutes). Is my SSD model problematic, or does it mean if I can mount it, it should work and I made a mistake somewhere?

    Also, I am a bit confused about the guide. In step 6, the before should be af1800e7-01 and not af1800e7-02? After all, I am not changing from sdcard-boot to ssd-root but from sdcard-root to ssd-root.

    And why do I would reboot the pi in step 7 before adjusting /etc/fstab so that my entry for / has the updated PARTUUID?

    1. Avatar for Tman

      But it does work now. I connected through a serial console and saw that hint about the root account being locked. So I set fsck.repair=no in cmdline.txt and then it worked.

  2. Avatar for Hendy

    i have a question, does the raspbian version in the SD card have to match the raspbian version in the SSD?
    e.g. i have a raspbian lite on the SD card, while my ssd has the minimal desktop version.

    1. Avatar for jamesachambers

      Hey Hendy,

      No it definitely doesn’t. In fact, it wouldn’t matter if the partition that wasn’t your boot partition was completely empty.

      Basically all that matters is that handful of files in the /boot folder. We are basically sacrificing a SD card to use as a bootloader for our USB device while we patiently wait for true USB support to come to the Pi!

  3. Avatar for hendy

    hello, great guide, i made it until the end, up to the part where you had to update.
    after update, suddenly everything slowed down to a crawl.
    granted I am not using any of the above hardware you suggested (i am in indonesia).
    using a WD green sata ssd 240gb. have yet to run benchmark.
    any suggestions?
    i will update with my benchmark results if it ever works.

  4. Avatar for Nia

    Hello all!
    So I have been following this guide to boot my Pi4 from SD and have my rootfs on my SSD, this is my set-up:

    * SSD: WD 250GB 2,5″ BLUE SSD BULK WDS250G2B0A
    * enclosure: Renkforce RF-4038897 mSATA USB 3.0

    Somehow every time I try to reboot my Pi at step #7 , I cant access it anymore. I tried several times, I made sure the SSH file is there too for headless boot. Also changed the PARTUUIDs so they are not the same anymore.
    I changed the cmdline.txt accordingly and also put rootdelay=5 (found that on another guide and thought it might help after it didnt work before) and it is still not working:

    console=serial0,115200 console=tty1 root=PARTUUID=bd1d394e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=5

    I cant access with SSH and I am really clueless by now what could cause the problem. Generally I am new to working with the Pi, so maybe there is something I did not think of yet. Basically I am stuck at step #7 of the guide. Any ideas? Thank you!

    1. Avatar for jamesachambers

      Hey Nia,

      This comment is probably a little late to help you but I wanted to leave it anyways in case it helps others.

      If you are struggling with the SSH access absolutely take the time to plug in *both* devices to your computer and recreate the ssh file. It tends to get “consumed” when you are going through this process and when the devices are switching back and forth it may not necessarily apply. Put both the SD card and SSD in and double check that both have a ssh file (and that it didn’t get eaten in a previous step).

      I also updated the instructions quite a bit to hopefully help reduce headaches related to those steps.

      1. Avatar for Nia

        Hey James!

        Thanks for your reply, I started from scratch and I made sure to have the ssh file present on both drives – also after the first access via ssh.
        But it still wont let me access it, it also didnt boot, only the red led is lighting up. So I still dont have any clue what the problem might be. Will update if I find a solution.
        And thank you for the update on the instructions, those were quite useful!

  5. Avatar for Arjen Raateland

    I run my Pi4B with the / partition on a Crucial BX500 SSD in a UGREEN USB3 enclosure. It works without a problem, except it doesn’t support fstrim. The only way I could perform TRIM on that SSD was using an about 10 year old script that I found and with the drive connected to my Linux Mint 19.2 laptop.
    As that is not really a practical way of trimming and SSD, I bought some Inateck FE2010 enclosures which I had read worked with Linux and will let FSTRIM do its work. It is said to have a JMS578 controller.

    In short: with the abovementioned SSD in the new Inateck case connected to a Pi4B’s USB3 port, booting was nearly impossible. One time I was patient enough to let it struggle for almost 30 minutes and eventually it brought up the Raspbian desktop. It took 60 times longer than with the SSD in the UGREEN case, totally unworkable.
    I have not too many ideas about what to do then to try and solve this, if at all possible, so I shut the PI4B down and moved the SSD to the old UGREEN case. It still worked perfectly as far as I can tell. At on estage I ran a check of the file system. All OK.

    With the Inateck case and the SSD in it connected to my Linux laptop, I was able to run FSTRIM on it. Also otherwise it behaved normally.

    At the moment I don’t have another SSD to try in this Inateck FE2010 case, but if I connect it to the PI4B in addition to the UGREEN case with the SSD, and then boot, the Pi4B refuses to start.

    If I boot the RPi4B with just the UGREEN case and SSD and then plug in the empty Inateck case later, I can see it appear in lsusb output.
    LSUSB output from this case (with SSD in it) doesn’t state a vendor. HWINFO output is like this with nonsensical vendor and name info. Very annoying:

    44: SCSI 400.0: 10600 Disk
    [Created at block.245]
    Unique ID: ofUZ.G_lTKP6Z8G9
    Parent ID: MZfG.yHudtVzDTT6
    SysFS ID: /class/block/sdd
    SysFS BusID: 4:0:0:0
    SysFS Device Link: /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/host4/target4:0:0/4:0:0:0
    Hardware Class: disk
    Model: “TO Exter nal USB 3.0”
    Vendor: “TO Exter”
    Device: “nal USB 3.0”
    Revision: “6402”
    Driver: “uas”, “sd”
    Driver Modules: “uas”
    Device File: /dev/sdd (/dev/sg3)
    Device Files: /dev/sdd, /dev/disk/by-id/usb-TO_Exter_nal_USB_3.0_201503310009A-0:0, /dev/disk/by-path/pci-0000:00:14.0-usb-0:1.1:1.0-scsi-0:0:0:0
    Device Number: block 8:48-8:63 (char 21:3)
    Drive status: no medium
    Config Status: cfg=new, avail=yes, need=no, active=unknown
    Attached to: #35 (USB Controller)

    I have read about there being f/w updates for the JMS578 controller, but the info concerns odroid which I know nothing about.
    I downloaded the update-package and ran the updater on my laptop to find out the f/w version, but even that didn’t work. At the moment I hava not been able to confirm there being a JMS578 controller in this Inateck case nor what version f/w it contains.
    I wasn’t able to find any update support from the maker of the chip.
    I could run an updater on Windows if that’s the only practical way. I made an FAT32 partition on the SSD just so Windows would see the drive.
    (One day that may become the boot partition, which is now on the SD card)

    In between I tried a Startech enclosure model S251BMU313 which was supposed to support trim. It didn’t and I returned it and was promised my money back. In a chat a Startech representative conformed there were ‘limitations’ in Linux which Startech blames for trim not working. Otherwise it ran as well as the UGREEN enclosure.
    Elsewhere I read that it is Windows not adhering to ‘the standard’ and letting USB enclosure makers get away with half working products. I mean AFAIK TRIM is essential for SSD disks. There have been SSD disks on the market for many many years, even though I didn’t use any before, so how are these situations even possible these days?

    1. Avatar for jamesachambers

      Did you try the usb-storage quirks? I don’t see any mention of them and they may help here. I recently expanded this article and wrote a section on how to apply the quirks worth checking out.

  6. Avatar for FreelancerJ

    Working here, with a Orico NVMe M.2 enclosure, model TCM2-C3-BL, which runs the J-Micron JMS583 chipset, and a Crucial P1

    Read-Write speeds seem a bit lower than I expected. Connected directly to my MacBook Pro, I get ~880MBps read, just over 900 write no problems, but connected to the Pi, I’m only getting low 300s in the benchmark for this site.

    At first I thought maybe Raspian wasn’t supporting UASP, but after a little digging, it seems it is.

    I’m sure I saw someone somewhere riding 600MBps through the Pi 4’s USB 3 port before I ordered the enclosure, but now I have no idea where I saw that.

    Am I dreaming, or are there optimisations I could apply that might bump the performance?

      1. Avatar for FreelancerJ

        I didn’t think it was likely to help, as I wasn’t getting any of the errors in dmesg that the RPF said to look for before applying USB-Storage Quirks, but I gave it a shot

        Benchmark before turning on quirks: 6396
        Benchmark after turning on quirks: 4413

        So that doesn’t seem to be it… any other ideas, anyone? 😊

      2. Avatar for FreelancerJ

        Oh, and I found where I saw someone getting such high speeds, thanks to you sending me after the USB quirks, it’s on the second page of that forum thread

  7. Avatar for Marek

    Hey guys,

    is trim working for you?

    Adapter StarTech.com 2.5″ SATA to USB Cable:
    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

    # hdparm -I /dev/sda|grep TRIM
    * Data Set Management TRIM supported (limit 8 blocks)

    Root:
    /dev/sda2 on / type ext4 (rw,noatime)

    # fstrim -v /
    fstrim: /: the discard operation is not supported

    1. Avatar for Marek

      Sorry, I’m stupid, just found it…

      # cat /etc/udev/rules.d/01-unmap.rules
      ACTION==”add|change”, ATTRS{idVendor}==”174c”, ATTRS{idProduct}==”55aa”, SUBSYSTEM==”scsi_disk”, ATTR{provisioning_mode}=”unmap”

  8. Avatar for Jens Hoofs

    Sadly the Pi 4 has lots or problems with usb 3.0 and running my pi from the SSD makes it slower the DD test show it begin just as fast as the sdcard i used, but in real time use it is much slower.

  9. Avatar for Jens

    This is a way better tutorial than i could find. Combined with the one from Toms harware i was able to get an already running raspberry pi 4 root system to be copied onto my ssd drive perfect.

  10. Avatar for Tarcam

    My solution to the identical PARTUUIDs – downloaded the older *June* release of Buster instead of the September (9/26). Followed the instructions in the article and then updated at the end.

  11. Avatar for Mark

    I started out fresh and both my devices had the same UUIDs and PARTUUIDs. This caused me much frustration but I managed to successfully change both (I don’t think changing UUIDs is strictly necessary for this but probably a good idea anyway). What I did was mount the SD card to my desktop and use fdisk to change the PARTUUID with the “x” and then “i” commands, using uuidgen for the UUID. The UUIDs were changed using dd for the boot partition (https://superuser.com/a/1294893/287342) and tune2fs for the root partition.

    Another issue I ran into is that the ssh file would be deleted from the boot partition after booting so I’d have to remember to recreate it before subsequent boots. I *think* just enabling the ssh service once booted should make it not rely on the ssh file any more.

    1. Avatar for Mark

      Forgot to mention that I think fstab needs to be updated after changing the PARTUUID, at least if you still want to boot off the SD card’s root partition.

  12. Avatar for Brian Kelly

    Just tried following your excellent guide but when I list the PARTUUIDs for the sd card and the usb drive they’re identical so I don’t expect this is going to work, I’m using the latest (2019-09-26) raspbian lite image

  13. Avatar for hi_pat_trick

    Thank you for your excellent write up! I had a question of clarification for “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.”

    In this case, am I supposed to be using the same tools I would be to prepare the Flash Drive on the SSD as well? As in, set up the SSD as if it were going to be the boot drive from the start?

  14. Avatar for Derek Belz

    Hallo
    I have an INTENSO SSD 128 GB.
    After many days of trying I found out that it works with the raspberry pi 4 on the 2.0 USB ports. Obviously not with USB 3.0.
    Regards
    Derek

  15. Avatar for Tom

    Hey James,

    great Guide!
    Everything worked like a charm … except that I overlooked at least 10 times the “Known Problematic Adapters” section.

    @All: The “Sabrent mSATA” Adapter is really and for sure not working in the USB 3.0 Ports! 🙂
    I spend several hours to proof that, just plug it into the USB 2.0 Port of the PI4 and it works flawlessly.

    James, maybe you can change the font size of that section to >128px, color it red and make it blink 😉

    Tom

    1. Avatar for jamesachambers

      Hey Tom,

      I appreciate the feedback, and I completely agree. I’ve made the section HUGE with capital letters after saying (VERY COMMON). For some reason the subheading was a size smaller than it should have been so that should make it much easier to see.

  16. Avatar for Tommy Thorn

    I bought the StarTech directly from the link above, but it does _not_ work for me without a “usb-storage.quirks=174c:55aa:u ” added to cmdline.txt. With it and a Samsung 850EVO 1TB is managed a measly score of ~ 4000. FWIW, I had a bunch of other SSDs that wouldn’t work with _any_ power-powered adapter, even with the added quirk. They _did_ work with a (slower) externally powered adapter.

    The Raspberry Pi 4 definitely is very finicky!

    Thanks for all your work!

  17. Avatar for Dave

    Hi Guys I followed these instructions having set up Ubuntu on my pi 4. So I now need Ubuntu to boot from usb but cmdline.txt does not contain any uuid for any drives for me to re-point the thing to use usb instead. Has anyone got any advice please?

    1. Avatar for jamesachambers

      Hey Dave,

      Check out my reply to DerFritz below, basically just change root=/dev/sda2 instead of using PARTUUIDs on the cmdline.txt for Ubuntu

  18. Avatar for Bruce Schneider

    I’m trying to put your ubuntu image(V12) on a ssd and boot from buster lite on sd. Fails with a fails with ‘kernel panic – not syncing’. No luck… Worked OK with buster on sd and ssd. Any suggestions???

  19. Avatar for JeffHart

    Thanks all for your tips & guidance. Made it work the hard way, for some reason having issues (cerebral flatulence) on getting the rsync exclude to properly exclude, but was able to bypass by using remote rsync of /boot to an SSD attached to another rPi4, move the drive to the intended rPi4, update cmdline.txt and fstab and so far it’s working, booting from microSD with rootfs on SSD. Used a StarTec USB cable and a Crucial BX500 240GB drive.

    Since I’ve already purchased some of the Sabrent SATA to USB, I decided to risk pulling the SSD from the StarTec and installing it in the Sabrent SATA to USB enclosure and luckily it booted. Checked syslog and didn’t appear to be anything different in the boot process between the two controllers. lsusb shows the Sabrent as “JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge”

    While that worked far a lite image, doing a full image would be very painful, so instead attached an SSD with two partitions to the rPi4 booted from a clean full image on a microSD. Copied the full image zip from my PC to a flash drive, installed and mounted the flash drive on the rPi4 and copied the zip to the second partition that will eventually be a data store. Unzipped the image, mounted it and am rsyncing between two partitions on the same SSD drive in USD 3.0 port with Sabrent SATA to USB, still taking longer than I’d hoped; after two hours has transferred 1.6GB of 5.7GB

    Will update with results and if they’re good, with more details on mounting the image file, etc.

    1. Avatar for jeffhart

      Quick update as to not lead anyone else down this rabbit hole – systems are all unstable, have tried adding “usb-storage-quirks=aaaa:bbbb” with with the correct vendor and product ID’s ( 152d:0578) for the Sabrent/JMicron to cmdline.txt to no avail. I’m working on setting up a Kubernetes on Ceph cluster so too many moving parts, am going to need to drop back and diagnose methodically. Will update if I find anything that may be helpful.

    2. Avatar for foobar

      Please don’t update. You are an idiot and have no idea what you are doing. Don’t complicate such a simple procedure. Rsync? Are you nuts? WTF are you doing??

Leave a Comment

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

Type here..