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

UPDATE 11/27/2020 – The new Raspberry Pi bootloader is out which makes these instructions largely obsolete. Check out the new Raspberry Pi Bootloader Configuration Guide here

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

StarTech 2.5″ SATA to USB 3.1 Adapter2.5″ SATA to USB 3.0Verified working in comments (thanks Fredrick)
StarTech 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.1Verified working great by myself and others on Pi 4
Orico Transparent 2.5″ SATA to USB 3.0 Enclosure2.5″ SATA to USB 3.1Confirmed working by Ashjas in comments
ELUTENG 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
CSL 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.
Shinestar 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).
QNINE 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.
UGREEN M.2 NVMe SSD Enclosure, USB C 3.1 Gen 2M.2 NVME to USB-C 3.1Confirmed working in comments by Chad D.
UGreen 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
Tanbin mSATA to USB AdaptermSATA to USB 3.0I used this mSATA to USB adapter for my Crucial M550 benchmark — working in 3.0 ports.
Generic mSATA to USB 3.0 Adapter (fe2008)mSATA to USB 3.1Confirmed working in comments by Nico
Canakit 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.

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

  1. Avatar for Atrap

    just to let you know in case some of you have issues with USB3 SATA adapters (or memory stick) not properly supporting the uas mode (USB-Attached SCSI); the Sabrent adapters I have are all based on JMicron chips and have that issue.

    You can force your USB/SATA adapter to fallback to usb-storage mode by inserting

    usb-storage.quirks=VVVV:PPPP:u
    at the beginning of your /boot/cmdline.txt, where VVVV is the VID = vendor Id and PPPP the PID = product Id of your adapter (or USB stick)

    You can find them with the lsusb utility.

    Full discussion here : https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931

    Also if you want your SSD drives to have trimming enabled, create a rules file and enable the fstrim.timer service.

    example /etc/udev/rules.d/my-usb-ssd.rule :

    ACTION==”add|change”, ATTRS{idVendor}==”VID”, ATTRS{idProduct}==”PID”, SUBSYSTEM==”scsi_disk”, ATTR{provisioning_mode}=”unmap”
    You may want to edit the fstrim.service definition, and avoid the discard option in fstab for your partitions as it is not recommended.

    Check this thread for full explanation : https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=245348

    THIS IS COPIED FROM Zeferby answer on another website, UNTESTED. try it at your own risk ( if there’s any)

  2. Avatar for malvism

    There seems to be a problem with new Raspbian version which came out on June (somethn?).
    So on PARTUUID you must set the value 0x2fed7fee

    so blkid will give you such row:
    /dev/sda2: LABEL=”rootfs” UUID=”706944a6-7d0f-4a45-9f8c-7fb07375e9f7″ TYPE=”ext4″ PARTUUID=”2fed7fee-02″

    otherwise it’s searching for root partition on 2fed7fee, although nowhere that was configured

    1. Avatar for malvism

      didn’t notice it at the start, but now it’s loading all data from USB SSD disk:
      pi@raspberrypi:~ $ lsblk
      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      sda 8:0 0 465.8G 0 disk
      ├─sda1 8:1 0 256M 0 part /boot
      ├─sda2 8:2 0 10G 0 part /
      └─sda3 8:3 0 455.5G 0 part /home
      mmcblk0 179:0 0 3.8G 0 disk
      ├─mmcblk0p1 179:1 0 256M 0 part
      └─mmcblk0p2 179:2 0 3.5G 0 part

      but it still need some data from SD card, as it won’t boot if card doesn’t have raspbian on it.

      Any ideas which files are needed?

      1. Avatar for Someone

        You need to make sure to follow the guides in section “Update /etc/fstab”. It appears you have changes both lines to point to your USB device. You must only change the line that is responsible for mounting “/”. The line that mounts “/boot” must still point to the SD card, otherwise all the firmware updates will be done to your USB device, not to the SD card that is actually responsible for updating the firmware.

  3. Avatar for Dave

    I have an Oyen Digital mSATA enclosure with the ASMedia 1153E chipset. It works great, but not with the USB cable it came with. I picked out a shorter, thicker cable and that seems to work great. What a difference in boot times!

  4. Avatar for Don

    I came here to try the SSD boot and found the explanation for why I can’t use my current SSD + 2.5″ SATA adapter in the USB 3.0 ports, so thanks for that. I guess I can’t try now until I get a new adapter.

    For the record, it’s an Apricorn 2.5″ SATA to USB 3.0 adapter I’ve had for years. Plugged into a USB 2 port lbusb shows 0984:0301 Apricorn.

    Doesn’t show up at all when plugged into a USB 3 port.

  5. Avatar for SMIKE

    Went ahead and cat (with pv) over the entire SD Card to the solid state (didn’t feel like starting over); it went superb. (sudo sh -c ‘pv /dev/sdc (the SD card) >/dev/sdb (the SSD)’). Boot up fine and did all the steps splendidly. Thanks for the guide.

  6. Avatar for Paul Verket

    Thanks for a great tutorial! I used your instructions with minor mods to get Ubuntu 20.04 (64 bit) going with a spare APS-XS03-240 SSD on my 4 GB pi4. I’ve used Ubuntu on pi a fair bit and what a huge difference in speed this made!

  7. Avatar for John

    I’ve just tried this using a new 8GB Pi4 with a Kingston A400 SSD and the recommended Startech adapter (along with the May 27 version of raspbianOS) – and it didn’t work using either quirks or non-quirks methods – just never came up after a reboot. I eventually found another way using a tom’s hardware guide of replacing the firmware with a beta version and replacing all the .elf and .dat files on the SSD with ones from the Raspberry Pi org github repo – worked like a charm. still “only” got 7819 though! (shrugs, and waits for native USB boot support in updated stable firmware)…

    1. Avatar for Paul

      I’m having the sam issues as John, using the RaspiOS image from May 27th, 2020.
      I’m going to retry this with the Raspbian Buster image from Feb 13th 2020 (since I happen to have a copy already downloaded)lsu

  8. Avatar for Mckinley

    Undeniably consider that that you stated. Your favourite reason appeared to be at the web the easiest thing to take into accout of.
    I say to you, I definitely get annoyed at the same time as other people consider concerns that they just do not know about.

    You controlled to hit the nail upon the highest and outlined out the whole thing without having side-effects , other folks could
    take a signal. Will probably be back to get more. Thank you

    Se você quiser saber pouco mais de dados, recomendo que encontre este web site: como fazer um bolo de cenoura simples e fofinho

  9. Avatar for Bernhard Geis

    I followed the instructions with “Orico Transparent 2.5″ SATA to USB 3.0 Enclosure” several times without success. Then I switched to “StarTech 2.5″ SATA to USB 3.0 Adapter” and followed the instructions again and now it works perfect. I recommend not to use “Orico Transparent 2.5″ SATA to USB 3.0 Enclosure” but “StarTech 2.5″ SATA to USB 3.0 Adapter”!

  10. Avatar for Steven Skynet

    James, thank you so much for all the work you put into this tutorial, it was a great help and I was able to set up successfully a SanDisk Extreme Pro Solid State Flash Drive with docker and Home Assistant. I have just updated my firmware following this guide https://www.tomshardware.com/how-to/boot-raspberry-pi-4-usb, and my RPi4 can now boot from spare a USB drive I have without the SD card inplace and I can ssh to it. Win!

    A Noob question please, what do I need to do to amend SanDisk Extreme Pro build to take advantage of the no SD card boot, I have copied the *.dat and *.elf files mention in step 9 of the Tomshardware instructions but the SanDisk Extreme Pro build will not boot ( without the SD card ) , I suspect it need something else changed to say “boot from me”, not the redundant SD card. Do you know what that is please?

  11. Avatar for Todd

    I have a ORICO 2.5″ Transparent USB 3.0 to SATA 3.0 External Hard Drive Disk Enclosure Box, USB 3.0 High-Speed Case for 2.5″ HDD / SSD, Case Support UASP Protocol SATA III Tool Free Up To 4TB that will NOT boot from usb3. USB2 boots fine.

    Chip set in mine is: Bus 001 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge

    So might want to put an * in the list of KNOWN WORKING enclosures

    1. Avatar for Todd

      Without QUIRKS would not boot from usb3. WITH quirks on a RPi4 booted to the splash screen (white screen w/ 1 berry on it) and stopped.

      1. Avatar for Paul Hallam

        The “ELUTENG M2 to USB Adapter M.2 SATA NGFF Enclosure Support All SATA B and B + M key SSD NGFF Caddy” uses the same chipset and has the same issues as described here

      2. Avatar for Andy Turfer

        I have the same enclosure: 152d:0578. I’m running Ubuntu Server (64 bit), and it only works with USB 2, which means a disk throughput of around 27MB/s 🙁

        I’m just going to buy a new enclosure, one that is compatible.

  12. Avatar for FireTaz

    Suptronics X825, Pi attached SATA to USB 3.0 board, with Crucial BX500 1TB…..Was 15th fastest of all time in SSD, sraight out of box when taken. Set up this tutorial with a hub, received X825 later, hooked SSD to board, hooked board to Pi 4….ZZZOOOOOOOOOMMMMMM! Very surprising considering the low quality of the BX500. Grabbed it figuring it was good enough for the Pi, instead of a mSD. Very happy and apparently this add on board, plays very well with its own Pi. Scored a 10,306. https://storage.jamesachambers.com/benchmark/23419

  13. Avatar for Chris Hanson

    Thank you for a very in-depth and well thought out tutorial on this subject. I believe with the right USB adapter it will work quite well. I tried it with a Fideco M.2 NVME to USB 3.1 adapter with a Samsung 970 EVO SSD and was able to *almost* finish the process using quirks before an intermittent hang I had been seeing with the unit froze the system.

    This unit seems to not play nice on the USB bus: I also tried it on an Anker USB dock and a Seagate drive on the other USB port promptly unmounted. The drive, which had behaved flawlessly until that point was fine after removing the Fideco adapter.

    This unit has a J Micron JS583 bridge chip on it as do several other similar adapters available. I know this is only one data point, but it seems advisable to stay away from this bridge chip – and not just on a Pi 4.

    Also: my compliments on your storage benchmark package. Very well done!

  14. Avatar for Rodrigo

    Good evening,

    I followed the tutorial and I got the raspberry 4 booting from ssd successfully.

    However after a few hours I lose the connection to the raspberry pi and the SSD box light is off.
    Removing the power of the raspberry and reconnecting, everything back to normal.
    This happens every day.

    Do you have any idea what it might be?

    Thank you.

    1. Avatar for Petter

      I had problems with a Startech.com USB3S2SAT3CB adapter. Good performance, but bad mechanical quality. The connector on the SATA end of the cable is very fragile and easily damaged, resulting in variable/poor connection and all kinds of crash / disconnection of the SSD.

      Also, a not suitable power supply can make such problems. Be sure to use a power supply that is known to be suitable for the Raspberry Pi 4.

    1. Avatar for Jeff

      Are there any tips on how to convert an installation which followed this tutorial to utilize the new bootloader? Or is it better to just leave it be?

      Would it just be a matter of updating /etc/fstab to point to the boot partition on the SSD? And copying the contents of the current /boot partition on the SD card to the SSD? I suspect that they are already close, but couldn’t hurt to copy anyway.

      1. Avatar for Jeff

        Replying to my own question – I went ahead and tried it.

        Copied the contents of the /boot partition on SD Card to the one that was on the SSD.
        Edited the /etc/fstab file to point at the d34db33f-01 partition on the SSD.

        Rebooted – with SD card. Booted fine.
        Shutdown, removed SD Card, started up. Error messages – needs newer software.
        Replaced SD Card, booted.

        Researched that I needed to download the latest *.elf and *.dat files from the github repo. Did this.

        Shutdown, removed SD Card, started up just fine!

          1. Avatar for Maik

            Just for the record – Step by Step:
            I changed the bootloader branch to “stable”
            sudo nano /etc/default/rpi-eeprom-update

            checked partitions with
            lsblk

            Then mounted the 256M Partition to /mnt , in my case
            sudo mount -rw /dev/sda1 /mnt

            Cleared /mnt
            sudo rm /mnt/* -r

            Copied the bootfiles to /mnt
            sudo cp /boot/* /mnt/ -r

            Checked the partid
            blkid

            Edited fstab
            sudo nano /etc/fstab

            Reboot -> Ok
            Shutdown -> Remove SD-Card -> Boot -> Ok

            No need to update *.elf and *.dat anymore.

      2. Avatar for Jeff

        Last comment disappeared…

        I went ahead and tried…

        Copied contents of the /boot folder on the SD Card to the /boot folder on SSD.
        Edited /etc/fstab to point to the d34db33f-01 partition of the SSD.
        Rebooted with SD card still installed and it booted fine.
        Shut down and removed SD card. Started up and got a bunch of errors – one of which stated that newer software was needed for USB boot.

        Replaced SD card, booted. Researched and found link stating that I needed to copy all the *.elf and *.bin files from the github repo.
        Downloaded zip of /firmware/boot from github, and copied them to my /boot folder on the SSD.
        Shut down, removed SD card, restarted, and booted to my desktop with no further issues!

  15. Avatar for neil furnival

    everything for me worked fine, however when i plug in an external drive into the usb 3 port they SSD is plugged into everything I type into the command line says not available. until i unplug the external drive and reboot then everything is back to normal.

    1. Avatar for neil

      adding usb-storage.quirks=XXXX:XXXX:u to the SSD /boot/firmware/cmdline.txt (as it was Ubuntu Port) fixed the problem, but have to remove the external HD before i reboot else it will not load up.

  16. Avatar for Kelly

    I just tried this with several USB-SATA adapters. I can report that the Cable Matters model from this Amazon link:
    https://www.amazon.com/gp/product/B00U6JEKVA/ref=as_li_ss_tl?ie=UTF8&linkCode=ll1&tag=codemallet-20&linkId=4fde69385cca6fb724dd6f4d2dcb1380&language=en_US
    shows as an ASM1051E just like the known good StarTech. Worked fine.

    Before trying that one, I tried one with a smoky translucent shield on the SATA end. I can’t find that in my purchase history, but in “lsusb” it reports as “ID 1f75:0888 Innostor Technology Corporation IS888 SATA Storage Controller”. That one gives an error about “not working / maybe the cable is bad” during bootup. Confirmation steps along the way seemed to show it was the active drive, but I didn’t trust it (and what’s the point if I can’t use USB3?) so I switched to the Cable Matters one which worked perfectly with no boot text errors.

Leave a Comment

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

Type here..