New Raspberry Pi 4 Bootloader USB / Network Boot Guide

Raspberry Pi 4 with Samsung 950 Pro NVME SSD
Raspberry Pi 4 with Samsung 950 Pro NVMe SSD

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.

If you are looking to boot Ubuntu 20.04 or Ubuntu 20.10 you should check out my guide specifically for Ubuntu here.

Equipment Used

Raspberry Pi 4 Model B 8GB*

Raspberry Pi 4 8GB
Raspberry Pi 4 8GB

StarTech 2.5″ SATA to USB Adapter *-AND- Kingston A400 SSD 120GB SATA 3 2.5” Solid State Drive*

Kingston A400 SSD
Kingston A400
StarTech 2.5" SATA to USB Adapter
SATA to 2.5″ USB Adapter

You may use other types of drives with the Pi such as M.2 SATA to USB 3.0, M.2 NVMe to USB 3.0 and mSATA to USB 3.0. Here’s some adapters I’ve used for those types of drives:

UGREEN M.2 NVMe to USB Enclosure*

UGREEN M.2 NVME to USB Enclosure
UGREEN M.2 NVME to USB Enclosure


UGREEN M.2 SATA to USB Enclosure
UGREEN M.2 SATA to USB Enclosure

VL716 mSATA to USB Adapter*

VL716 mSATA to USB Adapter
VL716 mSATA to USB Adapter

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 Raspberry Pi 4 Power Supply with PiSwitch

CanaKit 3.5A Raspberry Pi 4 Power Supply
CanaKit 3.5A (very important to have enough power for a SSD) Power Supply

Sabrent 4-Port USB 3.0 Hub with Individual LED Lit Power Switches, Includes 5V/2.5A Power Adapter (HB-UMP3)*

Sabrent Powered USB Hub
Sabrent 2.5A Externally Powered USB 3.0 Hub gives a whopping dedicated 2.5A of power to satisfy even the thirstiest of drives

Known Working Adapters

This is a compiled list of known working adapters built by myself from adapters I’ve purchased and commenters from ones they have purchased in this article and my older guide that utilized a SD card for USB booting.

StarTech 2.5″ SATA to USB 3.1 Adapter*2.5″ SATA to USB 3.0Verified working in comments (thanks Fredrick)
StarTech 2.5″ SATA to USB 3.0 Adapter* (AliExpress Listing)2.5″ SATA to USB 3.1Verified working great by myself and others on Pi 4
Inateck FE2004 2.5″ SATA to USB 3.0 Hard Drive Enclosure*2.5″ SATA to USB 3.0Mirco reports that this enclosure is working but trim is not supported
Samsung 2.5″ SATA to USB 850 EVO Kit /w Adapter* (Alternate link*)2.5″ SATA to USB 3.0 KitThis is a kit that comes with a drive and adapter. Rene confirms the adapter works including with non-Samsung drives.
CSL 2.5″ SATA to USB 3.0 Adapter*2.5″ SATA to USB 3.0The CSL SL adapter is confirmed to be working by Krikitt in the comments. Available in Europe. Not available in US.
UGREEN 2.5″ SATA to USB-C 3.1 Enclosure Drive Caddy*2.5″ SATA to USB-C 3.1Confirmed to be working by CAProjects in the comments. Available in both Europe and US
UGREEN 2.5″ SATA to USB-C 3.1 “Protect What You Love” Case* (AliExpress Listing – Make sure to select USB-C 3.1)2.5″ SATA to USB-C 3.1Reported working by Michal in the comments, thanks!
UGREEN 2.5″ to USB 3.0 “SATA USB Converter” Adapter* (AliExpress Listing)2.5″ SATA to USB 3.0Also reported by Michal as working in the comments, thanks again!
UGREEN 2.5″ SATA to USB 3.0 Adapter Cable with UASP Converter*2.5″ SATA to USB 3.0This adapter is reported to be working by Mirco in the comments
SABRENT 2.5″ SATA to USB-C 3.1 Type A Adapter*2.5″ SATA to USB-C 3.1 Type AThe 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!
AliExpress Generic 2.5″ SATA to USB 3.0 “2.5 Inch 3 colors Hard Disk Case”2.5″ SATA to USB 3.0Reported as working with UASP support by pierro78 in the comments
AliExpress Generic 2.5″ SATA to USB 3.0 “New USB 3.0 To 2.5in SATA 7+15Pin Hard Drive Adapter”2.5″ SATA to USB 3.0Extremely cheap adapter from AliExpress confirmed to work by PPCM
AUKEY 2.5″ SATA to USB 3.0 Rigid Case*2.5″ SATA to USB 3.0Confirmed as working well in the comments by Alex
ICY BOX M.2 NVMe (M Key) to USB-C 3.1 Gen 2 Enclosure* (Alternate listing*)M.2 NVME M Key to USB-C Gen 2Returning 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*. Pending confirmation on if it works with a 3.5A adapter (I have one coming too).
TDBT M.2 NVMe (B+M Key) to USB-C 3.1 Gen 2 Enclosure*M.2 NVMe (B+M Key) to USB-C 3.1 Gen 2Confirmed to be working well by WorkHard in the comments
AliExpress Generic M.2 NVMe (B+M Key) to USB 3.1 “M2 SSD Case NVME Enclosure”M.2 NVMe (B+M Key) to USB 3.1 Type AConfirmed working by Jens Haase, thanks Jen!
SSK Aluminum M.2 NVMe (M Key) to USB 3.1 Gen 2 SSD Enclosure*M.2 NVMe (M Key) to USB 3.1 Gen 2Brian L reports this is working well with beta firmware upgrades, but that it did not work at all without them!
ORICO M.2 NVMe SSD Enclosure, USB 3.1 Gen 2 (10 Gbps)* (AliExpress Listing)M.2 NVME to USB 3.1 Gen 2M.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.
DELOCK 42570 M.2 SATA (B Key) to USB Micro-B 3.1 Gen 2 SSD Enclosure*M.2 SATA (B Key) to USB Micro-B 3.1 Gen 2Andreas Franek reports that the enclosure works with a 3.0A power adapter (gets a little warm)
Shinestar M.2 NVMe (M Key) to USB 3.0 Adapter*M.2 NVMe (M Key) to USB 3.0This is the adapter I’m using in the picture at the top of the article. It is for NVMe M.2 drives only and is getting hard to find
UGREEN M.2 NVMe (B+M Key to USB-C 3.1 Gen 2 SSD Enclosure*M.2 NVMe (B+M Key) to USB-C 3.1 Gen 2Confirmed working in comments by Chad D
UGREEN M.2 SATA (B+M Key) to USB 3.1 Enclosure*M.2 SATA (B+M Key) to USB 3.1 EnclosureReported as working well in the comments by John H. Reinhardt with a ASM1051E chipset
QNINE M.2 SATA (B Key) to USB 3.0 Enclosure*M.2 SATA (B Key) to USB 3.0I used this enclosure to benchmark M.2 SATA Lite-On and SanDisk drives — working great in 3.0 ports
ArgonOne M.2 SATA (B+M Key) Pi 4 Case*M.2 SATA (B+M Key) Pi 4 CaseThis case gives you a M.2 SATA port for your Raspberry Pi and is also a case! Confirmed working by Frank.
Tanbin mSATA to USB Adapter*mSATA to USB 3.0I used this mSATA to USB adapter for my Crucial M550 benchmark — working in 3.0 ports
Generic mSATA to USB 3.0 Adapter (fe2008)*mSATA to USB 3.1Confirmed working in comments by Nico
Canakit Raspberry Pi 4 Power Supply (USB-C)*3.5A USB-C Power SupplyCanakit 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
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).

