
The new Raspberry Pi bootloader is out which makes these instructions only necessary if you want to continue to use the SD card as a bootloader. Check out the new Raspberry Pi Bootloader Configuration Guide here to enable native USB booting support!
The Raspberry Pi 4* is finally here and has a lot of exciting changes. One very major downside is that it doesn’t support true USB booting yet out of the box (like the 3 series did). The Raspberry Pi foundation states that it is being worked on and will be added back with a future update. No timeline has been given yet for that to happen but they state it’s one of their top priorities.
Most of my projects heavily depend on having good performing storage so sitting and waiting was not an acceptable solution. In this guide I’ll show you a workaround to use USB devices as your rootfs device and use a Micro SD card as bootloader only which gives us full SSD performance after boot! To see exactly how much of a performance difference this makes (spoiler: it’s gigantic) check out the Raspberry Pi Storage Benchmarks.
I highly recommend doing this on a completely new install. If you try to upgrade your old ones and something goes wrong there’s a good chance you might lose data. We will be modifying the boot partition, resizing partitions, etc. so don’t use a drive with any data on it unless you are positive you have all of the steps down!
Compatible USB Adapters
The Raspberry Pi 4 is proving to be picky about what SATA, M.2, etc. adapters will work in the USB 3.0 port. The USB 3.0 ports are the ones in the middle that are blue inside. The black ones are USB 2.0 and won’t give you the faster speeds the new Pi offers.
It’s very likely that some of these will be fixed via software and firmware updates and the Raspberry Pi Foundation has several open known issues related to USB 3. Until that happens though I will maintain a list here of known working ones and known problematic ones. It’s still very early in the release of the Pi 4 so we still have a lot to learn about which adapters work / don’t work. If you have working and nonworking adapters leave a comment and I’ll add it in this list.
If the adapters worked before on older Pis then one thing you can try is putting them in the black USB 2.0 ports. Obviously this is stupid because we all want the Pi 4 performance gains but if you end up needing to buy a new adapter this will give you a workaround until a replacement arrives!
Find USB adapter chipset
There are certain chipsets used in adapters that are known to be working/not working.
pi@raspberrypi:~ $ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This is a lsusb dump of all my connected USB devices. I have bolded the line with the USB bridge device. We can see that the chipset is ASM1153E. This is a really common one that works well with the Pi.
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 newer guide that utilizes the new Raspberry Pi 4’s native bootloader for USB booting.
StarTech 2.5″ SATA to USB 3.1 Adapter* | 2.5″ SATA to USB 3.0 | Verified working in comments (thanks Fredrick) |
StarTech 2.5″ SATA to USB 3.0 Adapter* | 2.5″ SATA to USB 3.1 | Verified 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.0 | Mirco reports that this enclosure is working but trim is not supported |
Samsung 2.5″ SATA to USB 850 EVO Kit /w Adapter* (Alternate amazon.de link*) | 2.5″ SATA to USB 3.0 Kit | This 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.0 | The 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.1 | Confirmed to be working by CAProjects in the comments. Available in both Europe and US |
SABRENT 2.5″ SATA to USB-C 3.1 Type A Adapter* | 2.5″ SATA to USB-C 3.1 Type A | The new USB-C 3.1 Type A version of the Sabrent adapter is reported as working in the comments by UEF. DO NOT get the USB 3.0 version as that one is below on the naughty list and won’t work! |
ICY BOX M.2 NVMe (M Key) to USB-C 3.1 Gen 2 Enclosure* (Alternate amazon.de listing*) | M.2 NVME M Key to USB-C Gen 2 | Returning legendary commentary Frank Meyer reports: Does not work with a 3.0A power adapter (also reported by TTE). It’s not enough power for this enclosure. Does work with a powered USB hub*. 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 2 | Confirmed to be working well by WorkHard in the comments |
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 2 | Brian 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)* | NVME to USB 3.1 Gen 2 | M.Yusuf has given the first ever report of a working Orico adapter! Make sure it’s the USB 3.1 Gen 2 version that says “Support UASP for NVMe SSD”. This is the way. |
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 2 | Andreas 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.0 | This 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 2 | Confirmed 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 Enclosure | Reported 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.0 | I 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 Case | This 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.0 | I 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.1 | Confirmed working in comments by Nico |
Canakit Raspberry Pi 4 Power Supply (USB-C)* | 3.5A USB-C Power Supply | Canakit has been making very reliable power supplies for several Pi generations now. Using a 3.5A power supply will give enough extra power for your Pi to power the drive without causing instability |
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 2 | Lee 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.0 | Reporting 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.0 | Only works in the USB 2.0 ports. Will not boot in a USB 3.0 port. I have two of these and can confirm they don’t work. RIP to Sabrent, our previous king of the Pi 3 era of adapters. |
ELUTENG 2.5″ SATA to USB 3.0 Adapter* | 2.5″ SATA to USB 3.0 | Despite earlier reports as working Ryan and one other have reported this adapter does not work unless you enable quirks mode! Don’t make Ryan’s sacrifice in vain and avoid this one. |
USB 3.0 to 2.5″ SATA III Hard Drive Adapter UASP Support-20cm, Black* | 2.5″ SATA to USB 3.0 | reported 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.0 | Several 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.0 | Commenters 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 1 | Confirmed 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.0 | Does 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.
Recommendations
StarTech 2.5″ SATA to USB Adapter *-AND- Kingston A400 SSD 120GB SATA 3 2.5” Solid State Drive*
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*
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
Known Working Adapters
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:
usb-storage.quirks=XXXX:XXXX:u
In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):
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).
Change PARTUUID
We need to change the PARTUUID of our SSD’s partitions so the Pi doesn’t get confused about what device to boot from. Right now the partitions on both the SD card and the SSD are an exact match and we need them to be different so we can tell the Pi to boot specifically from our SSD’s partition.
We are going to use fdisk to change the SSD’s PARTUUID to the hexadecimal d34db33f to make our SSD easy to identify. Use the following:
$ sudo fdisk /dev/sda Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors Disk model: ASM105x Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x6c586e13 Device Boot Start End Sectors Size Id Type /dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA) /dev/sda2 532480 500118191 499585712 238.2G 83 Linux Command (m for help): x Expert command (m for help): i Enter the new disk identifier: 0xd34db33f Disk identifier changed from 0x6c586e13 to 0xd34db33f. Expert command (m for help): r Command (m for help): w The partition table has been altered. Syncing disks.
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 / /dev/sda2
Verify that partition has switched over as shown below to /dev/sda2 (SSD) instead of /dev/mmcblk0p2 (SD card).
Update /etc/fstab
We are now ready to edit the /etc/fstab file to point to our updated drive. To edit the file type:
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 (/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!
Conclusion
The Samsung 950 Pro NVMe drive in the featured picture scored a 9189 on the Raspberry Pi Storage Benchmark. The previous all-time record score on a Pi 3B+ was 3561. The performance gains are very real and very dramatic.
For me getting this performance is well worth having to waste a micro SD card just to be a bootloader. I am largely after the USB 3.0 bus and gigabit ethernet performance improvements and using this method I am able to achieve the performance I was after without waiting an indeterminate amount of time for the feature to be added back in!
Although there are ongoing compatibility issues and we lack the super easy native USB booting support we had before I’m more than willing to go through the growing pains to finally get rid that ancient USB 2.0 bus! Just make sure if you are planning to build a system you plan your adapters and parts accordingly.
This is fantastic work James, permitting the full power of Raspberry Pi 4 to be unleashed!
The adapter 152d:0759 (“Vendor” JMicron – maybe successor to the 0758?) seems to require the usb-storage.quirks as well; highly unstable behaviour observed otherwise.
Tested with 4 different Raspberry 4B under EEPROM 137ab and buster lite from 2020-02-13 with 4 different Intenso Portable SSD Premium 128GB.
sorry… 152d:0579 (152d:0578 resp) are the correct numbers
I have used this type nvme to usb3: SSK SHE-C325 M.2(NVMe) to type-C3.1
https://item.jd.com/100004180899.html
and “Western Digital SN520 NVMe SSD”
and I have ported my existed raspberry pi os and data to my SSD as these steps:
0. connect usb ssd device to Pi4, using ‘lsusb’ and ‘sudo fdisk -l’ to confirm device connected and status is ok;
1. remote login Pi4 GUI Desktop using MS Remote Desktop;
2. open left/top corner menu item: Accessories-> SD Card Copier;
3. select “mmlblk0(SD Card)” as “Copy From Device”, select “SSK SSK Storage(/dev/sda)” as “Copy To Device”, check “New Partition UUIDs”, click “Start”;
4. after copying finished, open terminal, do following:
cd /boot
cp cmdline.txt cmdline.txt.bak
vi cmdline.txt
modify value of “root=PARTUUID” to
mount SSD root PARTITION to some directory, and modify SSD’s etc/fstab, change /boot PARTUUID to SDCard’s boot partition’s PARTUUID
reboot
5. run storage.sh to test performace of SSD by usb3.
Performace Test Result:
Description: Western Digital SN520 NVMe SSD on Pi 4 using JMicron SATA to USB adapter on SSK SHE-C325 M.2(NVMe) to type-C3.1
Category Test Result
HDParm Disk Read 280.76 MB/s
HDParm Cached Disk Read 283.80 MB/s
DD Disk Write 192 MB/s
FIO 4k random read 15729 IOPS (62918 KB/s)
FIO 4k random write 8228 IOPS (32912 KB/s)
IOZone 4k read 31675 KB/s
IOZone 4k write 28058 KB/s
IOZone 4k random read 23987 KB/s
IOZone 4k random write 34455 KB/s
Score: 8420
Finally my BlitzWolf BW-SSD1 128GB arrived from China. Coupled it with a Genesys Logic, Inc. GL3310 SATA 3Gb/s Bridge Controller I had laying around to attach it to my Raspberry Pi 4 4GB. Score is 5.619. Happy with it 🙂
Oh Thanks! Working on a Gearbest no label USB 3.0 USB with JMicron Technology Corp. JMS567 SATA ID “152d:0578” quirk. Thank you so much. I looked for the product but it is now discontinued. Great content.
I installed official ubuntu server 64 bit on my pi. there is no config for ssd boot. just burn same image both sd and ssd and plug in them to pi and turn on pi, thats all. I think if ubuntu detects bootable ssd pluged to the pi, it is automaticly booting from ssd. it choose boot partition from label named “writeable”. I also changed sd cards boot partition label from writeable to ubuntu and reboot again, whola, everything is working perfect. so I can be sure it boots from ssd.
Just tested a cheap SSD Hoodisk HDSSLSB-064GBX, which I bought from China’s well-known online flea market Xianyu.
Using a JEYI M.2 2242 SATA to USB adapter, the result looks pretty good, even though I know this SSD is made by an unknown manufacturer with unknown NAND chips.
Category Test Result
HDParm Disk Read 328.58 MB/s
HDParm Cached Disk Read 234.52 MB/s
DD Disk Write 147 MB/s
FIO 4k random read 25632 IOPS (102528 KB/s)
FIO 4k random write 11709 IOPS (46838 KB/s)
IOZone 4k read 35480 KB/s
IOZone 4k write 27050 KB/s
IOZone 4k random read 21428 KB/s
IOZone 4k random write 29538 KB/s
Score: 8137
HI,
First of all, thank you very much for your tutorials, which are very usefull and comprehensive for most of us.
I did this tutorial month ago without problem till today :
I did update and upgrade as i do regularly but my Raspberry Pi didn’t reboot.
From this update, I saw that they was eeprom update and other files, i haven’t done any update since one and half month. I just say that because i haven’t had any problem with previous update, so it may be the cause of my problem.
Nevermind, I searched explanation from partuuid of the ssd, from fstab or cmd.txt, and i tried a lot of combination of configuration, without result. I decided to restart everything from the beginning, three times, but failed.
So, i decided to use my SD card only, without my ssd. Then, i did update and upgrade (from SD card) without problem.
At this step, i tried to do a clone of my SD card to my SSD (MAC OS : dd command) and i followed the tutorial as mentioned above from the step “Change PARTUUID” and it worked ! My Raspberry pi (re)boot from SSD !
So it may help to update/upgrade from SD card only, and then do a clone SD card to SSD and change cmd.txt and fstab.
Thank you
I had the same issue. I change the PARTUUID and after reboot : “connection refused”
my steps :
– installation of Rasbian on the SD card
– sudo apt-get update
– sudo apt-get upgrade -y
– sudo apt-get dist-upgrade -y
– ssh file on the sd card
– cloning of SSD with the SD image (thanks to ApplePiBaker for Mac Os)
– and for the rest, I followed the tutorial from “Change PARTUUID”
If you get the “permission denied” error when you try to SSH into your Pi after the step “Test SSD”:
The /boot/ssh file is automatically deleted from the SD card (but is left intact on the SSD) when you changed the PARTUUID or edited the /boot/commandline.txt
1. Remove the SD card from your Pi and insert it in your computer.
2. Then create the /boot/ssh file again like you did after you flashed Raspbian for the first time.
3. Safely unmount the SD card and reinsert it in the Pi.
4. You should now again be able to SSH into the Pi without the “permission denied” error.
I had the same problem. Thank you!
I bought a ugreen usb 3.1 hdd enclosure. it’s working flawlessly. before I had a noname usb 3.0 to sata cable but with this cable ssd was booting normally then it hangs for a while booting and some services won’t start because of timeout. you can find out ugreen usb 3.1 device scores at https://storage.jamesachambers.com by user murdocklawless.
I have tested some adapters I had lying around my place with my Raspberry Pi 4B (4GB). None of them worked with the native drivers, so I activated quirks and performed a benchmark using the instructions above. Forgot to copy the score but maybe this is of some use for somebody.
Manufacturer: Orico (Quirks: 0080:a001)
Category Test Result
HDParm Disk Read 197.86 MB/s
HDParm Cached Disk Read 195.73 MB/s
DD Disk Write 174 MB/s
FIO 4k random read 5209 IOPS (20839 KB/s)
FIO 4k random write 6692 IOPS (26771 KB/s)
IOZone 4k read 24278 KB/s
IOZone 4k write 21385 KB/s
IOZone 4k random read 19478 KB/s
IOZone 4k random write 23147 KB/s
Manufacturer: Crucial (Quirks 174c:1153)
Category Test Result
HDParm Disk Read 145.83 MB/s
HDParm Cached Disk Read 147.85 MB/s
DD Disk Write 153 MB/s
FIO 4k random read 4432 IOPS (17731 KB/s)
FIO 4k random write 6580 IOPS (26323 KB/s)
IOZone 4k read 22792 KB/s
IOZone 4k write 20836 KB/s
IOZone 4k random read 16040 KB/s
IOZone 4k random write 22369 KB/s
Manufacturer: Sabrent (Quirks: 152d:1561)
Category Test Result
HDParm Disk Read 163.79 MB/s
HDParm Cached Disk Read 164.98 MB/s
DD Disk Write 168 MB/s
FIO 4k random read 5147 IOPS (20588 KB/s)
FIO 4k random write 6610 IOPS (26442 KB/s)
IOZone 4k read 27974 KB/s
IOZone 4k write 24218 KB/s
IOZone 4k random read 19637 KB/s
IOZone 4k random write 22109 KB/s
Manufacturer: Salcar (Quirks: 152d:0578)
Category Test Result (RUN 1) Category Test Result (RUN 2)
HDParm Disk Read 189.64 MB/s HDParm Disk Read 163.48 MB/s
HDParm Cached Disk Read 165.84 MB/s HDParm Cached Disk Read 163.32 MB/s
DD Disk Write 166 MB/s DD Disk Write 191 MB/s
FIO 4k random read 5644 IOPS (22579 KB/s) FIO 4k random read 5130 IOPS (20521 KB/s)
FIO 4k random write 6587 IOPS (26349 KB/s) FIO 4k random write 6543 IOPS (26172 KB/s)
IOZone 4k read 24014 KB/s IOZone 4k read 27844 KB/s
IOZone 4k write 20748 KB/s IOZone 4k write 24184 KB/s
IOZone 4k random read 19307 KB/s IOZone 4k random read 19652 KB/s
IOZone 4k random write 22381 KB/s IOZone 4k random write 22136 KB/s
after reboot, it’s saying connection refused while making ssh from putty. I put empty ssh file both sd and ssd.
If you get the “permission denied” error when you try to SSH into your Pi after the step “Test SSD”:
The /boot/ssh file is automatically deleted from the SD card (but is left intact on the SSD) when you changed the PARTUUID or edited the /boot/commandline.txt
1. Remove the SD card from your Pi and insert it in your computer.
2. Then create the /boot/ssh file again like you did after you flashed Raspbian for the first time.
3. Safely unmount the SD card and reinsert it in the Pi.
4. You should now again be able to SSH into the Pi without the “permission denied” error.
I spend several hours because of the same issue – repeating the setup steps to see whether I had erroneously missed a step.
In the end resorting to attaching to TV using HDMI and setting SSH manually through the GUI.
With 2020-02-13-raspbian-buster-full /boot/cmdline.txt had:
… root=/dev/mmcblk0p7 …
I used
… root=/dev/sda2 …
and all worked well with a Lexar 500 GB SSD and RPi 4
Yes you can use SD Card Copier from Accessories to make existing system boot from SSD.
Complete steps as described but don’t reboot.
Change /etc/fstab as described first. Then
cd ~
mkdir sda2
sudo mount /dev/sda2 ~/sda2
cp /etc/fstab ~/sda2/etc/fstab
worked for me.
Slight typo in your guide:
To verify this, run the command “findmnt -n -o SOURCE” / to ensure your
Should be:
To verify this, run the command “findmnt -n -o SOURCE /” to ensure your
Amazing! Thank you so much! Lets hope they release pure USB booting soon…
I bought the Orico Transparent 2.5″ SATA to USB 3.0 Enclosure, and it does not work for me. I verified with 2 different SSDs, unfortunately no way of getting it to work with my Pi4 :(.
Tried Orico Transparent 2.5″ SATA to USB 3.0 Enclosure as well. It doesn’t work on the USB3 ports, only on the USB2 ports. PI ver 1.2
Seems to work for me with Orico Transparent 2.5″ SATA to USB 3.0. I did all the config on USB2 then switched to USB 3.0.
This did work for me on the USB 3.0 port – I am assuming you did enter the Quirks correctly – ensuring the line endings were Linux compatible and not windows and also only a single line entry – BTW you need to keep the Quirks when you alter /boot/cmdline.txt for the second time!
Hi James,
Thank’s for the guide line, I’m finally succesfully boot from SSD-USB.
First it is successfull when attached to USB-2.0 using Orico Transparent Enclosure and detected by my Raspberry Pi 4 as JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge.
After changing /etc/fstab and resize, successfully attached to USB-3.0 and works.
SSD Performance test result, as follows :
Enter a description of your storage and setup (Example: Kingston A400 SSD on Pi 4 using StarTech SATA to USB adapter)
Description: SanDisk Plus SSD 240 GB on JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
(Optional) Enter alias to use on benchmark results. Leave blank for completely anonymous.
Alias (leave blank for Anonymous): After Resize and works Attached at USB-3.0
Category Test Result
HDParm Disk Read 793.48 MB/s
HDParm Cached Disk Read 245.66 MB/s
DD Disk Write 168 MB/s
FIO 4k random read 640 IOPS (2562 KB/s)
FIO 4k random write 10083 IOPS (40334 KB/s)
IOZone 4k read 14468 KB/s
IOZone 4k write 17993 KB/s
IOZone 4k random read 14639 KB/s
IOZone 4k random write 19998 KB/s
Score: 5664
Compare with previous benchmark results at:
https://storage.jamesachambers.com/
pi@raspberrypi:~ $
Regards,
Totonafo Lase
Picked up the NexStar TX 2.5″ enclosure from Micro Center, and a small Inland 240GB SSD.
So far, seems to work fine (WITH quirks steps).
Can I use this method with the SanDisk SDCZ880-128G-G46 Extreme PRO 128GB USB 3.1 Solid State Flash Drive USB? This is the chea USB you suggested in the general PI SSD article.
Don, this one works, not sure if it’s the exact same model:
https://storage.jamesachambers.com/benchmark/11501
I can confirm that the following SATA –> USB3.0 adapter does NOT work:
Vantec USB 3.0 2.5″ SATA Hard Drive Adapter with Case
[https://www.microcenter.com/product/454623/vantec-usb-30-25-sata-hard-drive-adapter-with-case]
I swapped it out for the known “ELUTENG” and it works perfectly without any other modifications to my setup.
Thanks for the great write-up!