The new Raspberry Pi 4 bootloader has finally come out of beta and made it’s way into the official latest Raspbian! This has been long awaited since when the Raspberry Pi 4 was released it had no native support for booting from USB / Network but it was promised right from the start it would get it through a later update.
This guide will show how to configure the new bootloader and set up your Pi to boot from USB devices as well as the other boot options now available within the Raspberry Pi 4 bootloader.
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 USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.
The SanDisk Extreme A1-A2 SD card has the best scoring SD card on pibenchmarks.com for years and is second in popularity only to the SanDisk Ultra (often included in combo kits). The application class (A1) means random I/O speeds (very important when running an OS) have to meet a higher standard. There’s no benefit on the Pi for A2 right now so get whichever is cheaper/available.
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:
UGREEN M+B Key M.2 Enclosure
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 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!
Another option for M.2 SATA (not NVMe) is to use the Argon One Pi case:
Argon ONE Pi 4 M.2 Case
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
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!
To edit the bootloader configuration you should have a copy of Raspbian on a SD card. Right now support in third party operating systems to do anything with the new Raspberry Pi 4’s firmware or bootloader is very limited / nonexistent. You can use a third party operating system later once you set the boot mode, but to actually make these changes we will use official Raspbian.
First make sure that you have the absolute latest updates and firmware for the Pi. To upgrade all your packages and firmware to the latest version use the following command:
sudo apt update && sudo apt full-upgrade -y
Once the update has completed restart your Pi with a sudo reboot command to apply the latest firmware / kernel updates.
Verify EEPROM Bootloader is up to date
We can check if your Pi’s bootloader firmware is up to date with the following command:
sudo rpi-eeprom-update
If your Raspbian is *very* out of date you may not have this utility and can install it using:
sudo apt install rpi-eeprom
The output from rpi-eeprom-update will look like this if you are not up to date:
BCM2711 detected
VL805 firmware in bootloader EEPROM
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103)
LATEST: Tue 24 Nov 15:08:04 UTC 2020 (1606230484)
FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000138a1
If it says any updates are available they be installed manually by adding ‘-a’ to the end of our previous command like this:
sudo rpi-eeprom-update -a
After the updates finish installing restart your Pi as firmware updates will not be applied until after a reboot. Now if you run rpi-eeprom-update to check for updates again it should say you are on the latest and up to date!
Verify Power Supply Size (3.5A strongly recommended)
Check your Raspberry Pi’s power supply size and make sure it is delivering at least 3.5A. There are a lot of USB C adapters for the Raspberry Pi that are only 3.0A. These will typically work fine, until you plug in something like a SSD which draws power from the Pi and there is nothing left to give.
Most SSDs are quite power efficient but HDDs draw significantly more. Older generations of SSDs used quite a bit more power than newer ones as well. If you are using an older drive or a drive that you know is power hungry you need to pay extra attention to having a quality power source with plenty of capacity.
A good alternative option to relying on the Pi to power the drive is using a powered USB hub* so your drive doesn’t need to draw power from the Pi’s limited power budget. Make sure you get one that is compatible with the Pi as some powered USB hubs won’t work properly with it so check the reviews and do your research to make sure people are using it successfully with the Pi.
Image your bootable drive (your SSD / HDD / USB Flash Drive / etc.) the same way you imaged your micro SD card. You write the image of the operating system you want to run to the disk with Etcher / Win32DiskImager / however you normally would write one.
Once this is finished we are ready to edit the bootloader configuration to tell it to boot to our drive instead of the built in microSD slot.
If you’ve completed the prerequisites you are now ready to edit your Raspberry Pi’s bootloader configuration to tell the Pi to boot from a specified device instead of the built in microSD slot. To edit the bootloader configuration use the following command:
Our target is the BOOT_ORDER parameter in bold above. It is 0x1 in firmware versions up until 2020-05-150 and was changed to 0xf41 (try SD card first, then boot from USB if that fails) in newer versions after that. Here are the different configuration options for the BOOT_ORDER parameter (from Raspberry Pi documentation):
Stop and display error pattern (since 2020-09-03). A power cycle is required to exit this state.
0xf
RESTART
Start again with the first boot order field. (since 2020-09-03)
Raspberry Pi 4 USB BOOT_ORDER Options
The configuration option we want is USB mass storage device boot or option 0x4. We can use this option by itself or combine it with other options in the table placed in the order we want the Pi to try to boot from. To understand how to do this, let’s examine the default Raspberry Pi OS value of 0xf14. The values are read from right to left so this value means it will try USB booting first and then fall back to SD storage next.
If you want to leave the SD card and the “restart on failure” fallback options in place you can change it to 0xf14 (remember, the order is from right to left). Go ahead and use your arrow keys to navigate to the BOOT_ORDER line and change it 0x4 or 0xf14 so it reads:
BOOT_ORDER=0x4
or
BOOT_ORDER=0xf14 (to enable falling back to SD card if USB boot fails)
This translates to attempt to boot from USB mass storage first. If that fails, try to boot from SD card. If that fails, start over from step 1 and try again (back to USB mass storage). As another example, if you wanted to add booting from the network you could add the 0x2 value from the table for the “NETWORK” option and make it the final BOOT_ORDER value 0xf124. If you wanted to change the order so that the network boots first instead you could reorder it to 0xf142.
Choose the appropriate BOOT_ORDER you would like and use your arrow keys to move down to the BOOT_ORDER line. Change the line and press Control+X and then ‘y’ to save your changes. Make sure you have your boot device we set up in the prerequisites section plugged into one of the blueUSB ports as these ports are USB 3.0 and the black USB ports are USB 2.0 (slower). Now restart the Pi.
If all went well the Pi will immediately boot up from your boot device instead of the SD card!
Help, something went wrong!
Try Booting from SD card
Generally if the Pi fails to boot from the USB device it will fall back to booting from the SD card. If the Pi didn’t boot after making the change try unplugging your USB device and just booting from the SD card again by removing power from the Pi and plugging it back in again.
If the device is booting fine from the SD card but not from the external drive double check that you have a compatible adapter and that the drive was imaged correctly. Plug it into a PC and make sure it has the files on it and perhaps try giving it a clean image again just in case something went wrong with imaging the first time.
Verify rpi-eeprom-config configuration
Make sure your changes that we made earlier actually stuck by verifying the configuration using the command:
sudo -E rpi-eeprom-config --edit
and verify that the BOOT_ORDER=0x1 line is changed to BOOT_ORDER=0x4.
Restore Bootloader to Defaults
If things are *really* broken and the Pi will not boot at all with your SD card or otherwise then you may need to restore the bootloader back to defaults.
To do this we need to prepare a SD card with the Raspberry Pi 4 EEPROM boot recovery tool. The easiest way to do this is to use the official Raspberry Pi Imager tool from the Raspberry Pi foundation to prepare the recovery image.
Here is how we create the recovery image inside the utility. Choose the “Misc utility images” category as shown below:
Raspberry Pi Imager Step #1
Next choose the “Raspberry Pi 4 EEPROM boot recovery” option:
Raspberry Pi Imager Step #2
Next choose your SD card and then choose “Write”. Now unplug your Pi and put in the newly prepared SD card. Connect the power and let it boot. This will restore your bootloader to defaults. You should see a continuous rapid green blinking light. You may now disconnect the power and put your original SD card back / reinstall Raspbian and boot the Pi normally!
The beta firmware released since the original USB mass storage device support launched contains a bunch of fixes related to USB mass storage devices and USB booting. The downside is the beta firmware is not as well tested so you shouldn’t install it unless you are doing it to fix a specific issue addressed in those updates.
To switch to the beta channel edit the configuration file with the following command:
sudo nano /etc/default/rpi-eeprom-update
Change the line FIRMWARE_RELEASE_STATUS=”critical” (sometimes it can be “stable”) to:
FIRMWARE_RELEASE_STATUS="beta"
Now press Ctrl+X and then ‘y’ to save our changes in nano. Now execute a Pi firmware update using:
sudo rpi-eeprom-update -a
The updater will tell you whether updates were applied or not. Now do a full reboot of your Pi as the firmware updates won’t be applied until you do! If you want to switch back to normal firmware simply change the configuration back to “stable” or “critical”.
Verify Drive 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!
Fix (some) USB Adapter Problems Using Quirks
Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.
To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.
Find Your Adapter
To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:
$ sudo lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB 3.1* 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 “Verify Drive Performance” section).
If you want to see which Pi storage performs the fastest and get an idea of what kind of drives to look for check out my 2022 Raspberry Pi Storage Benchmarks
Thanks a ton for the results! I’ve been going through and finally updating the storage benchmark. It’s looking a lot better here but there’s still a lot I want to do like adding filtering options, more comparable menus like a “Brand” menu that shows all the drives from a company.
I also want to do more rankings between the drives. I’m going to add your changes to the list here (I think there’s a couple other ones lower I need to get to to), but thanks again!
Your database is priceless! 🙂 I hope it will help more people to find the right adapter for the RPi. I have a couple more of SSD drives and few no-brand-chinesse cables pending to test. Will update the results soon to the database.
Can’t wait to see the new updates with the new menus and comparations between adapters and drives 🙂
That’s awesome! The more I have the more it helps. I’m down to about 4000 unidentified tests out of 37000 so it’s identifying something like 89.2% of all the benchmarks people submit right now. If you’ve submitted ones that the site didn’t recognize they are among those 4000. They’re all still in there, it just doesn’t display them publicly on the site because it has no clue what those drives are yet!
When I’m finding new models of drives that need to be added I usually sort the unidentified drives by how many benchmarks there are for them so having this additional data really helps. The site is just barely becoming even “browsable” in the barebones sense and was basically a giant list previously for the past year that was difficult to navigate and know what to even really do with. A lot of the work I’m doing is in the backend right now but definitely the frontend is getting redone completely as well!
The ones that it isn’t identifying are either really new drives or drives exactly like you’re talking about. The Chinese drives are very tough to identify and I have to mostly rely on what you guys type in the “notes” field to figure out what these ones are. There’s actually some that I have quite a few benchmarks of that I can’t identify that I’m just waiting for the one or two submitters who comment and tell me what it is to crack the case!
Sorry James, I haven’t had time yet to complete the test, one of my raspberrys is freezing randomly even after a clean install, another SD card, another SSD but I can’t find the reason why is freezing.
I’ve ordered another RP4 this week, as soon as it get home i will do more test.
Chinese boxes are identified by model number not by the SSD/HDD inside, maybe looking for the model will bring more details?
My two Chinese-cases are recognize by model number.
No rush at all! That’s a great tip about the Chinese drives being identified by model. I’m doing this type of model identification a little bit already with some of the brands I’m able to identify but I’m excited for whenever you get the chance to submit them! The notes field will help a lot!
My pi400 is freezing when overclocking, running an external ssd and keeping a conservative over_voltage setting. Increasing over_voltage by one solves the freezes.
That is fascinating! I actually ordered a Pi 400 here since the prices from the scalpers on eBay dropped to like $100 (still $30 over MSRP I believe, but still not as bad as before Christmas).
I should have preordered two of the things and I would have saved a lot of money and had them much earlier!
It looks like mine has shipped but isn’t coming until Monday because since it was a scalper they picked “USPS Retail Ground” as the delivery method to save themselves a few bucks on the shipping and have it take a week instead of 2-3 days!
I am going to give this a try for sure and see if I can reproduce your results as soon as it comes!
Hey James, sorry for late answer, looks like my old Pi4 had an issue with the RAM and fail on every single memory test I did. I ordered a new one together with a new Startech USB – SATA adapter, performance is much better vs the Chinese-no-brand adapters, +7k points on the benchmark, no quircks added on the config file and boots without any issue.
I will send you in a separate email few pictures of two non-working adapters, neither adding quircks in the config file.
Luca, thanks for the tip, but I not running any of my raspberrys overclocked, stable OS vs unstable speed, I choose stable OS, I’m getting old 😛
Wow, that is an end to the story I did not expect! An actual hardware failure!
You may be able to warranty it through whoever you bought it from depending on how long ago it was. Some vendors cover it for up to a year, and my understanding is that if you are in the EU or somewhere with favorable consumer protections the vendor sometimes will warranty it for a second year after the first year. It may be worth reaching out to see if they’ll just give you another one. It really is handy to have more than 1 around!
I have owned every generation of Pi since my original two Pi 1 Model Bs. They all still work 100% except for one. One of my 2 RPI4 4GB launch models (very bad heat management and buggy firmware) is the only one that has ever been defective and the hardware failed. It was the SD card port that failed (probably from me testing/imaging cards and taking them in/out 100 times in a row sometimes, very hard on the SD slot).
You have joined an elite club of people with verified Raspberry Pi hardware failures! It happens, but it’s rare, and it happens much less than just about any consumer electronics product you’ll find. I work on hardware as a tech professionally and would rate the Pi as far more reliable than a lot of the enterprise level products I work with.
I look forward to getting your email, and I’m relieved you have figured this out and found success!
Stuart
3 years ago
UGREEN USB-3.1 enclosure (labelled ‘UGREEN 2.5″ SATA to USB-C 3.1 Enclosure Drive Caddy*’ above) has no problems with UAS, but blocks TRIM commands 🙁
It also has a timed spin-down mode enabled by default which requires the use of a somewhat-dodgy Windows-only reprogrammer to disable.
I have the same enclosure and trim works just fine, assuming you’re referring to the ASM235CM chipset (or similar). Have you added the following trim rule?
That works for me, it’s also worth noting that trimming an empty 1tb ssd drive takes about one minute.
Also, regarding spin-down, is it noticeable? what’s the duration before spin-down?
Best
L
Richard Smith
3 years ago
Method I used to convert my RPI4 4gb and 8gb servers from 32bit to 64bit.
1. Use Filezilla to login to the server you plan to convert to 64 bit
2. Copy the complete minecraft folder to your PC.
3. Use Etcher or Pi Imager with image of “2020-08-20-raspios-buster-arm64-lite”
Download it from: downloads.raspberrypi.org
4. Write to your SSD with Etcher or Pi Imager.
5. Boot your rpi4 without the sd card if your bios is newer than 9/20, otherwise first update bios with recovery image on an sd card from Pi Imager then boot without sd card.
6. Connect rpi4 to your network.
7. Default login, User: pi Password: raspberry
8. Using Terminal: sudo raspi-config, set password, SSH enabled, timezone, language.
9. Log in with Putty ssh from your PC.
10. Putty Commands, this installs PI Minecraft Server:
Copy and Paste into Putty session: wget https://raw.githubusercontent.com/TheRemote/RaspberryPiMinecraft/master/SetupMinecraft.sh
chmod +x SetupMinecraft.sh
./SetupMinecraft.sh
hit enter key and wait for setup to finish.
11. reboot with power switch
12. Login with Putty cd minecraft
./stop.sh (stop the server)
13. With Filezilla log into server
delete the minecraft folder
paste in the minecraft folder you saved previously on the PC.
14. Reboot rpi server. (server will restart) You are done.
I forgot to mention in my post that I am using Startech USB3S2AT3CB USB 3.0 to SATA Cables to boot my Minecraft servers. I found this article at “https://www.glump.net/howto/desktop/enable-trim-on-an-external-ssd-on-linux” on how to enable TRIM on these adaptors. Logged in with putty, I created a Rules File:
sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules
The contents are: ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
Note: This rules file is only for my Startech adapter, your device may have a different Vendor and Product ID.
Also both my ASM enclosures show up with the same vendor/model id as your adapter for which you needed to add a quirk. I haven’t added quirks and am not seeing anything wrong with them at the moment, what issues did you encounter?
Please kindly let me know
Thanks and Merry Christmas!
Luca
Is your Orico one working? That’s the one I see on there that I would definitely expect to encounter problems. Has that one been working?
The UGREENs typically haven’t had any problems from what I’ve heard although those are mostly from user reports. Sometimes people are encountering power issues where they don’t have enough power and have to use a powered USB hub but I think other than that the UGREENs have been working without quirks for the most part.
We’ve also been expecting them to fix some of the adapters over time with firmware updates. Maybe they’ve fixed some of these in the recent updates. I know that the patch notes say that there have been some changes made to improve compatibility!
I have yet to hear of a working Orico adapter which is why I was extra curious about that one. I would pick the UGREEN since I have received the most positive feedback about those, but I definitely recognize the chipset in the Ennotek as well although I’m not as familiar with that one!
Definitely let us know which one you try and whether it works or not, and Merry Christmas to you too!
I have the three enclosures with me and have been testing them with my pi400 recently on both ntfs and ext4 builds.
They all appear to be working fine with UAS and TRIM (by adding a rule) including the Orico, which mounts the Vl716Q4 chipset. Actually, is there any way to spot uas issues that I might’ve missed?
Regarding my original query, I’m still curious as to why your ASM1053E chipset, which has the same model/make identifer as both the ASM235CM and ASM1153E chipsets, requires quirks, whereas my two enclosures don’t. What sort of issues did you see that made you discover the need for using quirks?
In terms of performance they’re all very similar, with the Ugreen ASM235CM>Orico VL71Q4>Ennotek ASM1153E, but we’re taking 3-7% difference max.
I still don’t fully trust the Orico though, especially given community feedback is leaning towards the ASM chipset. At the moment I’m undecided between the Ugreen ASM235CM which is £19 and the Ennotek ASM1153E for £11.5, but my gut feeling is to keep the Ugreen with the newer chipset out of the three.
Lastly, I noticed something odd when overclocking to 2200 with 6 over_voltage. I found this configuration to be stable without no ssd connected.
I noticed that the pi400 is freezing when the ssd is connected and in use though. Increasing over_voltage to 7 solves this. Do you find it odd for the system to be more stable with ssd connected when supplying more voltage to the CPU?
So regarding the ASM1053E I think that specific chipset in the example didn’t need quirks enabled to work. I was just using it as an example for the documentations of how you would enable it regardless of the chipset using whatever was plugged into my Pi at the time. The ASM105x is actually the older StarTech USB 3.0 (not the 3.1) which does not require quirks or anything else to work (I think). At any rate, it definitely wasn’t a UGREEN but it sounds like they share the same chipset as what I had plugged in.
Sorry for the confusion on this, it wasn’t meant to be directed toward any specific adapter and was only meant as a guide to how to find the adapter you’re using (assuming most people probably wouldn’t have the specific models that I had anyway and that it would be irrelevant, but it’s one of the most popular ones so this was a mistake in retrospect). I could be misremembering which adapter it was here, but I don’t think it was actually one that needed quirks if I remember right.
For the uas issues there are a few factors at play here you’ll want to take into account. The first one is what specific version of firmware you are using on your Pi. This actually matters a lot, as they have been constantly fixing compatibilities with certain chipsets. It’s a lot of reading, but check out the changes just for the bootloader firmware here.
Let’s look at some highlights here:
2020-10-28 – “Improve compatibility with external USB 3.0 disk enclosures by enumerating the downstream hubs before executing the USB port power off. N.B. Pi4 8GB automatically powers off the USB ports during chip-reset and does not need this change”
2020-10-28 – Don’t timeout a USB MSD device after USB_MSD_LUN_TIMEOUT if there are no other MSD devices or LUNs to try. This avoids unnecessary timeouts on very slow to initialise disk drives e.g. USB HDDs designed for backups.
2020-09-14 – Improve compatibility for USB devices which require the USB port power to be switched off for a period of time during a reboot.
2020-11-24 – XHCI protocol layer fixes for non-VLI controllers.
There’s some real whoppers in here. XHCI protocol layer fixes in the Pi’s onboard firmware as recently as 2020-11-24! These types of fixes are what a lot of these drives need to work properly in full uas mode with no quirks. It’s driver/firmware level fixes.
Now you may be saying “I’m sure I have the latest firmware” on there and everything now, but it complicates things because we are now comparing information that when myself or others wrote it all of these months or years worth of fixes didn’t exist yet. It’s very possible that some adapters on the “naughty list” actually work now if you have all the latest firmware updates for the Pi and for the drive itself. It may turn out that the “naughty list” evolves into something more like a “you have to have this firmware for it to work” list!
That brings me to the next point. Another thing that may explain some of these adapters working is that people are buying newer versions of these products that are coming with newer firmware on them. The firmware for these devices is often a nightmare to find and flash for end users typically but I think it’s something we need to look at more.
My storage benchmark actually captures a lot of this information and I’ve been furiously working on the Pi Benchmarks site to eventually get it to where we have an “Adapters” section. I think it would be useful if I made that information display in the benchmark and we could look more closely at the adapters that people have and what specific version of the firmware they were running. These may even explain some performance differences on some of these tests with otherwise identical looking adapters! I think you’re on the right track and that everyone needs to pay more attention to their enclosure/adapter’s firmware and apply updates if they are available. I would even be willing to start compiling that information here!
Finally for the last piece with the freezing SSD: this is a tricky one, but my initial thoughts are it’s power related, both the quantity and quality of power it is receiving. Even some of my most recent interactions with others commenting on this article and other related ones they have had a *lot* of power issues. Especially with NVMe drives, and also especially with enclosures!
Do you have a powered USB hub available to test if the freezing stops? The other suspicion I have had for a while is that the USB hubs are actually “masking” uas and other issues by acting as a translator. These devices generally have better compatibility (meant to connect with anything) as opposed to the storage adapters which are only meant to connect to a limited range of devices generally (like a PC, sometimes even running specific versions of an OS!).
You had a very astute observation about the over_voltage. I think what is happening here is that you are hitting the limits in the firmware of how much power the Pi is allowing to “pass through” it. This is a higher limit than previous Pis had on the 4 but you are not the first one that has bumped up against it using NVMe enclosures. My suspicion is that these devices combined with the NVMe drives are just pulling a hair too much power. I’ve actually never tried bypassing it like this by raising the amount of voltage in config.txt that is allowed to be delivered to the Pi.
The massive overclock is definitely not helping with the power limits either and you probably need to raise this limit to allow enough power to pass through the Pi 400. At least that’s my best guess as to what is happening here. I got my spouse a Pi 400 for Christmas but I have not got myself one yet! It could be something specific to the Pi 400 since when I saw a teardown it’s not just a regular Raspberry Pi 4 like I thought it would be. If you watch them tear it down on YouTube it’s definitely some kind of custom board I’ve never seen before that is actually a long weird specific shape to make it a good fit for the Pi 400!
Hi James, thanks for the informative and super useful reply.
I’m sure your spouse will love the new pi400, I quite like the form factor.
Your db is such a useful resource, exposing the chipset data would be quite useuful to!
Interesting to read about ssds disks issues, and recent improvements to the firmware. It’s worth noting that people use external ssds with Retropie on the Pi4 with an enclosure or use external samsung ssd drives directly and there are no common issues reported. Perhaps Retropie doesn’t quite push the system hard enough to cause power issues?
Regarding my overclock freezes, I was afraid this could be caused by power, unfortunately I don’t have a powered usb to test, and in all honestly I would love to try and solve this without one, whether possible, but do let me know if you definitely feel this is a lost cause.
Ultimately what I’m interested about is finding stable overclock settings for my system for when needing extra power with Retropie: a good 2100, 2200, aggressive 2300.
I’m continuing with my stability tests and can definitely see a correlation between increasing voltage and freezes going away. My full-on stability test now consists of 2 hours of concurrent:
-stress-ng -c4
-Redream Dreamcast emulator running 18 wheeler in demo mode at 1920×1080
-onlinebenchmark.sh /pathToMountedExternalSSD (this is in a loop, also I removed the online submission bit at the end in order not to flood and spam your server)
Does this set of heavy duty operations make sense for stability?
Would you recommend a better disk usage tool/script to keep the ssd busy, instead of running onlinebenchmark.sh?
Also, from my tests, it seems that running the ssd in ext4, compared to ntfs is less prone to freezes.
And the vl716q4 enclosure performs better (but still hangs occasionally) with 2200,6,750, compared to the asm235cm enclosure which hangs 100% of the time. However the asm235cm beautifully at 2300,8,750 whereas the vl716q4 hangs with these settings after around 2h. In more detail below:
2200,6,750:
-I switched back to the Orico vl716q4 enclosure yesterday and run 2200,6,750 for 1h straight without issues. A subsequent test failed after a total 2h unfortunately.
-The asm235cm ugreen would hang at 2200,6,750 after 10-40mins.
2200,7,750:
-Both enclosures are stable after a continuous 2h.
2300,8,750
Again, interestingly, Orico failed after 2h.
The Ugreen enclsoure run for 4h without problems, which I find puzzling, considering it would fail more easily as shown above.
One last question. In case of freezes, and considering that the OS is on the sdcard rather than external ssd, is there a chance of data corruption? is there a system in place to spot corruption after the fact?
P.s.
Would you want to continue this conversation via email?
Regarding the three enclosures, If you want I can share my excel where I stored the output of onlinebenchmark.sh with both ntfs and ext4 partitions.
I understand and can relate to not wanting to use a powered USB hub. I like my setups to be sleek and have as few wires as possible.
They’re nice to have around for testing though. I have the Sabrent one but I lost the tiny little power adapter for it in my last move somewhere. I need to either find out what adapter it can take or just get another one since they’re relatively cheap and I want to do some further testing with how storage adapters react to having a “middleman” of a universal USB hub instead of talking directly to the Pi.
I’m guessing that this could have a wide variety of effects. In some cases it may increase speeds/stability/performance by “smoothing out” whatever the Pi doesn’t like about how the storage adapter is talking to it directly vs. how the USB hub communicates. I think in the cases of super cheap or poorly made hubs it may hurt performance to go through these.
I doubt there is zero effect at this point because we’ve seen and discussed so many different factors like firmware versions, revisions of existing adapters like 3.0 vs 3.1 revisions or even “stealth” revisions where they change to a different chipset without telling anyone.
The reason I jumped straight to power is that if the drives are undervolted when the OS tries to access something it will hang like this. Think of a situation like the OS asking it to retrieve a file and then the drive losing power for a millionth of a second and it forgets it was supposed to retrieve something and the OS keeps waiting kind of thing. It’s obviously much more complicated than that, but it illustrates a little why this could happen.
The other reason is your overclock. Maintaining power during overclocks is tough even without an external drive when you get in the extreme range because sudden changes in power or “dirty” power will cause it to freeze as well. You probably have the official power supply to even be hitting these clocks already I’m guessing as a lot of power adapters won’t provide clean enough power to hit these kinds of speeds.
Are you using a 3.0A power adapter? That’s definitely the most common one and you have to make an effort to find a bigger one like the CanaKit one. I’m not trying to shill for CanaKit and they almost certainly have no idea that I exist, but there aren’t many USB-C adapters out there specifically designed for the Pi but are beefier like this.
For those like us who aren’t overly excited about adding a powered USB hub into our Pi setup this is a great option, but the official Raspberry Pi 4 adapter (which is only rated for 3.0A) has been measured to put out higher than that. I don’t have any sources for that, but people who have them have much less trouble than some of the more generic options. Since it was designed for the Pi it would make sense if they built extra head room in to power accessories attached to the device as well.
3.0A is actually the minimum requirement for power. This is not good if you are running on the minimum and want to attach external drives! Check out this chart to understand what I mean about extra headroom (check out the minimum requirements in particular):
Note that the USB current draw is the total USB current draw allowed from all devices. This is important because it means if you have other USB devices plugged in like a mouse or anything else, it is actually limiting how much power goes to your drive. I suspect the setting you are changing in config.txt to raise the overcurrent allowed through the board is letting you pass this slightly.
In regard to your last question, yes, there is absolutely a chance for data corruption if this happens in the middle of a write. How often does it happen? If I were to guess just based on my testing with all these SSDs in different configurations over there years I would say roughly every 5 to 10 times it happens the drive will probably need an fsck.
A simple fsck on the drive (both partitions, fix the boot and the root!) fixes things like that about 98% of the time. Your chances of corruption will increase exponentially if you know you are going to be doing a ton of writes all of the time like for a database or a server. Sometimes things can go really wrong though, like if it freezes in the middle of the final apt dist-upgrade copying steps for example. This can kill your OS in a way that fsck won’t be able to recover from on it’s own and I’ve had to reimage a few before that crashed at really bad times!
Hopefully that all helps give you some ideas to consider. The power chart I hadn’t seen before until I tried to look up some stuff to double check what I was saying in this comment was correct (hopefully, sometimes it turns out I should have triple checked!). I should probably write a new article specifically about the Raspberry Pi and power incorporating all the things I’m learning here from everyone and from the storage benchmark!
Hmmm, ok, lots to consider. I have the official power adapter and unfortunately here in the UK there are no better adapters on sale, such as the canada one.
But at what point can I call it a day and declare my system stable?
Do you think the stress stability test I run for 2-4 hours is adequate to assess this?
From my earlier msg, my full-on stability test now consists of 2 hours of concurrent:
-stress-ng -c4
-Redream Dreamcast emulator running 18 wheeler in demo mode at 1920×1080
-onlinebenchmark.sh /pathToMountedExternalSSD (this is in a loop, also I removed the online submission bit at the end in order not to flood and spam your server)
Or would you recommend a better disk usage tool/script to keep the ssd busy, instead of running onlinebenchmark.sh hundreds of times?
Looking forward to your pi400 findings. Perhaps disabling wifi (unused on my setup) might help giving power back, every little drop counts 🙂
Best
I think the official power adapter is a good second best! I think you’re on the right track here. If it is stable for a couple of hours during stress testing that sounds like it’s getting very stable!
So for testing the disks and keeping them busy there are some pretty good examples in the Storage.sh bash file that use fio, iozone and dd to all stress the disk for benchmarking. For example:
This line from the script starts a FIO test to write 80MB of data. You could definitely increase the numbers substantially to stress it for a long period of time. This will create a file named “test” in the directory you’re in so remove it afterward with:
rm -f test
There’s nothing wrong with how you’re currently doing it except this would be an easier one liner so I figured I’d throw it out there!
So far I’m happy enough with the stability of the system with the asm235cm ugreen adapter. I actually considered an alternative usb3 enclosure with the same chipset with its own 12v adapter, but it looks a bit clunky to use, and pricey, so I didn’t go ahead.
One thought, is power comsumption going to be lower if the sdcard is disabled, by booting from the usb3 ssd instead? I’m probably splitting hair now, but then, I’m a curious individual.
I think the UGREEN is a good choice. My personal belief is that the sweet spot is where it is performing to the fullest potential while maintaining 100% rock solid stability with no crashes. This is where you’ll be the most effective without having to spend any time recovering from freezes/crashes which will slow you down on whatever you’re doing. I’m glad to hear you’ve found the sweet spot!
As for my Pi 400 it looks like it unfortunately got delayed:
Jan 5, 2021
3:00am
We were unable to dispatch the trailer on time. This may cause a delay.
It looks like it arrived in my regional post office tonight at 8PM so hopefully I will get it tomorrow!
Markus
3 years ago
in case somebody wants to migrate to full usb, follow as described but skip preparing usb drive, as you already have your ssd drive connected.
before rebooting(after Editing Bootload Configuration):
1) “clone” boot partition from sd card to ssd: sudo mkdir /mnt/bootssd
sudo mount /dev/sda1 /mnt/bootssd
sudo rm -rf /mnt/bootssd/*
sudo cp -r /boot/. /mnt/bootssd/
2) change /etc/fstab so boot partition also points to ssd
from existing eg PARTUUID=738a4d67-01 /boot vfat defaults 0 2
to(d34db33f has to match the identifier from ssd like the line below) PARTUUID=d34db33f-01 /boot vfat defaults 0 2
after that a reboot should have you covered.
Uef
3 years ago
Hi, I would like to contribute an update to the list of adapters:
I bought this Sabrent adapter (before I found this site and your warning regarding Sabrent)
(Sabrent USB 3.1 (Typ-A) to SSD / 2,5-Zoll-SATA-disc Adapter [optimized for SSD, supports UASP SATA III] (EC-SS31) )
It’s working fine on the USB 3.0 port with a Raspberry Pi 4, 4GB:
Write: sudo dd if=/dev/zero of=test.tst bs=4096 count=100000
--> 409600000 bytes (410 MB, 391 MiB) copied, 1.26424 s, 324 MB/s
Read: sudo dd if=test.tst of=/dev/null bs=4096 count=100000
--> 409600000 bytes (410 MB, 391 MiB) copied, 0.768701 s, 533 MB/s
Hope, this helps
Hi! first of all, thank you very much for posting this!
I have a Raspiberry Pi 4 4GB, with boot via SSD, and I will migrate to an RPi4 8GB. Will I need to do the procedure of configuring the EEPROM booloader again in the 8GB Rpi or just connect the SSD used in the 4GB Rpi?
Great question! Most likely yes the 8 GB one will need the latest firmware update unless it has recently been used by an up to date Raspbian installation. Eventually people are going to start receiving new ones with new enough firmware to do it but my original firmware on my 8GB was way too old. I imagine it will be the same for most people unless your reseller pulled out the Pi and plugged in a Raspbian SD card (just to make sure the device powers on for example before shipping it) and it automatically updated it during testing.
The reason for this is that the Pi 4 is the first one ever that actually has a real on-board EEPROM chip. The older Pis actually stored this stuff on the SD card (as bootcode.bin on the “boot” partition, all previous Pis still boot from this file) but now on the 4 it’s a soldered in chip so basically unlike previous Pis just putting in a different SD card/SSD/etc. won’t have any effect anymore on the bootloader if that makes sense.
This is actually a totally new issue for Pi owners because since bootcode.bin is used on older Pis it used to be that you would receive your Pi and then you would put a freshly imaged SD card in the Pi which would have at least had as new of a copy of the bootloader firmware as their Raspbian download had. Now you may have *very* dated firmware when you get your Pi!
These things typically take a very long journey to get to you and do a lot of sitting in warehouses so the firmware is usually pretty dated unless you have a really “Good Guy” reseller who actually tests and updates them for their customers. Your Pi will probably come with newer firmware than mine since I’ve had it for a while but there have been a *ton* of recent changes and fixes as well as new parameters added so it’s definitely worth an update!
What I would do is just have a fresh Raspbian SD card prepared to do the update the one time and then that Pi is all set!
Hey James,
Another device working with the following configuration:
cmdline.txt: usb-storage.quirks=152d:0578:u console=tty1 .....Benchmark: #37585
Not the best performance results but acceptable for me using a 4€ USB case and reused SSD Samsung MZ7LN256HMJP-000H1
Thanks for all your work! 🙂
Hey Juanjo,
Thanks a ton for the results! I’ve been going through and finally updating the storage benchmark. It’s looking a lot better here but there’s still a lot I want to do like adding filtering options, more comparable menus like a “Brand” menu that shows all the drives from a company.
I also want to do more rankings between the drives. I’m going to add your changes to the list here (I think there’s a couple other ones lower I need to get to to), but thanks again!
Hey James,
Your database is priceless! 🙂 I hope it will help more people to find the right adapter for the RPi. I have a couple more of SSD drives and few no-brand-chinesse cables pending to test. Will update the results soon to the database.
Can’t wait to see the new updates with the new menus and comparations between adapters and drives 🙂
Thanks 😉
That’s awesome! The more I have the more it helps. I’m down to about 4000 unidentified tests out of 37000 so it’s identifying something like 89.2% of all the benchmarks people submit right now. If you’ve submitted ones that the site didn’t recognize they are among those 4000. They’re all still in there, it just doesn’t display them publicly on the site because it has no clue what those drives are yet!
When I’m finding new models of drives that need to be added I usually sort the unidentified drives by how many benchmarks there are for them so having this additional data really helps. The site is just barely becoming even “browsable” in the barebones sense and was basically a giant list previously for the past year that was difficult to navigate and know what to even really do with. A lot of the work I’m doing is in the backend right now but definitely the frontend is getting redone completely as well!
The ones that it isn’t identifying are either really new drives or drives exactly like you’re talking about. The Chinese drives are very tough to identify and I have to mostly rely on what you guys type in the “notes” field to figure out what these ones are. There’s actually some that I have quite a few benchmarks of that I can’t identify that I’m just waiting for the one or two submitters who comment and tell me what it is to crack the case!
Sorry James, I haven’t had time yet to complete the test, one of my raspberrys is freezing randomly even after a clean install, another SD card, another SSD but I can’t find the reason why is freezing.
I’ve ordered another RP4 this week, as soon as it get home i will do more test.
Chinese boxes are identified by model number not by the SSD/HDD inside, maybe looking for the model will bring more details?
My two Chinese-cases are recognize by model number.
Hey Juanjo,
No rush at all! That’s a great tip about the Chinese drives being identified by model. I’m doing this type of model identification a little bit already with some of the brands I’m able to identify but I’m excited for whenever you get the chance to submit them! The notes field will help a lot!
Check this out.
My pi400 is freezing when overclocking, running an external ssd and keeping a conservative over_voltage setting. Increasing over_voltage by one solves the freezes.
That is fascinating! I actually ordered a Pi 400 here since the prices from the scalpers on eBay dropped to like $100 (still $30 over MSRP I believe, but still not as bad as before Christmas).
I should have preordered two of the things and I would have saved a lot of money and had them much earlier!
It looks like mine has shipped but isn’t coming until Monday because since it was a scalper they picked “USPS Retail Ground” as the delivery method to save themselves a few bucks on the shipping and have it take a week instead of 2-3 days!
I am going to give this a try for sure and see if I can reproduce your results as soon as it comes!
Hey James, sorry for late answer, looks like my old Pi4 had an issue with the RAM and fail on every single memory test I did. I ordered a new one together with a new Startech USB – SATA adapter, performance is much better vs the Chinese-no-brand adapters, +7k points on the benchmark, no quircks added on the config file and boots without any issue.
I will send you in a separate email few pictures of two non-working adapters, neither adding quircks in the config file.
Luca, thanks for the tip, but I not running any of my raspberrys overclocked, stable OS vs unstable speed, I choose stable OS, I’m getting old 😛
Hey Juanjo,
Wow, that is an end to the story I did not expect! An actual hardware failure!
You may be able to warranty it through whoever you bought it from depending on how long ago it was. Some vendors cover it for up to a year, and my understanding is that if you are in the EU or somewhere with favorable consumer protections the vendor sometimes will warranty it for a second year after the first year. It may be worth reaching out to see if they’ll just give you another one. It really is handy to have more than 1 around!
I have owned every generation of Pi since my original two Pi 1 Model Bs. They all still work 100% except for one. One of my 2 RPI4 4GB launch models (very bad heat management and buggy firmware) is the only one that has ever been defective and the hardware failed. It was the SD card port that failed (probably from me testing/imaging cards and taking them in/out 100 times in a row sometimes, very hard on the SD slot).
You have joined an elite club of people with verified Raspberry Pi hardware failures! It happens, but it’s rare, and it happens much less than just about any consumer electronics product you’ll find. I work on hardware as a tech professionally and would rate the Pi as far more reliable than a lot of the enterprise level products I work with.
I look forward to getting your email, and I’m relieved you have figured this out and found success!
UGREEN USB-3.1 enclosure (labelled ‘UGREEN 2.5″ SATA to USB-C 3.1 Enclosure Drive Caddy*’ above) has no problems with UAS, but blocks TRIM commands 🙁
It also has a timed spin-down mode enabled by default which requires the use of a somewhat-dodgy Windows-only reprogrammer to disable.
I have the same enclosure and trim works just fine, assuming you’re referring to the ASM235CM chipset (or similar). Have you added the following trim rule?
That works for me, it’s also worth noting that trimming an empty 1tb ssd drive takes about one minute.
# /etc/udev/rules.d/01-unmap-trim.rules# ASMedia ASM1153E and compatible bridge chips (Ugreen adapters)
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
Also, regarding spin-down, is it noticeable? what’s the duration before spin-down?
Best
L
Method I used to convert my RPI4 4gb and 8gb servers from 32bit to 64bit.
1. Use Filezilla to login to the server you plan to convert to 64 bit
2. Copy the complete minecraft folder to your PC.
3. Use Etcher or Pi Imager with image of “2020-08-20-raspios-buster-arm64-lite”
Download it from: downloads.raspberrypi.org
4. Write to your SSD with Etcher or Pi Imager.
5. Boot your rpi4 without the sd card if your bios is newer than 9/20, otherwise first update bios with recovery image on an sd card from Pi Imager then boot without sd card.
6. Connect rpi4 to your network.
7. Default login, User: pi Password: raspberry
8. Using Terminal: sudo raspi-config, set password, SSH enabled, timezone, language.
9. Log in with Putty ssh from your PC.
10. Putty Commands, this installs PI Minecraft Server:
Copy and Paste into Putty session:
wget https://raw.githubusercontent.com/TheRemote/RaspberryPiMinecraft/master/SetupMinecraft.shchmod +x SetupMinecraft.sh
./SetupMinecraft.sh
hit enter key and wait for setup to finish.
11. reboot with power switch
12. Login with Putty
cd minecraft./stop.sh (stop the server)
13. With Filezilla log into server
delete the minecraft folder
paste in the minecraft folder you saved previously on the PC.
14. Reboot rpi server. (server will restart) You are done.
Beautiful, thanks Richard!
I forgot to mention in my post that I am using Startech USB3S2AT3CB USB 3.0 to SATA Cables to boot my Minecraft servers. I found this article at “https://www.glump.net/howto/desktop/enable-trim-on-an-external-ssd-on-linux” on how to enable TRIM on these adaptors. Logged in with putty, I created a Rules File:
sudo nano /etc/udev/rules.d/50-usb-ssd-trim.rules
The contents are:
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"Note: This rules file is only for my Startech adapter, your device may have a different Vendor and Product ID.
I have two of those adapters, great tip, thanks Richard!
For those who don’t know, you definitely want trim mode enabled to get good performance out of your SSD!
Hey James, I have three enclosures with different chipsets and need to pick one for uasp trim and ideally no quirks, which one would you recommend keeping?
VL716Q4 Orico black meshed aluminum usb c
ASM153E Ennotek aluminum
ASM235CM Ugreen aluminum usb c
Also both my ASM enclosures show up with the same vendor/model id as your adapter for which you needed to add a quirk. I haven’t added quirks and am not seeing anything wrong with them at the moment, what issues did you encounter?
Please kindly let me know
Thanks and Merry Christmas!
Luca
Hey Luca,
Is your Orico one working? That’s the one I see on there that I would definitely expect to encounter problems. Has that one been working?
The UGREENs typically haven’t had any problems from what I’ve heard although those are mostly from user reports. Sometimes people are encountering power issues where they don’t have enough power and have to use a powered USB hub but I think other than that the UGREENs have been working without quirks for the most part.
We’ve also been expecting them to fix some of the adapters over time with firmware updates. Maybe they’ve fixed some of these in the recent updates. I know that the patch notes say that there have been some changes made to improve compatibility!
I have yet to hear of a working Orico adapter which is why I was extra curious about that one. I would pick the UGREEN since I have received the most positive feedback about those, but I definitely recognize the chipset in the Ennotek as well although I’m not as familiar with that one!
Definitely let us know which one you try and whether it works or not, and Merry Christmas to you too!
Hi James,
I have the three enclosures with me and have been testing them with my pi400 recently on both ntfs and ext4 builds.
They all appear to be working fine with UAS and TRIM (by adding a rule) including the Orico, which mounts the Vl716Q4 chipset. Actually, is there any way to spot uas issues that I might’ve missed?
Regarding my original query, I’m still curious as to why your ASM1053E chipset, which has the same model/make identifer as both the ASM235CM and ASM1153E chipsets, requires quirks, whereas my two enclosures don’t. What sort of issues did you see that made you discover the need for using quirks?
In terms of performance they’re all very similar, with the Ugreen ASM235CM>Orico VL71Q4>Ennotek ASM1153E, but we’re taking 3-7% difference max.
I still don’t fully trust the Orico though, especially given community feedback is leaning towards the ASM chipset. At the moment I’m undecided between the Ugreen ASM235CM which is £19 and the Ennotek ASM1153E for £11.5, but my gut feeling is to keep the Ugreen with the newer chipset out of the three.
Ugreen ASM235CM comes with firmware 171120D11E80:
Orico VL716Q4 – Unknown firmware:
Ennotek ASM1153E enclosure comes with firmware 141126A1CC40:
Lastly, I noticed something odd when overclocking to 2200 with 6 over_voltage. I found this configuration to be stable without no ssd connected.
I noticed that the pi400 is freezing when the ssd is connected and in use though. Increasing over_voltage to 7 solves this. Do you find it odd for the system to be more stable with ssd connected when supplying more voltage to the CPU?
Happy new year
Best
Luca
Hey Luca,
Excellent questions!
So regarding the ASM1053E I think that specific chipset in the example didn’t need quirks enabled to work. I was just using it as an example for the documentations of how you would enable it regardless of the chipset using whatever was plugged into my Pi at the time. The ASM105x is actually the older StarTech USB 3.0 (not the 3.1) which does not require quirks or anything else to work (I think). At any rate, it definitely wasn’t a UGREEN but it sounds like they share the same chipset as what I had plugged in.
Sorry for the confusion on this, it wasn’t meant to be directed toward any specific adapter and was only meant as a guide to how to find the adapter you’re using (assuming most people probably wouldn’t have the specific models that I had anyway and that it would be irrelevant, but it’s one of the most popular ones so this was a mistake in retrospect). I could be misremembering which adapter it was here, but I don’t think it was actually one that needed quirks if I remember right.
For the uas issues there are a few factors at play here you’ll want to take into account. The first one is what specific version of firmware you are using on your Pi. This actually matters a lot, as they have been constantly fixing compatibilities with certain chipsets. It’s a lot of reading, but check out the changes just for the bootloader firmware here.
Let’s look at some highlights here:
2020-10-28 – “Improve compatibility with external USB 3.0 disk enclosures by enumerating the downstream hubs before executing the USB port power off. N.B. Pi4 8GB automatically powers off the USB ports during chip-reset and does not need this change”
2020-10-28 – Don’t timeout a USB MSD device after USB_MSD_LUN_TIMEOUT if there are no other MSD devices or LUNs to try. This avoids unnecessary timeouts on very slow to initialise disk drives e.g. USB HDDs designed for backups.
2020-09-14 – Improve compatibility for USB devices which require the USB port power to be switched off for a period of time during a reboot.
2020-11-24 – XHCI protocol layer fixes for non-VLI controllers.
There’s some real whoppers in here. XHCI protocol layer fixes in the Pi’s onboard firmware as recently as 2020-11-24! These types of fixes are what a lot of these drives need to work properly in full uas mode with no quirks. It’s driver/firmware level fixes.
Now you may be saying “I’m sure I have the latest firmware” on there and everything now, but it complicates things because we are now comparing information that when myself or others wrote it all of these months or years worth of fixes didn’t exist yet. It’s very possible that some adapters on the “naughty list” actually work now if you have all the latest firmware updates for the Pi and for the drive itself. It may turn out that the “naughty list” evolves into something more like a “you have to have this firmware for it to work” list!
That brings me to the next point. Another thing that may explain some of these adapters working is that people are buying newer versions of these products that are coming with newer firmware on them. The firmware for these devices is often a nightmare to find and flash for end users typically but I think it’s something we need to look at more.
My storage benchmark actually captures a lot of this information and I’ve been furiously working on the Pi Benchmarks site to eventually get it to where we have an “Adapters” section. I think it would be useful if I made that information display in the benchmark and we could look more closely at the adapters that people have and what specific version of the firmware they were running. These may even explain some performance differences on some of these tests with otherwise identical looking adapters! I think you’re on the right track and that everyone needs to pay more attention to their enclosure/adapter’s firmware and apply updates if they are available. I would even be willing to start compiling that information here!
Finally for the last piece with the freezing SSD: this is a tricky one, but my initial thoughts are it’s power related, both the quantity and quality of power it is receiving. Even some of my most recent interactions with others commenting on this article and other related ones they have had a *lot* of power issues. Especially with NVMe drives, and also especially with enclosures!
Do you have a powered USB hub available to test if the freezing stops? The other suspicion I have had for a while is that the USB hubs are actually “masking” uas and other issues by acting as a translator. These devices generally have better compatibility (meant to connect with anything) as opposed to the storage adapters which are only meant to connect to a limited range of devices generally (like a PC, sometimes even running specific versions of an OS!).
You had a very astute observation about the over_voltage. I think what is happening here is that you are hitting the limits in the firmware of how much power the Pi is allowing to “pass through” it. This is a higher limit than previous Pis had on the 4 but you are not the first one that has bumped up against it using NVMe enclosures. My suspicion is that these devices combined with the NVMe drives are just pulling a hair too much power. I’ve actually never tried bypassing it like this by raising the amount of voltage in config.txt that is allowed to be delivered to the Pi.
The massive overclock is definitely not helping with the power limits either and you probably need to raise this limit to allow enough power to pass through the Pi 400. At least that’s my best guess as to what is happening here. I got my spouse a Pi 400 for Christmas but I have not got myself one yet! It could be something specific to the Pi 400 since when I saw a teardown it’s not just a regular Raspberry Pi 4 like I thought it would be. If you watch them tear it down on YouTube it’s definitely some kind of custom board I’ve never seen before that is actually a long weird specific shape to make it a good fit for the Pi 400!
Hopefully it helps, let us know what you learn!
Hi James, thanks for the informative and super useful reply.
I’m sure your spouse will love the new pi400, I quite like the form factor.
Your db is such a useful resource, exposing the chipset data would be quite useuful to!
Interesting to read about ssds disks issues, and recent improvements to the firmware. It’s worth noting that people use external ssds with Retropie on the Pi4 with an enclosure or use external samsung ssd drives directly and there are no common issues reported. Perhaps Retropie doesn’t quite push the system hard enough to cause power issues?
Regarding my overclock freezes, I was afraid this could be caused by power, unfortunately I don’t have a powered usb to test, and in all honestly I would love to try and solve this without one, whether possible, but do let me know if you definitely feel this is a lost cause.
Ultimately what I’m interested about is finding stable overclock settings for my system for when needing extra power with Retropie: a good 2100, 2200, aggressive 2300.
I’m continuing with my stability tests and can definitely see a correlation between increasing voltage and freezes going away. My full-on stability test now consists of 2 hours of concurrent:
-stress-ng -c4
-Redream Dreamcast emulator running 18 wheeler in demo mode at 1920×1080
-onlinebenchmark.sh /pathToMountedExternalSSD (this is in a loop, also I removed the online submission bit at the end in order not to flood and spam your server)
Does this set of heavy duty operations make sense for stability?
Would you recommend a better disk usage tool/script to keep the ssd busy, instead of running onlinebenchmark.sh?
Also, from my tests, it seems that running the ssd in ext4, compared to ntfs is less prone to freezes.
And the vl716q4 enclosure performs better (but still hangs occasionally) with 2200,6,750, compared to the asm235cm enclosure which hangs 100% of the time. However the asm235cm beautifully at 2300,8,750 whereas the vl716q4 hangs with these settings after around 2h. In more detail below:
2200,6,750:
-I switched back to the Orico vl716q4 enclosure yesterday and run 2200,6,750 for 1h straight without issues. A subsequent test failed after a total 2h unfortunately.
-The asm235cm ugreen would hang at 2200,6,750 after 10-40mins.
2200,7,750:
-Both enclosures are stable after a continuous 2h.
2300,8,750
Again, interestingly, Orico failed after 2h.
The Ugreen enclsoure run for 4h without problems, which I find puzzling, considering it would fail more easily as shown above.
One last question. In case of freezes, and considering that the OS is on the sdcard rather than external ssd, is there a chance of data corruption? is there a system in place to spot corruption after the fact?
P.s.
Would you want to continue this conversation via email?
Regarding the three enclosures, If you want I can share my excel where I stored the output of onlinebenchmark.sh with both ntfs and ext4 partitions.
Best
Luca
Hey Luca,
I understand and can relate to not wanting to use a powered USB hub. I like my setups to be sleek and have as few wires as possible.
They’re nice to have around for testing though. I have the Sabrent one but I lost the tiny little power adapter for it in my last move somewhere. I need to either find out what adapter it can take or just get another one since they’re relatively cheap and I want to do some further testing with how storage adapters react to having a “middleman” of a universal USB hub instead of talking directly to the Pi.
I’m guessing that this could have a wide variety of effects. In some cases it may increase speeds/stability/performance by “smoothing out” whatever the Pi doesn’t like about how the storage adapter is talking to it directly vs. how the USB hub communicates. I think in the cases of super cheap or poorly made hubs it may hurt performance to go through these.
I doubt there is zero effect at this point because we’ve seen and discussed so many different factors like firmware versions, revisions of existing adapters like 3.0 vs 3.1 revisions or even “stealth” revisions where they change to a different chipset without telling anyone.
The reason I jumped straight to power is that if the drives are undervolted when the OS tries to access something it will hang like this. Think of a situation like the OS asking it to retrieve a file and then the drive losing power for a millionth of a second and it forgets it was supposed to retrieve something and the OS keeps waiting kind of thing. It’s obviously much more complicated than that, but it illustrates a little why this could happen.
The other reason is your overclock. Maintaining power during overclocks is tough even without an external drive when you get in the extreme range because sudden changes in power or “dirty” power will cause it to freeze as well. You probably have the official power supply to even be hitting these clocks already I’m guessing as a lot of power adapters won’t provide clean enough power to hit these kinds of speeds.
Are you using a 3.0A power adapter? That’s definitely the most common one and you have to make an effort to find a bigger one like the CanaKit one. I’m not trying to shill for CanaKit and they almost certainly have no idea that I exist, but there aren’t many USB-C adapters out there specifically designed for the Pi but are beefier like this.
For those like us who aren’t overly excited about adding a powered USB hub into our Pi setup this is a great option, but the official Raspberry Pi 4 adapter (which is only rated for 3.0A) has been measured to put out higher than that. I don’t have any sources for that, but people who have them have much less trouble than some of the more generic options. Since it was designed for the Pi it would make sense if they built extra head room in to power accessories attached to the device as well.
3.0A is actually the minimum requirement for power. This is not good if you are running on the minimum and want to attach external drives! Check out this chart to understand what I mean about extra headroom (check out the minimum requirements in particular):
This chart is from the official Raspberry Pi documentation’s FAQ in the Pi Power section and is definitely worth a read as well as it dives deep into this stuff!
Note that the USB current draw is the total USB current draw allowed from all devices. This is important because it means if you have other USB devices plugged in like a mouse or anything else, it is actually limiting how much power goes to your drive. I suspect the setting you are changing in config.txt to raise the overcurrent allowed through the board is letting you pass this slightly.
In regard to your last question, yes, there is absolutely a chance for data corruption if this happens in the middle of a write. How often does it happen? If I were to guess just based on my testing with all these SSDs in different configurations over there years I would say roughly every 5 to 10 times it happens the drive will probably need an fsck.
A simple fsck on the drive (both partitions, fix the boot and the root!) fixes things like that about 98% of the time. Your chances of corruption will increase exponentially if you know you are going to be doing a ton of writes all of the time like for a database or a server. Sometimes things can go really wrong though, like if it freezes in the middle of the final apt dist-upgrade copying steps for example. This can kill your OS in a way that fsck won’t be able to recover from on it’s own and I’ve had to reimage a few before that crashed at really bad times!
Hopefully that all helps give you some ideas to consider. The power chart I hadn’t seen before until I tried to look up some stuff to double check what I was saying in this comment was correct (hopefully, sometimes it turns out I should have triple checked!). I should probably write a new article specifically about the Raspberry Pi and power incorporating all the things I’m learning here from everyone and from the storage benchmark!
Hmmm, ok, lots to consider. I have the official power adapter and unfortunately here in the UK there are no better adapters on sale, such as the canada one.
But at what point can I call it a day and declare my system stable?
Do you think the stress stability test I run for 2-4 hours is adequate to assess this?
From my earlier msg, my full-on stability test now consists of 2 hours of concurrent:
-stress-ng -c4
-Redream Dreamcast emulator running 18 wheeler in demo mode at 1920×1080
-onlinebenchmark.sh /pathToMountedExternalSSD (this is in a loop, also I removed the online submission bit at the end in order not to flood and spam your server)
Or would you recommend a better disk usage tool/script to keep the ssd busy, instead of running onlinebenchmark.sh hundreds of times?
Looking forward to your pi400 findings. Perhaps disabling wifi (unused on my setup) might help giving power back, every little drop counts 🙂
Best
Hey Luca,
I think the official power adapter is a good second best! I think you’re on the right track here. If it is stable for a couple of hours during stress testing that sounds like it’s getting very stable!
So for testing the disks and keeping them busy there are some pretty good examples in the Storage.sh bash file that use fio, iozone and dd to all stress the disk for benchmarking. For example:
fio --minimal --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=80M --readwrite=randwriteThis line from the script starts a FIO test to write 80MB of data. You could definitely increase the numbers substantially to stress it for a long period of time. This will create a file named “test” in the directory you’re in so remove it afterward with:
rm -f testThere’s nothing wrong with how you’re currently doing it except this would be an easier one liner so I figured I’d throw it out there!
Thanks, will try those 3-4 lines instead.
So far I’m happy enough with the stability of the system with the asm235cm ugreen adapter. I actually considered an alternative usb3 enclosure with the same chipset with its own 12v adapter, but it looks a bit clunky to use, and pricey, so I didn’t go ahead.
One thought, is power comsumption going to be lower if the sdcard is disabled, by booting from the usb3 ssd instead? I’m probably splitting hair now, but then, I’m a curious individual.
How’s your new pi400?
Hey Luca,
I think the UGREEN is a good choice. My personal belief is that the sweet spot is where it is performing to the fullest potential while maintaining 100% rock solid stability with no crashes. This is where you’ll be the most effective without having to spend any time recovering from freezes/crashes which will slow you down on whatever you’re doing. I’m glad to hear you’ve found the sweet spot!
As for my Pi 400 it looks like it unfortunately got delayed:
Jan 5, 20213:00am
We were unable to dispatch the trailer on time. This may cause a delay.
It looks like it arrived in my regional post office tonight at 8PM so hopefully I will get it tomorrow!
in case somebody wants to migrate to full usb, follow as described but skip preparing usb drive, as you already have your ssd drive connected.
before rebooting(after Editing Bootload Configuration):
1) “clone” boot partition from sd card to ssd:
sudo mkdir /mnt/bootssdsudo mount /dev/sda1 /mnt/bootssd
sudo rm -rf /mnt/bootssd/*
sudo cp -r /boot/. /mnt/bootssd/
2) change /etc/fstab so boot partition also points to ssd
from existing eg
PARTUUID=738a4d67-01 /boot vfat defaults 0 2to(d34db33f has to match the identifier from ssd like the line below)
PARTUUID=d34db33f-01 /boot vfat defaults 0 2after that a reboot should have you covered.
Hi, I would like to contribute an update to the list of adapters:
I bought this Sabrent adapter (before I found this site and your warning regarding Sabrent)
(Sabrent USB 3.1 (Typ-A) to SSD / 2,5-Zoll-SATA-disc Adapter [optimized for SSD, supports UASP SATA III] (EC-SS31) )
It’s working fine on the USB 3.0 port with a Raspberry Pi 4, 4GB:
Write:
sudo dd if=/dev/zero of=test.tst bs=4096 count=100000--> 409600000 bytes (410 MB, 391 MiB) copied, 1.26424 s, 324 MB/s
Read:
sudo dd if=test.tst of=/dev/null bs=4096 count=100000--> 409600000 bytes (410 MB, 391 MiB) copied, 0.768701 s, 533 MB/s
Hope, this helps
Thanks Uef, I have added this to the list!
Hi! first of all, thank you very much for posting this!
I have a Raspiberry Pi 4 4GB, with boot via SSD, and I will migrate to an RPi4 8GB. Will I need to do the procedure of configuring the EEPROM booloader again in the 8GB Rpi or just connect the SSD used in the 4GB Rpi?
Hey Marcelo,
Great question! Most likely yes the 8 GB one will need the latest firmware update unless it has recently been used by an up to date Raspbian installation. Eventually people are going to start receiving new ones with new enough firmware to do it but my original firmware on my 8GB was way too old. I imagine it will be the same for most people unless your reseller pulled out the Pi and plugged in a Raspbian SD card (just to make sure the device powers on for example before shipping it) and it automatically updated it during testing.
The reason for this is that the Pi 4 is the first one ever that actually has a real on-board EEPROM chip. The older Pis actually stored this stuff on the SD card (as bootcode.bin on the “boot” partition, all previous Pis still boot from this file) but now on the 4 it’s a soldered in chip so basically unlike previous Pis just putting in a different SD card/SSD/etc. won’t have any effect anymore on the bootloader if that makes sense.
This is actually a totally new issue for Pi owners because since bootcode.bin is used on older Pis it used to be that you would receive your Pi and then you would put a freshly imaged SD card in the Pi which would have at least had as new of a copy of the bootloader firmware as their Raspbian download had. Now you may have *very* dated firmware when you get your Pi!
These things typically take a very long journey to get to you and do a lot of sitting in warehouses so the firmware is usually pretty dated unless you have a really “Good Guy” reseller who actually tests and updates them for their customers. Your Pi will probably come with newer firmware than mine since I’ve had it for a while but there have been a *ton* of recent changes and fixes as well as new parameters added so it’s definitely worth an update!
What I would do is just have a fresh Raspbian SD card prepared to do the update the one time and then that Pi is all set!
Perfect! Thank you very much
No problem, let us know how it goes once it gets here!