FIDECO M207CPS USB3.2 to M2 NVME/SATA SSD Enclosure*M.2 NVME to USB 3.2 Gen 2Lee Myring reports that the FIDECO M207CPS has issues working with the Pi
UGREEN 30848 2.5″ SATA to USB 3.0 Hard Drive Enclosure*2.5″ SATA to USB 3.0Reporting as not working properly and disconnecting often by Mirco, thanks!
Sabrent USB 3.0 to 2.5″ SATA adapter*2.5″ SATA to USB 3.0Only 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.
Sabrent USB 3.0 to 2.5″ SATA Tool-Free External Hard Drive Enclosure*2.5″ SATA to USB 3.0Another nonworking Sabrent adapter reported by Alex, thanks Alex!
ELUTENG 2.5″ SATA to USB 3.0 Adapter*2.5″ SATA to USB 3.0Despite 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.
USB 3.0 to 2.5″ SATA III Hard Drive Adapter UASP Support-20cm, Black*2.5″ SATA to USB 3.0reported by dzm in the comments as having very poor I/O performance
ORICO 2.5″ SATA to USB C 3.0 Enclosure (Transparent)*2.5″ SATA to USB 3.0Several commenters have stated the transparent ORICO is not working. Avoid!
ORICO 2.5″ SATA to USB 3.0 Enclosure (Black) 2588US3-BKT*2.5″ SATA to USB 3.0Commenters report that the USB-C variant of the transparent ORICO enclosure also does not work
ORICO 2.5″ SATA to USB-C 3.1 Gen 1 Enclosure (Transparent)*2.5″ SATA to USB-C 3.1 Gen 1Confirmed as not working by Andrea De Lunardi in the comments (thanks!)
Vantec 2.5″ SATA to USB 3.0 USB Adapter with Case*2.5″ SATA to USB 3.0Does not work after hours of testing and frustration by Moshe Katz in the comments!

So far we have not found a single ORICO adapter that has worked correctly so I would avoid that brand completely for the Raspberry Pi.


Get Latest Raspbian & Updates

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

Using a 3.5A power supply* or powered USB hub* will ensure your drive is getting enough power without impacting the Pi’s stability.

Prepare Bootable Drive

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 are wanting to do a USB mass storage device boot with Ubuntu 20.04 or 20.10 check out my specific USB booting guide for Ubuntu 20.04 / 20.10 here.

Editing Bootloader Configuration

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:

sudo -E rpi-eeprom-config --edit

The default configuration will look like this:


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 in newer versions after that. Here are the different configuration options for the BOOT_ORDER parameter (from Raspberry Pi documentation):

0x1SD CARDSD card (or eMMC on Compute Module 4)
0x2NETWORKNetwork boot
0x3USB DEVUSB device boot – See usbboot (since 2020-09-03)
0x4USB MSDUSB mass storage boot (since 2020-09-03)
0xeSTOPStop and display error pattern (since 2020-09-03). A power cycle is required to exit this state.
0xfRESTARTStart 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 look as Raspbian’s default value of 0xf41:

If you want to leave the SD card and the “restart on failure” fallback options in place you can leave/change it to 0xf41. Go ahead and use your arrow keys to navigate to the BOOT_ORDER line and change it 0x4 or 0xf41 so it reads:



BOOT_ORDER=0xf41 (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 0xf412. If you wanted to change the order so that the network boots first instead you could reorder it to 0xf241.

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 blue USB 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
Raspberry Pi Imager Step #1

Next choose the “Raspberry Pi 4 EEPROM boot recovery” option:

Raspberry Pi Imager Step #2
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!

For a more detailed step by step guide on this check out my Bootloader Recovery Guide

Try Beta Firmware

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.

If your drive / USB storage adapter isn’t working then it is worth considering trying the beta firmware to see if the fixes in the versions released not on stable yet will help with your device.

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:


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:

sudo curl | sudo bash

This will give you a score you can compare to the other Raspberry Pi Storage Benchmark results and make sure that you are getting an equivalent speed to your peers with the same device!

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 2.5″ SATA to USB 3.0* 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:


In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):

usb-storage.quirks=174c:55aa:u console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline rootwait

Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.

Verifying Quirks

Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:

