Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives

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

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

The Raspberry Pi 4 is finally here and has a lot of exciting changes. One very major downside is that it doesn’t support true USB booting yet out of the box (like the 3 series did). The Raspberry Pi foundation states that it is being worked on and will be added back with a future update. No timeline has been given yet for that to happen but they state it’s one of their top priorities.

Most of my projects heavily depend on having good performing storage so sitting and waiting was not an acceptable solution. In this guide I’ll show you a workaround to use USB devices as your rootfs device and use a Micro SD card as bootloader only which gives us full SSD performance after boot! To see exactly how much of a performance difference this makes (spoiler: it’s gigantic) check out the Raspberry Pi Storage Benchmarks.

I highly recommend doing this on a completely new install. If you try to upgrade your old ones and something goes wrong there’s a good chance you might lose data. We will be modifying the boot partition, resizing partitions, etc. so don’t use a drive with any data on it unless you are positive you have all of the steps down!

Compatible USB Adapters

The Raspberry Pi 4 is proving to be picky about what SATA, M.2, etc. adapters will work in the USB 3.0 port. The USB 3.0 ports are the ones in the middle that are blue inside. The black ones are USB 2.0 and won’t give you the faster speeds the new Pi offers.

It’s very likely that some of these will be fixed via software and firmware updates and the Raspberry Pi Foundation has several open known issues related to USB 3. Until that happens though I will maintain a list here of known working ones and known problematic ones. It’s still very early in the release of the Pi 4 so we still have a lot to learn about which adapters work / don’t work. If you have working and nonworking adapters leave a comment and I’ll add it in this list.

If the adapters worked before on older Pis then one thing you can try is putting them in the black USB 2.0 ports. Obviously this is stupid because we all want the Pi 4 performance gains but if you end up needing to buy a new adapter this will give you a workaround until a replacement arrives!

Find USB adapter chipset

There are certain chipsets used in adapters that are known to be working/not working.

pi@raspberrypi:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

This is a lsusb dump of all my connected USB devices. I have bolded the line with the USB bridge device. We can see that the chipset is ASM1153E

Known Good Chipsets

  • ASMedia ASM115X (StarTech 2.5″ SATA, UGREEN USB Enclosure, several others)

Known Working Adapters

StarTech 2.5″ SATA to USB 3.1 Adapter2.5″ SATA to USB 3.0Verified working in comments (thanks Fredrick)
StarTech 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.1Verified working great by myself and others on Pi 4
Orico Transparent 2.5″ SATA to USB 3.0 Enclosure2.5″ SATA to USB 3.1Confirmed working by Ashjas in comments
ELUTENG 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.0The ELUTENG is one of the known working 2.5″ SATA to USB 3.0 adapters for the Pi 4
CSL 2.5″ SATA to USB 3.0 Adapter2.5″ SATA to USB 3.0The CSL SL adapter is confirmed to be working by Krikitt in the comments. Available in Europe. Not available in US.
Shinestar NVME to USB 3.0 AdapterM.2 NVME to USB 3.0This is the adapter I’m using in the picture at the top of the article. It is for NVME M.2 drives only (need different one for M.2 SATA).
QNINE M.2 SATA to USB 3.0 EnclosureM.2 SATA to USB 3.0I used this enclosure to benchmark M.2 SATA Lite-On and SanDisk drives — working great in 3.0 ports.
UGREEN M.2 NVMe SSD Enclosure, USB C 3.1 Gen 2M.2 NVME to USB-C 3.1Confirmed working in comments by Chad D.
UGreen M.2 SATA to USB 3.1 EnclosureUGreen M.2 SATA to USB 3.1 EnclosureReported as working well in the comments by John H. Reinhardt with a ASM1051E chipset
Tanbin mSATA to USB AdaptermSATA to USB 3.0I used this mSATA to USB adapter for my Crucial M550 benchmark — working in 3.0 ports.
Generic mSATA to USB 3.0 Adapter (fe2008)mSATA to USB 3.1Confirmed working in comments by Nico
Canakit Raspberry Pi 4 Power Supply (USB-C)USB-C Power SupplyCanakit has been making very reliable power supplies for several Pi generations now

Known Problematic Adapters (VERY COMMON)

Fix (some) USB Adapter Problems Using Quirks

Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.

To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.

Find Your Adapter

To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:

$ sudo lsusb
 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.

If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:

