**The new Raspberry Pi bootloader is out which makes these instructions only necessary if you want to continue to use the SD card as a bootloader. View the Raspberry Pi Bootloader Configuration Guide here!**
The Raspberry Pi 4* is finally here and has a lot of exciting changes. One very major downside is that it doesn’t support true USB booting yet out of the box (like the 3 series did). The Raspberry Pi foundation states that it is being worked on and will be added back with a future update. No timeline has been given yet for that to happen but they state it’s one of their top priorities.
Most of my projects heavily depend on having good performing storage so sitting and waiting was not an acceptable solution. In this guide I’ll show you a workaround to use USB devices as your rootfs device and use a Micro SD card as bootloader only which gives us full SSD performance after boot! To see exactly how much of a performance difference this makes (spoiler: it’s gigantic) check out the Raspberry Pi Storage Benchmarks.
I highly recommend doing this on a completely new install. If you try to upgrade your old ones and something goes wrong there’s a good chance you might lose data. We will be modifying the boot partition, resizing partitions, etc. so don’t use a drive with any data on it unless you are positive you have all of the steps down!
Compatible USB Adapters
The Raspberry Pi 4 is proving to be picky about what SATA, M.2, etc. adapters will work in the USB 3.0 port. The USB 3.0 ports are the ones in the middle that are blue inside. The black ones are USB 2.0 and won’t give you the faster speeds the new Pi offers.
It’s very likely that some of these will be fixed via software and firmware updates and the Raspberry Pi Foundation has several open known issues related to USB 3. Until that happens though I will maintain a list here of known working ones and known problematic ones. It’s still very early in the release of the Pi 4 so we still have a lot to learn about which adapters work / don’t work. If you have working and nonworking adapters leave a comment and I’ll add it in this list.
If the adapters worked before on older Pis then one thing you can try is putting them in the black USB 2.0 ports. Obviously this is stupid because we all want the Pi 4 performance gains but if you end up needing to buy a new adapter this will give you a workaround until a replacement arrives!
Find USB adapter chipset
There are certain chipsets used in adapters that are known to be working/not working.
pi@raspberrypi:~ $ lsusb Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This is a lsusb dump of all my connected USB devices. I have bolded the line with the USB bridge device. We can see that the chipset is ASM1153E. This is a really common one that works well with the Pi.
The new USB-C 3.1 Type A version of the Sabrent adapter is reported as working in the comments by UEF. DO NOT get the USB 3.0 version as that one is below on the naughty list and won’t work!
Make absolutely sure it’s the 10Gbps USB 3.1 Gen 2 version. There is another one that looks identical that is a USB 3.1 Gen 2 6Gbps that will not work. Confirmed working by RRT in the comments.
It’s bold. It’s beautiful. It’s also confirmed working by TADRACKET and Steve B. However, be warned, it takes a *lot* of power! Steve B. reports that even with the oversized 3.5A CanaKit adapter* it does not work. If you have the standard 3.0 adapter you can be practically certain it won’t power this enclosure. Does work with a powered USB hub*.
Returning legendary commentary Frank Meyer reports: Does not work with a 3.0A power adapter (also reported by TTE). It’s not enough power for this enclosure. Does work with a powered USB hub*.
M.Yusuf has given the first ever report of a working Orico adapter! Make sure it’s the USB 3.1 Gen 2 version that says “Support UASP for NVMe SSD”. This is the way.
Canakit has been making very reliable power supplies for several Pi generations now. Using a 3.5A power supply will give enough extra power for your Pi to power the drive without causing instability
Reported as working by JeffG but with an ugly messy appearance
Known Working Adapters
Known Problematic Adapters (Naughty List)
Here is a list of common USB adapters that are known to have problems with the Raspberry Pi 4. You can get some of these adapters working by using quirks mode (see the “Fix (some) USB Adapter Problems Using Quirks” section below).
Only works in the USB 2.0 ports. Will not boot in a USB 3.0 port. I have two of these and can confirm they don’t work. RIP to Sabrent, our previous king of the Pi 3 era of adapters.
Despite earlier reports as working Ryan and one other have reported this adapter does not work unless you enable quirks mode! Don’t make Ryan’s sacrifice in vain and avoid this one.
Extremely cheap adapter from AliExpress — MADATALIEXPRESS bought 5 of them and none worked, PPCM had one working, very unreliable and slow when it does work, not recommended even if you get lucky!
The Samsung 980 Pro (NVMe) is a professional grade SSD and one of the fastest in the world. The Samsung NVMe drives have been at the top of this category for a long time and are well trusted for both their performance and reliability / long life.
The ICY BOX is basically a giant heatsink that you mount a high performance M.2 NVMe drive inside of. This enclosure is really fast but requires a powered USB hub. Not even the 3.5A adapter can reliably power it! The enclosure works well and will physically feel warm to the touch as it is pulling the heat off your NVMe drive!
The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!
The SanDisk Extreme Pro USB SSD is a true solid state drive. This is different than a typical “flash drive” which uses extremely cheap memory and has very low random I/O performance/throughput compared to a real solid state drive. I’ve used both the USB 3.1 and USB 3.2 variants with the Pi successfully and they benchmark very well!
You may use other types of drives with the Pi such as M.2 SATA to USB 3.0 and m-SATA to USB 3.0. Here’s some adapters I’ve used for those types of drives:
VL716 mSATA Enclosure
The VL716 mSATA enclosure lets you connect micro SATA drives to the Pi. These drives are an older type of SSD (usually seen in laptops) predating the M.2 slot but are still widely available and perform extremely well!
The UGREEN M+B enclosure is a great enclosure for the Pi for M.2 SATA 2280 NGFF drives. It supports both B-key and M-key drives. Does not support newer NVMe drives. As with other types of enclosures it requires more power than other options!
The Argon ONE M.2 is a M.2 SATA Pi 4 case / storage solution. With the case and M.2 SATA expansion board you can completely enclosure your Pi 4 and have a built in M.2 slot! The M.2 SATA board is sometimes sold separately from the case itself and can be used as well. Does not support NVMe, this is for SATA M.2 drives only!
Power can be a serious problem with these drives. We are learning from the comments that you are especially likely to run into power issues with NVMe enclosures. A powered USB hub or a power adapter that puts out 3.5A comes not only just strongly recommended, it may actually be required that you choose one option or the other for your drive to function.
The specific requirements of how much power you’ll need depend on the adapter/enclosure and the model of your drive itself. As a very rough guideline, older models of drives tend to use more power than newer models of drives. 3.5″ form factor drives also use more power than 2.5″ drives. The earliest SSD models like first and second generation models are also well understood to use significantly more power than newer models. This is due to changes and improvements in technology over the years and even using different more efficient memory like 3D NAND. Some super high end performance drives will consume more power as well.
Here’s the current recommendations based on everyone’s comments combined with stuff I’ve personally used with the Pi:
CanaKit 3.5A Power Adapter
The CanaKit 3.5A adapter has an extra half an amp (500 mA) of capacity to give some breathing room to your accessories. This is bigger than the official Pi power supply which provides 3.0A.
The Sabrent powered USB hub delivers a whopping 2.5A of dedicated power for your USB attached devices. This is almost as much as the Pi adapter itself is rated for (3.0A). It will easily power the most thirsty of setups such as NVMe enclosures.
Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power
Fixing (some) USB Adapter Problems Using Quirks
Some of the very common adapters on the naughty list above (such as the Sabrent) can be made to work by using USB quirks to disable UAS mode on the drive. This lowers performance, but it’s still much faster than a SD card and your adapter won’t go to waste.
To find out the quirks we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.
Find Your Adapter
To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:
$ sudo lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB adapter*). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.
If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:
sudo dmesg | grep usb
[ 0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.828597] usb usb3: Product: DWC OTG Controller
[ 0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd
[ 0.828644] usb usb3: SerialNumber: fe980000.usb
[ 0.830051] usbcore: registered new interface driver uas
[ 0.830182] usbcore: registered new interface driver usb-storage
[ 0.836488] usbcore: registered new interface driver usbhid
[ 0.836511] usbhid: USB HID core driver
[ 0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[ 1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.154281] usb 1-1: Product: USB2.0 Hub
[ 1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1.333026] usb 2-1: Product: ASM105x
[ 1.333048] usb 2-1: Manufacturer: ASMT
[ 1.333071] usb 2-1: SerialNumber: 123456789B79F
This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.
Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge
Our adapter’s ID is: 174c:55aa
Applying Quirks
To apply the quirks to our USB adapter we are going to edit /boot/cmdline.txt. Type:
sudo nano /boot/cmdline.txt
We are going to add the following entry into the very front of cmdline.txt:
usb-storage.quirks=XXXX:XXXX:u
In place of the X’s above you will put in your adapter’s ID that we got before. With the example commands I gave above mine would look like this: usb-storage.quirks=174c:55aa:u. After this my cmdline.txt looks like this (everything should be one continuous line, no line breaks!):
Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.
Verifying Quirks
Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:
sudo dmesg | grep usb
[ 1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1.332983] usb 2-1: Product: ASM105x
[ 1.333006] usb 2-1: Manufacturer: ASMT
[ 1.333028] usb 2-1: SerialNumber: 123456789B79F
[ 1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 1.336611] scsi host0: usb-storage 2-1:1.0
This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see storage benchmark section near the end).
USB Boot Instructions
There are a lot of steps to follow to set everything up properly. If you make a mistake the first time don’t spend too much time trying to correct it or figure out what you did wrong. It’s usually faster to burn the images again and reconfigure again rather than try to figure out which step you might have made a typo on. It’s much easier the second time!
Note: Don’t attempt to use raw dd commands to write the images. Too many silly things can go wrong that are checked for/fixed by the recommended programs. Do yourself a big favor and use one of the recommends to avoid spending a ton of time troubleshooting basic imaging problems!
Preparing SSD
We are going to burn a second identical copy of Raspbian to the SSD. This ensures everything the Pi needs to boot is there so we can use the SD card as a bootloader but our actual system will be on our nice fast SSD drive.
Note: Make sure you create the empty file named “ssh” on the boot partition of both drives if you are headless or don’t have a mouse/keyboard attached so you can ssh in on the first boot.
First Boot (SD card only, SSD unplugged)
Insert your freshly imaged SD card into the Pi and connect the power. Sign into the Pi for the first time.
Don’t do an apt-get upgrade/dist-upgrade or any additional configuration yet. Just stick with the instructions until we have finished configuration (especially since if something goes wrong you may have to start over and any other setup you did will be lost).
Once the Pi has finished booting and you have signed in for the first time plug in your SSD to your Pi’s USB 3.0 ports. The USB 3.0 ports are the ones that have the blue plastic inside instead of the black plastic (the black ones are USB 2.0 ports).
Change PARTUUID
We need to change the PARTUUID of our SSD’s partitions so the Pi doesn’t get confused about what device to boot from. Right now the partitions on both the SD card and the SSD are an exact match and we need them to be different so we can tell the Pi to boot specifically from our SSD’s partition.
We are going to use fdisk to change the SSD’s PARTUUID to the hexadecimal d34db33f to make our SSD easy to identify. Use the following:
$ sudo fdisk /dev/sda
Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Disk model: ASM105x
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c586e13
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 500118191 499585712 238.2G 83 Linux
Command (m for help): x
Expert command (m for help): i
Enter the new disk identifier: 0xd34db33f
Disk identifier changed from 0x6c586e13 to 0xd34db33f.
Expert command (m for help): r
Command (m for help): w
The partition table has been altered.
Syncing disks.
Your /dev/mmcblk0 and /dev/sda devices should now be different from each other. The SD card’s ID is 6c586e13 and the SSD’s PARTUUID is now
Update /boot/cmdline.txt
We are going to change cmdline.txt to point to the SSD for booting instead of the SD card. First make a backup of your existing cmdline.txt file with the following command:
sudo cp /boot/cmdline.txt /boot/cmdline.txt.bak
We’ve now created a backup you can restore if something goes wrong. If you need to restore your backup plug the SD card into a computer/device and replace cmdline.txt with cmdline.txt.bak that we made above. Now your Pi should boot normally again.
Open up /boot/cmdline.txt using nano or your favorite text editor:
Make the change and double check the line is what it should be,then press Ctrl+X to save our changes.
Note: cmdline.txt should be one long solid line with no breaks — don’t add any line breaks or the system won’t boot and you’ll need to restore the backup we made earlier!
Test SSD
We are now ready to test booting from the SSD. Restart your Pi by issuing a
sudo reboot
The first boot with your SSD can be slow due to running fsck on the drive. If you have a really large SSD it can take surprisingly long to check all that space. Once the check completes it will mark the drive clean and skip the disk check from now on. It can take over a minute or two sometimes for really big drives so give it at least that much time before assuming it didn’t work.
After signing in we can verify that the SSD is being used like this:
$ findmnt -n -o SOURCE /
/dev/sda2
Verify that partition has switched over as shown below to /dev/sda2 (SSD) instead of /dev/mmcblk0p2 (SD card).
Update /etc/fstab
We are now ready to edit the /etc/fstab file to point to our updated drive. To edit the file type:
We want to change the root ( / ) partition (PARTUUID ending with -02) to load our SSD’s PARTUUID instead of the SD card. Replace the 2nd partition’s PARTUUID field on the last line in the file with the d34db33f label we applied earlier with fdisk. After making the change my /etc/fstab file looks like this:
Press Ctrl+X to tell nano to save our changes. Now type sudo reboot to restart the Pi.
Note: We want to leave the first partition (/boot) on the SD card. If you change this to the SSD then apt will update your SSD instead of the SD card so they won’t be used during boot! Remember that we are using the SD card as a bootloader and that is why the firmware updates (such as start.elf, etc) should go there instead of the SSD’s boot partition (which is never used).
Resizing Filesystem
By default the partition on the SSD / Flash drive will only be 1.8G. The Pi expands this automatically on micro SD drives but we will need to do it ourselves for a SSD / Flash drive. To do this we need to expand the partition and then resize the file system.
First let’s open fdisk and print the partitions:
pi@raspberrypi:~ $ sudo fdisk /dev/sda
Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Disk model: ASM105x
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd34db33f
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/sda2 532480 4390911 3858432 1.9G 83 Linux
There is the line we need. Our start value for /dev/sda2 (rootfs) is 532480. Next we need to remove and recreate the partition as a larger size.
If you make any mistakes during this command just close fdisk by pressing q. The changes won’t be written to disk. If you mess up any of the commands the drive will no longer boot and you’ll have to start over again so be careful!
Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-500118191, default 2048): 532480
Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-500118191, default 500118191): 500118191
Created a new partition 2 of type 'Linux' and of size 238.2 GiB.
Partition #2 contains a ext4 signature.
Do you want to remove the signature? [Y]es/[N]o: N
Command (m for help): w
The partition table has been altered.
Syncing disks.
If everything went well then type “w” and press enter. Otherwise press “q” to quit and try again. Once you enter “w” the changes will be permanently written to disk!
Now reboot the system. Type “df -h” to view the current disk:
We can see our disk is still 1.8G even after resizing the partition. That’s because we still have one more step! We need to resize the filesystem to fill our new partition space. For this we will use “sudo resize2fs /dev/sda2”:
sudo resize2fs /dev/sda2
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 15
The filesystem on /dev/sda2 is now 62448214 (4k) blocks long.
And that’s it! You will now be using all of your space on your drive.
Verify SSD Functionality / Performance
You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:
This will give you a score you can compare to the other Raspberry Pi Storage Benchmark results and make sure that you are getting an equivalent speed to your peers with the same device!
Update Pi using apt
Now that we’ve updated fstab it is safe (and highly recommended) to update your Pi’s software. Type “sudo apt-get update && sudo apt-get dist-upgrade” to update the system and firmware.
Your system will now be running completely from your USB drive! To verify this, run the command “findmnt -n -o SOURCE” / to ensure your root partition has switched over as shown below to /dev/sda2 instead of /dev/mmcblk0p2.
Conclusion
The Samsung 950 Pro NVMe drive in the featured picture scored a 9189 on the Raspberry Pi Storage Benchmark. The previous all-time record score on a Pi 3B+ was 3561. The performance gains are very real and very dramatic.
For me getting this performance is well worth having to waste a micro SD card just to be a bootloader. I am largely after the USB 3.0 bus and gigabit ethernet performance improvements and using this method I am able to achieve the performance I was after without waiting an indeterminate amount of time for the feature to be added back in!
Although there are ongoing compatibility issues and we lack the super easy native USB booting support we had before I’m more than willing to go through the growing pains to finally get rid that ancient USB 2.0 bus! Just make sure if you are planning to build a system you plan your adapters and parts accordingly.
The enclosures typically require a lot more power than the adapters. If it looks like it’s receiving power too late the problem is likely that it isn’t receiving enough power period to boot at least. Do you have a powered USB hub or a larger power adapter by chance?
I looked up your blink code and it is pretty much what I expected it to be, there’s no start.elf files found (since the drive/enclosure isn’t getting enough power there aren’t any boot files for it to find).
Do you have the latest bootloader firmware on your Pi or are you trying to boot using the SD card method? You may want to try my newer article for native USB booting with the RPI 4 here! The method in this artlce uses your SD card to bootstrap USB booting the Pi but it’s an older article that was written before native USB booting was released. It still works and is useful for operating systems that don’t support native USB booting yet or have issues but otherwise the native USB booting is definitely easier (and better).
It could also be the way the drive was imaged/prepared. Did you use the rpi-imager tool to image the drive and can see the normal files that should be on there if you plug it into a PC?
Thank you James! I had already ordered the Sabrent UC-UASP and was planning to do this upgrade, then discovered your website and this article, which placed that enclosure on the “naughty list” & was noted wouldn’t work. You saved me some time! I cancelled that order and was able to instead order what was recommended (StarTech 2.5″ SATA to USB adapter & Kingston A400 SSD/128GB). I just finished setting them up and it works PERFECTLY! I have included some speed tests below, to give others an appreciation of how much faster the SSD is. I also tried a USB thumb drive while waiting for the SSD, and it’s interesting to compare them both to the microSD to see just how much better either option is than regular microSD.
If using a pi for anything other than tinkering, it’s highly recommended to use a USB thumb drive (at least) or a SSD/NVMe drive (for more serious work, as it’s a major speed boost). I am a heavy user of Docker (15 containers), and my pi was buckling under the strain of running those on a microSD card & external USB storage. I’m now enjoying the speed benefits of the SSD! Thank you so much for all the advice and great information shared by this community. 🙂 And now, some speed test results. Enjoy!
—
Load Leveling: How long after boot-up for system to have a load level less than 1.00.
– 15 minutes on microSD
– 10 minutes on USB 3.0 thumb drive
– 4 minutes on SSD
Docker Performance (running “docker pull linuxserver/ombi”, ~100MB [already had other linuxserver images so didn’t have to download more than 100MB]
– 3 minutes on microSD
– 1 minute and 30 seconds on USB 3.0 thumb drive
– 27 seconds on SSD!!!!! WOW!
Speed test (“hdparm -t –direct [DEVICE]”)
– microSD: 40.03 MB/sec
– USB 3.0 thumb drive: 99.92 MB/sec
– SSD: 311.69 MB/sec
—
Thanks a ton for posting your results! Those are some impressive leaps in performance there. The 27 seconds jump over even the thumb drive’s 1 minute and 30 seconds particularly caught my eye!
I’m very glad you were able to cancel the Sabrent one in time as a lot of other people have had to either return or use the adapter for other things (or eat the performance penalties of quirks if those work).
Odd. I have a 4B hw rev. 1.1; the Eluteng SATA adapter works fine with a Kingston A400 to boot from USB (even without the quirks workaround.) I just bought the Sabrent HB-UMP3 hub and it keeps the pi from powering up correctly if using it as a powered hub (but only in the USB3 ports…) If the hub is unpowered it boots fine, but still going to return it as I need it to power several hard drives. Anyone else run into this?
I’ve got mixed reports about the ELUTENG one. I initially heard it worked but then got several comments later that it didn’t work. It may be power related where some people had a more powerful adapter or a powered hub setup and that is why they were successful and others weren’t.
I’ve definitely ran into the power up issue on the powered USB hubs as well (the ones that actually will work at all) and have always just unplugged the USB hub’s connection with the Pi briefly, plugged the power into the Pi and then quickly plugged the USB hub back in.
This should work even with multiple hard drives since the hub will only be connected to the Pi with a single cable. It definitely is annoying though since the hub provides enough power for the Pi to try to boot from it but not enough power for the Pi to actually successfully boot and power up to a happy green light state.
I have heard there are (probably expensive) hubs out there that isolate the power to avoid this a long time ago but I don’t know of a specific product that does it so if anyone has one and has successfully tried it with the Pi let me know and I can add that hub in here!
RaspiPi 4, StarTech USB to SSD, Samsung 860 EVO SSD – will boot up from fine on power on. Attempt to reboot whilst power remains on, and system just hangs. Any ideas?
I have an issue running the Pi 4 Rev 1.2 4G with Home Assistant. I have tried both the StarTech 3.0 and 3.1 controllers and the Kingston 120G SSD and the Samsung EVO 250G series SSD. All work in Home Assistant on OS version 5.4 and below. All combinations lock up after 3 hours to almost 24 hours on any version of the OS above 5.4. I tried the latest development version (6.x) based on the Pi 5.10 kernel and it worked for 23 hours before locking up. No error messages. Any ideas on what to try?
That’s actually good news you were able to get it to work on the development channel (for 23 hours at least). That is the first I have heard of anyone getting it to boot at all!
I don’t have any good answers for you unfortunately for HA as I believe we are at the developer’s mercy here to get support implemented which it sounds like they’re making progress!
I have no issues on 5.4 and below in HA. There is an issue report (see spreadsheet that shows a lot of info that list’s people that can boot with HA and have issues. The issue is they can not update and if they do the pi freezes. Reading a lot on the internet it looks like there may be an internal timing issue due to how the PI4 implemented USB3. Not sure if this is correct?
Thanks for the info and the link to the GitHub thread. I read the whole thing and it doesn’t sound like anyone has found a viable workaround here.
For those having difficulties with USB booting HomeAssistant this GitHub issues thread would be good to check up on. There’s a *ton* of people chiming in specifically about USB booting on the Pi!
One thing that caught my eye in that thread was that HomeAssistant seems to have it’s own bootloader. This is part of what made Ubuntu tricky to set up with SSD booting for so many years too until it became officially supported within the past year (they use u-boot on Ubuntu). Here’s a comment from one of the devs (pvizeli).
That is an important part. Like we said at the Conference and maintain it on different docs, USB-Boot is very buggy and can fail at every update. It’s not usually to boot from an external drive with an firmware. That is only done by RPi to keep the product cheap/profit. If you looking at their end, they have also a lot of issues with hardware and updates. I really recommend using our data disk feature. The USB boot is already hacky with just the RPi firmware, but our OS has also an own bootloader, and to keep the disk over 2 bootloaders running is very unstable.
I’m not sure I agree with their reasoning that these issues are due to profit seeking and being cheap (most of the other distros/projects seem to have it figured out by now, it’s HA that keeps popping up as the outlier) but regardless it sounds like the dev knows there’s serious issues with USB booting and strongly recommends using the “data disk feature”.
I looked up this feature and it sounds like you basically still boot off the SD card but you move the HomeAssistant “data partition” to your SSD. I don’t know if you’ve tried this, but it was the only thing I found in those 300 replies that seemed like something that may be worth a try!
I tried this and it works no better. My issue isn’t booting it is locking up after so many hours. They, Home Assistant developers, have an issue. They changed something after OS 5.4 was released (Kernel maybe) that caused an issue for a lot of people. Very frustrating with the software troubleshooting tools available that someone can’t figure out the issue. I addressed pvizeli on this and never received a response. I also had several discussions with agner and I believe he understands the issue but does not have a fix.
Thanks for the additional information! It definitely helps since many others have had this issue as well and it lets me know if it’s worth recommending it or not.
It sounds like it’s only a matter of time since we know for sure the developers are aware of the problems since you have personally spoken to some of them. Other distros/projects had issues as well when the native USB booting support was released (such as Ubuntu for which I have a guide fixing weird issues like this) but most of them have been fixed.
I’m not nearly as proficient with HA or I am sure we could probably figure out how to fix it. It’s very likely firmware related (not the bootloader firmware but the firmware that HA’s own bootloader is loading into it like the start.elf files, etc.) but it could be an issue with the kernel that they need to adjust a config flag for or something like that.
My HA installation was on my Tinkerboard since it was one of the only things that had Tinkerboard official support but it seemed like it crashed during an update and was completely corrupted and I haven’t rebuilt it yet! Thanks again for the follow up, I know others have had issues with HA and may even be watching this thread for progress/updates!
I think it maybe related to something else. Maybe a board change or memory management change. It seems the 8GB 1.4 version works on Home Assistant OS above 5.4 where the 4GB 1.2 doesn’t. Maybe a timing difference?
I did find something interesting on the Pi forums. Here’s a bunch of people saying there were some changes made in that revision that could impact the images booting (something to do with a mailbox call to get the VLI firmware in the right state).
Oddly in this post it was breaking the images which is exactly the opposite of yours where that is the only revision that is working. I wonder if it’s related though since HA has it’s own bootloader and I doubt they are taking these board revisions into account. It definitely does look like the board revisions can impact the boot process/low level hardware/API calls and there’s documented instances of it! This is actually a great find. I have not had anyone come by here working on HA yet that was able to get it working reliably and it seems you’ve found a board revision it likes!
Bill Schatzow
A little confusion. I have the Pi4 4G with release 1.2 PCB. The 8GB 1.4 PCB seems to work.
>That is very interesting. Is the same version of firmware on each Pi?
This does not seem to be an issue. I have used every stable release since Sept. Currently on Feb 2021.
1.2 fixed the USB-C power issue. Not sure what was changed in 1.4?
Asked for clarification in the Raspberry general forums. No reply.
Bill Schatzow
A little more information. I tried the RPI OS with Home Assistant as supervisor (not supported) and it ran stable for a week. I then tried the Debian with HA as supervisor(officially supported) and it crashed like the RPI OS above 5.4. Someone asked to check the power supply (again as I tried the “official” 3 A version as well as the 3.5A with no difference.
I have an inline tester that I am monitoring the current & voltage and the HA OS is typically below an Amp. I’ll test the other two versions and report back.
Do you if anyone as done this type of testing? If so, could one of the OSs be needing more power and maybe causing an issue? Hard for me to believe, but as I have no answers for months, I keep trying different test to try and figure out a solution.
Have you tried with a powered USB hub yet? There’s quite a few NVMe enclosures for example that will not work with a 3.5A or any size power adapter (and will either only boot sometimes or will work fine if it’s right on the edge then the OS will try to do several things at once and it will freeze since the power will drop too low) because of the hard limits built into the Raspberry Pi on how much power it can pass through. Basically even if you connected a 50A power supply the Pi would still only pass through 1.2A of that power to all of your accessories (COMBINED).
I’ve even seen instances here in the comments where people could boot fine with their USB setup until they plugged in an external keyboard. Since the power limit for the USB accessories is shared the keyboard was putting them over the limit (they ended up using a powered USB hub).
I’d say HA is probably the #1 most common OS to have this issue and if you go through the comments of this post and the “New USB guide” there’s tons of other people who have had the same issue and I ended up actually linking them to your comment threads saying that as far as I knew this was still ongoing. If you’re trying with Debian as the host OS and still getting it though then it would definitely be worth picking up a $20ish powered USB hub and ruling that out since you’ve already spent months working on this and that’s a pretty easy thing to check (and is honestly a great improvement for a Pi setup too if you’re connecting *anything* to it).
Others have been having issues like this (not with HA specifically but with other less common OS’s that aren’t a common flavor like Ubuntu, Debian, etc.) and actually fixed it ended up upgrading their OS’s bootloader (u-boot) to a newer version to get it to play nice with the newer Pis. When I’ve fixed issues like this with other operating systems it was almost always they were using too old of Pi firmware bundled in their OS (usually a year or two old and you need < months old for native USB booting to work properly) or needed to upgrade their OS's custom bootloader like this gentleman did.
The Debian thing definitely does seem to point to some sort of power issue. What adapter/drive setup are you using? If it’s NVMe or an enclosure then power is by far the most common culprit for the not booting sometimes/random lockups. Definitely let us know what you find in your continuing investigation!
Bill Schatzow
Thanks for the detailed reply. I’m glad you mentioned the 50A supply. I don’t know how many times I have told people it is not an input power supply but something else.
My current situation is that I had a lot of issues get Debian to work and with Tamsy’s help I was able to get it working with no issues after 1 1/2 and counting. His last suggestion was to remove the HDMI connection (everything else was already disconnected). Once this was done no issues. Not sure if it is power or noise or something else?
I purchase a power hub that should be in shortly. I will test it with HAOS 5.13 that was failing and see if this fixes the issue.
I still am not clear why one OS has issues and others do not if it is truly a port power issue? HAOS 5.4, RPIOS (4/2021) work with identical hardware and the same HA (loaded from a snapshot). HA OS 5.13 and Debian do not.
I am now starting to see users with just the SD card having issues with HA on versions above 5.4. So maybe it is something else?
I’ll do some more testing and report my findings.
Thanks again for all of your advise.
Bill Schatzow
I have tested the HAOS 5.13 with the powered hub. It crashed in three hours. My conclusions is that something was changed in the HAOS (after 5.4 release) that affects many users. As I have a more than adequate P/S (3.5A) and a powered hub, I do not believe that the issue has anything to do with power.
Back to using Debian and HA as supervisor. This is now very stable for me. If you need more information on what I tested, let me know.
I agree with your conclusions. I think you gave us all the information but if you learn more I’d love if you’d come back and let us know, take care!
Bill Schatzow
Just to keep you updated the issue is finally fixed. The fix had nothing to do with the different hardware that was attached to the Pi4 ( Power Supplies, controllers, SSD, etc). Back in Nov. 2020 RPI developers made a change in the firmware (recommended by Broadcom) that effected a small number of users. It has since been corrected and a release was issued in early Jan 2022. If interested you can follow the troubleshooting and fixes here.
Thanks for the update! I actually have had some people over the past year or so that I’ve referred to your thread. It’s rare, but a few other people encountered this and I actually referred them to your post and told them that you had encountered this before and as far as I knew that you were still working on it! For example Andrew ran into it here.
I’m not surprised this ended up being such an obscure issue as we’re probably able to solve 90% of these at least on the site as one of the usual suspects (or even one of the lesser known suspects, but not anywhere near as unknown as this issue ended up being). Of the remaining 10% these outstanding issues made up probably 5-6% of that!
I’ve posted this as an article here. I did this because it’s pretty buried here in the comments and it’s important information and will get indexed a lot better as it’s own article.
Thanks a ton Bill, and thanks especially for the follow-up. More people than just myself have been wondering whether this went anywhere, congratulations on tracking this down!
Maruan
Hi James,
thanks for the quirks-section above. I have in Intenso Portable SSD Premium 128 GB and it didn’t work at the USB3.0 port. But somewhere I read, that it works with the USB2.0 port of the Rapsberry Pi 4. I tried it and it was true. After the successful boot on USB2.0 port, I changed the cmdline.txt as discribed above and boot the Raspberry from SSD using the USB 3.0 port. It worked fine.
lsusb showed the following device:
Bus 002 Device 002: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.
I used your speedtest (pibenchmarks.com) and got the following scores:
USB 2.0: 2.460
USB 3.0: 5.038
I hope this information can help someone, how also struggled with this Intenso SSD.
Beautiful, I’m glad you were able to get it working properly, and it looks like it was well worth the struggle as your performance score literally doubled by getting USB 3.0 working correctly!
Thanks a ton for posting your solution, it should help anyone else struggling with this setup!
I bought 5 “AliExpress Generic 2.5″ SATA to USB 3.0 “New USB 3.0 To 2.5in SATA 7+15Pin Hard Drive Adapter”* and had problems with every single one of them. I had to reset my raspberry pi’s multiple times for them to boot properly, after a few times rebooting wouldn’t even work.
I got all kind of errors from services failing to start to unable to read block and so on.
Hi! I have problems with the:
UGREEN 2.5″ SATA to USB-C 3.1 “Protect What You Love”
I cant boot with the instructions. It blinks 5 times (first time quick).
The SSD appears to be receiving power too late. It’s not even booting.
Any ideas?
Hey Tom,
The enclosures typically require a lot more power than the adapters. If it looks like it’s receiving power too late the problem is likely that it isn’t receiving enough power period to boot at least. Do you have a powered USB hub or a larger power adapter by chance?
I looked up your blink code and it is pretty much what I expected it to be, there’s no start.elf files found (since the drive/enclosure isn’t getting enough power there aren’t any boot files for it to find).
Do you have the latest bootloader firmware on your Pi or are you trying to boot using the SD card method? You may want to try my newer article for native USB booting with the RPI 4 here! The method in this artlce uses your SD card to bootstrap USB booting the Pi but it’s an older article that was written before native USB booting was released. It still works and is useful for operating systems that don’t support native USB booting yet or have issues but otherwise the native USB booting is definitely easier (and better).
It could also be the way the drive was imaged/prepared. Did you use the rpi-imager tool to image the drive and can see the normal files that should be on there if you plug it into a PC?
Thank you James! I had already ordered the Sabrent UC-UASP and was planning to do this upgrade, then discovered your website and this article, which placed that enclosure on the “naughty list” & was noted wouldn’t work. You saved me some time! I cancelled that order and was able to instead order what was recommended (StarTech 2.5″ SATA to USB adapter & Kingston A400 SSD/128GB). I just finished setting them up and it works PERFECTLY! I have included some speed tests below, to give others an appreciation of how much faster the SSD is. I also tried a USB thumb drive while waiting for the SSD, and it’s interesting to compare them both to the microSD to see just how much better either option is than regular microSD.
If using a pi for anything other than tinkering, it’s highly recommended to use a USB thumb drive (at least) or a SSD/NVMe drive (for more serious work, as it’s a major speed boost). I am a heavy user of Docker (15 containers), and my pi was buckling under the strain of running those on a microSD card & external USB storage. I’m now enjoying the speed benefits of the SSD! Thank you so much for all the advice and great information shared by this community. 🙂 And now, some speed test results. Enjoy!
—
Load Leveling: How long after boot-up for system to have a load level less than 1.00.
– 15 minutes on microSD
– 10 minutes on USB 3.0 thumb drive
– 4 minutes on SSD
Docker Performance (running “docker pull linuxserver/ombi”, ~100MB [already had other linuxserver images so didn’t have to download more than 100MB]
– 3 minutes on microSD
– 1 minute and 30 seconds on USB 3.0 thumb drive
– 27 seconds on SSD!!!!! WOW!
Speed test (“hdparm -t –direct [DEVICE]”)
– microSD: 40.03 MB/sec
– USB 3.0 thumb drive: 99.92 MB/sec
– SSD: 311.69 MB/sec
—
Hardware Details:
– Samsung 64GB Evo Plus microSD (supposedly one of the fastest microSD cards)
– PNY 128GB Turbo USB 3.0
– Kingston A400 128GB SSD w/ StarTech 2.5″ SATA->USB 3.0 adapter (as recommended by this great article!)
Hey bryan,
Thanks a ton for posting your results! Those are some impressive leaps in performance there. The 27 seconds jump over even the thumb drive’s 1 minute and 30 seconds particularly caught my eye!
I’m very glad you were able to cancel the Sabrent one in time as a lot of other people have had to either return or use the adapter for other things (or eat the performance penalties of quirks if those work).
Awesome results, thanks again for sharing!
Odd. I have a 4B hw rev. 1.1; the Eluteng SATA adapter works fine with a Kingston A400 to boot from USB (even without the quirks workaround.) I just bought the Sabrent HB-UMP3 hub and it keeps the pi from powering up correctly if using it as a powered hub (but only in the USB3 ports…) If the hub is unpowered it boots fine, but still going to return it as I need it to power several hard drives. Anyone else run into this?
Hey Mike,
I’ve got mixed reports about the ELUTENG one. I initially heard it worked but then got several comments later that it didn’t work. It may be power related where some people had a more powerful adapter or a powered hub setup and that is why they were successful and others weren’t.
I’ve definitely ran into the power up issue on the powered USB hubs as well (the ones that actually will work at all) and have always just unplugged the USB hub’s connection with the Pi briefly, plugged the power into the Pi and then quickly plugged the USB hub back in.
This should work even with multiple hard drives since the hub will only be connected to the Pi with a single cable. It definitely is annoying though since the hub provides enough power for the Pi to try to boot from it but not enough power for the Pi to actually successfully boot and power up to a happy green light state.
I have heard there are (probably expensive) hubs out there that isolate the power to avoid this a long time ago but I don’t know of a specific product that does it so if anyone has one and has successfully tried it with the Pi let me know and I can add that hub in here!
Yes, the Sabrent HB-UMP3 don’t work because of back powering the Raspi4 over USB3. Will send it back and hope another UGREEN Hub work better, …
RaspiPi 4, StarTech USB to SSD, Samsung 860 EVO SSD – will boot up from fine on power on. Attempt to reboot whilst power remains on, and system just hangs. Any ideas?
I have an issue running the Pi 4 Rev 1.2 4G with Home Assistant. I have tried both the StarTech 3.0 and 3.1 controllers and the Kingston 120G SSD and the Samsung EVO 250G series SSD. All work in Home Assistant on OS version 5.4 and below. All combinations lock up after 3 hours to almost 24 hours on any version of the OS above 5.4. I tried the latest development version (6.x) based on the Pi 5.10 kernel and it worked for 23 hours before locking up. No error messages. Any ideas on what to try?
Hey Bill,
I have definitely seen people saying that they have been having trouble with HA in this thread and the New Raspberry Pi 4 Bootloader USB / Network Boot Guide.
That’s actually good news you were able to get it to work on the development channel (for 23 hours at least). That is the first I have heard of anyone getting it to boot at all!
I don’t have any good answers for you unfortunately for HA as I believe we are at the developer’s mercy here to get support implemented which it sounds like they’re making progress!
I have no issues on 5.4 and below in HA. There is an issue report (see spreadsheet that shows a lot of info that list’s people that can boot with HA and have issues. The issue is they can not update and if they do the pi freezes. Reading a lot on the internet it looks like there may be an internal timing issue due to how the PI4 implemented USB3. Not sure if this is correct?
Hey Bill,
Thanks for the info and the link to the GitHub thread. I read the whole thing and it doesn’t sound like anyone has found a viable workaround here.
For those having difficulties with USB booting HomeAssistant this GitHub issues thread would be good to check up on. There’s a *ton* of people chiming in specifically about USB booting on the Pi!
One thing that caught my eye in that thread was that HomeAssistant seems to have it’s own bootloader. This is part of what made Ubuntu tricky to set up with SSD booting for so many years too until it became officially supported within the past year (they use u-boot on Ubuntu). Here’s a comment from one of the devs (pvizeli).
I’m not sure I agree with their reasoning that these issues are due to profit seeking and being cheap (most of the other distros/projects seem to have it figured out by now, it’s HA that keeps popping up as the outlier) but regardless it sounds like the dev knows there’s serious issues with USB booting and strongly recommends using the “data disk feature”.
I looked up this feature and it sounds like you basically still boot off the SD card but you move the HomeAssistant “data partition” to your SSD. I don’t know if you’ve tried this, but it was the only thing I found in those 300 replies that seemed like something that may be worth a try!
I tried this and it works no better. My issue isn’t booting it is locking up after so many hours. They, Home Assistant developers, have an issue. They changed something after OS 5.4 was released (Kernel maybe) that caused an issue for a lot of people. Very frustrating with the software troubleshooting tools available that someone can’t figure out the issue. I addressed pvizeli on this and never received a response. I also had several discussions with agner and I believe he understands the issue but does not have a fix.
Hey Bill,
Thanks for the additional information! It definitely helps since many others have had this issue as well and it lets me know if it’s worth recommending it or not.
It sounds like it’s only a matter of time since we know for sure the developers are aware of the problems since you have personally spoken to some of them. Other distros/projects had issues as well when the native USB booting support was released (such as Ubuntu for which I have a guide fixing weird issues like this) but most of them have been fixed.
I’m not nearly as proficient with HA or I am sure we could probably figure out how to fix it. It’s very likely firmware related (not the bootloader firmware but the firmware that HA’s own bootloader is loading into it like the start.elf files, etc.) but it could be an issue with the kernel that they need to adjust a config flag for or something like that.
My HA installation was on my Tinkerboard since it was one of the only things that had Tinkerboard official support but it seemed like it crashed during an update and was completely corrupted and I haven’t rebuilt it yet! Thanks again for the follow up, I know others have had issues with HA and may even be watching this thread for progress/updates!
I think it maybe related to something else. Maybe a board change or memory management change. It seems the 8GB 1.4 version works on Home Assistant OS above 5.4 where the 4GB 1.2 doesn’t. Maybe a timing difference?
Hey Bill,
That is very interesting. Is the same version of firmware on each Pi? You can check with:
sudo rpi-eeprom-update -aThere’s another possibility. There have been hardware level revisions to the Pi 4 that your 8GB Pi would have and that 4GB Pi would not.
Funny enough the 1.2 version of the Pi 4 is supposed to have those revisions according to this.
I did find something interesting on the Pi forums. Here’s a bunch of people saying there were some changes made in that revision that could impact the images booting (something to do with a mailbox call to get the VLI firmware in the right state).
Oddly in this post it was breaking the images which is exactly the opposite of yours where that is the only revision that is working. I wonder if it’s related though since HA has it’s own bootloader and I doubt they are taking these board revisions into account. It definitely does look like the board revisions can impact the boot process/low level hardware/API calls and there’s documented instances of it! This is actually a great find. I have not had anyone come by here working on HA yet that was able to get it working reliably and it seems you’ve found a board revision it likes!
A little confusion. I have the Pi4 4G with release 1.2 PCB. The 8GB 1.4 PCB seems to work.
>That is very interesting. Is the same version of firmware on each Pi?
This does not seem to be an issue. I have used every stable release since Sept. Currently on Feb 2021.
>Funny enough the 1.2 version of the Pi 4 is supposed to have those revisions according to this.
1.2 fixed the USB-C power issue. Not sure what was changed in 1.4?
Asked for clarification in the Raspberry general forums. No reply.
A little more information. I tried the RPI OS with Home Assistant as supervisor (not supported) and it ran stable for a week. I then tried the Debian with HA as supervisor(officially supported) and it crashed like the RPI OS above 5.4. Someone asked to check the power supply (again as I tried the “official” 3 A version as well as the 3.5A with no difference.
I have an inline tester that I am monitoring the current & voltage and the HA OS is typically below an Amp. I’ll test the other two versions and report back.
Do you if anyone as done this type of testing? If so, could one of the OSs be needing more power and maybe causing an issue? Hard for me to believe, but as I have no answers for months, I keep trying different test to try and figure out a solution.
Hey Bill,
Have you tried with a powered USB hub yet? There’s quite a few NVMe enclosures for example that will not work with a 3.5A or any size power adapter (and will either only boot sometimes or will work fine if it’s right on the edge then the OS will try to do several things at once and it will freeze since the power will drop too low) because of the hard limits built into the Raspberry Pi on how much power it can pass through. Basically even if you connected a 50A power supply the Pi would still only pass through 1.2A of that power to all of your accessories (COMBINED).
I’ve even seen instances here in the comments where people could boot fine with their USB setup until they plugged in an external keyboard. Since the power limit for the USB accessories is shared the keyboard was putting them over the limit (they ended up using a powered USB hub).
I’d say HA is probably the #1 most common OS to have this issue and if you go through the comments of this post and the “New USB guide” there’s tons of other people who have had the same issue and I ended up actually linking them to your comment threads saying that as far as I knew this was still ongoing. If you’re trying with Debian as the host OS and still getting it though then it would definitely be worth picking up a $20ish powered USB hub and ruling that out since you’ve already spent months working on this and that’s a pretty easy thing to check (and is honestly a great improvement for a Pi setup too if you’re connecting *anything* to it).
Others have been having issues like this (not with HA specifically but with other less common OS’s that aren’t a common flavor like Ubuntu, Debian, etc.) and actually fixed it ended up upgrading their OS’s bootloader (u-boot) to a newer version to get it to play nice with the newer Pis. When I’ve fixed issues like this with other operating systems it was almost always they were using too old of Pi firmware bundled in their OS (usually a year or two old and you need < months old for native USB booting to work properly) or needed to upgrade their OS's custom bootloader like this gentleman did.
The Debian thing definitely does seem to point to some sort of power issue. What adapter/drive setup are you using? If it’s NVMe or an enclosure then power is by far the most common culprit for the not booting sometimes/random lockups. Definitely let us know what you find in your continuing investigation!
Thanks for the detailed reply. I’m glad you mentioned the 50A supply. I don’t know how many times I have told people it is not an input power supply but something else.
My current situation is that I had a lot of issues get Debian to work and with Tamsy’s help I was able to get it working with no issues after 1 1/2 and counting. His last suggestion was to remove the HDMI connection (everything else was already disconnected). Once this was done no issues. Not sure if it is power or noise or something else?
I purchase a power hub that should be in shortly. I will test it with HAOS 5.13 that was failing and see if this fixes the issue.
I still am not clear why one OS has issues and others do not if it is truly a port power issue? HAOS 5.4, RPIOS (4/2021) work with identical hardware and the same HA (loaded from a snapshot). HA OS 5.13 and Debian do not.
I am now starting to see users with just the SD card having issues with HA on versions above 5.4. So maybe it is something else?
I’ll do some more testing and report my findings.
Thanks again for all of your advise.
I have tested the HAOS 5.13 with the powered hub. It crashed in three hours. My conclusions is that something was changed in the HAOS (after 5.4 release) that affects many users. As I have a more than adequate P/S (3.5A) and a powered hub, I do not believe that the issue has anything to do with power.
Back to using Debian and HA as supervisor. This is now very stable for me. If you need more information on what I tested, let me know.
Thanks Bill,
I agree with your conclusions. I think you gave us all the information but if you learn more I’d love if you’d come back and let us know, take care!
Just to keep you updated the issue is finally fixed. The fix had nothing to do with the different hardware that was attached to the Pi4 ( Power Supplies, controllers, SSD, etc). Back in Nov. 2020 RPI developers made a change in the firmware (recommended by Broadcom) that effected a small number of users. It has since been corrected and a release was issued in early Jan 2022. If interested you can follow the troubleshooting and fixes here.
Hey Bill,
Thanks for the update! I actually have had some people over the past year or so that I’ve referred to your thread. It’s rare, but a few other people encountered this and I actually referred them to your post and told them that you had encountered this before and as far as I knew that you were still working on it! For example Andrew ran into it here.
I’m not surprised this ended up being such an obscure issue as we’re probably able to solve 90% of these at least on the site as one of the usual suspects (or even one of the lesser known suspects, but not anywhere near as unknown as this issue ended up being). Of the remaining 10% these outstanding issues made up probably 5-6% of that!
I’ve posted this as an article here. I did this because it’s pretty buried here in the comments and it’s important information and will get indexed a lot better as it’s own article.
Thanks a ton Bill, and thanks especially for the follow-up. More people than just myself have been wondering whether this went anywhere, congratulations on tracking this down!
Hi James,
thanks for the quirks-section above. I have in Intenso Portable SSD Premium 128 GB and it didn’t work at the USB3.0 port. But somewhere I read, that it works with the USB2.0 port of the Rapsberry Pi 4. I tried it and it was true. After the successful boot on USB2.0 port, I changed the cmdline.txt as discribed above and boot the Raspberry from SSD using the USB 3.0 port. It worked fine.
lsusb showed the following device:
Bus 002 Device 002: ID 152d:0579 JMicron Technology Corp. / JMicron USA Technology Corp.
I used your speedtest (pibenchmarks.com) and got the following scores:
USB 2.0: 2.460
USB 3.0: 5.038
I hope this information can help someone, how also struggled with this Intenso SSD.
Thanks again for the help on this page.
R
Maruan
Hey Maruan,
Beautiful, I’m glad you were able to get it working properly, and it looks like it was well worth the struggle as your performance score literally doubled by getting USB 3.0 working correctly!
Thanks a ton for posting your solution, it should help anyone else struggling with this setup!
Beware:
I bought 5 “AliExpress Generic 2.5″ SATA to USB 3.0 “New USB 3.0 To 2.5in SATA 7+15Pin Hard Drive Adapter”* and had problems with every single one of them. I had to reset my raspberry pi’s multiple times for them to boot properly, after a few times rebooting wouldn’t even work.
I got all kind of errors from services failing to start to unable to read block and so on.
I have to order StarTech 2.5″ SATA to USB Adapter from Amazon and I hope they work just fine.
Don’t waste your money on this cheap adapter, they are also super fragile and the slightest amount of force bends their pins.
Verified: its the problem with cheap adapters.
Switched to StarTech from Amazon and what used to take over 10 minutes with low success rate now takes 10 seconds,
Hey MADATALIEXPRESS,
Thanks for the warning, I have added your words of caution to the list and moved it to the naughty list as well!