**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.
Beautiful blog by the way!
Nicely made, actively maintained, tops!
Erik A.
3 years ago
Why make this all so complex?
I bought a msata SSD drive (with USB 3.0 adapter), made an image file from my Raspberry SD card, then wrote that image to my SSD drive.
And that’s it.
That is because this guide is because from way before that is possible and is the “old method” (mentioned in bold at the very top of the page). You are talking about the newer method using the Raspberry Pi bootloader which pretty much is that simple and the guide for that is here: Raspberry Pi 4 Bootloader USB Mass Storage Boot Guide.
I believe that the ELUTENG is a JMS578 adapter which means you may be able to update the firmware using my fixing storage adapters with firmware updates guide. On some adapters this has fixed them so you no longer have to use “quirks” mode and can enable UAS which increases performance. It may be worth a try as the worst thing that has ever happened when trying this is it won’t detect your adapter or the update won’t change anything (the updater checks for the JMS578 chipset specifically and it’s used in a wide range of adapters).
At any rate I’m glad you got it going and thanks for leaving the comment about the ELUTENG!
My chipset is JMicron JMS567 – I’ll try updating firmware to see if that works and let you know… ty
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: 2021-05-07-raspios-buster-arm64.zip
With quirks I’m getting:
Sequential Write: 172000 (slowest test) 241860 (fastest test) KB/sec
Random write: 6289 IOPS (consistent range for multiple tests)
Random read: 4645 IOPS (consistent range for multiple tests)
I’ve got another setup – no quirks on USB3
Drive: Inateck 2.5 Hard Drive Enclosure, USB 3.0 adapter
OS: Ubuntu Server 21.04
I did not test, but I’m going to, so I can compare. I’ll update this if anyone is interested.
Excellent! Here’s a good test to compare it to with a USB 3.0 adapter not using quirks on the Kingston A400. It looks like with UAS enabled / no quirks they got about 15,036 rand read IOPS and 7,778 rand write IOPS. It’s curious you got a higher write speed than read speed! This benchmark was 10% above average with a score of 6785, which is right where we would expect it to be without going NVMe or M.2 SATA.
People have got the Kingston A400 all the way up to 9481 though like here using the highest performance storage adapters (usually the StarTech) and a monster overclock reaching a whopping 27k write IOPS and 35k read IOPS!
I’d say it’s probably a 20-30% performance penalty usually although if those random read numbers are correct then losing UAS may be reducing the read performance by a good 60-70% if those numbers are consistent / not an outlier.
I’m curious what your comparison will be to the Inateck!
Hi James, Test result in post above was using Raspberry Pi Diagnostics, for what that’s worth – sudo apt install agnostics
Tests below using your link: sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash
4G Pi4
Adapter: ELUTENG 2.5″ SATA to USB 3.0 Adapter*
Chipset:JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: 2021-05-07-raspios-buster-arm64.zip
Quirks: Yes
FIO results – 4k RandWrite: 5785 IOPS (23141 KB/s) – 4k RandRead: 4267 IOPS (17070 KB/s)
Note: Should I try updating my JMS567 with JMS578 firmware? I don’t care if I brick it, if you think it may work?
If so I’ll add those results as a comparison to these.
—————————————————————————————————
8G Pi4
Adapter: Inateck 2.5 Hard Drive Enclosure, USB 3.0 adapter
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: Ubuntu Server 21.04 64
Quriks: No
FIO results – 4k RandWrite: 14453 IOPS (57812 KB/s) – 4k RandRead: 22068 IOPS (88275 KB/s)
That looks right. You can see your DD Write speed is nearly 50% of the non-quirks adapter/enclosure test!
I would absolutely try updating the firmware. I double checked and I couldn’t find somebody saying they tested the ELUTENG one specifically yet but the chipset is right and the update tool will find it even if it’s not from your specific manufacturer (namely because we are updating the chipset controller and a JMS567 is always a JMS567 made by JMicron and every adapter that uses one had to buy the controller from them).
I’ve never heard of anyone bricking one before trying this (since the update looks for a specific JMS567 etc.) but if you aren’t worried about bricking it then I would say extra double yes give it a try and let’s see if it helps! The worst case scenario is it still won’t boot without quirks enabled but we have had some success in the past with generic adapters. Even if it does nothing I would test it again to see if your performance numbers improved because on some chipsets if they can’t fix it they can sometimes greatly reduce the performance impact.
People definitely do routinely fix various adapters though. A couple examples are here and JSiler even got one like a week ago here so this is absolutely worth a try even though we don’t have a confirmation on the ELUTENG yet.
Rebooted without removing quirks and ran test – similar result to with quirks
Removed quirks – would not boot – no desktop nor could I ssh
Booted to USB2 – desktop was there. Shutdown – I did not add quirks back
Booted back to USB3 – no desktop just quick flash of pi image, but I could ssh in
Ran test – FIO results – 4k RandWrite: 11609 IOPS (46439 KB/s) – 4k RandRead: 23897 IOPS (95589 KB/s)
sudo apt update && sudo apt upgrade
Reboot – no desktop or ssh
Hard Reboot few times – got desktop image once but nothing else on screen – could no longer ssh in
Back to USB2 – add quirks
USB3 boots but same speed
I’m going to try installing Ubuntu 21.04. I had similar issues with Ubuntu 20.04 on Inateck adapter.
Just realized if I hit enter a few times at the end of test, I get a nice formatted output – boo me )
Excellent work so far! I have heard of going to the newer Ubuntu making a difference in some cases. That may be due to newer/better onboard firmware as well. Let us know what else you find, it would be great to have some definitive information on the ELUTENG!
Plugged adapter into my pc to overwrite – could no longer read on USB3 (firmware update?) – USB2 worked fine but would be slow to write OS
Plugged adapter into MacBook – read fine on USB3
Adapter: ELUTENG 2.5″ SATA to USB 3.0 Adapter with updated firmware
OS: See below – all 64 bit
4g Pi4
Replaced 2021-05-07-raspios-buster-arm64 with Ubuntu Desktop 21.04
Booted fine, no wireless keyboard or mouse though – used wired
Update and upgrade, was chugging along until screen went black and never came back – left overnight
Hard reboot a few times – no joy – blank screen
Replaced Ubuntu Desktop 21.04 with Ubuntu-Mate 20.10
Booted fine
Update and upgrade completed
Reboot – ‘You are in emergency mode – Enter for maintenance mode Ctrl-D to continue’
‘Ctrl+D’ – Mate icon comes up and just spins – let go for an hour
Hard reboot – ‘enter’ – takes me to root – tried to install curl but it failed
Since no luck with desktops – I tend to use hammer over brains approach
Replace Ubuntu-Mate 20.10 with Ubuntu Server 21.04
Booted fine – I did not run update && upgrade yet (scared after above results -)
Ran test- FIO results – 4k RandWrite: 15875 IOPS (63503 KB/s) – 4k RandRead: 13145 IOPS (52580 KB/s)
Update && Upgrade
Reboot – success – old kernel 5.11.0-1007-raspi new kernel 5.11.0-1017-raspi
Ran test again – FIO results – 4k RandWrite: 15753 IOPS (63015 KB/s) – 4k RandRead: 12792 IOPS (51168 KB/s)
Success – don’t need desktop anyway. Going to replace my home IoT server running on SD with this.
Thank you very much for your generous help, James. Won’t hurt my feelings if you delete most of my mess here and leave
an overview.
Link to git repo showing some of the stuff I do with my students on Pis – each has a video RaspberryPiServer_Xbee_Pi
I would never delete your messy comments! Mine are much worse and larger / more messy most likely all the time but that’s part of the “flavor” of the site. You’re going to find some weird stuff on here you won’t see anywhere else (especially detailed notes/experiments/etc.) so you are right at home!
Thanks for experimenting on this for us. I think you’ve definitively determined that the ELUTENG can not be saved and upgraded/fixed to have UAS support and if anything it will hurt that one to even try. This is how we’ve built up the list of information as a community over the years by experimenting and documenting this. It started with me but it would have never got this big without everyone else from all over the world trying every adapter under the sun and reporting the results!
Honestly I think you will be much happier with the StarTech overall. The performance scores on average are higher because it just has a higher “grade” of storage controller (think more expensive, probably 20 cents instead of 5 cents for a non-UAS capable one). I believe the StarTechs are a ASMedia chipset instead of a JMicron. This should take good care of you including on desktop and all devices/situations I’ve encountered so I think you’ll be all set!
Thank you James – Another weird thing is when I now plug adapter into USB2 (won’t read on USB3) on PC it kills my wireless mouse. Maybe the same reason I could not use wireless keyboard/mouse on Pi when I plug it in. Strange happenings.
That actually sounds a lot like power. You basically have a finite budget that all of your USB accessories draw power from. This will include even things like wireless keyboards/mice (and wired of course which use even more power). Here’s the technical link.
USB 3.0 is capable of providing more power than USB 2.0. I’m guessing this is “cutting off” your drive and keeping you within the power budget but under USB 3.0 your power collapses and it won’t boot. An easy test to see if I’m right is plug in the same combination on your computer and see if it cuts off like that (it won’t). Try plugging in the adapter to a USB 2.0 and the dongle in the same type as before. If it’s some sort of firmware bug it should still break it on the computer. Or are you saying it’s only breaking on the computer now?
It looks like there’s a bunch of dodgy ELUTENGs out there (this is very strange behavior). This person bought 10 of them and got widely varying results! You can also see that nobody has had a good thing to say about the ELUTENG basically.
There was some confusion early on about the ELUTENG because it used to be a different “model” that worked and then got changed into the blue connector version that we know/don’t love. Someone exposed this on the Pi forums here. I honestly think the ELUTENG might be worse than the Sabrents because these days most of the Sabrent ones can be successfully fixed with a firmware update (unlike the ELUTENG).
Do you have a powered USB hub by chance? You don’t have to have that specific Sabrent one, anything that you could power the drive off for a test would do!
There are also various versions of the firmware out there and you could try flashing different versions with to restore the original PC/Pi behavior or potentially still fix it. One of them will make the ELUTENG work (it doesn’t seem to like the one we tried which I think is Sabrent’s) and there can’t be more than a few major variants out there. There are more versions out there than I can count: JMS567+firmware but I suspect these only have very minor variations between them in reality but those very minor variations could cause exactly something like this.
Depending on your level of determination I would download a couple of these and see if one of them gets it working the way it was (or even better actually fixes it)! It could take more but I’m guessing the first 1 or 2 you try will restore the exact same behavior. Most of these are made in the same factories in China and there’s a dozen identical adapters to the ELUTENG out there sold on AliExpress etc. as completely different labels that are clearly the exact same adapter. Take a look at this one. It even says “ACCESS POWER” on it just like the ELUTENG but you will not find the name ELUTENG anywhere in that listing or the other lookalikes.
I think you’ll be much, much happier with the StarTech all around though!
Thanks James – I’m going to use it over ssh with Ubuntu Server, so no other USB connections necessary anyway. StarTech comes tomorrow – love those Sunday deliveries. Also ordered an SSK Aluminum M.2 NVME SSD Enclosure Adapter, from the list for a 1T M.2 I had lying around.
Sounds like a great plan! Just watch out for power on the 1TB NVMes (my 250s will go a lot of the time on a normal adapter but my 1TB ones generally want a powered USB hub). The performance jump is substantial though as you’ve probably seen on pibenchmarks.com. Definitely let us know how it all turns out!
No problem at all, that is great news! I almost missed it because some of the symptoms were happening on the PC but the symptoms themselves were a 100% match with power related issues.
I’m not totally sure why the firmware revisions had an impact on the behavior but it’s most likely power management related within the firmware and for some reason it’s consuming slightly more than with the stock firmware potentially but if it was that close to the edge then you were going to for sure have sporadic power issues anyway (usually during CPU/GPU spikes or if you plugged in something else to USB or pretty much anything would have put you in the red zone where you’ll have a freeze/crash/etc.) so this was definitely worth doing.
The PC itself wouldn’t have ever crashed (it won’t get low enough on power to destabilize from stuff plugged into the USB ports like the Pi can) but some of your USB accessories would have been dropped if too much power was being pulled on a single internal USB hub (safety features).
Doubly excellent news, thanks for the follow up, the StarTech should give you a bump in performance scores as well I’m guessing!
Damion
3 years ago
Hmmm. I have the UGREEN 2.5″ to USB 3.0 “SATA USB Converter” Adapter listed in the “working” section above. While I can’t say the adapter doesn’t work, if I also try to use a usb wireless remote, the remote has no range at all. I have to be right next to the dongle. If I plug the hdd adapter into a usb2 port instead the controller has full range. I thought this was maybe because the hdd was pulling too many amps and the remote dongle was getting starved. I then cracked open the adapter and wired an external power source to power the adapter and drive and disconnected the usb cable’s +5v and ground wire to the adapter and I get the same results.
Hmmm indeed, that is quite strange and not an issue I think has ever been posted here until now. You also did quite the power test wiring the adapter directly to rule things out!
Is the cable partially covering the bluetooth adapter? Can you have the Bluetooth adapter on top and the enclosure on bottom? This is why I ask.
I hadn’t really heard of it before, but USB 3.0 interference appears to actually be a thing (specifically USB 3.0 and not 2.0 as you discovered), with wireless, on the 2.4GHz band especially where WiFi/Bluetooth/other wireless consumer devices typically operate.
Check out this one from the Pi forums as well wrapped in tinfoil to avoid an interfering device from trashing his dongle performance. The shape of that adapter under the tinfoil looks like it absolutely could be the UGREEN under there (the really common Sabrent one also looks similar to this).
My best guess is that either the UGREEN enclosure/USB cable is very *unshielded* (more likely just looking at the thinness of the cable) and is letting off a ton of USB 3.0 WiFi interference, or the UGREEN enclosure/USB cable is very *shielded* and may be killing the dongle’s signal (especially if part of the cable/adapter is overlapping with the dongle). If this is the case some USB cables (not all created equal, and some other ones you may have been given might shield against this better than the one UGREEN provided) may impact/alleviate this type of interference.
The amount of USB activity that is going across the USB connection from your Pi to your drive is pretty intense relatively speaking so if USB 3.0 is known to generate this type of interference you will probably want a well insulated/shielded cable and then to put the dongle on the top USB port so the cable isn’t covering it. That is going to be a problem since I believe on your adapter the USB cable is a part of the adapter.
The UGREEN’s USB connector itself probably also isn’t shielded and the cable looks way too thin to be shielded to me in the picture (there are shielded USB cables if you search for them premade but it’s not the norm that you get with a product) but just doing the cable may be enough or some shielded tape over the connectors might even help as well. It may take some experimentation to see where this interference is leaking from (the USB connector, the cable, or both). Since you were comfortable rewiring the dongle earlier maybe you would be comfortable soldering a shielded connector (at least on the USB 3.0 connector end).
You might even be able to use a shielded USB 3.0 extension and just get the UGREEN away from the dongle to reduce/eliminate the problem (or vice versa, I guess you could put the dongle on the end of the USB extension as well).
Let us know what you find!
Henk Wieland
3 years ago
Hi James,
Tht’a a fast responce 😉
Thanks for the info.
I didn’t read that part about the slowing down so my mistake then.
I’m sort of new to this kind of tweaking although i’ve got a working old PI2 with Liberelec.
I was looking for a replacement for my 12 year old QNAP TS219 Which the PI2 was using (network share) for my music and movies.
Eventually I want to build/make an enclosure with real NVME support not just SATA.
So it must be something with powered USB reading my 2018 4TB seagate is now already a problem and NVME support like the CM4 seems to have.
It seems the Rock PI model C seems to support it.
I wonder what would happen if i connect a Blitzwolf TH12 14 in 1 docking station to the ep i 4 :-).
I’m just digging into your Ubuntu distribution story . So we keep tinkering and trying to nmakea stable build
Don’t sweat it at all! We’re in the information age and things move very quickly so I wanted to clarify and use it as an opportunity to point to where it was at mostly because it helps people jumping to the comments find out where the important stuff is since obviously the article is enormous at this point (to the point where if someone retained everything after the first read I’d be genuinely impressed). It definitely wasn’t meant as an attack and I wasn’t offended etc. so I’m glad you weren’t too put off by it!
The good old Pi 2! I still have one of every model including my 2 original Pi (1) Model Bs. Theoretically everything in the setup should be fine to hook together but the only question would be the Blitzwolf dock/adapter itself. I searched all 4400+ comments on the site and nobody has ever mentioned the word Blitzwolf before (but I’ve heard of it, I actually have identified a 2.5″ Blitzwolf drive on pibenchmarks.com here) but this is the first time I’ve seen a dock/adapter!
Most people haven’t had too much trouble with the M.2 SATA adapters (other than power) and since this is essentially a docking station (a fully equipped fancy powered USB hub with lots of additional ports) you should not need to worry about power at all. I can’t guarantee it will work since nobody has tried it before but like I said if you search through the comments here almost all M.2 SATA issues ended up being power related and almost never adapter specific (while 2.5″ SATA adapters/enclosures are extremely finicky especially with things like UAS support). Definitely let us know if you try it and I will add it to the list either way!
I think the Rock Pi models seem to have better support in general for USB and I wouldn’t be too concerned on that platform. I believe they also can take advantage of USB 3.1/3.2 and have been able to for years and we’re still waiting on the Pi! I think some of the problems on the Pi are due to the way that the Pi Foundation implemented USB on the Pi (some say not entirely correctly in some ways). Some of these were physical problems that were in the first revisions of the Pi 4 at release that were corrected in all post-launch Pi 4’s and other adapter/chipset compatibility issues get fixed from time to time in firmware and kernel updates.
The Ubuntu story was a wild ride. I basically added support for the Pi 4 because there were beta images out but no official support yet and the beta images were a nightmare. I think some people still use it although I haven’t been updating the kernel for it but I believe a few people have kept building the official Pi kernel and replacing the Ubuntu kernel like I did even in some of the later versions (which is totally possible with a few upgrades and a retool on the arm compiler). Hopefully some of that helps a little!
Henk Wieland
3 years ago
Hi,
Maybe its already in the comments but adding the parameter in the /boot/commandline.txt is for me the cause of slow disk performance.
If i take out the parameter UAS is used.
Booting from USB can also be handled in the raspi-config advanced options and you don’t even have to pull out the sd-card to make it work.
At least in my config. I use an argon m.2 enclosure with an NVME SATA WD red 1TB sudo dmesg | grep usb
[ 2.124658] usb 2-2: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[ 2.155965] usb 2-2: New USB device found, idVendor=174c, idProduct=1156, bcdDevice= 1.00
[ 2.155984] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 2.156001] usb 2-2: Product: Forty
[ 2.156018] usb 2-2: Manufacturer: Argon
[ 2.156034] usb 2-2: SerialNumber: 0000000000E4
[ 2.159511] usb 2-2: UAS is ignored for this device, using usb-storage instead
[ 2.159638] usb 2-2: UAS is ignored for this device, using usb-storage instead
[ 2.159657] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 2.160188] usb-storage 2-2:1.0: Quirks match for vid 174c pid 1156: 800000
[ 2.160363] scsi host1: usb-storage 2-2:1.0
performance score 5412
Without the parameter; [ 1.606280] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.636044] usb 2-2: New USB device found, idVendor=174c, idProduct=1156, bcdDevice= 1.00
[ 1.636064] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1.636082] usb 2-2: Product: Forty
[ 1.636099] usb 2-2: Manufacturer: Argon
[ 1.636115] usb 2-2: SerialNumber: 0000000000E4
performance score 7499
Maybe booting is a couple of seconds faster with, but performance is more important for me
But good article anyway glad i found it. Thanks for the info.
There is absolutely a performance penalty for enabling quirks mode. From the quirks section:
Some adapters (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.
You definitely don’t want to turn this on unless your adapter won’t work without it, and even then only if you’ve tried following my Fixing Firmware Adapters with Storage Updates to see if that fixes your UAS mode first.
As far as native USB booting support at the very top of the article there’s a warning that native USB booting is out and you will probably want to do that. This is the old method from before native USB booting was added. The guide for that type of USB booting is here: Raspberry Pi 4 Bootloader USB Mass Storage Boot Guide. This is called using the “bootloader” to boot and is definitely the best way to do it! Some operating systems don’t support native USB booting so this method is still widely used but it’s not necessary to use the SD card at all or do it this way with the bootloader support.
Hopefully that helps!
Chris
3 years ago
Hi guys, I have a Netac Mobiledatstar USB SSD and cant get it to work at all. I have seen two users: Fluffybot and Hubbert have posted scores of its use however I dont know how they have done it as the drive has a sector size of 4096 which is not compatible with the Pi’s hardware for booting. Can anyone advise?
I have tried the Pi Imager tool (On both Windows and RasperyPi OS), Balena Etcher(On both Windows and MacOS and Wi32 Disk Imager. All post the exact same results. A very strange partition setup after the write.
Gparted, Windows Disk Manager and Mini Partition Tool know what these partitions are 🙁
Can you try wiping the partition table out completely before imaging? I’ve seen issues before where previously existing weird partition tables seem to persist in some cases (I believe it was a drive that was imaged with zfs before when I’ve seen something like this).
Can you go into Gparted / windows command prompt and run “clean” and delete all the partitions off the disk and then try one more time? The disk should show zero partitions and be completely blank and then try imaging it.
Beautiful blog by the way!
Nicely made, actively maintained, tops!
Why make this all so complex?
I bought a msata SSD drive (with USB 3.0 adapter), made an image file from my Raspberry SD card, then wrote that image to my SSD drive.
And that’s it.
Hey Erik,
That is because this guide is because from way before that is possible and is the “old method” (mentioned in bold at the very top of the page). You are talking about the newer method using the Raspberry Pi bootloader which pretty much is that simple and the guide for that is here: Raspberry Pi 4 Bootloader USB Mass Storage Boot Guide.
Hopefully that helps!
ELUTENG 2.5″ SATA to USB 3.0 Adapter* now working fine after adding quirks – ty. Wish I found this site before my purchase.
Hey Paul,
I believe that the ELUTENG is a JMS578 adapter which means you may be able to update the firmware using my fixing storage adapters with firmware updates guide. On some adapters this has fixed them so you no longer have to use “quirks” mode and can enable UAS which increases performance. It may be worth a try as the worst thing that has ever happened when trying this is it won’t detect your adapter or the update won’t change anything (the updater checks for the JMS578 chipset specifically and it’s used in a wide range of adapters).
At any rate I’m glad you got it going and thanks for leaving the comment about the ELUTENG!
My chipset is JMicron JMS567 – I’ll try updating firmware to see if that works and let you know… ty
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: 2021-05-07-raspios-buster-arm64.zip
With quirks I’m getting:
Sequential Write: 172000 (slowest test) 241860 (fastest test) KB/sec
Random write: 6289 IOPS (consistent range for multiple tests)
Random read: 4645 IOPS (consistent range for multiple tests)
I’ve got another setup – no quirks on USB3
Drive: Inateck 2.5 Hard Drive Enclosure, USB 3.0 adapter
OS: Ubuntu Server 21.04
I did not test, but I’m going to, so I can compare. I’ll update this if anyone is interested.
edit: on my second setup.
Drive: Kingston 240GB A400 SATA 3 2.5″
Adapter: Inateck 2.5 Hard Drive Enclosure, USB 3.0 adapter
Hey Paul,
Excellent! Here’s a good test to compare it to with a USB 3.0 adapter not using quirks on the Kingston A400. It looks like with UAS enabled / no quirks they got about 15,036 rand read IOPS and 7,778 rand write IOPS. It’s curious you got a higher write speed than read speed! This benchmark was 10% above average with a score of 6785, which is right where we would expect it to be without going NVMe or M.2 SATA.
People have got the Kingston A400 all the way up to 9481 though like here using the highest performance storage adapters (usually the StarTech) and a monster overclock reaching a whopping 27k write IOPS and 35k read IOPS!
I’d say it’s probably a 20-30% performance penalty usually although if those random read numbers are correct then losing UAS may be reducing the read performance by a good 60-70% if those numbers are consistent / not an outlier.
I’m curious what your comparison will be to the Inateck!
Hi James, Test result in post above was using Raspberry Pi Diagnostics, for what that’s worth –
sudo apt install agnosticsTests below using your link:
sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash4G Pi4
Adapter: ELUTENG 2.5″ SATA to USB 3.0 Adapter*
Chipset:JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: 2021-05-07-raspios-buster-arm64.zip
Quirks: Yes
FIO results – 4k RandWrite: 5785 IOPS (23141 KB/s) – 4k RandRead: 4267 IOPS (17070 KB/s)
Note: Should I try updating my JMS567 with JMS578 firmware? I don’t care if I brick it, if you think it may work?
If so I’ll add those results as a comparison to these.
—————————————————————————————————
8G Pi4
Adapter: Inateck 2.5 Hard Drive Enclosure, USB 3.0 adapter
Drive: Kingston 240GB A400 SATA 3 2.5″
OS: Ubuntu Server 21.04 64
Quriks: No
FIO results – 4k RandWrite: 14453 IOPS (57812 KB/s) – 4k RandRead: 22068 IOPS (88275 KB/s)
Full test results
Hey Paul,
That looks right. You can see your DD Write speed is nearly 50% of the non-quirks adapter/enclosure test!
I would absolutely try updating the firmware. I double checked and I couldn’t find somebody saying they tested the ELUTENG one specifically yet but the chipset is right and the update tool will find it even if it’s not from your specific manufacturer (namely because we are updating the chipset controller and a JMS567 is always a JMS567 made by JMicron and every adapter that uses one had to buy the controller from them).
I’ve never heard of anyone bricking one before trying this (since the update looks for a specific JMS567 etc.) but if you aren’t worried about bricking it then I would say extra double yes give it a try and let’s see if it helps! The worst case scenario is it still won’t boot without quirks enabled but we have had some success in the past with generic adapters. Even if it does nothing I would test it again to see if your performance numbers improved because on some chipsets if they can’t fix it they can sometimes greatly reduce the performance impact.
People definitely do routinely fix various adapters though. A couple examples are here and JSiler even got one like a week ago here so this is absolutely worth a try even though we don’t have a confirmation on the ELUTENG yet.
Let us know what you find!
Hi James, Firmware update successful, Example 1
Rebooted without removing quirks and ran test – similar result to with quirks
Removed quirks – would not boot – no desktop nor could I ssh
Booted to USB2 – desktop was there. Shutdown – I did not add quirks back
Booted back to USB3 – no desktop just quick flash of pi image, but I could ssh in
Ran test – FIO results – 4k RandWrite: 11609 IOPS (46439 KB/s) – 4k RandRead: 23897 IOPS (95589 KB/s)
sudo apt update && sudo apt upgrade
Reboot – no desktop or ssh
Hard Reboot few times – got desktop image once but nothing else on screen – could no longer ssh in
Back to USB2 – add quirks
USB3 boots but same speed
I’m going to try installing Ubuntu 21.04. I had similar issues with Ubuntu 20.04 on Inateck adapter.
Just realized if I hit enter a few times at the end of test, I get a nice formatted output – boo me )
Hey Paul,
Excellent work so far! I have heard of going to the newer Ubuntu making a difference in some cases. That may be due to newer/better onboard firmware as well. Let us know what else you find, it would be great to have some definitive information on the ELUTENG!
Hi James,
Plugged adapter into my pc to overwrite – could no longer read on USB3 (firmware update?) – USB2 worked fine but would be slow to write OS
Plugged adapter into MacBook – read fine on USB3
Adapter: ELUTENG 2.5″ SATA to USB 3.0 Adapter with updated firmware
OS: See below – all 64 bit
4g Pi4
Replaced 2021-05-07-raspios-buster-arm64 with Ubuntu Desktop 21.04
Booted fine, no wireless keyboard or mouse though – used wired
Update and upgrade, was chugging along until screen went black and never came back – left overnight
Hard reboot a few times – no joy – blank screen
Replaced Ubuntu Desktop 21.04 with Ubuntu-Mate 20.10
Booted fine
Update and upgrade completed
Reboot – ‘You are in emergency mode – Enter for maintenance mode Ctrl-D to continue’
‘Ctrl+D’ – Mate icon comes up and just spins – let go for an hour
Hard reboot – ‘enter’ – takes me to root – tried to install curl but it failed
Since no luck with desktops – I tend to use hammer over brains approach
Replace Ubuntu-Mate 20.10 with Ubuntu Server 21.04
Booted fine – I did not run update && upgrade yet (scared after above results -)
Ran test- FIO results – 4k RandWrite: 15875 IOPS (63503 KB/s) – 4k RandRead: 13145 IOPS (52580 KB/s)
Update && Upgrade
Reboot – success – old kernel 5.11.0-1007-raspi new kernel 5.11.0-1017-raspi
Ran test again – FIO results – 4k RandWrite: 15753 IOPS (63015 KB/s) – 4k RandRead: 12792 IOPS (51168 KB/s)
Success – don’t need desktop anyway. Going to replace my home IoT server running on SD with this.
Thank you very much for your generous help, James. Won’t hurt my feelings if you delete most of my mess here and leave
an overview.
Link to git repo showing some of the stuff I do with my students on Pis – each has a video
RaspberryPiServer_Xbee_Pi
Just ordered another setup with StarTech 2.5″ SATA to USB 3.1 Adapter* need setup with desktop to run ROS2 for robotics class
Hey Paul,
I would never delete your messy comments! Mine are much worse and larger / more messy most likely all the time but that’s part of the “flavor” of the site. You’re going to find some weird stuff on here you won’t see anywhere else (especially detailed notes/experiments/etc.) so you are right at home!
Thanks for experimenting on this for us. I think you’ve definitively determined that the ELUTENG can not be saved and upgraded/fixed to have UAS support and if anything it will hurt that one to even try. This is how we’ve built up the list of information as a community over the years by experimenting and documenting this. It started with me but it would have never got this big without everyone else from all over the world trying every adapter under the sun and reporting the results!
Honestly I think you will be much happier with the StarTech overall. The performance scores on average are higher because it just has a higher “grade” of storage controller (think more expensive, probably 20 cents instead of 5 cents for a non-UAS capable one). I believe the StarTechs are a ASMedia chipset instead of a JMicron. This should take good care of you including on desktop and all devices/situations I’ve encountered so I think you’ll be all set!
Thank you James – Another weird thing is when I now plug adapter into USB2 (won’t read on USB3) on PC it kills my wireless mouse. Maybe the same reason I could not use wireless keyboard/mouse on Pi when I plug it in. Strange happenings.
Hey Paul,
That actually sounds a lot like power. You basically have a finite budget that all of your USB accessories draw power from. This will include even things like wireless keyboards/mice (and wired of course which use even more power). Here’s the technical link.
USB 3.0 is capable of providing more power than USB 2.0. I’m guessing this is “cutting off” your drive and keeping you within the power budget but under USB 3.0 your power collapses and it won’t boot. An easy test to see if I’m right is plug in the same combination on your computer and see if it cuts off like that (it won’t). Try plugging in the adapter to a USB 2.0 and the dongle in the same type as before. If it’s some sort of firmware bug it should still break it on the computer. Or are you saying it’s only breaking on the computer now?
It looks like there’s a bunch of dodgy ELUTENGs out there (this is very strange behavior). This person bought 10 of them and got widely varying results! You can also see that nobody has had a good thing to say about the ELUTENG basically.
There was some confusion early on about the ELUTENG because it used to be a different “model” that worked and then got changed into the blue connector version that we know/don’t love. Someone exposed this on the Pi forums here. I honestly think the ELUTENG might be worse than the Sabrents because these days most of the Sabrent ones can be successfully fixed with a firmware update (unlike the ELUTENG).
Do you have a powered USB hub by chance? You don’t have to have that specific Sabrent one, anything that you could power the drive off for a test would do!
There are also various versions of the firmware out there and you could try flashing different versions with to restore the original PC/Pi behavior or potentially still fix it. One of them will make the ELUTENG work (it doesn’t seem to like the one we tried which I think is Sabrent’s) and there can’t be more than a few major variants out there. There are more versions out there than I can count: JMS567+firmware but I suspect these only have very minor variations between them in reality but those very minor variations could cause exactly something like this.
Depending on your level of determination I would download a couple of these and see if one of them gets it working the way it was (or even better actually fixes it)! It could take more but I’m guessing the first 1 or 2 you try will restore the exact same behavior. Most of these are made in the same factories in China and there’s a dozen identical adapters to the ELUTENG out there sold on AliExpress etc. as completely different labels that are clearly the exact same adapter. Take a look at this one. It even says “ACCESS POWER” on it just like the ELUTENG but you will not find the name ELUTENG anywhere in that listing or the other lookalikes.
I think you’ll be much, much happier with the StarTech all around though!
Thanks James – I’m going to use it over ssh with Ubuntu Server, so no other USB connections necessary anyway. StarTech comes tomorrow – love those Sunday deliveries. Also ordered an SSK Aluminum M.2 NVME SSD Enclosure Adapter, from the list for a 1T M.2 I had lying around.
Sounds like a great plan! Just watch out for power on the 1TB NVMes (my 250s will go a lot of the time on a normal adapter but my 1TB ones generally want a powered USB hub). The performance jump is substantial though as you’ve probably seen on pibenchmarks.com. Definitely let us know how it all turns out!
Thanks – Probably should have got a powered adapter – I’ll order a different one if necessary
I’ve got this powered USB3 switching adapter. Not optimal, but the USB cables it came with are beefy. I’ll try to
boot from it.
Powered hub did the trick of wireless mouse not working on PC and PI ty
Hey Paul,
No problem at all, that is great news! I almost missed it because some of the symptoms were happening on the PC but the symptoms themselves were a 100% match with power related issues.
I’m not totally sure why the firmware revisions had an impact on the behavior but it’s most likely power management related within the firmware and for some reason it’s consuming slightly more than with the stock firmware potentially but if it was that close to the edge then you were going to for sure have sporadic power issues anyway (usually during CPU/GPU spikes or if you plugged in something else to USB or pretty much anything would have put you in the red zone where you’ll have a freeze/crash/etc.) so this was definitely worth doing.
The PC itself wouldn’t have ever crashed (it won’t get low enough on power to destabilize from stuff plugged into the USB ports like the Pi can) but some of your USB accessories would have been dropped if too much power was being pulled on a single internal USB hub (safety features).
I’m very relieved everything is working, enjoy!
Thank you James. Must have been a power issue with the ELUTENG on the USB3 also – reads fine on Mac and now on PC via powered USB3.
StarTech came and works great.
Doubly excellent news, thanks for the follow up, the StarTech should give you a bump in performance scores as well I’m guessing!
Hmmm. I have the UGREEN 2.5″ to USB 3.0 “SATA USB Converter” Adapter listed in the “working” section above. While I can’t say the adapter doesn’t work, if I also try to use a usb wireless remote, the remote has no range at all. I have to be right next to the dongle. If I plug the hdd adapter into a usb2 port instead the controller has full range. I thought this was maybe because the hdd was pulling too many amps and the remote dongle was getting starved. I then cracked open the adapter and wired an external power source to power the adapter and drive and disconnected the usb cable’s +5v and ground wire to the adapter and I get the same results.
Hmmm indeed, that is quite strange and not an issue I think has ever been posted here until now. You also did quite the power test wiring the adapter directly to rule things out!
Is the cable partially covering the bluetooth adapter? Can you have the Bluetooth adapter on top and the enclosure on bottom? This is why I ask.
I hadn’t really heard of it before, but USB 3.0 interference appears to actually be a thing (specifically USB 3.0 and not 2.0 as you discovered), with wireless, on the 2.4GHz band especially where WiFi/Bluetooth/other wireless consumer devices typically operate.
Check out this one from the Pi forums as well wrapped in tinfoil to avoid an interfering device from trashing his dongle performance. The shape of that adapter under the tinfoil looks like it absolutely could be the UGREEN under there (the really common Sabrent one also looks similar to this).
My best guess is that either the UGREEN enclosure/USB cable is very *unshielded* (more likely just looking at the thinness of the cable) and is letting off a ton of USB 3.0 WiFi interference, or the UGREEN enclosure/USB cable is very *shielded* and may be killing the dongle’s signal (especially if part of the cable/adapter is overlapping with the dongle). If this is the case some USB cables (not all created equal, and some other ones you may have been given might shield against this better than the one UGREEN provided) may impact/alleviate this type of interference.
The amount of USB activity that is going across the USB connection from your Pi to your drive is pretty intense relatively speaking so if USB 3.0 is known to generate this type of interference you will probably want a well insulated/shielded cable and then to put the dongle on the top USB port so the cable isn’t covering it. That is going to be a problem since I believe on your adapter the USB cable is a part of the adapter.
I have an idea. You could actually try shielding it with something like this which is basically a 1/8″ EMI shield tubing and you could run the USB cable through that to provide some modded shielding. If you are handy with a heatgun (assume yes from you directly wiring the dongle earlier) you could also do a pro heat shrinking shielded wrap with something like this.
The UGREEN’s USB connector itself probably also isn’t shielded and the cable looks way too thin to be shielded to me in the picture (there are shielded USB cables if you search for them premade but it’s not the norm that you get with a product) but just doing the cable may be enough or some shielded tape over the connectors might even help as well. It may take some experimentation to see where this interference is leaking from (the USB connector, the cable, or both). Since you were comfortable rewiring the dongle earlier maybe you would be comfortable soldering a shielded connector (at least on the USB 3.0 connector end).
You might even be able to use a shielded USB 3.0 extension and just get the UGREEN away from the dongle to reduce/eliminate the problem (or vice versa, I guess you could put the dongle on the end of the USB extension as well).
Let us know what you find!
Hi James,
Tht’a a fast responce 😉
Thanks for the info.
I didn’t read that part about the slowing down so my mistake then.
I’m sort of new to this kind of tweaking although i’ve got a working old PI2 with Liberelec.
I was looking for a replacement for my 12 year old QNAP TS219 Which the PI2 was using (network share) for my music and movies.
Eventually I want to build/make an enclosure with real NVME support not just SATA.
So it must be something with powered USB reading my 2018 4TB seagate is now already a problem and NVME support like the CM4 seems to have.
It seems the Rock PI model C seems to support it.
I wonder what would happen if i connect a Blitzwolf TH12 14 in 1 docking station to the ep i 4 :-).
I’m just digging into your Ubuntu distribution story . So we keep tinkering and trying to nmakea stable build
Hey Henk,
Don’t sweat it at all! We’re in the information age and things move very quickly so I wanted to clarify and use it as an opportunity to point to where it was at mostly because it helps people jumping to the comments find out where the important stuff is since obviously the article is enormous at this point (to the point where if someone retained everything after the first read I’d be genuinely impressed). It definitely wasn’t meant as an attack and I wasn’t offended etc. so I’m glad you weren’t too put off by it!
The good old Pi 2! I still have one of every model including my 2 original Pi (1) Model Bs. Theoretically everything in the setup should be fine to hook together but the only question would be the Blitzwolf dock/adapter itself. I searched all 4400+ comments on the site and nobody has ever mentioned the word Blitzwolf before (but I’ve heard of it, I actually have identified a 2.5″ Blitzwolf drive on pibenchmarks.com here) but this is the first time I’ve seen a dock/adapter!
Most people haven’t had too much trouble with the M.2 SATA adapters (other than power) and since this is essentially a docking station (a fully equipped fancy powered USB hub with lots of additional ports) you should not need to worry about power at all. I can’t guarantee it will work since nobody has tried it before but like I said if you search through the comments here almost all M.2 SATA issues ended up being power related and almost never adapter specific (while 2.5″ SATA adapters/enclosures are extremely finicky especially with things like UAS support). Definitely let us know if you try it and I will add it to the list either way!
I think the Rock Pi models seem to have better support in general for USB and I wouldn’t be too concerned on that platform. I believe they also can take advantage of USB 3.1/3.2 and have been able to for years and we’re still waiting on the Pi! I think some of the problems on the Pi are due to the way that the Pi Foundation implemented USB on the Pi (some say not entirely correctly in some ways). Some of these were physical problems that were in the first revisions of the Pi 4 at release that were corrected in all post-launch Pi 4’s and other adapter/chipset compatibility issues get fixed from time to time in firmware and kernel updates.
The Ubuntu story was a wild ride. I basically added support for the Pi 4 because there were beta images out but no official support yet and the beta images were a nightmare. I think some people still use it although I haven’t been updating the kernel for it but I believe a few people have kept building the official Pi kernel and replacing the Ubuntu kernel like I did even in some of the later versions (which is totally possible with a few upgrades and a retool on the arm compiler). Hopefully some of that helps a little!
Hi,
Maybe its already in the comments but adding the parameter in the /boot/commandline.txt is for me the cause of slow disk performance.
If i take out the parameter UAS is used.
Booting from USB can also be handled in the raspi-config advanced options and you don’t even have to pull out the sd-card to make it work.
At least in my config. I use an argon m.2 enclosure with an NVME SATA WD red 1TB
sudo dmesg | grep usb[ 2.124658] usb 2-2: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[ 2.155965] usb 2-2: New USB device found, idVendor=174c, idProduct=1156, bcdDevice= 1.00
[ 2.155984] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 2.156001] usb 2-2: Product: Forty
[ 2.156018] usb 2-2: Manufacturer: Argon
[ 2.156034] usb 2-2: SerialNumber: 0000000000E4
[ 2.159511] usb 2-2: UAS is ignored for this device, using usb-storage instead
[ 2.159638] usb 2-2: UAS is ignored for this device, using usb-storage instead
[ 2.159657] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 2.160188] usb-storage 2-2:1.0: Quirks match for vid 174c pid 1156: 800000
[ 2.160363] scsi host1: usb-storage 2-2:1.0
performance score 5412
Without the parameter;
[ 1.606280] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd[ 1.636044] usb 2-2: New USB device found, idVendor=174c, idProduct=1156, bcdDevice= 1.00
[ 1.636064] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1.636082] usb 2-2: Product: Forty
[ 1.636099] usb 2-2: Manufacturer: Argon
[ 1.636115] usb 2-2: SerialNumber: 0000000000E4
performance score 7499
Maybe booting is a couple of seconds faster with, but performance is more important for me
But good article anyway glad i found it. Thanks for the info.
Greetings,
Henk
Hey Henk,
There is absolutely a performance penalty for enabling quirks mode. From the quirks section:
Some adapters (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.You definitely don’t want to turn this on unless your adapter won’t work without it, and even then only if you’ve tried following my Fixing Firmware Adapters with Storage Updates to see if that fixes your UAS mode first.
As far as native USB booting support at the very top of the article there’s a warning that native USB booting is out and you will probably want to do that. This is the old method from before native USB booting was added. The guide for that type of USB booting is here: Raspberry Pi 4 Bootloader USB Mass Storage Boot Guide. This is called using the “bootloader” to boot and is definitely the best way to do it! Some operating systems don’t support native USB booting so this method is still widely used but it’s not necessary to use the SD card at all or do it this way with the bootloader support.
Hopefully that helps!
Hi guys, I have a Netac Mobiledatstar USB SSD and cant get it to work at all. I have seen two users: Fluffybot and Hubbert have posted scores of its use however I dont know how they have done it as the drive has a sector size of 4096 which is not compatible with the Pi’s hardware for booting. Can anyone advise?
Hey Chris,
Can you try imaging it using the Pi Imager tool from raspberrypi.org?
The software has some special logic to handle cases like this and should take care of the sector size!
Hi James, Thank you so much for replying! 🙂
I have tried the Pi Imager tool (On both Windows and RasperyPi OS), Balena Etcher(On both Windows and MacOS and Wi32 Disk Imager. All post the exact same results. A very strange partition setup after the write.
Gparted, Windows Disk Manager and Mini Partition Tool know what these partitions are 🙁
Can you try wiping the partition table out completely before imaging? I’ve seen issues before where previously existing weird partition tables seem to persist in some cases (I believe it was a drive that was imaged with zfs before when I’ve seen something like this).
Can you go into Gparted / windows command prompt and run “clean” and delete all the partitions off the disk and then try one more time? The disk should show zero partitions and be completely blank and then try imaging it.