sudo dmesg | grep usb
 [1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [1.332983] usb 2-1: Product: ASM105x
 [1.333006] usb 2-1: Manufacturer: ASMT
 [1.333028] usb 2-1: SerialNumber: 123456789B79F
 [1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
 [1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
 [1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
 [1.336611] scsi host0: usb-storage 2-1:1.0

This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see “Verify Drive Performance” section).

121 thoughts on “New Raspberry Pi 4 Bootloader USB / Network Boot Guide”

  1. Avatar for Stuart

    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.

    1. Avatar for Luca

      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?

  2. Avatar for Richard Smith

    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:

    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:
    chmod +x
    hit enter key and wait for setup to finish.

    11. reboot with power switch

    12. Login with Putty
    cd minecraft
    ./ (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.

    1. Avatar for Richard Smith

      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 “” 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.

  3. Avatar for Luca

    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!

    1. Avatar for jamesachambers

      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!

      1. Avatar for Luca

        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

        1. Avatar for jamesachambers

          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 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!

          1. Avatar for Luca

            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
   /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

            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:

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

            -Both enclosures are stable after a continuous 2h.

            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?

            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 with both ntfs and ext4 partitions.


            1. Avatar for jamesachambers

              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 kind 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):

              Raspberry Pi Power Supply and USB Current Chart

              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!

              1. Avatar for Luca

                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
       /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 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 🙂

                1. Avatar for jamesachambers

                  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 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=randwrite

                  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!

                  1. Avatar for Luca

                    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?

                    1. Avatar for jamesachambers

                      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, 2021
                      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!

  4. Avatar for Markus

    in case somebody is coming from and 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.

  5. Avatar for Uef

    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:
    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
    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

  6. Avatar for Marcelo

    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?

    1. Avatar for jamesachambers

      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!

  7. Avatar for Brian L

    This works with the “SSK Aluminum M.2 NVME SSD Enclosure Adapter, USB 3.1 Gen 2 (10 Gbps) to NVME PCI-E M-Key Solid State Drive External Enclosure” ( using the beta firmware. Took me a bit a futzing around and then deciding to try the beta firmware when I was about to give up. This is with Raspian. Going to see if 64-bit Ubuntu 20.10 works also.

    pi@raspberrypi:~ $ dmesg | grep “usb 2-2″
    [ 1.574854] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
    [ 1.605972] usb 2-2: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 2.08
    [ 1.605990] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 1.606007] usb 2-2: Product: SSK Storage
    [ 1.606022] usb 2-2: Manufacturer: SSK
    [ 1.606038] usb 2-2: SerialNumber: DD564198838D9
    pi@raspberrypi:~ $ lsusb
    Bus 002 Device 002: ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp.
    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
    pi@raspberrypi:~ $ sudo rpi-eeprom-update
    BCM2711 detected
    VL805 firmware in bootloader EEPROM
    BOOTLOADER: up-to-date
    CURRENT: Tue 24 Nov 2020 03:08:04 PM UTC (1606230484)
    LATEST: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)
    FW DIR: /lib/firmware/raspberrypi/bootloader/critical
    VL805: up-to-date
    CURRENT: 000138a1
    LATEST: 000138a1
    pi@raspberrypi:~ $ blkid
    /dev/sda1: LABEL_FATBOOT=”boot” LABEL=”boot” UUID=”04A5-3FE5″ TYPE=”vfat” PARTUUID=”1afe17c5-01″
    /dev/sda2: LABEL=”rootfs” UUID=”c1578b06-85c2-4327-9c65-4c474a8f23f9″ TYPE=”ext4″ PARTUUID=”1afe17c5-02″
    pi@raspberrypi:~ $ lsblk
    sda 8:0 0 931.5G 0 disk
    ├─sda1 8:1 0 256M 0 part /boot
    └─sda2 8:2 0 931.3G 0 part /

    1. Avatar for jamesachambers

      Very nice, I don’t think I’ve seen one of those before! I’ve added it to the list and put a note that beta firmware will probably be necessary for anyone buying this in the near future / already has it.

  8. Avatar for Frank Buell

    Hi I just received my Deskpi Pro Case from 52Pi and have been testing it. It has an M.2 SSD adapter builtin for Sata drives (non NVME). The design and engineering are great. However I am having issue with performance using a Kingston A400 M.2 SSD. The case is new to the market but I think the choose a poor adapter.

    Their web site is brand new without any support or way to leave a question or post a remark. Perhaps you more experience pundits have contacts to reach out to them.

    After tweaking I have found that editing the /boot/cmdline file to include “usb-storage.quirks=152d:0562:u” helps to speed up the ssd. But it is still slow.

    Your article is a great resource.

    Quote: “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 “Verifying Drive Performance” section).”

    Results are:
    Sudo dmesg | grep usb

    [    1.575361] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
    [    1.606696] usb 2-1: New USB device found, idVendor=152d, idProduct=0562, bcdDevice= 1.09
    [    1.606714] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [    1.606730] usb 2-1: Product: RPi_SSD
    [    1.606746] usb 2-1: Manufacturer: 52Pi
    [    1.606760] usb 2-1: SerialNumber: DD5641988389F
    [    1.610351] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
    [    1.610478] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
    [    1.610497] usb-storage 2-1:1.0: USB Mass Storage device detected
    [    1.610984] usb-storage 2-1:1.0: Quirks match for vid 152d pid 0562: 800000
    [    1.611144] scsi host0: usb-storage 2-1:1.0

    sudo hdparm -t –direct /dev/sda #With Quirk set. #Without Quirk set speed was 300kb/sec

    Timing O_DIRECT disk reads: 476 MB in  3.00 seconds = 158.58 MB/sec

    If there is another fix or method to get UAS performance let me know.

    1. Avatar for jamesachambers

      Hey Frank,

      My initial thought when I read this was to check if the DeskPi case had flashable/updatable firmware updates available but I wasn’t able to find any. I was able to find people having the exact same issue: and here:

      It looks like a lot of people have posted about it already but I don’t see any definitive response. I’m not sure what they can do. If the device doesn’t have any interface or way for the user to update the firmware (pretty common on lower cost things like storage adapters) then the only firmware that could be updated is the Raspberry Pi’s to deal with it. They have done some updates recently to address some issues like this. If you want to try the beta firmware channel to see if the new fixes make a difference with your device check out my firmware guide here.

      There *might* be other creative workarounds available but the reason disabling UAS works is that it forces the drive to communicate in a different (slower) mode that doesn’t have whatever “bug” or unexpected/different behavior is making the Pi choke. But I believe these are firmware-level issues which means other than using such workarounds to force it to communicate in a different way and tricks like that I’m not sure anyone can fix them but either the manufacturers of the adapters/enclosures or the Raspberry Pi foundation through Pi firmware updates.

      I would see where the conversations go on their GitHub. Almost everything on there is “calling them out” for this issue so they are going to respond eventually I’m sure!

      1. Avatar for Frank Buell

        Your are a wealth of information. Thank you.

        In the meantime, I think I will go with the ArgonOne M.2 case. UASP works with that case.


    1. Avatar for Frank Meyer


      I got the IceX to work. The trick is to put an active USB3 hub in between – with its own power supply. Then the adapter also works on the PI4. I think that the current provided by the PI4 on the USB3.0 port is not high enough. Bonnie++ reports transfer speeds of read 322 MB/s and write 224 MB/s with a SAMSUNG EVO 970.

      I also tested the UGREEN M.2 NVMe to USB Enclosure here from the blog. It also runs only with the active hub, not directly connected to my PI4. The transfer speeds here are similar to the IceX enclosure.

      Hope this helps,


      1. Avatar for jamesachambers

        Hey Frank,

        Do you have a 3.5A power supply or the standard 3.0A that many Pi kits ship with? I am definitely using a 3.5A in all my action shots that have NVMe drives.

        There’s a lot of cheap ones out there that don’t even hit their 3.0A if it’s not a quality one and it leaves nothing to power your drive! Just another option to consider. There is widely varying quality between the adapters.

        Note that this only applies to the Pi 4 as any Pi before that couldn’t pass enough current anyways but they bumped up the limits so if you have a larger power supply with your Pi 4 it can pass on the current now!

        Mileage may vary by drive. The older it is, the more power it likely uses, but that’s just a guideline and not universally true. I think we are learning though that for NVMe drives that using a powered hub is advisable!

        1. Avatar for Frank Meyer

          Hi James,

          it’s the original Raspberry PI power supply, but only standard 3.0A. Thanks for the tip, I will see if I can get a 3.5A power supply. Then I will test it again with that – and without active USB hub.

          I also just wanted to point out that the IceX case does work. Here in this blog it is listed in the chapter “Known Problematic Adapters (Naughty List)” as “ICY BOX M.2 NVMe (M Key) to USB-C 3.1 Gen 2 Enclosure”. If it gets enough power, it does work.

          Kind regards,


          1. Avatar for jamesachambers

            Hey Frank,

            Thanks again for following up with all this great information. I’m really curious what your results will be with the 3.5A with both this and the UGREEN adapter! I’m going to move the ICY BOX up to the works category with your warning that it requires a powered USB hub.

            I am still using the SHINESTAR adapter that is in the picture of this article (very thin stick style, and not an enclosure) to this day with a 3.5A. Unfortunately they stopped making these or something because they have been unavailable on Amazon for a while. There’s ones that look extremely similar/identical (probably produced in the same factory) but nobody has reported on one yet so I don’t feel comfortable putting them on here yet one way or another. I don’t have one of the UGREENs or ICY BOXes yet or I would test these myself before you get the 3.5A just to make sure it’s enough for that particular one!

            I actually may pick up an ICY BOX because I don’t have an enclosure style NVMe adapter right now and I think that one just looks really cool (superficial I know, but I have like a dozen USB to X adapters and they’re typically quite boring looking). I think it would be fun to try it. The only thing more ridiculous and over the top stylistically would probably be a RGB enclosure (haven’t seen one yet, but wouldn’t be shocked if this exists somewhere).

            Possibly we may need to add a stronger warning to most or all NVMe enclosures that you are especially likely you run into power issues with these and that a powered USB hub is strongly recommended or an adapter upgrade may be required!

            1. Avatar for Frank Meyer

              Hi James,

              in the FAQs of you can also find the hint that you should use active USB hubs:

              “Very high-demand USB devices may however require the use of a powered hub.”

              Unfortunately, I couldn’t find a 3.5A USB power supply on Amazon with a European plug (I am living in Germany), only chargers. The reviews of these chargers state that they do not provide a constant voltage (5V), but rather a constant current. Therefore, they are not suitable for the PI4.

              That’s why I have now ordered a 4A power supply unit with Micro-USB plug and an adapter from Micro-USB to USB-C.

              At you will find a summary of the speeds measured by bonnie++.

              1. Avatar for jamesachambers

                Oh wow, I didn’t realize CanaKit wasn’t as easily available over there! I was able to find the charger in a kit on but nothing for On even the CanaKit kits look like everything is CanaKit and then have some random charger thrown in there with them. I’m guessing they didn’t make a production run of the right wall socket style/wall voltage for over there or didn’t get it certified for those countries yet.

                What you’re doing should work fine, and there are some additional options you can consider that I usually don’t recommend but generally work perfectly well. I’ve personally used a Dell laptop USB-C charging cable, a Google Pixel 4a USB-C charger (only rated for 3.0A though so won’t give a boost here), a Samsung Galaxy S20 USB charger and a few others.

                People often have ones around the house that will work even if it’s just for a test to see if an overrated power supply will solve the power woes. Sometimes it’s still hard to find one that will put out more than the 3.0A one you have already although sometimes it’s worth testing with another 3.0A anyway as the quality of the output and how much they really do varies widely.

                If it’s a high quality USB-C power supply to a reputable brand it should generally be safe to power it. Not everything will work though, here’s a really good Hackaday article that has some of the technical details about why some adapters (like Mac ones) don’t work.

                It also talks about how many of these power supplies don’t even hit their rated outputs (extremely common and why I always recommend CanaKit ones, the Canadians have yet to let me down in all these years). I believe the resistors issue was fixed on newer Pi 4 revisions but if you got one of the initial production run Pi 4s (I have one surviving launch Pi 4 left, one of them died, my only Pi to ever die including my 2 original Pi 1s).

                The official Raspberry Pi 3.0A power supply is known to deliver more than 3.0A as well but I don’t think it delivers as much as the CanaKit 3.5A one.

                The Raspberry Pi 4 is a lot better at passing on this extra current to peripherals than previous generations of Pis were. I believe improved power management/flow is part of the USB-C specification if I remember correctly to improve compatibility. Older Pis could use oversized power adapters but they couldn’t pass on nearly as much power even if it was available.

                Here’s a bunch of other people doing this here (bottom of thread has the newer 2019 posts) and a lengthier StackExchange discussion here.

                It sounds like you’ve got a working solution inbound but I wanted to take the chance to link some good work that may help others trying to find a solution as well in the future!

                1. Avatar for Frank Meyer

                  Hi James,

                  my 4 A power supply unit has arrived.

                  First I tested without NVME adapter by booting the PI4 via SD card. This was successful, everything worked perfectly.

                  Then I connected the ICY case directly without an active hub and mounted /dev/sda2. That also worked.This behaviour was already better than with the original 3A power supply. But then during the bonnie test, errors appeared in /var/log/messages:

                  Dec 23 11:00:23 raspberrypi kernel: [ 296.819105] sd 0:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
                  Dec 23 11:00:23 raspberrypi kernel: [ 296.819125] sd 0:0:0:0: [sda] tag#17 CDB: opcode=0x28 28 00 00 25 22 e0 00 01 00 00
                  Dec 23 11:00:23 raspberrypi kernel: [ 296.929109] sd 0:0:0:0: [sda] tag#18 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
                  Dec 23 11:00:23 raspberrypi kernel: [ 296.929127] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x28 28 00 00 25 23 e0 00 01 00 00
                  Dec 23 11:00:27 raspberrypi kernel: [ 301.299178] sd 0:0:0:0: [sda] tag#19 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD
                  Dec 23 11:00:27 raspberrypi kernel: [ 301.299197] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 00 38 24 18 00 00 10 00
                  Dec 23 11:00:27 raspberrypi kernel: [ 301.339195] scsi host0: uas_eh_device_reset_handler start
                  Dec 23 11:00:27 raspberrypi kernel: [ 301.490250] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
                  Dec 23 11:00:27 raspberrypi kernel: [ 301.524697] scsi host0: uas_eh_device_reset_handler success

                  Meanwhile, the write rate has dropped from 230 MB/s to 90 MB/s.

                  Finally, I tried to boot the PI4 from the ICY adapter. The boot got stuck.

                  Conclusion: It does not work without an active USB hub.

                  I tested this with a new PI4, which does not have the error on the USB-C port that the early PI4s had (missing resistor).

  9. Avatar for Larry

    Hi James,

    Getting an error trying to boot my 4B 4GB from a OCZ Vertex 2 SATA II 240GB with a non powered BENFI USB 3.0 adapter. Boot up just loops.

    My bootloader config is:

    Error is:

    USB – MSD boot requires newer software
    ERROR: 00000044

    Missing/empty ‘fixup4rc.dat’

    Your thoughts?

    1. Avatar for Larry

      Info on the USB 3.0 adapter:

      sudo lsusb:

      Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

      sudo dmesg | grep usb:

      [ 1.875946] usb 2-1: Product: ASM105x
      [ 1.875961] usb 2-1: Manufacturer: ASMT
      [ 1.875976] usb 2-1: SerialNumber: 00000000000000000000

      1. Avatar for jamesachambers

        Hey Larry,

        What OS and version are you trying to boot? It doesn’t sound like it has new enough firmware on it. Did you create this using the official Raspberry Pi imaging tool? The newest image I see on the site for Raspberry Pi OS is for December 2nd which should have new enough firmware on it but if you didn’t download it very recently it is probably much older than that.

        The .dat and .elf files they are referring to can be updated by plugging in the SSD to your Pi on the latest version of Raspbian (fully updated with sudo apt update && sudo apt full-upgrade -y) and then copying the /boot/*.elf and /boot/*.dat files over to your SSD’s “boot” partition. However it’s important that your Raspbian is fully up to date to do this or those firmware files may not be new enough either.

        If you plug in the drive and use the following commands (note, you may need to substitute a different drive letter if your drive shows up on the system as something like /dev/sdb instead, see what is plugged in with command lsblk):

        sudo mkdir /mnt/boot
        sudo mount /dev/sda1 /mnt/boot
        sudo cp /boot/*.dat /mnt/boot
        sudo cp /boot/*.elf /mnt/boot
        sudo umount /mnt/boot

        This will update those files on the SSD that the error is referring to.

        I also wonder if updating to the beta firmware would fix yours. You can try that by doing:

        sudo nano /etc/default/rpi-eeprom-update

        and changing it from “critical” or “stable” to beta then running:

        sudo rpi-eeprom-update -a

        followed by a full reboot of your Pi. The new beta versions have fixed some strange issues with adapters and a bunch of other things related to USB mass storage / booting so for something like this it’s worth a shot.

        There is one more possibility which is that something is wrong with the firmware itself inside the onboard chip on your Pi (this has happened to a few other people although they had different symptoms). The official Raspberry Pi recovery image created from the Pi Imager tool has fixed a bunch of them so far! It definitely should resolve any bootloader issues if it’s not something related to the image you are using needing updated *.elf and *.dat files. My guide here can help for more detailed instructions!

  10. Avatar for Jeff


    Haven’t been back to this post in quite a while (since I got my Pi4 set up after the official USB boot support was added), but I have a quick question about “upgrading” to a larger external SSD…

    If I have a running setup booting off the external USB SSD (currently a 120GB PNY), what would be the best way to upgrade to something larger? I am using my pi4 as the main host for a Syncthing setup, and I would like to update to a bigger drive since my 120GB is not enough anymore.

    Could I just shut down the Pi, plug the external SSD into a windows PC and use cloning software like Macrium Relfect to clone to another external SSD (the bigger drive)? Or if I don’t have a second USB-SATA adapter, could I image the drive to some free space on my windows desktop internal storage drive and then use that image to create the second larger drive?

    I think I have another USB-SATA adapters around here somewhere, but it is one of the models that isn’t well-supported for Pi booting.

    Or is there another way to clone the drive directly from the Pi?

    And will all of this cloning mess up any of the modifications (like UUID changes) that were made during the process of setting up USB boot in the first place? It doesn’t seem like this would matter if it is a perfect clone of the original, but I am not an expert there…


    1. Avatar for Jeff Roetman

      Well, I just realized that this guide is an updated version for the RasPi4 after the update to allow USB booting. So from reading the above for the first time, it seems that the UUID changes are no longer needed (as they were in the previous guide for booting from SDcard and then using USB for everything else).

      But my above question still stands – what is the best method for cloning the existing USB to a new larger one?

      Thanks again!

      1. Avatar for jamesachambers

        Hey Jeff,

        Sorry I missed this earlier and you may have already figured this out, but the easiest way is using a GUI partition management tool. I’d say Clonezilla is really good for it. You can also do it on the command line doing dd.

        Once you’ve cloned it you would expand the partition table to use the new “free space” on the drive. This is why I was saying to grab one of the popular open source GUI tools to do this is it will take care of all these steps for you!

  11. Avatar for Frank Meyer


    First I updated Raspbian, now it shows:
    Linux pitv 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux

    Output of ‘sudo rpi-eeprom-update’:

    BCM2711 detected
    Dedicated VL805 EEPROM detected
    BOOTLOADER: up-to-date
    CURRENT: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
    LATEST: Do 3. Sep 12:11:43 UTC 2020 (1599135103)
    FW DIR: /lib/firmware/raspberrypi/bootloader/critical
    VL805: up-to-date
    CURRENT: 000138a1
    LATEST: 000138a1

    The command ‘sudo -E rpi-eeprom-config’
    shows only 3 lines:
    followed by 13 empty lines.
    If I call ‘sudo -E rpi-eeprom-config –edit’, nano shows only 3 lines filled with text, I can walk with cursor down also 13 empty lines following. Should I replace the 13 empty lines by the contens you posted above?

    1. Avatar for jamesachambers

      Hey Frank,

      Maris tried that here in the replies and it didn’t work but you can see if it will let you save it in there. He got some sort of eeprom timeout error.

      Could you give us the output of this command:

      vcgencmd bootloader_version

      I think the only thing that restored the configuration options was using the Raspberry Pi imaging tool and making the recovery image from that to reset the bootloader. I would give it a try!

      1. Avatar for Frank Meyer

        Hi James,

        $ vcgencmd bootloader_version
        Sep 3 2020 13:11:43
        version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
        timestamp 1599135103

        Kind regards


      2. Avatar for Frank Meyer

        Hi James,

        I loaded the recovery image and now the output of rpi-eeprom-config is fine:


        Thank you very much!



        1. Avatar for jamesachambers

          Hey Frank,

          Excellent, that looks perfect! I’m surprised how many people have had this issue so far. It seems like even though the bootloader changes are coming out of beta some percentage of people are not having the bootloader configuration update through apt.

          The weird thing is the people who have had this always seem to have the right bootloader firmware. It seems like it’s the configuration that won’t update for some reason but restoring using the official Raspberry Pi recovery image has fixed everyone who has experienced this so far.

          Thanks for letting us know it worked out!

          1. Avatar for Frank Meyer

            Hi James,

            Meanwhile I connected a USB3.1 to SATA adapter from Poppstar ( ) and copied the SD as image to an older 2.5″ SATA disk. The boot worked fine. 🙂

            bonnie++ gives a speed of 99MB/sec for block transfer – both reading and writing. I am very happy with that… it’s an old HDD.

            Now I installed another brand new RPI4 with the latest PI OS and then updated it – as described here in this blog.

            The same issue exists here as well:

            sudo -E rpi-eeprom-config’ shows only 3 lines:

            But now I know how to fix this problem 🙂

            Next I will test the boot of M.2 NVME SSD…

            Thank you!


  12. Avatar for Moshe Katz

    Thank you for this great resource!

    I spent 5 hours trying to boot from an SSD using a Vantec CB-STU3-2PB, and had nothing but problems.

    I found your page, switched to my StarTech/ASMedia ASM1051E, and was up and running in less than 30 seconds.

    You can add the Vantec to your “Known problems” list. I tried the quirks setting, but it didn’t help for this one.

  13. Avatar for Carto

    Thanks for this guide James.

    Do you have plans to update your guide for RPi4 Ubuntu now that the Raspberry Pi 4 Bootloader USB is out of beta? I hope this will make the setup for Ubuntu easier.

  14. Avatar for Maris

    I am obviously missing something. Executing the ‘sudo -E rpi-eeprom-config –edit’ command loads a file ‘/tmp/tmpmf8ua9ol/boot.conf’ into nano.
    The contents of the file :
    Adding the BOOT_LOADER params and saving (ctrl-X, Y with same file name) returns : ‘ERROR : rpi-eeprom-update -d -i -f /tmp/tmpjj_1frdu/pieeprom.upd timeout’.

    The MSD is a Samsung 1TB 860EVO. The OS is 2020-09-20-raspios-buster-armhf. The adapter is an Orico 3 –Sata III.

    The sudo rpi-eeprom-update -a output :
    BCM2711 detected
    BOOTLOADER: up-to-date
    CURRENT: Thu 03 sep 2020 12:11:43 PM UTC (1599135103)
    LATEST: Thu 03 sep 2020 12:11:43 PM UTC (1599135103)
    FW DIR: /lib/firmware/raspberrypi/bootloader/critical
    VL805: up-to-date
    CURRENT: 00013a1
    LATEST: 00013a1

    Orico prob ? Had a bunch of DEPENDENCY issues using Speiss method youtube #312

    Advice ?

    1. Avatar for jamesachambers

      Hmmm, that doesn’t look quite right, it looks like an old configuration from before the USB boot support was added. Can you try restoring the bootloader to defaults using a:

      sudo rpi-eeprom-update -a -d

      Also when you said you were having a dependency issue is your apt package manager still functioning correctly? You may want to do a

      sudo dpkg --configure -a
      sudo apt update
      sudo apt install --fix-broken
      sudo apt full-upgrade

      Let us know what you find!

        1. Avatar for jamesachambers

          Very curious. You are missing a lot of options. Check out the Raspberry Pi bootloader configuration page from the Raspberry Pi docs. Every configuration entry has a date from when it was added. Were the original 3 you posted the only ones in there still? That would date you all the way back to a 2019-07-15 bootloader configuration. Even the first one released in 2020 has additional options!

          You should be able to update the firmware from Raspbian on a SD card. It won’t matter that you use the SSD again later since the firmware is stored on a chip. Do you have a spare SD card you could try from with a fresh Raspbian image to rule out the SSD/adapter? I haven’t encountered this before. I almost wonder if your bootloader is locked somehow or being overridden through some of the options that are in the link I posted in the first paragraph potentially?

          Using the full blown official Raspberry Pi firmware/bootloader recovery image (see the “Restoring Bootloader to Defaults” section to see screenshots of this) may be in order potentially as well. What do you get from using the command:

          vcgencmd bootloader_config

          1. Avatar for Maris

            It appears my latest post didn’t make it.

            Noting that I try seems to make any difference. vcgencmd bootloader_config returns the same three options as before as does the rpi-eeprom-update -a -d command.

            I vaguely recall having timing issues with the 860EVO when I tried SSD boot a while ago (year?).

            I ordered the same set-up that you describe above and I’ll attempt it again.

            Just to double check : the image(s) to burn are :

            1. Avatar for jamesachambers

              The weird thing is that the SSD should have nothing to do with it. That bootloader configuration on the Pi 4 is stored on a chip inside the Pi. The vcgencmd utility is essentially relaying the actual bootloader settings that the Pi is using directly from the SoC. I was hoping it was some kind of bug with the edit command and that it wasn’t your actual configuration but that definitely seems to confirm it.

              Have you tried using the recovery image yet? Which SSD / SD card you use won’t make any difference. The bootloader is lower level than that. I know you said you reflashed, does that mean you used the official recovery image? And just to confirm, and I thought I said this somewhere in your older posts but now I’m not sure, this is a Pi 4? Because this won’t work for anything older than a 4 as they don’t have this bootloader.

              1. Avatar for Maris

                The updated boot loader via vcgencmd bootloader_config

                However :
                This is the same error stream I got using Spiess’ youtube (#312) technique. On boot after diddling the SSD for 10 mins. :
                Timed out waiting for device /dev/serial1
                Dependency failed for Configure Bluetooth Modems connected by UART
                Timed out waiting for device /dev/disk/by-portuuid/58ce116e-01
                Dependency failed for /boot

                and stop

                Obviously rpi 4 don’t like Samsung 860EVO. I’ll try it with the 250G Kingston when it arrives.

                1. Avatar for jamesachambers

                  That looks much better! At least your bootloader is functioning and correctly configured again. Everything I can find related to that error points to the partition UUID not matching your /etc/fstab file.

                  The Samsung 860 Evo is the 9th most popular SSD by number of submissions with over 322 benchmarks so far. I think the drive will be fine. The adapter is probably the culprit.

                  One other thing you should check is to try having the Raspberry Pi imaging tool create the SSD media for you. This would be the same tool you created the recovery image with. Have you tried that yet by chance? I only say this because I’ve seen some imaging tools mess up those PartUUIDs before so it may be worth giving a shot while you’re waiting!

                  1. Avatar for Jon

                    I seem to have the same issues as Maris. I’m using a Qnine NMVe adapter with a Toshiba drive. My rpi-eeprom-update output and looks identical to his except my specified FW DIR is to the /stable directory rather than /critical. My rpi-eeprom-config file looks identical to his as well with the BOOT_ORDER=0xf41 rather than your example of just 0x4.

                    The thing that suck out to me looking at the difference between the update outputs was that your version was newer (Nov 24) and showing as beta. Could that be part of the issue?

                    1. Avatar for jamesachambers

                      Hey Jon,

                      Thanks for chiming in! That can’t be a coincidence that you also have a Qnine adapter. Your bootloader looks fine for sure, Maris was missing all of those options and yours look normal and he appears to have fixed that part of it.

                      I updated to the beta release just so I could get a screenshot of what it looks like when there’s an update available but I didn’t have the beta firmware to make this tutorial. Most others seem to have been successful as well.

                      We could definitely have you guys try the beta channel if you would be interested. According to the firmware release notes it looks like there have been dozens of fixes that aren’t in stable. Here’s some that caught my eye:

                      • 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.
                      • 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.
                      • Fix failover to partition zero if the partition number is invalid. For USB MSD boot a start.elf update is also required.
                      • Fix issue where boot would stop if partition type 0x83 was encountered before the first FAT partition.
                      • XHCI protocol layer fixes for non-VLI controllers.

                      Those are just a few I saw in there that have been released since the September release firmware that is on stable. The first one I bolded in there looks particularly juicy as it specifically relates to timeouts for certain mass storage devices! The second one is also pretty interesting because I have an 8 GB Pi which apparently is immune but 4 GB and lower capacity Pis are not without the firmware update which at this time is in the beta channel.

                      Most people appear to be fine, but I think it would be worth you two trying the beta version. See my guide for instructions to change to the beta channel if you’re interested. If you aren’t comfortable going on the beta firmware then you can just wait until it’s released to stable which probably won’t be more than a couple of months.

                    2. Avatar for Maris

                      I used the imaging tool to burn the OS on both the SSD and SD. The SSD took forever but now with the “real” image it boots as expected.
                      I’m suspicious of the Balena Etcher especially imaging from a zip.

                  2. Avatar for Maris

                    I assume you mean an MSD adapter on the Pi 4. How to debug or fix.

                    Another question : what is the meaning of BOOT_ORDER=0xf41. It doesn’t match your notes wrt to setting the boot order.

                    1. Avatar for jamesachambers

                      Hey Maris,

                      You’re correct, I meant the mass storage device adapter. Check out my reply to Jon here but I think the only thing you can do other than try a different adapter is try the beta firmware. There have been some fixes in there that are related to booting and mass storage devices so that’s definitely worth a try! Normally I don’t recommend going on beta unless you have a specific problem that you need to fix. Both of you qualify in this case!

                      That’s a great question about the BOOT_ORDER. You can combine different codes together using the table in my article. Let’s break down 0xf41 as as an example:

                      0xf tells it to continuously restart the boot process if it fails. With this active you can power on the Pi without a SD card in it for example and if you put it in after it powers up it will succeed the next time it tries to reboot (it will retry forever). 0x1 is the SD card. So this example would equate to 0xf (restart on failure) + 0x4 (mass storage device) + 0x1 (sd card). This means boot from the mass storage device, if that fails try the SD card, and if that fails it will restart again from the beginning.

                      This is a nice feature and is very handy in certain situations where having a fallback is really valuable! You can actually add the other options in the table in there too if you wanted to add network booting in there you could change it to 0xf143 to have it try to network boot if mass storage and micro SD both fail. I’m adding this into the article because they recently changed the default to be 0xf41

  15. Avatar for Brad Smith

    I have 2 each of the StarTech USB3S2SATA3CB USB 3,0 STAT adapter and Crucial CTX 500 (250 MB) SSD and can report these have been very problematic for me with a Raspberry PI 4 8GB.

    1. Avatar for jamesachambers

      Hey Brad,

      I have several of both the StarTech 3.0 and 3.1 versions of the adapters and they have been reliable. I used one of them when writing this guide to connect with my SSD. I don’t recognize that Crucial model of CTX 500 though, is it a BX500? It definitely could be drive related, do you have any other types of drives you could test with around?

      What problems have you been having? Maybe we can help. Which power adapter are you using for the Pi 4 8GB? You want to make sure yours is at least a 3.5A (you should be able to see this on the adapter if you look at the label). I’ve seen some kits coming with 3.0A supplies from last gen with the Pi 4 (and people reusing older ones, I’ve been guilty of this) and it’s fine until you connect something like a SSD that needs to draw power from it.

      Another good thing to check is if you have a powered USB hub to try powering your drive off that instead of the Pi itself and see if things stabilize! Some SSDs can be quite power hungry, especially older ones.

  16. Avatar for Jonny

    (noob questions incoming)
    Can I use your tutorial on my pi 3b+?
    I’m planning on using your minecraft tutorials as well, would changing the bootloader mess anything up?
    Thank you for all your work, so nice having all this info in one place.

    1. Avatar for jamesachambers

      Hey Jonny,

      I don’t think this one will work for the 3B+ because the Raspberry Pi 4 started coming with an new onboard EEPROM chip soldered into the board that the bootloader is stored on. This is how the bootloader settings can survive you putting in a different SD card for example. Older Raspberry Pis don’t have this chip and boot off the older way of using bootcode.bin and start.elf.

      The good news is the 3B+ should support USB mass storage device booting right out of the box. Check out the bottom of the the Raspberry Pi USB mass storage device booting page for a little bit more info. Basically, you should be able to image your mass storage device just like you would a SD card and plug it in and it should be good to go!

      1. Avatar for Jonny

        doh, turns out my 3b+ was a 4 this whole time ha! I’ll no longer need a card in the microSD slot after I start booting off usb correct?

        1. Avatar for jamesachambers

          Hey Jonny,

          That’s absolutely right! If you set the boot mode to 0x4 it will only attempt to boot from the USB mass storage device. If you wanted it to fall back to the SD card if it failed you could set the code 0x41 but I just have been leaving mine empty!

          I updated the article to add this information to hopefully help others as well.

  17. Avatar for John

    Hi James,

    My pi 4 currently attached an external HDD Seagate Backup Plus 5TB. I’m looking for a recommended Enclosure Case SDD with power supply.


    1. Avatar for jamesachambers

      Hey John,

      Great question. You have a couple of different paths you can take. If you want a similar setup to what you have now where everything is self contained I would check out the portable SSD section at my storage benchmark site here:

      Of course the fastest option is going to be the more expensive one usually but even as soon as page 2 and 3 there are great performing drives that are very reasonably priced. These are basically the same as the setup you have now. The closest version to the Seagate Backup Plus is probably the Seagate One Touch SSD.

      It’s typically not necessary to provide external power to the SSDs but honestly it is a nice feature to have on a Pi where you have limited power to work with and big power draws can cause issues. A popular alternative to consider is to actually get a powered USB hub. Basically you power the drive off the USB hub instead of the Raspberry Pi which takes all the power draw off the Pi. Keep in mind that you’re only likely to run into this problem with very powerful or very old power hungry drives and only if you are pushing your Pi to the absolute limits but still it is a consideration.

      One note with the powered USB hubs is that you need to get one that doesn’t feed power back into the Pi. You have to be pretty careful here. I have this Sabrent one.

      The reason I say to be careful is that with this type of equipment the manufacturers sometimes make changes to which chipsets they are using and things like that without spinning it into a new model. This has happened with storage adapters too where in the middle of a production run they start using a different chipset etc. I always check the Amazon reviews to make sure people receiving it *recently* are saying it’s working with the Pi. I double checked the Sabrent and saw people from early October saying it was working great on their Pi 4 to power an external drive so this looks like a safe bet, but if you’re reading this later you should verify it the same way!

      The other option you can take is to use a USB adapter which allows you to use just about any SSD you want to. An example would be the StarTech 2.5″ SATA to USB Adapter. The adapters are very cheap. It’s especially cheap if you happen to have a spare/old drive anywhere!

      If you want to go this route instead definitely check out the sections above where myself and other commenters have basically got together and determined which adapters suck and which ones are great. There are many different types of adapters/enclosures on there that have already basically been tested.

      A great place to find SSDs to consider is the popular section of my storage benchmark site. This section is nice because it isn’t based on how fast it is but how many people are using it/benchmarking it so it isn’t just fast drives that cost hundreds of dollars. In fact, the most popular choice for a long time running now is the Kingston A400 which is around $25 when I wrote this comment and hovers between $20 or $30 for the past year or two.

      Hopefully that helps give some ideas to consider!

      1. Avatar for John

        Hi James,
        I got my SSD worked well. I bought ELUTENG 2.5″ SATA to USB 3.0 Adapter and Sabrent 4-Port USB 3.0 Hub with Individual LED Lit Power Switches.

        My SD card already had Dietpi. Then I followed this guide ( to clone my SD card to SSD. After that, I followed Editing Bootloader Configuration to make SSD boot.

        Thanks for your suggestion.

  18. Avatar for Adarsha

    I am still getting a raspbian from Oct 22 build date when I try distro upgrade. Is this version compatible with USB Boot?

    uname -a
    Linux raspberrypi4 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux


    1. Avatar for jamesachambers

      Hey Adarsha,

      That looks right to me and matches the Pi I just imaged to write this guide. I used the 64 bit beta version on my SD card which has the new support and the 32 bit image I put on the SSD also has it in there. This was my result:

      Linux raspberrypi 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux

      The easiest way to tell if you have the support is to try the command:

      sudo -E rpi-eeprom-config --edit

      If you are on a version that has the new bootloader utility it will open up the configuration in nano for you. If you are on an older version it will give you an error (I can’t recall what the exact error was off the top of my head, but I got it before I did a dist-upgrade on an older version of Raspbian).

      It looks like the firmware that supports USB mass storage booting was made the default (critical) EEPROM image on 9/3/2020 according to the release notes here: If your Raspbian is up to date you should be good to go, but you can double check that your firmware is updated with:

      sudo rpi-eeprom-update

      and to install the updates (if they are available):

      sudo rpi-eeprom-update -a

      and reboot.

  19. Avatar for Jack

    This is my first jump into Raspberry PI. I am pretty excited to give this a go. Thank you for the post. I found you through Andreas Spiess.

Leave a Comment

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

Type here..