sudo dmesg | grep usb

 [    0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
 [    0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 [    0.828597] usb usb3: Product: DWC OTG Controller
 [    0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
 [    0.828644] usb usb3: SerialNumber: fe980000.usb
 [    0.830051] usbcore: registered new interface driver uas
 [    0.830182] usbcore: registered new interface driver usb-storage
 [    0.836488] usbcore: registered new interface driver usbhid
 [    0.836511] usbhid: USB HID core driver
 [    0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
 [    1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
 [    1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
 [    1.154281] usb 1-1: Product: USB2.0 Hub
 [    1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
 [    1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
 [    1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 [    1.333026] usb 2-1: Product: ASM105x
 [    1.333048] usb 2-1: Manufacturer: ASMT
 [    1.333071] usb 2-1: SerialNumber: 123456789B79F

This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.

Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:

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

Our adapter’s ID is: 174c:55aa

Applying Quirks

To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt. Type:

sudo nano /boot/cmdline.txt

We are going to add the following entry into the very front of cmdline.txt:


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

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

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

Verifying Quirks

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

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

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

USB Boot Instructions

There are a lot of steps to follow to set everything up properly. If you make a mistake the first time don’t spend too much time trying to correct it or figure out what you did wrong. It’s usually faster to burn the images again and reconfigure again rather than try to figure out which step you might have made a typo on. It’s much easier the second time!

Prepare SD Card

Download the latest Raspbian release from https://www.raspberrypi.org/downloads/raspbian/. Both Lite or Desktop versions will work. Win32DiskImager (Windows) or balenaEtcher (Linux, Mac OS X, Windows) are highly recommended to burn the images.

Note: Don’t attempt to use raw dd commands to write the images. Too many silly things can go wrong that are checked for/fixed by the recommended programs. Do yourself a big favor and use one of the recommends to avoid spending a ton of time troubleshooting basic imaging problems!

Preparing SSD

We are going to burn a second identical copy of Raspbian to the SSD. This ensures everything the Pi needs to boot is there so we can use the SD card as a bootloader but our actual system will be on our nice fast SSD drive.

Note: Make sure you create the empty file named “ssh” on the boot partition of both drives if you are headless or don’t have a mouse/keyboard attached so you can ssh in on the first boot.

First Boot (SD card only, SSD unplugged)

Insert your freshly imaged SD card into the Pi and connect the power. Sign into the Pi for the first time.

Don’t do an apt-get upgrade/dist-upgrade or any additional configuration yet. Just stick with the instructions until we have finished configuration (especially since if something goes wrong you may have to start over and any other setup you did will be lost).

Once the Pi has finished booting and you have signed in for the first time plug in your SSD to your Pi’s USB 3.0 ports. The USB 3.0 ports are the ones that have the blue plastic inside instead of the black plastic (the black ones are USB 2.0 ports).


We need to change the PARTUUID of our SSD’s partitions so the Pi doesn’t get confused about what device to boot from. Right now the partitions on both the SD card and the SSD are an exact match and we need them to be different so we can tell the Pi to boot specifically from our SSD’s partition.

We are going to use fdisk to change the SSD’s PARTUUID to the hexadecimal d34db33f to make our SSD easy to identify. Use the following:

$ sudo fdisk /dev/sda

 Welcome to fdisk (util-linux 2.33.1).
 Changes will remain in memory only, until you decide to write them.
 Be careful before using the write command.
 Command (m for help): p
 Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
 Disk model: ASM105x
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0x6c586e13
 Device     Boot  Start       End   Sectors   Size Id Type
 /dev/sda1         8192    532479    524288   256M  c W95 FAT32 (LBA)
 /dev/sda2       532480 500118191 499585712 238.2G 83 Linux
 Command (m for help): x
 Expert command (m for help): i
 Enter the new disk identifier: 0xd34db33f
 Disk identifier changed from 0x6c586e13 to 0xd34db33f.
 Expert command (m for help): r
 Command (m for help): w
 The partition table has been altered.
 Syncing disks.

That’s it. Let’s verify our change using blkid:

$ sudo blkid

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="6c586e13-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="6c586e13-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="5203-DB74" TYPE="vfat" PARTUUID="d34db33f-01"
/dev/sda2: LABEL="rootfs" UUID="2ab3f8e1-7dc6-43f5-b0db-dd5759d51d4e" TYPE="ext4" PARTUUID="d34db33f-02"

Your /dev/mmcblk0 and /dev/sda devices should now be different from each other. The SD card’s ID is 6c586e13 and the SSD’s PARTUUID is now

Update /boot/cmdline.txt

We are going to change cmdline.txt to point to the SSD for booting instead of the SD card. First make a backup of your existing cmdline.txt file with the following command:

sudo cp /boot/cmdline.txt /boot/cmdline.txt.bak

We’ve now created a backup you can restore if something goes wrong. If you need to restore your backup plug the SD card into a computer/device and replace cmdline.txt with cmdline.txt.bak that we made above. Now your Pi should boot normally again.

Open up /boot/cmdline.txt using nano or your favorite text editor:

sudo nano /boot/cmdline.txt

The existing file will look like this:

console=serial0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

We are going to change the root=PARTUUID section to point to our new d34db33f PARTUUID like the following:

console=serial0,115200 console=tty1 root=PARTUUID=d34db33f-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

Make the change and double check the line is what it should be,then press Ctrl+X to save our changes.

Note: cmdline.txt should be one long solid line with no breaks — don’t add any line breaks or the system won’t boot and you’ll need to restore the backup we made earlier!

Test SSD

We are now ready to test booting from the SSD. Restart your Pi by issuing a

sudo reboot

The first boot with your SSD can be slow due to running fsck on the drive. If you have a really large SSD it can take surprisingly long to check all that space. Once the check completes it will mark the drive clean and skip the disk check from now on. It can take over a minute or two sometimes for really big drives so give it at least that much time before assuming it didn’t work.

After signing in we can verify that the SSD is being used like this:

$ findmnt -n -o SOURCE /


Verify that partition has switched over as shown below to /dev/sda2 (SSD) instead of /dev/mmcblk0p2 (SD card).

Update /etc/fstab

We are now ready to edit the /etc/fstab file to point to our updated drive. To edit the file type:

sudo nano /etc/fstab

Your current file will look like this:

$ cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=6c586e13-02  /               ext4    defaults,noatime  0       1
sudo nano /etc/fstab

Your current file will look similar to this (PARTUUID varies based on your Raspbian image version):

cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=6c586e13-02  /               ext4    defaults,noatime  0       1

We want to change the root ( / ) partition (PARTUUID ending with -02) to load our SSD’s PARTUUID instead of the SD card. Replace the 2nd partition’s PARTUUID field on the last line in the file with the d34db33f label we applied earlier with fdisk. After making the change my /etc/fstab file looks like this:

proc            /proc           proc    defaults          0       0
PARTUUID=6c586e13-01  /boot           vfat    defaults          0       2
PARTUUID=d34db33f-02  /               ext4    defaults,noatime  0       1

Press Ctrl+X to tell nano to save our changes. Now type sudo reboot to restart the Pi.

Note: We want to leave the first partition (https://origin.jamesachambers.com/boot) on the SD card. If you change this to the SSD then apt will update your SSD instead of the SD card so they won’t be used during boot! Remember that we are using the SD card as a bootloader and that is why the firmware updates (such as start.elf, etc) should go there instead of the SSD’s boot partition (which is never used).

Resizing Filesystem

By default the partition on the SSD / Flash drive will only be 1.8G. The Pi expands this automatically on micro SD drives but we will need to do it ourselves for a SSD / Flash drive. To do this we need to expand the partition and then resize the file system.

First let’s open fdisk and print the partitions:

pi@raspberrypi:~ $ sudo fdisk /dev/sda
 Welcome to fdisk (util-linux 2.33.1).
 Changes will remain in memory only, until you decide to write them.
 Be careful before using the write command.
 Command (m for help): p
 Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
 Disk model: ASM105x
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0xd34db33f
 Device     Boot  Start     End Sectors  Size Id Type
 /dev/sda1         8192  532479  524288  256M  c W95 FAT32 (LBA)
 /dev/sda2       532480 4390911 3858432  1.9G 83 Linux

There is the line we need. Our start value for /dev/sda2 (rootfs) is 532480. Next we need to remove and recreate the partition as a larger size.

If you make any mistakes during this command just close fdisk by pressing q. The changes won’t be written to disk. If you mess up any of the commands the drive will no longer boot and you’ll have to start over again so be careful!

Command (m for help): d
 Partition number (1,2, default 2): 2
 Partition 2 has been deleted.
 Command (m for help): n
 Partition type
    p   primary (1 primary, 0 extended, 3 free)
    e   extended (container for logical partitions)
 Select (default p): p
 Partition number (2-4, default 2): 2
 First sector (2048-500118191, default 2048): 532480
 Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-500118191, default 500118191): 500118191 
 Created a new partition 2 of type 'Linux' and of size 238.2 GiB.
 Partition #2 contains a ext4 signature.
 Do you want to remove the signature? [Y]es/[N]o: N
 Command (m for help): w
 The partition table has been altered.
 Syncing disks.

If everything went well then type “w” and press enter. Otherwise press “q” to quit and try again. Once you enter “w” the changes will be permanently written to disk!

Now reboot the system. Type “df -h” to view the current disk:

pi@raspberrypi:~ $ df -h
 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       1.8G  1.3G  415M  76% /
 devtmpfs        1.8G     0  1.8G   0% /dev
 tmpfs           2.0G     0  2.0G   0% /dev/shm
 tmpfs           2.0G  8.5M  1.9G   1% /run
 tmpfs           5.0M  4.0K  5.0M   1% /run/lock
 tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
 /dev/mmcblk0p1  253M   52M  201M  21% /boot
 tmpfs           391M     0  391M   0% /run/user/1000

We can see our disk is still 1.8G even after resizing the partition. That’s because we still have one more step! We need to resize the filesystem to fill our new partition space. For this we will use “sudo resize2fs /dev/sda2”:

sudo resize2fs /dev/sda2
 resize2fs 1.44.5 (15-Dec-2018)
 Filesystem at /dev/sda2 is mounted on /; on-line resizing required
 old_desc_blocks = 1, new_desc_blocks = 15
 The filesystem on /dev/sda2 is now 62448214 (4k) blocks long.

Now let’s check df -h again:

pi@raspberrypi:~ $ df -h
 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       235G  1.3G  224G   1% /
 devtmpfs        1.8G     0  1.8G   0% /dev
 tmpfs           2.0G     0  2.0G   0% /dev/shm
 tmpfs           2.0G  8.5M  1.9G   1% /run
 tmpfs           5.0M  4.0K  5.0M   1% /run/lock
 tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
 /dev/mmcblk0p1  253M   52M  201M  21% /boot
 tmpfs           391M     0  391M   0% /run/user/1000

And that’s it! You will now be using all of your space on your drive.

Update Pi using apt

Now that we’ve updated fstab it is safe (and highly recommended) to update your Pi’s software. Type “sudo apt-get update && sudo apt-get dist-upgrade” to update the system and firmware.

Your system will now be running completely from your USB drive! To verify this, run the command “findmnt -n -o SOURCE” / to ensure your root partition has switched over as shown below to /dev/sda2 instead of /dev/mmcblk0p2.

Verify SSD Performance

You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

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


The Samsung 950 Pro NVME drive in the featured picture scored a 9189 on the Raspberry Pi Storage Benchmark. The previous all-time record score on a Pi 3B+ was 3561. The performance gains are very real and very dramatic.

For me getting this performance is well worth having to waste a micro SD card just to be a bootloader. I am largely after the USB 3.0 bus and gigabit ethernet performance improvements and using this method I am able to achieve the performance I was after without waiting an indeterminate amount of time for the feature to be added back in!

Although there are ongoing compatibility issues and we lack the super easy native USB booting support we had before I’m more than willing to go through the growing pains to finally get rid that ancient USB 2.0 bus! Just make sure if you are planning to build a system you plan your adapters and parts accordingly.

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

  1. Avatar for Walter

    Hi Walter here, I am bad. I accidentally forgot the micro sd was also in the RPI 4.
    Right now without the micro sd neither enclosure boots with my ssd drive.
    I am going to reflash the ssd drive.

  2. Avatar for Walter

    Hi here is an update, I bought the ELUTENG ssd drive enclosure and put my Crucial SSD drive in it and my RPi 4 booted quickly.
    Comparing the ELUTENG and the Orico enclosures the components are in the same place the part numbers look identical. Besides the name being different the two enclosures look identical.
    I put my SSD drive back into the Orico and it now also boots quickly and all four restarts, warm and cold have been quick.
    I also ran the original drive cable with both enclosures.
    End result now both the ELUTENG and Orico enclosures allow quick booting now.
    Did running the straight sata to USB3 cable do something?

  3. Avatar for Luca

    I’m glad I found this page, I’ve been banging my head against a wall for a week now. I bought four different usb3 2.5″ enclosures and all have had their problems.

    I’d like to use my Samsung 850evo 1tb ssd with my pi400. Can you recommend a good enclosure, ideally UsbC-UsbA, fast, that works equally well on both Windows10 and the Pi400 using trim and uasp?

    Below my findings:
    Sabrent EC-UM30 and EC-UASP:
    Flashed both the latest Sabrent firmware on Windows, and also latest firmware as per https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931&start=50#p1570022.
    They don’t boot using usb3.0 on the pi400.
    They corrupt the image when used in conjunction with Win32DiskImager for writing .IMG files to the ssd.
    This results in a missing boot partition and difficulty in removing partitions using the Windows storage manager. Also ssd becomes too hot to the touch which is of course worrying.
    HOWEVER, the EC-UM30 has the fastest performance on Windows, it’s amazing, stable constant real 300Mb/s transfer read/write. Benchmark is 400+/400+ using CrystalDisk.

    UGREEN 2.5″ 3.1gen2 Metallic and plastic enclosures:
    They work OK on the pi400 as you can see: https://storage.jamesachambers.com/benchmark/36047
    HOWEVER, occasionally there seems to be a 20 seconds pause on the pi400 when copying files, or even when listing folder content. This worries me a bit but I can’t fully replicate it.
    On Windows both UGREEN enclosures are slower, and they drop down to 0.5/1Mb/s speeds once every 15 seconds. Speed oscillates regularly. Copying large images becomes impossible leading up to 14hours vs 50minutes using the Sabrent enclosures. Benchmark is 400/200 using CrystalDisk.

    Many thanks

    Also, could some of these issues be caused by the official Raspberry Pi4 5.1v 3A power adapter? Please note I only have the ssd via enclosure and logitech k400 dongle (usb2) attached to my pi400.

  4. Avatar for Walter

    Hi I also recent bought the ORICO 2.5″ USB 3.0 External Hard Drive Enclosure for 2.5 Inch SATA HDD from Amazon.ca https://www.amazon.ca/gp/product/B01LY97QE8/ref=as_li_ss_tl?ie=UTF8&psc=1&&linkCode=ll1&tag=codemallet08-20&linkId=5a6cf3f57d6586f544e29aa20ce399e7&language=en_CA
    Bought November 25, 2020

    Someone else commented this enclosure works.

    I am running this attached to Raspberry pi 4 B, 2 GB ram.
    It works, but incredibly slow. I takes about 4 minutes to boot, everything loads slowly, way slower then the micro-sd card.
    I am using a Crucial BX500 2.4 SSD 120GB. At first I thought I did the boot procedure wrong.
    I found this article about issues with some enclosures.
    I took the drive out of the ORICO enclosure and ran a straight sata to USB3 cable, I now get a 26 second boot time and a responsive system.

    1. Avatar for jamesachambers

      Hey Walter,

      Have you tried the quirks mode at the bottom of this article by chance? Sometimes it can clean up the performance in the case of buggy chipsets.

      You may also want to consider giving the beta firmware a try and see if the fixes which I covered more in depth in the comments of my most recent article here make any difference. I have some instructions on how to do that in this article if you’re interested.

      Note: I don’t recommend updating to beta firmware for most people unless you’re having specific issues that are addressed in those updates, otherwise just wait for it to come to stable to avoid potential headaches.

      I don’t own that adapter personally and my understanding is it has been working from the comments but depending on what you find and if we continue to see issues like this it may need to be moved to the danger zone section.

  5. Avatar for Rasmus

    Samsung EVO 860 250 GB in a Orico 2569S3 (Banggood) with ASM1153E controller works like a charm. No quirks. Benchmark score 7998. Sweet!

    The Orico 2139 with the Jmicron 578 of course doesn’t without setting the quirk flag. I tried a firmware upgrade but unfortunately flashed a wrong one which bricked it :-/

  6. Avatar for Robert W Flanagan

    I had no success booting from a pair of cheap adapters. I could transfer the OS using rpi-imager on my PC but no luck with booting. I then plugged in the adapters to a powered USB 3.0 hub and they worked great. I’m guessing there was a voltage drop across the adapter cable that was the problem.

  7. Avatar for Lipo

    Dears, I just got the working adapter here in Czechia from ITEC – U3MYSAFE025 for 2,5″ and it is absolutly different experience using the drive without qirks – it does not use a lot of cpu for drive operations. I can drain the cpu to 100% and still watch movies and play music without any stutters sound distortion. It has ASM115X . I especially thanks to the customer support of that company for letting me know which adapters has this chipset. They told me that also MYSAFE35U401 for 3,5 drives has this chipset. James, please add it to the list.

  8. Avatar for Doug Hadfield

    I can confirm that the Orico DOES NOT work in uasp mode with the RPi4 (and 400) – it uses the Jmicron chipset (as reported by lsusb). Using the “quirks” workaround to turn off uasp mode does enable the interface to boot, but at a lower speed (about half the speed of uasp mode). Plugging the adaptor into an already running pi (booted from another drive) does recognise the unit in uasp mode and it does work at full speed, but of course only as a second drive.

  9. Avatar for John Loop

    James, great article for details. Hoping I don’t need all that…….. explains what is going on!
    Confused here tho. I have a microSD [vilros or canakit standard pkg] with noobs on a pi4, and I installed raspian.
    I made changes to do the usb boot, and I have raspi-config changed to boot usb.
    I connected via usb 3 a 64GB Samsung SSD, and I used “disks” utility to erase partitions, so I have free space now on the SSD. I am attempting to “SD card copy” from the microSD to the SSD and am having trouble. It creates identical partitions, but never seems to be able to complete the copy. failures of one kind or another after “copying partition 1.”
    The partition 1 is “recovery” and is noobs I assume. The rest is an extended partition with partitions 5, 6 and 7 as “settings” “/boot” and “/” -not sure what “settings” is…….
    Does “noobs” get in the way of this?
    I am assuming a boot always goes thru the noobs “recovery” partition since it gives me the option to reinstall.
    I was able to mount the partitions on the SSD and see them [before I erased it all], so I presume the usb driver is working.
    Thanks for any help!

  10. Avatar for mkapsville

    Thank you for your guide. Unfortunately I´m running into problems.
    I can change partuuid but after updating my cmdline.txt the system wont reboot. Is it possible that my USB to SSD adapter is able to detect the SSD but is not able to boot from it?

    1. Avatar for Mark


      first off thank you for the article. I set up my pi 4 a while ago and it was working perfectly. But after the recent OS updates my sytem was shot. I was not able to boot normally. So I reset and followed your guide again. Now, I am having the same issue mkapsville is having: edited boot order. Now, it is not rebooting. No I/O LEDs blinking. I followed a different guide, which helped but my sequential read/write speeds dropped in half. Tested different adapters and M2s, same issue. Were there changes to newest Raspbian that might be causing problems?

      1. Avatar for jamesachambers

        Hey Mark,

        It definitely sounds like it has something to do with the new bootloader support. Edited boot order seems to point me toward this:


        There is a BOOT_ORDER field in the new bootloader. Depending on what this is set to it will attempt to boot from the SD card for 0x1, a USB device for 0x3, etc.

        This support is new from after I wrote this guide (it didn’t exist at the time). It looks like maybe it is coming out of beta here and being released to everybody possibly!

        It looks like the command to edit the bootloader is:

        sudo -E rpi-eeprom-config --edit

        This will only work if your system is fully patched and up to date it looks like but you can see the options here:


        It looks like it is time for me to write the guide for the new bootloader here, but give editing the BOOT_ORDER field in there a try (0x4 for a USB mass storage device, other choices are in the link earlier in the post) and see if it works for you!

        UPDATE: New guide posted here: https://jamesachambers.com/new-raspberry-pi-4-bootloader-usb-network-boot-guide/

        1. Avatar for Mark

          Hi, jamesachambers,

          Thank you for the quick reply! Yeah, updates seemed to have rolled September which is right around the time I started having this issue. Right now I basically just reimaged my m2 ssd with the raspian imager using the newest OS build, enabled headless ssh mode, and plugged the ssd into one of the usb3 ports – no SD card involved. Works fine: I can restart, run updates etc. but I am only downloading with 29MBs/sec whereas before I was hitting 50MBs/sec. I ruled out my ISP and other potential bottlenecks (I have a 500mbit connection which I am fully getting on other devices).

          I will backup my current setup and test your guide. Thank you again!


          1. Avatar for Mark

            So, I realized changing the boot order does not really help since I reset everthing and I am already able to to boot from usb port. Still do not know why my download speed is so slow though. Basically cannot use my pi as my download manager anymore.

            1. Avatar for jamesachambers

              Hey Mark,

              You said this drive had recently been reimaged. Have you ran the ‘trim’ command on the drive? This may be a bit of a long shot but during my storage testing I’ve noticed this sometimes. Trim will tell the drive to actually drop all data marked for deletion/no longer used from the device. You can try it with:

              sudo fstrim -av

              This keeps the SSD from having to write over this old data (which takes time). When you reimage a drive the entire old image is still left on there until the trim command is run. If you want to understand more there’s a pretty good writeup of SSDs and trim here.

              After this give the device a reboot and try running your test again. You may also want to consider running my storage benchmark on it. This tests your drive’s speed using standard benchmarking tools/techniques and returns a score that we can easily compare against other submissions with the same drive. We can also look at the raw numbers and see where it’s struggling (things like random IO performance vs read / write performance, etc). It’s very likely other people have tested your same drive or one very similar we can compare it to!

              There are some storage adapters and even SSDs that don’t support trim out there but they’re all older. If you’re using a modern one it should be able to do it! Adapter quality can also impact performance but if you’re comparing performance to how it was from before the updates it doesn’t make sense that the adapter would be the cause in this case.

              I know your overall concern is network download performance but on the Pi a lot of the busses/lanes that carry this data are shared between the different components so it definitely can matter! At least on the Pi 4 they finally separated the ethernet from the main USB bus, but even so storage is still very likely to be the bottleneck here.

              If you have any additional drives you can image and run the same network test on this would narrow things down. What download rate do you get with a standard SD card for example would be a good thing to check. It could definitely end up being related to a package or a change in one of the updates in which case you should see the same slowdown on anything running the latest version.

              1. Avatar for Mark


                I am actually getting decent download speeds (300-350mbits) running speedtest-cli via terminal but big spikes.
                I have also been using your benchmark tool and my score is close to 7000 on average so those parameters look fine.
                I am using JDownloader as my main download tool which downloads to my DS413j. I ruled out my NAS as well by using a download folder on my pi as the destination. Maybe it is related to the JDownloader’s recent updates and its terrible Java code base…
                I have not found an alternative for Raspbian though which supports filehosters, etc. My pi is passively cooled and remains under 70 degrees Celcius under heavy load so CPU/GPU throttling should not be it. Also thank you for the trim tip. Just ran your cmd. Here are my most recent raw stats.

                HDParm Disk Read 293.52 MB/s
                HDParm Cached Disk Read 278.41 MB/s
                DD Disk Write 169 MB/s
                FIO 4k random read 16370 IOPS (65483 KB/s)
                FIO 4k random write 7981 IOPS (31925 KB/s)
                IOZone 4k read 28309 KB/s
                IOZone 4k write 23576 KB/s
                IOZone 4k random read 17552 KB/s
                IOZone 4k random write 24261 KB/s

                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 15.632 ms
                Download: 245.66 Mbit/s
                Upload: 49.73 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 14.072 ms
                Download: 299.02 Mbit/s
                Upload: 49.33 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 13.416 ms
                Download: 241.75 Mbit/s
                Upload: 49.16 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 13.121 ms
                Download: 224.04 Mbit/s
                Upload: 49.46 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 13.606 ms
                Download: 343.81 Mbit/s
                Upload: 49.51 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 12.783 ms
                Download: 213.43 Mbit/s
                Upload: 50.43 Mbit/s
                @raspberrypi:~ $ speedtest-cli –simple
                Ping: 13.454 ms
                Download: 425.74 Mbit/s
                Upload: 49.09 Mbit/s

                I tested a brand new WD Blue SN550 250 GB NVMe SSD in a UGREEN SSD M.2 NVMe enclosure. Same behavior.

                1. Avatar for jamesachambers

                  Hey Mark,

                  I definitely see it fluctuating there. I gave it a few runs on my Pi and it chose different servers a couple of times. Here’s what mine looked like:

                  Hosted by Think Smart Inc 7.558 ms
                  Download: 341.58 Mbit/s
                  Upload: 372.93 Mbit/s
                  Hosted by UTOPIA Fiber 5.288 ms
                  Download: 342.06 Mbit/s
                  Upload: 364.29 Mbit/s
                  Hosted by UTOPIA Fiber 5.757 ms
                  Download: 338.92 Mbit/s
                  Upload: 330.31 Mbit/s

                  So it looks like it can fluctuate but not usually by that much. Are you wired in or using wireless? Do you have access to another internet connection or network like at work / friend / family you could take it to and run this same test to see if you see the same type of network fluctuations?

                  It’s also possible it’s Java related. Have you tried it on the 64 bit Raspbian beta? That would run on a 64 bit Java Virtual Machine which can definitely benefit some applications. It can also be worse in some cases since it typically uses a little more memory so it’s good for 8 GB Pis but not so good for smaller capacities.

                  It definitely seems like there is some sort of network performance issue going on from your speedtest-cli numbers though!

                  1. Avatar for Mark

                    I am wired directly into my WIFI Router (1Gbit). I only have the 4GB RAM Version and do not want to deal with Betas. I will double check my basic troubleshooting steps (reboot router, check cables, try different ethernet ports, maybe even try over wireless since my Pi sits next to the router, etc.)

                    Are there any JDownloader alternatives that you know of?

                    1. Avatar for jamesachambers

                      Hey Mark,

                      I’ll be honest and say I’m not super familiar with JDownloader itself. I have definitely had a ton of run-ins with Java and the JDK over the years via my Minecraft Pi server script.

                      I think you are on the right track troubleshooting and narrowing things down as much as possible. These types of issues can be really difficult to diagnose because something like network transfer speed has so many underlying pieces to it that have to all work together to achieve maximum speeds.

                      I would keep looking for alternatives if possible just as a comparison and keep trying to test different variables. I think you’re getting close here!

  11. Avatar for Jan

    I wonder a bit about that you seem to have posted your very good article on 19th of october this year while other sources stated about a month before that USB bootloading with the PI4 is officially supported from bootloader Version 2020-09-03?
    Apart from that your list of working/nonworking adapters is highly useful of course.
    Regards, jan

    1. Avatar for jamesachambers

      Hey Jan,

      Sorry, that’s because it’s showing when it was last updated and that was the last time it updated the list. It’s on my to-do list to add the original published date below it but haven’t got to it yet, but you’re quite right! Thanks for the kind words on the article!

  12. Avatar for Andrew G

    I bought 4 Eluteng USB SATA adaptors from Amazon and they all worked perfectly. However I recently purchased one more of the same Eluteng adaptors from Amazon and this one didn’t work. It should have been exactly the same item, but closer inspection shows the USB A connector is moulded differently from the pictures of the Eluteng adaptor, and on the rear of the SATA connector the Eluteng label is applied with a sticker.

    The proper ones that work report from `lsusb` that they use the ASMedia/ASM chipset, the so-called Eluteng adaptor that doesn’t work shows it’s got a JMicron chipset. It’s worth double-checking what you receive, either Eluteng have gone cheap(?) with their adaptors or there are cheap knock-offs being sold as Eluteng adaptors.

    1. Avatar for Teleportist

      Thank you Andrew.

      It seems this was the issue. So please beware all that there are ‘dodgy’ Eluteng adapters in circulation.

      Today My Kingspec SSD arrived. This works perfectly on USB3.

      1. Avatar for jamesachambers

        Wow, thanks for the update Teleportist!

        I know I’ve seen different variations of models out there of many of these mass produced super cheap adapters. Sometimes the same product can even have different chipsets in some cases. There will also be variants for USB 3.0 and then a new one for USB 3.1 (which is the case with the Eluteng line, there’s a 3.0 and 3.1 variant of the transparent clear case that is really popular).

        Aside from all that, there’s also some that just fail (or were maybe always defective from right when they were manufactured). I almost like to have a couple of each model around so that if I’m having trouble I can test it with the other one to narrow things down via troubleshooting. Often when you grab these on sale they can be cheap enough that getting a couple is still extremely cheap.

        Thanks for giving the update. If we start to see more people seeing this I’ll update the list and post a warning.

  13. Avatar for Teleportist

    So I have the RPi 4B (4GB) booting Home Assistant Development Build 5.3 (hassos_rpi4-64-5.3.img.gz) when connected to one of the USB 2 ports.
    But when I plug it in to to a USB 3.0 if fails.

    From reading the above, I assumed it was the Sabrent SSD Interface I was using.

    So I swapped this out for the above recommended Eluteng cable. But this hasn’t fixed the issue.

    As my SSD is a Kingston A400, which appears on the benchmark list, so should be compatible, I’m at a total loss as to why this isn’t working.

    Any suggestions much appreciated, thanks.

  14. Avatar for Bota

    I have a Vektor 2.5″ HDD External Enclosure USB3.0 to Sata VK-UB12 (GD25603) and without the quirks doesn’t work 🙁
    The chipset is a JMS567 SATA 6Gb/s bridge (ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp.)
    I have tried an M.2 to USB3 enclosure always with a chipset from JMicron Technology and this also doesn’t work

  15. Avatar for Rob Bohn

    The release notes for Ubuntu 20.10 (Groovy Gorilla) says it can boot directly from the USB-attached disk:

    “With the removal of U-Boot from the default boot process, USB and network boot is now enabled on all Pi models via the same procedure as Raspbian 20. U-Boot will remain as an option this cycle (it is still installed on the boot partition and can still be selected with config.txt options) but is considered deprecated.”

    Has anyone had a chance to try this out yet? I currently use 20.04 with an SD card for the boot and an SSD for the rest, and the current workarounds for USB-boot only are tedious with the need to manually intervene each update to decompress vmlinuz etc. etc.

    1. Avatar for Rob Bohn

      Quick note: I’ve got Ubuntu 20.10 booting directly from a USB SSD on two out of three RPI4s; still deciphering the issue on the third (boot loop).

  16. Avatar for Chad Dankbutt

    After some confusion on my part, I can confirm Model Number 60354 of “UGREEN M.2 NVMe SSD Enclosure, USB C 3.1 Gen 2 to M-Key M&B-Key NVMe PCIe 10Gbps External Enclosure Thunderbolt 3 Compatible with MacBook Pro, WD, Samsung, Toshiba, 2230/2242/2260/2280 NVMe PCIe SSD” on Amazon works great with the Samsung 970 Evo Plus NVMe M.2.

    Important though, the enclosure comes with a type C-type C cable so you will need a GOOD USB cable to function well.

    If you have an existing SD card and a Windows PC, my suggestion would be to pop out the card clone the card as a .img file with Win32 Disk Imager and then flash to your drive with Balena Etcher. It booted just fine from that point.

    1. Avatar for smmi

      unless amazon is incorrect (not unheard of) – fix your quoted “Wrong” part number typo (above) for those reading, please…

      UGREEN Model Number 60355=M.2 SATA NGFF SSD @ $19.99 w/USB A to C cable -USB 3.0 -> (NOT for NVMe)… ASIN B07NPG5H83


      in amazon’s description, it points to a newer item which is the correct part number for your description (see below)…

      UGREEN Model Number 60354=M.2 NVMe SSD Enclosure @ $35.99 – w/USB C to C cable – USB 3.1 gen2 -> (for NVMe)… ASIN B07NPFV21K


  17. Avatar for Chad

    Hmmm, I’m trying the newer Ugreen adapter for use with a Samsung Pro 970- https://www.amazon.com/gp/product/B07NPFV21K/ref=as_li_ss_tl?ie=UTF8&psc=1&redirect=true&ref_=nav_ya_signin&&linkCode=ll1&tag=codemallet-20&linkId=d2142a809857056611cd4c949b12692f&language=en_US

    I get just 32 MiB read and write, tried USB quirks, nothing seems to change.

    [ 1.198192] scsi host0: usb-storage 2-2:1.0
    [ 1.334785] usb 1-1.1: new high-speed USB device number 3 using xhci_hcd
    [ 1.527032] usb 1-1.1: New USB device found, idVendor=174c, idProduct=2362, bcdDevice= 1.00
    [ 1.527041] usb 1-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
    [ 1.527047] usb 1-1.1: Product: Ugreen Storage Device
    [ 1.527053] usb 1-1.1: Manufacturer: Ugreen
    [ 1.527059] usb 1-1.1: SerialNumber: S59BNS0N709653Y

    Is it supposed to identify as USB 1-1.1?

    Here’s lsusb
    Bus 002 Device 002: ID 1058:25a3 Western Digital Technologies, Inc. Elements Desktop (WDBWLG)
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 003: ID 174c:2362 ASMedia Technology Inc.
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    I’m guessing I’ll need to switch the adapter, I’ll try a different cable and see what happens

    1. Avatar for Chucks

      Alright! It was the cable. This Ugreen adapter works with the Samsung Pro 970- https://www.amazon.com/gp/product/B07NPFV21K/ref=as_li_ss_tl?ie=UTF8&psc=1&redirect=true&ref_=nav_ya_signin&&linkCode=ll1&tag=codemallet-20&linkId=d2142a809857056611cd4c949b12692f&language=en_US. The included cable is a type C to type C, so you’ll need to supply your own type C to type A USB cable. And it’s got to be a decent one. My first cable gave 32 MB/32 MB read write, the second one powered the drive but it wasn’t recognized, third one was nice and thick and labeled blue for USB 3.0, got 198 MB/s write 276 MB/s write

  18. Avatar for Richard

    I have tested on my Raspberry Pi 4 an ORICO / NVME M.2 SSD Enclosure / Model PRM2-C3 / USB3.1 Type-C as a new boot device.

    If I boot for the first time with the latest raspbian release 2020-08-20, the system will start as expected. After doing the initialisation (country, network, etc.) and finally reboot, the system does not start again. Disk is still blinking and getting hot.

    Raspberry: Pi 4 – 4 GB
    bootloader: c305221a Sep 3 2020
    config: a9c83900

    Is there any hint available to overcome this problem? Many thanks for a sugestion.


  19. Avatar for Pearl.852

    I confirm that the Ugreen 50743, a 2.5-inch Hard Drive Enclosure with USB-C Port, uses ASM1153E SoC is working great with Samsung 860 EVO 500GB SSD on Raspberry Pi 4B running RPi OS with Linux kernel 4.19.
    $ lsusb
    Bus 002 Device 003: 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
    Taobao for ¥69.00 (US$10.25)
    Amazon for US$16.99

    1. Avatar for Luca

      I have both the same enclosure and 70498 which is the same with aluminum exterior and both work well. Could you kindly check what transfer speeds you’re getting are under Windows10 and usb3? In my case speed oscillates from 200Mb/s down to 0.9Mb/s every 15 seconds, resulting in very slow speeds when copying large files.
      Speeds on the pi400 are better, luckily.

  20. Avatar for Aaje

    I should have checked here before buying an orico case from amazon.. Indeed does not work. Just ordered a UGreen cable with ASM chipset, so hope to have more luck.

  21. Avatar for dgd

    pi os ubuntu should work out of the box. I have one case bought on special from amazon . No uas support and would not boot pi 3, pi 3b+ or pi4 until I applied the usb-storage.quirks=174c:55aa:u to the beging of cmdline.txt. In artical above. PI 4 load new image to sd and in terminal run
    sudo apt-get update && sudo apt-get full-upgrade -y and reboot.
    The sd will become your backup, PLUG YOUR USB OR SSD.
    Open up the menu and click no Accessories/SD card Copier
    Select your drives “Click on down arrow in box”
    Top box is your “SD card”
    Bottom box is “USB or SSD”
    Tick the box under neath beside the text “New Partition UUID”
    Click no “Start”
    When complete “exit and shutdown”
    Remove SD and Restart
    should start resize drive and reboot.
    If not apply the usb-storage.quirks=xxxx:xxxx:u to the begging of cmdline.txt. In artical above.

Leave a Reply to IanMcNeilly Cancel Reply

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

Type here..