**The new Raspberry Pi bootloader is out which makes these instructions only necessary if you want to continue to use the SD card as a bootloader. View the 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. This is a really common one that works well with the Pi.
The new USB-C 3.1 Type A version of the Sabrent adapter is reported as working in the comments by UEF. DO NOT get the USB 3.0 version as that one is below on the naughty list and won’t work!
Make absolutely sure it’s the 10Gbps USB 3.1 Gen 2 version. There is another one that looks identical that is a USB 3.1 Gen 2 6Gbps that will not work. Confirmed working by RRT in the comments.
It’s bold. It’s beautiful. It’s also confirmed working by TADRACKET and Steve B. However, be warned, it takes a *lot* of power! Steve B. reports that even with the oversized 3.5A CanaKit adapter* it does not work. If you have the standard 3.0 adapter you can be practically certain it won’t power this enclosure. Does work with a powered USB hub*.
Returning legendary commentary Frank Meyer reports: Does not work with a 3.0A power adapter (also reported by TTE). It’s not enough power for this enclosure. Does work with a powered USB hub*.
M.Yusuf has given the first ever report of a working Orico adapter! Make sure it’s the USB 3.1 Gen 2 version that says “Support UASP for NVMe SSD”. This is the way.
Canakit has been making very reliable power supplies for several Pi generations now. Using a 3.5A power supply will give enough extra power for your Pi to power the drive without causing instability
Reported as working by JeffG but with an ugly messy appearance
Known Working Adapters
Known Problematic Adapters (Naughty List)
Here is a list of common USB adapters that are known to have problems with the Raspberry Pi 4. You can get some of these adapters working by using quirks mode (see the “Fix (some) USB Adapter Problems Using Quirks” section below).
Only works in the USB 2.0 ports. Will not boot in a USB 3.0 port. I have two of these and can confirm they don’t work. RIP to Sabrent, our previous king of the Pi 3 era of adapters.
Despite earlier reports as working Ryan and one other have reported this adapter does not work unless you enable quirks mode! Don’t make Ryan’s sacrifice in vain and avoid this one.
Extremely cheap adapter from AliExpress — MADATALIEXPRESS bought 5 of them and none worked, PPCM had one working, very unreliable and slow when it does work, not recommended even if you get lucky!
The Samsung 980 Pro (NVMe) is a professional grade SSD and one of the fastest in the world. The Samsung NVMe drives have been at the top of this category for a long time and are well trusted for both their performance and reliability / long life.
The ICY BOX is basically a giant heatsink that you mount a high performance M.2 NVMe drive inside of. This enclosure is really fast but requires a powered USB hub. Not even the 3.5A adapter can reliably power it! The enclosure works well and will physically feel warm to the touch as it is pulling the heat off your NVMe drive!
The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!
The SanDisk Extreme Pro USB SSD is a true solid state drive. This is different than a typical “flash drive” which uses extremely cheap memory and has very low random I/O performance/throughput compared to a real solid state drive. I’ve used both the USB 3.1 and USB 3.2 variants with the Pi successfully and they benchmark very well!
You may use other types of drives with the Pi such as M.2 SATA to USB 3.0 and m-SATA to USB 3.0. Here’s some adapters I’ve used for those types of drives:
VL716 mSATA Enclosure
The VL716 mSATA enclosure lets you connect micro SATA drives to the Pi. These drives are an older type of SSD (usually seen in laptops) predating the M.2 slot but are still widely available and perform extremely well!
The UGREEN M+B enclosure is a great enclosure for the Pi for M.2 SATA 2280 NGFF drives. It supports both B-key and M-key drives. Does not support newer NVMe drives. As with other types of enclosures it requires more power than other options!
The Argon ONE M.2 is a M.2 SATA Pi 4 case / storage solution. With the case and M.2 SATA expansion board you can completely enclosure your Pi 4 and have a built in M.2 slot! The M.2 SATA board is sometimes sold separately from the case itself and can be used as well. Does not support NVMe, this is for SATA M.2 drives only!
Power can be a serious problem with these drives. We are learning from the comments that you are especially likely to run into power issues with NVMe enclosures. A powered USB hub or a power adapter that puts out 3.5A comes not only just strongly recommended, it may actually be required that you choose one option or the other for your drive to function.
The specific requirements of how much power you’ll need depend on the adapter/enclosure and the model of your drive itself. As a very rough guideline, older models of drives tend to use more power than newer models of drives. 3.5″ form factor drives also use more power than 2.5″ drives. The earliest SSD models like first and second generation models are also well understood to use significantly more power than newer models. This is due to changes and improvements in technology over the years and even using different more efficient memory like 3D NAND. Some super high end performance drives will consume more power as well.
Here’s the current recommendations based on everyone’s comments combined with stuff I’ve personally used with the Pi:
CanaKit 3.5A Power Adapter
The CanaKit 3.5A adapter has an extra half an amp (500 mA) of capacity to give some breathing room to your accessories. This is bigger than the official Pi power supply which provides 3.0A.
The Sabrent powered USB hub delivers a whopping 2.5A of dedicated power for your USB attached devices. This is almost as much as the Pi adapter itself is rated for (3.0A). It will easily power the most thirsty of setups such as NVMe enclosures.
Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power
Fixing (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!):
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!
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.
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:
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:
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:
Press Ctrl+X to tell nano to save our changes. Now type sudo reboot to restart the Pi.
Note: We want to leave the first partition (/boot) on the SD card. If you change this to the SSD then apt will update your SSD instead of the SD card so they won’t be used during boot! Remember that we are using the SD card as a bootloader and that is why the firmware updates (such as start.elf, etc) should go there instead of the SSD’s boot partition (which is never used).
Resizing Filesystem
By default the partition on the SSD / Flash drive will only be 1.8G. The Pi expands this automatically on micro SD drives but we will need to do it ourselves for a SSD / Flash drive. To do this we need to expand the partition and then resize the file system.
First let’s open fdisk and print the partitions:
pi@raspberrypi:~ $ sudo fdisk /dev/sda
Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Disk model: ASM105x
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd34db33f
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 4390911 3858432 1.9G 83 Linux
There is the line we need. Our start value for /dev/sda2 (rootfs) is 532480. Next we need to remove and recreate the partition as a larger size.
If you make any mistakes during this command just close fdisk by pressing q. The changes won’t be written to disk. If you mess up any of the commands the drive will no longer boot and you’ll have to start over again so be careful!
Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-500118191, default 2048): 532480
Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-500118191, default 500118191): 500118191
Created a new partition 2 of type 'Linux' and of size 238.2 GiB.
Partition #2 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: N
Command (m for help): w
The partition table has been altered.
Syncing disks.
If everything went well then type “w” and press enter. Otherwise press “q” to quit and try again. Once you enter “w” the changes will be permanently written to disk!
Now reboot the system. Type “df -h” to view the current disk:
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.
And that’s it! You will now be using all of your space on your drive.
Verify SSD Functionality / 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:
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!
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.
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.
1,024 thoughts on “Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives”
Pawel Kolberg
Hello guys,
strange behavior here. Got the advised USB312SAT3CB from startech, a Kingston A400 with 240gb and the default 3A power supply on my rasp4b. But it hangs on “4 ports detected” on boot. Only goes on booting when i replug the ssd to the connector.
That is some strange behavior indeed! I do have a lead for you. This has recently got a bunch more posts/activity over the past few days so I’m guessing you’re not the only one that has seen this issue come up again. My best guess from reading this is that this is a regression that was fixed in the 4.19 branch but is now back after they updated the kernel to the 5.x branch. One of the devs said: “There is a possibility that there’s a regression in how the passthrough plumbing works in kernels after 4.19. This relates to my previous comment about my downstream patch exacerbating an upstream issue.”. It’s very possible this is a kernel level issue and mostly outside our control other than changing to a different kernel version (if a working one is identified) or wait for them to patch it (ugh).
Other things to check: Is there anything else plugged into your Pi? A USB keyboard, anything? I’ve seen that drain enough power to not boot properly before. It’s tricky because you have the same symptoms as power would cause but with power if you try enough times it usually will go and with yours I’m guessing no matter how many times you try it won’t go. That could be because there is literally never enough power but I think there’s a good chance it will be something to do with these kernel issues.
One repeating thing I’m seeing come up in this thread is arm_64bit=1 vs not having that flag and some other things. What is your configuration? Are you running a 32 bit default Raspberry Pi OS install? Outdated firmware is another possibility which I have a guide to update here.
Thank you for the hint. Kernel was one of my last guesses, too. Tried arch arm and raspos lite 32. Flashed it with different eeproms like 20 times, even beta. Nearly bricked, i thought. Thought im on the safe side following your advices, just went a bit to far (i guess) by taking the 3.1 (which i dont really need for the pi) instead 3.0 cable from startech, which seems more reliable!? Is it normal the 3.1 shows as ASM105x from ASMT with dmesg? Support says yes, older versions could do ident different. Since there are different, maybe not all USB312SAT3CB work out of the box? Its just the usb, pi and me, sometimes the lan cable attached to electic. Nothin else. Invested nearly a week. Cable or Software
There definitely are some differences between 3.0 and 3.1 but I think the actual problem is the way the Pi implements 3.1 (or doesn’t implement it, more on that later). 3.2 devices also seem to much more universally work but 3.1 devices are where there’s all kinds of weird issues.
This one in particular had been fixed but I remember it from comments in this very post when it used to happen (from a long way back, hundreds and hundreds down). The Pi 4 can only implement USB 3.0 so what is happening is a mix between the vendors implementing backwards compatibility with 3.0 wrong in some cases and the Pi implementing the USB spec wrong in other cases. The Pi has had serious issues with USB-C from the start.
I’m sure if you installed an old copy with the 4.19 kernel it would probably fire up just fine if you have one of those available. It sounds like you’ve definitely already covered the Pi’s firmware with all those flashes although sometimes the recovery image (from the Pi Imager tool as the recovery option image) will fix weird issues like this as well particularly with the bootloader. You may also want to consider trying the 64 bit version of Raspberry Pi OS as it tends to have newer fixes in than the mainline version.
I have a mix of the 3.0 and 3.1 adapters and I haven’t seen this and I’m not sure why. I do have an idea though. Can you go here and download the firmware for the adapter. You’ll probably have to disconnect it from the Pi and use a Windows PC to do this unless there were Linux options I wasn’t seeing on their site. Basically once you launch the update with the adapter plugged in (I didn’t have a drive attached to it but it probably doesn’t matter) it will pop up a screen that says something like “Successful, please replug the device”. The firmware update fixes trim support and some other things and I have a hunch it might get yours to work like mine does!
Done alrdy. Since a quick downgrade to 4.19 failed with a boot error like firmware to old, i now try the opposite. Archarm64. Not ONE time i had luck in this universe. Just grey hair, starting with the zero nearly 6 years back. Keep you updated. Btw the github link is mostly hdd related.
It’s not adding up then and definitely points away from the adapter. Just as a test I tried setting up a brand new Raspberry Pi OS 32 bit from Pi Imager with my 3.1 adapter, headless configuration:
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux
pi@raspberrypi:~ $ lsusb
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
You can see how many years of reliable service this thing has given for USB booting on the Pi here. It even has layers of sealant on it!
I’d think it has to be power related at this point. It’s definitely not anything to do with the kernel or the adapter as I just tested the same hardware / firmware revision / OS and it fired right up. Power is also the #1 cause of any of these issues over the years for sure. The only other hardware thing I could think is if the Kingston A400 has a firmware update for it that for some reason would make a difference but I haven’t heard of a drive firmware update fixing an issue like this before but it’s possible if something was tweaked on the USB stack etc. Still may be worth checking out if there’s no other options.
Definitely let us all know what happens since this one has been a really deep mystery and you have me on the edge of my seat! The last time I had this much trouble helping someone with one it ended up being they had formatted the drive with zfs before or something really weird and not even the Pi Imager tool was detecting it. He had to completely delete all of the partitions from within fdisk and then image the drive and then it was able to USB boot correctly. If you have spares of anything around that you can swap like spare drives etc. you can test it’s worth it to narrow things down. Best of luck and let me know if I can help further!
Some news: Raspi OS 64 works like a charm. Newest image, Raspi Imager to ssd and it boots straight away. Arch64 didnt, but it was late yesterday. Couldnt detect my second partition. But i have hope again. Ive red some updates with chroot to the ssd could help
Fantastic, I’m actually kind of surprised, that sounds like it was a kernel issue after all! That lines up more with my earlier theory where the bug reports related to this issue had all of the sudden got a bunch of new activity within the past week and nobody had brought this issue up here in years which would point toward a regression (when a fixed bug in an older kernel branch finds it’s way back into the new branch and reappears). This issue hasn’t really been coming up recently until now if you look through the previous comments here.
The 64 bit distribution seems to be based on their “next” distro since it’s literally the “beta” distribution but the upside of that is that fixes that won’t make it to 32 bit Pi for another year have been on the 64 bit one for 6 months already etc. Thanks for letting us know what got it for you, I’m sure it will help others who are fighting with this!
auanasgheps
Hi,
Looks like that THIS enclosure does not work which is probably a variant of other ORICO devices that don’t work.
This one is a M2 SATA to USB-C 3.1 Gen 1.
It is recognized by the raspberry (I’m using an old Raspberry Pi 3) but I can’t boot from it. Not sure if it’s the Pi3 fault, though.
Very interesting, I haven’t seen that one before! It looks just like the ICY BOX lineup but it has a USB 3.1 Gen 1 chipset. This is probably what the issue is. I’ve noticed Gen2 devices seem to be a lot more compatible and don’t have the conflict. I’ve added it to the list here.
When I check out jmicron.com it says that theoretically the JMS580 should have a Gen 2 chipset. It may be worth checking if Orico has a firmware update available for that model which some others have let me know in the comments fixed their enclosures but they aren’t always available.
Actually is visually identical to one you have listed at this link but has Gen 1 speed.
However, your theory about Gen 2 applies once again: I’ve returned the Orico and ordered this one which just arrived few minutes ago.
Is “no name” and doesn’t have many reviews, but hey, IT WORKS!
I’ve ordered it because Amazon says it comes with the VL716 chip, which is mentioned in your website.
So yes, the ORICO is confirmed not to work (I wasn’t doing anything wrong with the setup) and the Eletrand (the name does not appear anywhere?) box works.
Excellent, I’m glad you got it working! I’m not actually sure why it’s so finicky with the USB 3.1 chipsets as they are supposed to be pretty similar to each other and backwards compatible etc. It’s just a pattern I’ve noticed that even from brands that are notorious for not working with the Pi like Sabrent and Orico seem to work with their Gen 3.2 chipsets!
The VL716 chip has always worked perfectly for some reason even though it is a USB 3.1 chipset. Most of my experience with it comes from the mSATA enclosures where it’s extremely common. It seems to be one of the few 3.1 chipsets that plays nice for some reason. Thanks for letting us know how it all turned out!
That’s an interesting one. I don’t recognize JMS567 but I am seeing nothing but problems when I google JMS567. This was the third result down which they actually link to my site in the original post. That made my day! More importantly though, he seems to say there are firmware updates available that may help. Others have left comments here before saying firmware updates fixed their specific adapter, so it’s always worth investigating whether there is any such firmware available for yours!
Have you tried the USB quirks mode yet? Some of the people were able to get it working in quirks compatibility mode which disables UAS (some adapters don’t support UAS) and can get these working. I do have a quirks section in this article if you want to give it a try. Thanks for letting us know your experience!
The only Sabrent I have found that works well is the USB 3.0 Dual Bay Docking Station. It boots up the Pi running Manjaro very fast. Nice performance. But the other two Sabrents do not work, as you mentioned above
That is interesting! I’ve had a couple other comments left on some of the Sabrent adapters here and there as well. It seems like the USB 3.1/3.2 ones (which I don’t think there’s too many Sabrent ones but there are some) are more likely to work as they don’t seem to have whatever firmware issues the chipset they used in many of their earlier 3.0 adapters had. I’ve added the dual bay to the list as a working one!
I’ve also heard you can download firmware from Sabrent to fix some enclosures. I’ve heard that the performance still isn’t great but that some of them do work better that you can find firmware updates for. Thanks for leaving a note with your specific one, it will definitely help others!
Many thanks for your detailed instructions. I’m using the Ugreen USB-C Port enclosure (model ref 50743) with the same chipset as displayed in your examples. Using quirks made no difference, each time I plugged the ugreen into a usb3 port on either of my pi4s it would lock the pi up but work happily in the usb2 ports. Searching with google I found a reference to both the HDMI and wifi affecting transfers in astrophotography applications. Stopping the HDMI made no difference but as soon as I used the lan port and turned wifi off the ugreen booted first time in a usb3 port.
This may well be a red herring but it works for me achieving a 7,500+ score in your ratings.
Maybe a little late to the show, but I have recently bought a Sabrent USB 3.1 SATA adapter and it works fine booting from my SanDisk SSD Plus on a USB 3 port. Just wanted to mention it, maybe there were some updates, which fixed the problems mentioned above.
I believe there have been firmware updates to the newer revisions. I think it’s also possible to download the firmware update from Sabrent for certain adapters and others have mentioned to me in the past that this works. Great to know the new revisions are working!
Maybe I was a little bit too optimistic: I’m using the SSD with a Home Assistant installation and it turned out that even if it should be faster with an SSD the startup takes 10 min. I double checked with the same installation on a SD card and the startup time is only about 2 mins.
To actually verify my assumption I ordered a new adapter (UGREEN) to check if the SSD works better.
UPDATE: So I received the new connector and I have to admit, that I was wrong about the Sabrent adapter. The startup time really seems to be related to the adapter. So I think your list is definitely still correct.
That’s fantastic you got it working at full speed! No worries about the Sabrent adapter, I know some people have got it working with newer revisions/firmware updates but I don’t believe that one supports UAS so the performance will be limited.
I agree with all your conclusions, we will leave it on the list where it is just to steer people away from the problems associated with that one. Take care!
Hello guys,
strange behavior here. Got the advised USB312SAT3CB from startech, a Kingston A400 with 240gb and the default 3A power supply on my rasp4b. But it hangs on “4 ports detected” on boot. Only goes on booting when i replug the ssd to the connector.
Hey Pawel,
That is some strange behavior indeed! I do have a lead for you. This has recently got a bunch more posts/activity over the past few days so I’m guessing you’re not the only one that has seen this issue come up again. My best guess from reading this is that this is a regression that was fixed in the 4.19 branch but is now back after they updated the kernel to the 5.x branch. One of the devs said: “There is a possibility that there’s a regression in how the passthrough plumbing works in kernels after 4.19. This relates to my previous comment about my downstream patch exacerbating an upstream issue.”. It’s very possible this is a kernel level issue and mostly outside our control other than changing to a different kernel version (if a working one is identified) or wait for them to patch it (ugh).
Other things to check: Is there anything else plugged into your Pi? A USB keyboard, anything? I’ve seen that drain enough power to not boot properly before. It’s tricky because you have the same symptoms as power would cause but with power if you try enough times it usually will go and with yours I’m guessing no matter how many times you try it won’t go. That could be because there is literally never enough power but I think there’s a good chance it will be something to do with these kernel issues.
One repeating thing I’m seeing come up in this thread is arm_64bit=1 vs not having that flag and some other things. What is your configuration? Are you running a 32 bit default Raspberry Pi OS install? Outdated firmware is another possibility which I have a guide to update here.
Definitely let us know what you find!
Thank you for the hint. Kernel was one of my last guesses, too. Tried arch arm and raspos lite 32. Flashed it with different eeproms like 20 times, even beta. Nearly bricked, i thought. Thought im on the safe side following your advices, just went a bit to far (i guess) by taking the 3.1 (which i dont really need for the pi) instead 3.0 cable from startech, which seems more reliable!? Is it normal the 3.1 shows as ASM105x from ASMT with dmesg? Support says yes, older versions could do ident different. Since there are different, maybe not all USB312SAT3CB work out of the box? Its just the usb, pi and me, sometimes the lan cable attached to electic. Nothin else. Invested nearly a week. Cable or Software
Hey Pawel,
There definitely are some differences between 3.0 and 3.1 but I think the actual problem is the way the Pi implements 3.1 (or doesn’t implement it, more on that later). 3.2 devices also seem to much more universally work but 3.1 devices are where there’s all kinds of weird issues.
This one in particular had been fixed but I remember it from comments in this very post when it used to happen (from a long way back, hundreds and hundreds down). The Pi 4 can only implement USB 3.0 so what is happening is a mix between the vendors implementing backwards compatibility with 3.0 wrong in some cases and the Pi implementing the USB spec wrong in other cases. The Pi has had serious issues with USB-C from the start.
I’m sure if you installed an old copy with the 4.19 kernel it would probably fire up just fine if you have one of those available. It sounds like you’ve definitely already covered the Pi’s firmware with all those flashes although sometimes the recovery image (from the Pi Imager tool as the recovery option image) will fix weird issues like this as well particularly with the bootloader. You may also want to consider trying the 64 bit version of Raspberry Pi OS as it tends to have newer fixes in than the mainline version.
I have a mix of the 3.0 and 3.1 adapters and I haven’t seen this and I’m not sure why. I do have an idea though. Can you go here and download the firmware for the adapter. You’ll probably have to disconnect it from the Pi and use a Windows PC to do this unless there were Linux options I wasn’t seeing on their site. Basically once you launch the update with the adapter plugged in (I didn’t have a drive attached to it but it probably doesn’t matter) it will pop up a screen that says something like “Successful, please replug the device”. The firmware update fixes trim support and some other things and I have a hunch it might get yours to work like mine does!
Done alrdy. Since a quick downgrade to 4.19 failed with a boot error like firmware to old, i now try the opposite. Archarm64. Not ONE time i had luck in this universe. Just grey hair, starting with the zero nearly 6 years back. Keep you updated. Btw the github link is mostly hdd related.
Hey Pawel,
It’s not adding up then and definitely points away from the adapter. Just as a test I tried setting up a brand new Raspberry Pi OS 32 bit from Pi Imager with my 3.1 adapter, headless configuration:
pi@raspberrypi:~ $ uname -aLinux raspberrypi 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux
pi@raspberrypi:~ $ lsusb
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
You can see how many years of reliable service this thing has given for USB booting on the Pi here. It even has layers of sealant on it!
I’d think it has to be power related at this point. It’s definitely not anything to do with the kernel or the adapter as I just tested the same hardware / firmware revision / OS and it fired right up. Power is also the #1 cause of any of these issues over the years for sure. The only other hardware thing I could think is if the Kingston A400 has a firmware update for it that for some reason would make a difference but I haven’t heard of a drive firmware update fixing an issue like this before but it’s possible if something was tweaked on the USB stack etc. Still may be worth checking out if there’s no other options.
Definitely let us all know what happens since this one has been a really deep mystery and you have me on the edge of my seat! The last time I had this much trouble helping someone with one it ended up being they had formatted the drive with zfs before or something really weird and not even the Pi Imager tool was detecting it. He had to completely delete all of the partitions from within fdisk and then image the drive and then it was able to USB boot correctly. If you have spares of anything around that you can swap like spare drives etc. you can test it’s worth it to narrow things down. Best of luck and let me know if I can help further!
Some news: Raspi OS 64 works like a charm. Newest image, Raspi Imager to ssd and it boots straight away. Arch64 didnt, but it was late yesterday. Couldnt detect my second partition. But i have hope again. Ive red some updates with chroot to the ssd could help
Hey Pawel,
Fantastic, I’m actually kind of surprised, that sounds like it was a kernel issue after all! That lines up more with my earlier theory where the bug reports related to this issue had all of the sudden got a bunch of new activity within the past week and nobody had brought this issue up here in years which would point toward a regression (when a fixed bug in an older kernel branch finds it’s way back into the new branch and reappears). This issue hasn’t really been coming up recently until now if you look through the previous comments here.
The 64 bit distribution seems to be based on their “next” distro since it’s literally the “beta” distribution but the upside of that is that fixes that won’t make it to 32 bit Pi for another year have been on the 64 bit one for 6 months already etc. Thanks for letting us know what got it for you, I’m sure it will help others who are fighting with this!
Hi,
Looks like that THIS enclosure does not work which is probably a variant of other ORICO devices that don’t work.
This one is a M2 SATA to USB-C 3.1 Gen 1.
It is recognized by the raspberry (I’m using an old Raspberry Pi 3) but I can’t boot from it. Not sure if it’s the Pi3 fault, though.
Uses JMS580. (I can’t get this info out of dmegs)
Hey auanasgheps,
Very interesting, I haven’t seen that one before! It looks just like the ICY BOX lineup but it has a USB 3.1 Gen 1 chipset. This is probably what the issue is. I’ve noticed Gen2 devices seem to be a lot more compatible and don’t have the conflict. I’ve added it to the list here.
When I check out jmicron.com it says that theoretically the JMS580 should have a Gen 2 chipset. It may be worth checking if Orico has a firmware update available for that model which some others have let me know in the comments fixed their enclosures but they aren’t always available.
Hopefully that helps!
Actually is visually identical to one you have listed at this link but has Gen 1 speed.
However, your theory about Gen 2 applies once again: I’ve returned the Orico and ordered this one which just arrived few minutes ago.
Is “no name” and doesn’t have many reviews, but hey, IT WORKS!
I’ve ordered it because Amazon says it comes with the VL716 chip, which is mentioned in your website.
So yes, the ORICO is confirmed not to work (I wasn’t doing anything wrong with the setup) and the Eletrand (the name does not appear anywhere?) box works.
Excellent, I’m glad you got it working! I’m not actually sure why it’s so finicky with the USB 3.1 chipsets as they are supposed to be pretty similar to each other and backwards compatible etc. It’s just a pattern I’ve noticed that even from brands that are notorious for not working with the Pi like Sabrent and Orico seem to work with their Gen 3.2 chipsets!
The VL716 chip has always worked perfectly for some reason even though it is a USB 3.1 chipset. Most of my experience with it comes from the mSATA enclosures where it’s extremely common. It seems to be one of the few 3.1 chipsets that plays nice for some reason. Thanks for letting us know how it all turned out!
Hi there,
I have one like this:
Bus 001 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridgeAnd this does NOT work.
Cheers
Fuuu
Hey Fuu,
That’s an interesting one. I don’t recognize JMS567 but I am seeing nothing but problems when I google JMS567. This was the third result down which they actually link to my site in the original post. That made my day! More importantly though, he seems to say there are firmware updates available that may help. Others have left comments here before saying firmware updates fixed their specific adapter, so it’s always worth investigating whether there is any such firmware available for yours!
Have you tried the USB quirks mode yet? Some of the people were able to get it working in quirks compatibility mode which disables UAS (some adapters don’t support UAS) and can get these working. I do have a quirks section in this article if you want to give it a try. Thanks for letting us know your experience!
The only Sabrent I have found that works well is the USB 3.0 Dual Bay Docking Station. It boots up the Pi running Manjaro very fast. Nice performance. But the other two Sabrents do not work, as you mentioned above
Hey William,
That is interesting! I’ve had a couple other comments left on some of the Sabrent adapters here and there as well. It seems like the USB 3.1/3.2 ones (which I don’t think there’s too many Sabrent ones but there are some) are more likely to work as they don’t seem to have whatever firmware issues the chipset they used in many of their earlier 3.0 adapters had. I’ve added the dual bay to the list as a working one!
I’ve also heard you can download firmware from Sabrent to fix some enclosures. I’ve heard that the performance still isn’t great but that some of them do work better that you can find firmware updates for. Thanks for leaving a note with your specific one, it will definitely help others!
Many thanks for your detailed instructions. I’m using the Ugreen USB-C Port enclosure (model ref 50743) with the same chipset as displayed in your examples. Using quirks made no difference, each time I plugged the ugreen into a usb3 port on either of my pi4s it would lock the pi up but work happily in the usb2 ports. Searching with google I found a reference to both the HDMI and wifi affecting transfers in astrophotography applications. Stopping the HDMI made no difference but as soon as I used the lan port and turned wifi off the ugreen booted first time in a usb3 port.
This may well be a red herring but it works for me achieving a 7,500+ score in your ratings.
How strange, that’s a great workaround though, thanks for sharing, I’m sure it will help someone!
Maybe a little late to the show, but I have recently bought a Sabrent USB 3.1 SATA adapter and it works fine booting from my SanDisk SSD Plus on a USB 3 port. Just wanted to mention it, maybe there were some updates, which fixed the problems mentioned above.
Hey Christian,
I believe there have been firmware updates to the newer revisions. I think it’s also possible to download the firmware update from Sabrent for certain adapters and others have mentioned to me in the past that this works. Great to know the new revisions are working!
Maybe I was a little bit too optimistic: I’m using the SSD with a Home Assistant installation and it turned out that even if it should be faster with an SSD the startup takes 10 min. I double checked with the same installation on a SD card and the startup time is only about 2 mins.
To actually verify my assumption I ordered a new adapter (UGREEN) to check if the SSD works better.
I’ll keep you updated
UPDATE: So I received the new connector and I have to admit, that I was wrong about the Sabrent adapter. The startup time really seems to be related to the adapter. So I think your list is definitely still correct.
Hey Christian,
That’s fantastic you got it working at full speed! No worries about the Sabrent adapter, I know some people have got it working with newer revisions/firmware updates but I don’t believe that one supports UAS so the performance will be limited.
I agree with all your conclusions, we will leave it on the list where it is just to steer people away from the problems associated with that one. Take care!
just tested the ORICO 2,5″hard drive enclosure 2520U3 with suported UASP but it has the J_Micron inside and did not work to boot RP pi OS
Thanks Richon, I did not have that one and have added it to the list!