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 d34db33f 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.

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

  1. Avatar for David

    Tried again using Rasbian Desktop and the Startech 2.5″ SATA SSD adapter cable with a Kingston SSD A400 Solid State Drive (2.5 Inch SATA 3), 120 GB. My earlier issue was an incorrectly written image on the SSD. So did it all again and it worked!

    I have just run the storage benchmark and using the original SD card only the score was 1025
    and now with the SSD its 8430.

    What a difference, thanks to James for sharing this

  2. Avatar for Leo

    reboot in step 7 ended with a stuck system. started from scratch, but left out the system update in step 3. only after the last step I did a system update and now everything seems to work fine.
    Benchmark results improved from ~1500 (using a pretty decent SD card) to ~5200 (using a pretty old crucial M4 SSD with a hdd housing I found in a drawer). Responsiveness of the raspberry pi is now much improved.
    Thanks! 🙂

  3. Avatar for PauloHeaven

    Hello,

    Thank you for your tutorial.

    I am using a Raspberry Pi 4 2 GB with Raspbian Buster, with a Kingston A400 120 GB and a 16 GB SanDisk Ultra card, and I encounter some issues.

    My first one was the Pi not booting after step n°2. I solved it by looking down the comments, and using the rpi-update command. So the firmware included in the repositories doesn’t seem to be recent enough, but it is solved nonetheless.

    The second one is when I boot on the SSD (when I still can, because of the third problem). Two lines appear when beginning an SSH session:

    rfkill: cannot open /dev/rfkill: No such file or directory
    rfkill: cannot read /dev/rfkill: Bad file descriptor

    Third issue: once the steps are completed, I can use the Raspberry flawlessly, with the OS on the SSD… Until I do sudo apt update && sudo apt dist-upgrade. So :

    – OS installed on the SD card, software and firmware updates done: life continues
    – OS installed on the SSD, guide steps completed, apt upgrade : the OS doesn’t reboot. At all. I tried to change the PARTUUID on the SD card’s cmdline.txt at least to get the OS installed on the SD card working, nothing. The SD card LED doesn’t flash. The SSD doesn’t show any activity either, the activity LED on the Startech cable is off, like there is no power. I tried with only the SD card plugged in, only the SSD plugged in, nothing plugged in so maybe something resets, to no avail. Like the Pi is angry and going on strike.

    The SD card and the SSD are working fine on my computer, and all the files seem to be there. But obviously, in front of thousands of files, I have absolutely no idea of which one I should look at, where something could be wrong, disappeared, tampered etc.

    I did all the process 3 times, use Etcher to flash the storage devices, which is known to be good at flashing Raspbian images, the most recent Raspbian release, and the recommended hardware. And it works very well when it does, as you can see on your storage benchmark that I used a few times. But in the long term, I am still facing the last 2 issues. Is there a package that I shouldn’t upgrade? Should I run rpi-config which I didn’t try at this moment?

    I can’t find a single person on Internet in the same of one of the above cases. It looks like it is either a tiny forgotten thing or an inextricable problem. I really don’t know what I did wrong, and am pulling my hair out on this. If you have an idea, I am very willing to bring more details.

    Thanks

    1. Avatar for PauloHeaven

      Update: I finally got it working.

      I tried yesterday again, and there were 20 more packages to upgrade when searching for updates. There should be something improved in them because I had no problem connecting after updates and reboot, and the rfkill messages disappeared. I didn’t even need to do sudo rpi-update. Problem was solved by itself. I hope it will stay the same, I’m glad I can finally enjoy my Pi with a working OS an the SSD 😃

      Thanks

  4. Avatar for Javanaut

    Just applied your guide to a setup of:

    RPi 4B v1.1
    Current Raspian Buster Lite flashed with balenaEtcher
    SanDisk microSD 16GB
    IcyBox IB-AC703-U3 Sata III to USB 3.0
    Samsung 860 EVO 1TB

    Had 2 failures which may come from trying an update of raspbian before applying steps 8 and 9 of the guide due my impatience. Third attempt now showing proper function including running your benchmark. This adaptor didnt work on a Pi 3 / USB 2.0 but here its doing its job as far as i can tell now.

    Greetings

  5. Avatar for Mike Pastore

    Got Ubuntu 18.04.3 LTS with a root filesystem on a WD My Passport SSD all working using your preinstall image, firmware, and kernel. The firmware is loaded on a small microSD card, with the partition mounted at /boot/firmware after boot. The major downside is that UAS is disabled in the device firmware so performance is meh. I’ve uploaded a benchmark. Thank you very much!

  6. Avatar for Amit Bahree

    I could not get this to work and would appreciate any guidance. I got a new raspberry Pi 4, and got the suggested ELUTENG 2.5″ SATA to USB 3.0 cable and a Kingston SSD drive – now when I follow this, and on Step 7 when I reboot- I can see the pi boot up (have it attached to a monitor), but I see some error which goes by too fast. And the attached keyboard and mouse doesn’t work – I tried a wireless (via a USB dongle) and a wired one too.

    So now the pi is booting from the SSD, but it isn’t configured – it is not on the network or has a IP and with either the keyboard or mouse not working, I can’t configure it. Any ideas on how to try and debug this and try and get it working? When I switch back the cmdline.txt from the backup then it works as expected.

    Thanks,
    Amit.

    1. Avatar for jamesachambers

      Hey Amit,

      It sounds like you’ve narrowed the problem down to cmdline.txt. Can you tell us what your new and old cmdline.txt is?

      1. Avatar for Amit Bahree

        Thanks Ja,es.

        The old cmdline.txt is:
        dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=3b3e03b5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

        And the new one (not working) is:
        dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=3b18e43a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

        The only difference is the PARTUUID as outlined in the steps. So the thing boots up, but then the usb keyb and mouse doesn’t work – it is just waiting there for me to hit next and continue to finish configuring.

        Any ideas?

        Thanks,
        Amit.

        1. Avatar for jamesachambers

          Those look like old boot flags from Pi 3ish. Let’s try with the ones I’m using in my Ubuntu preinstalled 18.04.3 image and that most other working distros seem to be using.

          First try this one:
          dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=PARTUUID=3b18e43a-02 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

          Next you can try this if the PARTUUID selector isn’t working:
          dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

          1. Avatar for Javanaut

            Did this help?

            I had 2 fails before and I am not sure what it was but it also disabled my keyboard. I followed then this guide more exactly plus I disabled wifi, bt and the hciuart service as one of the errors shown at boot pointed to this service. which prevented errors until now. Must say that I dont have tested much more until now, but this is on the todo list…

            Greetings

          2. Avatar for Amit Bahree

            Thanks for the suggestions, but unfortunately, neither of them work and I get the same behavior. Boots up, can see it is booting from the drive but then get to the Welcome to Raspberry Pi screen and cannot configure or use keyb + mouse. And this is using the latest raspbian image, and not trying Ubuntu. Could there be anything in there?

            Thanks.

            1. Avatar for Amit Bahree

              Also, if it would help, here is the output of blkid (when it boots up from the SD card). I don’t know why for the SSD (rootfs partition), it says PPTYPE as dos.

              pi@raspberrypi:~ $ sudo blkid
              /dev/mmcblk0p1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”0C61-73F5″ TYPE=”vfat” PARTUUID=”3b3e03b5-01″
              /dev/mmcblk0p2: LABEL=”rootfs” UUID=”43f2d0bb-83be-464f-94d0-9a751f376c64″ TYPE=”ext4″ PARTUUID=”3b3e03b5-02″
              /dev/sda1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”0C61-73F5″ TYPE=”vfat” PARTUUID=”3b18e43a-01″
              /dev/sda2: LABEL=”rootfs” UUID=”43f2d0bb-83be-464f-94d0-9a751f376c64″ TYPE=”ext4″ PARTUUID=”3b18e43a-02″
              /dev/mmcblk0: PTUUID=”3b3e03b5″ PTTYPE=”dos”

              Thanks.

              1. Avatar for jamesachambers

                Hey Amit,

                This does help. The concerning thing to me is that the partition layout doesn’t match. /dev/mmcblk0 is the SD card and /dev/sda is the SSD. The SD card seems to be carrying an additional DOS PARTUUID that I honestly don’t think I’ve ever seen before. If you download the Raspbian image and write it to both devices one after another the partition layout should match 100% (other than the PARTUUIDs, which is generated specifically to be unique for this reason)!

                Raspbian is by far the easiest of all of them to get working on an SSD. Let’s try again with a simplified version of steps:

                1. Download latest Raspbian (7-10-19 at this time)
                2. Use Win32DiskImager/Etcher to write the image to both a SD card and the SSD at the time same
                3. Put the Raspbian SD card in the Pi and boot normally. Do sudo apt-get update && sudo apt-get dist-upgrade then a sudo rpi-update to update everything to the latest firmware (including your boot SD card, important!)
                4. Now plug the freshly imaged SSD — run lsblk and change /boot/cmdline.txt to the SSD partition 2, reboot

                Don’t do any other steps for now like /etc/fstab, let’s worry about that later. Those 4 steps should be all it takes for you to get a complete boot into the Pi on the SSD.

                That’s basically it. Honestly there isn’t a lot of room for things to go wrong. You are really only updating the firmware then changing the rootfs text entry in cmdline.txt. We don’t have to rebuild the kernel, change any kernel modules, anything like that. Things like driver issues, etc. should not be occurring. I think it has to be something weird at this point like an incomplete image, etc.

                The reason we update the firmware first is that the /boot on the SD card will not have any of the latest patches and the Raspberry Pi 4 has a change where it actually has onboard firmware instead of loading it from the SD card like all older Pis.

                I’ll be very interested to see what you find out. It has to be something silly in the early steps where something went wrong I think! It could also be something with the adapter, the SSD, etc. but since those are both known working devices this is definitely a strange case! You can also try plugging in your SSD into one of the black ports instead of the blue ones just to test.

                1. Avatar for Amit Bahree

                  James,
                  Firstly I appreciate your help and patience with me – as a fellow geek (albeit not very knowledgeable in the boot loader on Linux), I am thankful.

                  So I did a complete fresh install – checked the image was the latest and imaged both the SD card and the SSD drives. The only difference wsa that I also ran sudo rpi-update, to update the firmware. The steps in your blog post don’t outline that specific step -I don’t know if that was by design or a ‘bug’.

                  Irrespective the outcome hasn’t changed. When I changed the PARTUUID, it boots up and I can see the desktop, but then keyb and mouse not working.

                  And for reference below is the output from blkid and all I did was change the “25789520-02” to “3b18e43a-02″.

                  I am happy to try and debug this if it helps you and others. And finally, as a reference, when I had tried this method in the past, that had worked – but I hadn’t checked enough to make sure. I can try that again and see if that is accurate using: findmnt -n -o SOURCE /

                  pi@raspberrypi:~ $ sudo blkid
                  /dev/mmcblk0p1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”0C61-73F5″ TYPE=”vfat” PARTUUID=”25789520-01″
                  /dev/mmcblk0p2: LABEL=”rootfs” UUID=”43f2d0bb-83be-464f-94d0-9a751f376c64″ TYPE=”ext4″ PARTUUID=”25789520-02″
                  /dev/mmcblk0: PTUUID=”25789520″ PTTYPE=”dos”
                  /dev/sda1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”0C61-73F5″ TYPE=”vfat” PARTUUID=”3b18e43a-01″
                  /dev/sda2: LABEL=”rootfs” UUID=”43f2d0bb-83be-464f-94d0-9a751f376c64″ TYPE=”ext4″ PARTUUID=”3b18e43a-02″

                  Thanks,
                  Amit.

                  1. Avatar for Sven

                    I am having the same issue. It worked fine with the same SD card and SSD in August. I tried it today with the same “2019-07-10-raspbian-buster.img”. It boots with SSD but the mouse and keyboard are not working.

                    1. Avatar for Louis De Lange

                      I had exactly the same problem on X855 mSATA adapter, booting fine but then USB mouse and keyboard would not work.

                      Solution was to not do the system update until the very end. Now working perfectly.

                    2. Avatar for Amit Bahree

                      Louis, quick question – did you also upgrade the firmware when you ran this in the end – i.e did you run rpi-update or only apt-get update and apt-get dist-upgrade?

                      Thanks.

                  2. Avatar for Petie Rademeyer

                    Same issue with me. SD card boot and SSD/USB rootfs.
                    Initial Buster image worked, but as soon as I update, no usb keyboard or mouse functions. Did anyone found a solution yet.

                    1. Avatar for Louis De Lange

                      I dont know if it is “the” solution, but when I delayed “sudo apt-get update && sudo apt-get dist-upgrade” from step 3, to after step 9 my mouse and keyboard is working fine. I tried this with both Raspbian Buster Lite and Raspbian Buster with desktop and recommended software

                    2. Avatar for jamesachambers

                      Hey Louis,

                      A few other people encountered this as well. I have updated the instructions to put the update step at the very end (now step 10).

  7. Avatar for Denny Fox

    I ran across this posting with a work-around for misbehaving USB3 adapters on the Raspberry Pi 4B:

    https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931#p1501426
    STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this

    I have four different adapters: Sabrent enclosure, Sabrent cable, ELUTENG enclosure, and Startech cable. The only adapter that would boot and run without the quirk fix in /boot/cmdlime.txt was the Startech cable. This confirms the information in the article above.

    When I applied the usb-storage.quirks= fix to /boot/cmdline.txt, all adapters functioned well. Interestingly the StarTech cable turned in better performance with the quirk fix in place than without it. I am using fio with the commands from the link above for testing.

    w/o with
    Startech Cable sequential-read 69.8 159
    174c:55aa sequential-write 79.9 211
    random4k-read 13.9 13.8
    mixedrandom4k-read-write 3.9 3.4
    random4k-read-4processes 40.3 11.1

    The quirk fix disables UAS support and reverts to mass storage for USB3.

    Here is my /boot/cmdline.txt for reference:
    # SD Card
    dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=0cd3cae7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    # SSH on sda1 – no quirk
    #dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    # Startech Cable
    #usb-storage.quirks=174c:55aa:u dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    # Sabrent Enclosure
    #usb-storage.quirks=152d:1561:u dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    # ELUTENG Enclosure
    #usb-storage.quirks=152d:0578:u dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    # Sabrent Cable
    #usb-storage.quirks=152d:1561:u dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

    Only one line may be uncommented for each case.

    Hopefully we will get improvements in the Raspberry Pi 4 firmware including booting directly from USB as time goes on. Until then it looks like the quirk fix is useful.

  8. Avatar for Francois Gervais

    As a reference, I get a 5x sequencial write speed upgrade:

    sudo dd if=/dev/urandom of=/dev/testfile bs=1M count=1000
    dd: error writing ‘/dev/testfile’: No space left on device
    841+0 records in
    840+0 records out
    881577984 bytes (882 MB, 841 MiB) copied, 32.809 s, 26.9 MB/s

    Using RIITOP NVMe USB Adapter + SN750 250GB:

    sudo dd if=/dev/testfile of=testfile bs=1M conv=fsync
    840+1 records in
    840+1 records out
    881577984 bytes (882 MB, 841 MiB) copied, 4.6014 s, 192 MB/s

    Using Samsung PRO Endurance 32GB:

    sudo dd if=/dev/testfile of=testfile bs=1M conv=fsync
    840+1 records in
    840+1 records out
    881577984 bytes (882 MB, 841 MiB) copied, 23.7579 s, 37.1 MB/s

  9. Avatar for olivier

    Hello,

    nice work, i succeed to run my Pi4 with my Crucial Bx500 and the ELUTENG adaptator cable, but its very slow to start until the desktop is ok.
    When i said very slow, its between 5 and 10 minutes…lol

    Is there something i can check?

    When i am on the desktop, its fine, i have install hassio in docker, it works, just a problem to load my last snapshot from a hassos config on rpi3 whithout docker.

    Thanks!

    Olivier

    1. Avatar for Christian

      I tried ist also with a Crucial Bx500 SSD, everything fine as long as ist plugged to USB 2 on USB 3 it sometimes dont even start. Doing the same with an older Seagate Maxtor normal HDD much faster and no Problems on USB 3. So It is more likely a problem with the SSD than with the SATA/USB cable.

  10. Avatar for Tom

    I bought the recommended “StarTech.com 2.5″ SATA to USB Cable” to connect a 128 GB Intel 545s to my Raspberry 4. However, I’m quite disappointed by the low performance:

    root@raspberrypi4:~# sync; echo 3 > /proc/sys/vm/drop_caches; dd if=/dev/zero of=~/test bs=8k count=500k conv=fsync; sync; echo 3 > /proc/sys/vm/drop_caches; dd if=~/test of=/dev/null bs=8k count=500k
    512000+0 records in
    512000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 42.1646 s, 99.5 MB/s
    512000+0 records in
    512000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 43.73 s, 95.9 MB/s

    root@raspberrypi4:~# lsusb
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 1f75:0621 Innostor Technology Corporation
    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

    Also tried to set usb-storage.quirks in /boot/cmdline.txt, but although it’s active, it does not speed up things;

    [ 1.271661] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
    [ 1.303041] usb 2-2: New USB device found, idVendor=1f75, idProduct=0621, bcdDevice= 0.36
    [ 1.303071] usb 2-2: New USB device strings: Mfr=4, Product=5, SerialNumber=6
    [ 1.303094] usb 2-2: SerialNumber: 20190803
    [ 1.306134] usb-storage 2-2:1.0: USB Mass Storage device detected
    [ 1.306474] usb-storage 2-2:1.0: Quirks match for vid 1f75 pid 0621: 800000
    [ 1.306590] scsi host0: usb-storage 2-2:1.0
    [ 2.312553] scsi 0:0:0:0: Direct-Access INTEL SS DSC2KW128G8 PQ: 0 ANSI: 6
    [ 2.313656] sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
    [ 2.314576] sd 0:0:0:0: [sda] Write Protect is off
    [ 2.314601] sd 0:0:0:0: [sda] Mode Sense: 3b 00 00 00
    [ 2.315574] sd 0:0:0:0: [sda] No Caching mode page found
    [ 2.315599] sd 0:0:0:0: [sda] Assuming drive cache: write through
    [ 2.319398] sda: sda1 sda2
    [ 2.322897] sd 0:0:0:0: [sda] Attached SCSI disk

    So what’s wrong here? Is it a problem with the SSD, or is it some problem related to the adapter?

    1. Avatar for jamesachambers

      Hey Tom,

      Have you ran my storage benchmark on that drive yet? It looks like the DD write speed on this drive is pretty underwhelming although Intel’s description of this drive is an enterprise level storage that focuses on reliability in an a enterprise level data center rather than high performance. This SSD will probably last decades but the performance on it will never be a head turner as that isn’t what it was made for.

      If you go to Raspberry Pi storage benchmarks let the table load and then sort descending by DD write speed. Once we get down to the 100s we can see your drive (based only on DD speed which is a poor measure of performance) falls in the performance range of something like a Samsung 750 Evo. You’ll also notice that the DD write speed is only a small part of the score as devices in this range can test thousands of points apart when we calculate 4k blocksize and random read/random write scores.

      I do have good news for you though. Intel states this drive is supposed to be above average for small blocksize I/O which is *exactly* what a Pi using it as the operating system drive needs. I would take my storage benchmark on that drive and let us know your total score. The benchmark won’t recognize the drive automatically because it is a pretty uncommon one but it will still score it normally and we may be surprised at the results if Intel is telling the truth about their focus on small blocksize random I/O!

      1. Avatar for Tom

        Hi James,

        thanks for your detailed answer. Here are the results of the benchmark:

        Category Test Result
        HDParm Disk Read 76.20 MB/s
        HDParm Cached Disk Read 73.52 MB/s
        DD Disk Write 92.6 MB/s
        FIO 4k random read 4890 IOPS (19562 KB/s)
        FIO 4k random write 6668 IOPS (26673 KB/s)
        IOZone 4k read 18739 KB/s
        IOZone 4k write 15216 KB/s
        IOZone 4k random read 14683 KB/s
        IOZone 4k random write 17996 KB/s

        Score: 4537

        Probably better than a micro SD card, but not outstanding…

        The main reason why I bought this drive are reliability and durability – however, before buying it, I also looked for a “good” performance, and according to benchmarks I found on the web, it seemed as if this drive would perform quite good.

        As the system did not yet go into productional use – is there any rather cheap, more powerful SSD you would prefer over the Intel 545s, keeping in mind reliability and durability are rather important for my use case?

    2. Avatar for Francois Gervais
      Francois Gervais

      The kernel might not be fast enough to feed the drive. I would make a file in ram first.

      dd if=/dev/urandom of=/dev/testfile bs=1M count=500

      Then use testfile to feed the dd to ~/test.

      1. Avatar for Tom

        Hi Francois,

        thanks for your reply, but that’s not the problem, /dev/zero is fast enough – when using the approach you suggested, the dd write speed slightly increased from 99.5 to 100 MB/s (copying from /dev/zero to /dev/test ran at 472 MB/s).

  11. Avatar for Johnny Graham

    Do you recommend running this set up with the new x855 mSATA card from GeekWorm/SupTronics? They claim to be waiting for the Pi4 group to fix the USB boot issue, but the went ahead and released the card.

    1. Avatar for David Fruehwald

      I did it with their X870 and an Inland Professional 256GB SSD Microcenter had on sale for $30. You will need to add the usb-storage.quirks=aaaa:bbbb:u to /boot/cmdline.txt and I’d recommend skipping the updates until after you have rootfs on the USB3 disk. I also removed rootfs from the SD and boot from the SSD so that I was sure they were not being used.

      1. Avatar for David Fruehwald

        oops, forgot to say aaaa = usb vendor id and bbbb = usb product id for my X870 it was
        usb-storage.quirks=152d:0562:u

    2. Avatar for Louis De Lange

      X855 works, although I had the delay the system update step in step 3, until after completion of step 9. Performance benchmark score with Dogfish SSD is 5200, which means that it is at the low end of all the SSDs out there – but at least it is still 5 times faster than a class 10 microUSB.

      I also tried the usb-storage.quirks as described here https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931#p1501426 but it made performance slightly worse.

  12. Avatar for Richard Jones

    So glad I found this site. I’m new to Linux and looking to put together a Pi based NAS using PoE with an eye on OpenMediaVault (OMV) with a couple of SSD. Has anyone here gone that far? I’ll post a comment when I make any progress

  13. Avatar for Joseph

    ELEGIANT USB 3.0 to SATA, Super Speed USB 3.0 to SATA 22Pin Converter Adapter Cable for 2.5Inch Hard Drive Disk HDD and Solid State Disk SSD, Supports UASP SATA I II III,10CM from amazon.ca works too.

    https://www.amazon.ca/gp/product/B00TH1B250/ref=as_li_ss_tl?ie=UTF8&psc=1&&linkCode=ll1&tag=codemallet08-20&linkId=c158e4f40a240b8270c32dc50526642d&language=en_CA

    However, despite using ASM1153, only show SATA 3Gb /s speeds for my Crucial MX500, Samsung Evo 850 and Samsung Evo 860 2.5 SSD Sata III drives. I will be getting the starmedia one to see if I can get 6Gb /s like you did.

    pi@raspberrypi:~ $ lsusb
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 003: ID 045e:0800 Microsoft Corp.
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    1. Avatar for jamesachambers

      Awesome I am glad you got it working!

      That’s definitely strange that the adapter is only running at 3 GB/s. There are definitely a lot of different versions of ASM1153 out there. Even more confusingly sometimes if you order the same adapter it may have a different chipset in it depending on date of manufacture. The StarTech line has treated me really well though.

      It’s definitely holding back your MX500 for sure. If you search for MX500 and sort by score on the benchmarks you are missing a couple thousand points from all the other Raspberry Pi 4s. I’ll be interested to see the results with the new adapter!

      1. Avatar for Joseph

        Amazing News, StarTech.com SATA to USB Cable – USB 3.0 to 2.5” SATA III Hard Drive Adapter, the same one you recommend here, made a huge difference in performance. My overall Score went from 6329 to 8973. Loading times are highly noticeable faster, including booting times for my Rpi 4. FIO 4k Random read test are 6x times faster, before it was 3865 IOPS 15463 Kb /s, now it is 19534 IOPS (78138 Kb /s)
        It does show 6Gb /s under lsusb. A happy camper now.

  14. Avatar for joseph

    Great guide, however, I got stuck in “Updating fstab” step. Where did you get the new PARTUUID from? you forgot to write instructions how to edit fstab?, I am new to linux here.

    cat /etc/fstab

    proc /proc proc defaults 0 0
    PARTUUID=adf03486-01 /boot vfat defaults 0 2
    PARTUUID=adf03486-02 / ext4 defaults,noatime 0 1
    # a swapfile is not a swap partition, no line here
    # use dphys-swapfile swap[on|off] for that

    findmnt -n -o SOURCE /
    /dev/mmcblk0p2

    1. Avatar for jamesachambers

      Hey joseph,

      Sorry about that, those instructions were pretty terrible and I have updated them. I have basically rewritten that entire section to be much more clear. The key part missing was this command:

      lsblk -o name,label,partuuid

      I really appreciate the feedback. Sometimes when I am writing these things I’ll be in too techy of a headspace and get lost in the weeds. Thanks again!

      1. Avatar for Joseph

        Thank you for such quick reply. You are my man! Got it working now and runs like a champ. Pretty impressive speeds for my Crucial MX500 512Gb compare to my Sandisk Extreme Pro 64Gb. I am using a basic USB 3.0 to SATA connector. Will test with different SSD’s and other usb 3.0 adapters/enclosures

  15. Avatar for Adam B Tolbert

    Hello Author, I read this article, you described so deeply about boot instruction, good chipsets, compatible usb adapters. Can you please advise me best usb drives recovery program which is good for flash drive. I search on internet and most of them asked for Stellar Data Recovery, Recuva. Your suggestion will be appreciated. Thanks!!

  16. Avatar for Wim

    I also encounter the problem of a frozen mouse and keyboard.
    It realy was switched over to the SSD.
    I also run the PI4.
    Is there a solution around? I did not get it.
    Wim

  17. Avatar for Thomas

    I bought some no name USB 3.0 adapter and it turned out to be a JMicron one:
    “`
    $ lsusb
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
    “`

    So… as the result, it didn’t work with USB 3.0 ports but it worked with USB 2.0 ports. However with the MARKUS’ help and the article (https://www.raspberrypi.org/forums/viewtopic.php?t=245931) with `usb-storage.quirks` option for /boot/cmdline.txt` I managed to run my drive successfully with USB 3.0 ports!!!

    Some of you might be curious about the performance and it’s quite good actually, take a look:
    “`
    $ sudo dd if=/dev/zero of=/mnt/test bs=8k count=500k conv=fsync
    512000+0 records in
    512000+0 records out
    4194304000 bytes (4.2 GB, 3.9 GiB) copied, 18.2822 s, 229 MB/s
    “`

    I hope it will help somebody 🙂

Leave a Comment

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

Type here..