Official support from Canonical for the Raspberry Pi has come a long way. We can now install officially supported Ubuntu on the Pi! In my previous guide for Ubuntu 18.04 on the Pi the Raspberry Pi was not officially supported yet and to be honest the experience was pretty janky.
The previous LTS “unofficial” release had so many problems I actually rolled my own image with dozens of fixes to common ailments before I quickly realized that maintaining a Linux distro, even in such a limited capacity as patching in and distributing fixed binaries, was a monumental undertaking.
Fortunately the current Ubuntu 20.04 LTS release is officially certified for the Raspberry Pi. This combined with Ubuntu’s full 64 bit userland/system environment allows you to take full advantage of the 8 GB Pi’s memory without per-process 3GB memory limits (very useful if you are doing something like running a Minecraft server and want to allocate almost all of the 8 GB to it) means there has never been a better time to give Ubuntu a try on the Pi.
This guide takes it a step further and shows you how to get Ubuntu 20.04 / 20.10 / 21.04 / etc. working with a SSD. Let’s get started!
Equipment Used
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!
Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
NVME Option (powered USB hub required, see “Power Requirements” section in my more generalized Raspberry Pi 4 USB booting guide):
The Samsung 970 EVO Plus is a fantastic drive and has fallen in price substantially. It’s widely available around the world. The smaller capacities (such as the 250GB version) of this drive are perfect for the Pi! This is the top performance option without going into the “Pro” series of the lineup which are much more expensive.
Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
If you really want to take things over the top the ASUS Rog Strix M.2 NVMe enclosure uses the latest USB 3.2 Gen2 specification, is RGB capable and works with the Pi! Unsurprisingly, adding the extra lighting does take extra power! A powered USB hub is also required for this enclosure. More widely available than the ICY BOX but tends to be on the expensive side.
Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, *Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
Prerequisites
Verify Power Supply Size (3.5A strongly recommended)
Check your Raspberry Pi’s power supply size and make sure it is delivering at least 3.5A. There are a lot of USB C adapters for the Raspberry Pi that are only 3.0A. These will typically work fine, until you plug in something like a SSD which draws power from the Pi and there is nothing left to give.
Most SSDs are quite power efficient but HDDs draw significantly more. Older generations of SSDs used quite a bit more power than newer ones as well. If you are using an older drive or a drive that you know is power hungry you need to pay extra attention to having a quality power source with plenty of capacity.
A good alternative option to relying on the Pi to power the drive is using a powered USB hub* so your drive doesn’t need to draw power from the Pi’s limited power budget. Make sure you get one that is compatible with the Pi as some powered USB hubs won’t work properly with it so check the reviews and do your research to make sure people are using it successfully with the Pi.
Using a 3.5A power supply* or powered USB hub* will ensure your drive is getting enough power without impacting the Pi’s stability.
Recommended Power Solutions
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.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.uk*, Amazon.es*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*
Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power
The 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.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.sg*
Verify Storage Adapter Compatibility
You will need a USB 3.0 storage adapter. See my other article on USB booting not specific to Ubuntu for a lot more details on the storage adapters!
Get Latest Raspbian & Updates
To update your bootloader / firmware you should use Raspbian on a SD card. Right now support in third party operating systems to do anything with the new Raspberry Pi 4’s firmware or bootloader is very limited / nonexistent. You can use a third party operating system later once you set the boot mode, but to actually make these changes we will use official Raspbian.
First make sure that you have the absolute latest updates and firmware for the Pi. To upgrade all your packages and firmware to the latest version use the following command:
sudo apt update && sudo apt full-upgrade -y
Once the update has completed restart your Pi with a sudo reboot command to apply the latest firmware / kernel updates.
Verify EEPROM Bootloader is up to date
We can check if your Pi’s bootloader firmware is up to date with the following command:
sudo rpi-eeprom-update
If your Raspbian is *very* out of date you may not have this utility and can install it using:
sudo apt install rpi-eeprom
The output from rpi-eeprom-update will look like this if you are not up to date:
BCM2711 detected VL805 firmware in bootloader EEPROM *** UPDATE AVAILABLE *** BOOTLOADER: update available CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103) LATEST: Tue 24 Nov 15:08:04 UTC 2020 (1606230484) FW DIR: /lib/firmware/raspberrypi/bootloader/beta VL805: up-to-date CURRENT: 000138a1 LATEST: 000138a1
If it says any updates are available they be installed manually by adding ‘-a’ to the end of our previous command like this:
sudo rpi-eeprom-update -a
After the updates finish installing restart your Pi as firmware updates will not be applied until after a reboot. Now if you run rpi-eeprom-update to check for updates again it should say you are on the latest and up to date!
Changing rpi-eeprom’s Release Channel
Note: As of February 16th the firmware available in the “critical” branch is new enough to USB boot so I no longer recommend changing this. One reader even let me know in the comments that on the “stable” channel his storage was getting corrupted prompting a full reinstall!
By default you will only receive updates from Raspbian’s “critical” channel. This is a very conservative firmware update channel that will only give you very well tested firmware updates that are considered critical fixes for the device. Another channel that is available is “stable”.
Carlos and other commenters have reported that the current “critical” firmware didn’t work for them and they had to upgrade to the “stable” channel.
To switch to the stable channel we are going to edit the file /etc/default/rpi-eeprom-update:
sudo nano /etc/default/rpi-eeprom-update
Change the line FIRMWARE_RELEASE_STATUS=”critical” to:
FIRMWARE_RELEASE_STATUS="stable"
Now you can run sudo rpi-eeprom-update and you should see a new update available.
Install Ubuntu on USB Storage Device
The new official Raspberry Pi imaging tool is really good. It’s available on Windows, Linux and MacOS and is a small and fast download. It also works fine on most USB mass storage devices like SSDs. Since Ubuntu is now officially supported the image itself is also available in this tool which saves you the trouble of having to find and download the right image files.
64 bit images are recommended for the Pi 4 for better performance but the 32 bit images work as well.
If you want to do things the traditional way you can download the image from the main Ubuntu site and write it yourself using Etcher / dd / Win32diskimager / your preferred tool and skip to the next section. It’s recommended to create the media with the Raspberry Pi Imager unless you are having problems with that utility or are using this as a troubleshooting step.
Once you’ve downloaded the tool run it as administrator/sudo to avoid permission errors. To run the utility from the command line is usually sudo rpi-imager. You’ll be greeted with this screen:
Next click the “Choose OS” button:
Ahh, the benefits of being officially supported! Ubuntu is right there on the list waiting for us. Select the Ubuntu option and you will get the different choices of flavors/architectures. There’s Ubuntu Desktop, Ubuntu Server, and Ubuntu Core in various forms of 64-bit (arm64) and 32-bit (armhf).
If you want to use the out-of-the-box Ubuntu Desktop edition you need to use the 64 bit Ubuntu 20.10 image as they never made a 20.04 desktop version for some reason. This really isn’t usually a big deal though because you can always choose the “Server” version and install Ubuntu’s desktop environment later with:
sudo apt install ubuntu-desktop
Once you’ve selected the edition you want go ahead and pick the “Choose SD Card” option and write the image. Despite not being a SD card my USB mass storage devices showed up anyway (writing the guide I used a StarTech adapter and a Kingston A400 SSD).
I’m sure some of you will manage to find unusual devices and configurations that may not show up in this tool. It doesn’t appear to show “fixed drives” that are physically installed in your machine. Regardless if it is causing a headache you may need to do it the old fashioned way and download the image from the main Ubuntu site and write the image using your favorite imaging tool instead.
Modifying Ubuntu for USB Booting
We need to make some changes to the Ubuntu drive we just created before we boot from it. Make sure your Pi is powered on and booted into Raspbian then plug in your newly imaged Ubuntu drive. We are going to make the changes using the Pi.
Find and Mount Storage Device
First let’s find your storage device using the command:
lsblk
This will show you all the storage devices attached to your system:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 256M 0 part └─sda2 8:2 0 2.8G 0 part mmcblk0 179:0 0 59.5G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 59.2G 0 part /
Your SD card will always start with mmcblk so you can rule that one out. That leaves sda as the only other disk device on the system. This will be the same for most of you but depending on what type of drive and storage adapter you use this can vary. You can substitute whatever yours is in place of /dev/sda in these instructions going forward. If yours is sdb use /dev/sdb. If it’s nvme0 use /dev/nvme0, etc.
In my output under the “MOUNTPOINT” column you can see it is blank. This means the drive isn’t mounted on my system. My mmcblk0p1 mountpoint though is not blank and is “/boot” as an example of a non-blank mountpoint. If you are using the full “Desktop” version of Raspbian it may have automatically mounted your drive and created 2 shortcuts on your desktop that will take you to the files. If your mountpoint is not blank and has something like /media/pi/writable go ahead and unmount them now using the following commands substituting the mountpoint listed for your drive:
sudo umount /media/pi/writable sudo umount /media/pi/system-boot
Now we are going to create two mountpoints and mount the Ubuntu drive. Use these commands substituting your own drive it is not /dev/sda:
sudo mkdir /mnt/boot sudo mkdir /mnt/writable sudo mount /dev/sda1 /mnt/boot sudo mount /dev/sda2 /mnt/writable
Once you have mounted everything correctly your lsblk command’s output should look like this with the mountpoint field now populated:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 256M 0 part /mnt/boot └─sda2 8:2 0 2.8G 0 part /mnt/writable mmcblk0 179:0 0 59.5G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot └─mmcblk0p2 179:2 0 59.2G 0 part /
Modify Mounted Partitions – Option A – Automated Script
If you just want to get your Ubuntu partition bootable I have made an automated script to do this. As long as you have mounted the partitions as /mnt/boot and /mnt/writable the script will make the necessary changes for Ubuntu 20.04 / 20.10 to boot! The source code for the script is available at https://github.com/TheRemote/Ubuntu-Server-raspi4-unofficial/blob/master/BootFix.sh
Here is a one liner to run the script:
sudo curl https://raw.githubusercontent.com/TheRemote/Ubuntu-Server-raspi4-unofficial/master/BootFix.sh | sudo bash
You may also download it for inspection (such as nano BootFix.sh or opening it in the Text Editor if you are using Desktop Raspbian) with:
curl https://raw.githubusercontent.com/TheRemote/Ubuntu-Server-raspi4-unofficial/master/BootFix.sh -O BootFix.sh chmod +x BootFix.sh nano BootFix.sh
To execute the script use:
sudo ./BootFix.sh
As long as you mounted your partitions correctly it will modify the partition and tell you that it was successful. Now unmount your partitions with the following commands:
sudo umount /mnt/boot sudo umount /mnt/writable
You may now shut down your Pi and remove the SD card from the Pi leaving just the USB mass storage device plugged in. Reconnect the power.
Modify Mounted Partitions – Option B – Manual Instructions
See bottom of the article for the manual instructions section
First Boot
If all went well the system should boot up into Ubuntu’s logon screen! The default credentials are:
Username: ubuntu Password: ubuntu
Before logging in for the first time you will be forced to select a new password. Once you have done that you will be fully logged in!
Important Note: Upon logging in for the first time if the Pi is connected to the internet Ubuntu will immediately/soon start a lengthy update process via snapd and apt. This can be annoying since you'll be ready to start configuring the system and if you do an apt install it will halt and wait for the updates to finish. It may seem like they're stuck, but if you use the 'top' command you will see all sorts of apt/package/update/extraction related activity happening. Even on my 8 GB Pi and a gigabit fiber connection these took a good 20 minutes or so before my CPU activity went back to 0 and the apt lock released. I highly recommend letting these finish and not yanking the power on the Pi / forcing a reboot / trying to kill the processes. It will often cause a ton of very nasty apt and dpkg problems to the point where it's easier to start over from a fresh image than try to fsck and apt install --fix-broken your way out of it Try to do other necessary configuration that doesn't involve apt in the mean time and let these finish in the background.
Once the patching is finished your shiny new Ubuntu 20.04 system is fully ready to use!
Manual Instructions
These are the manual instructions to recreate what the automated script does. If you used the automated script you don’t need to do anything further in this section unless you want to understand more about how it works or you want to do the process manually.
Decompress the kernel
We need to decompress the kernel as we will be changing the way the Pi is booting. Ubuntu uses u-boot by default and we will be switching away from that. We can do this with the following command:
zcat -qf "/mnt/boot/vmlinuz" > "/mnt/boot/vmlinux"
Update config.txt with correct parameters
Now let’s update /mnt/boot/config.txt with the parameters we need to load the decompressed kernel. Open up config.txt with nano with:
sudo nano /mnt/boot/config.txt
Change the [pi4] section to the following contents:
[pi4] max_framebuffers=2 dtoverlay=vc4-fkms-v3d boot_delay kernel=vmlinux initramfs initrd.img followkernel
Create script to automatically decompress kernel
We are going to create a script to automatically decompress the kernel. If we don’t do this we have to decompress it every time Ubuntu updates. This particular part of the script was not written by me and was found at the post on the Raspberry Pi forums by egrechko.
First let’s create the decompression script. Open up a new file with nano using:
sudo nano /mnt/boot/auto_decompress_kernel
Paste the following contents:
#!/bin/bash -e # auto_decompress_kernel script BTPATH=/boot/firmware CKPATH=$BTPATH/vmlinuz DKPATH=$BTPATH/vmlinux # Check if compression needs to be done. if [ -e $BTPATH/check.md5 ]; then if md5sum --status --ignore-missing -c $BTPATH/check.md5; then echo -e "\e[32mFiles have not changed, Decompression not needed\e[0m" exit 0 else echo -e "\e[31mHash failed, kernel will be compressed\e[0m" fi fi # Backup the old decompressed kernel mv $DKPATH $DKPATH.bak if [ ! $? == 0 ]; then echo -e "\e[31mDECOMPRESSED KERNEL BACKUP FAILED!\e[0m" exit 1 else echo -e "\e[32mDecompressed kernel backup was successful\e[0m" fi # Decompress the new kernel echo "Decompressing kernel: "$CKPATH".............." zcat -qf $CKPATH > $DKPATH if [ ! $? == 0 ]; then echo -e "\e[31mKERNEL FAILED TO DECOMPRESS!\e[0m" exit 1 else echo -e "\e[32mKernel Decompressed Succesfully\e[0m" fi # Hash the new kernel for checking md5sum $CKPATH $DKPATH > $BTPATH/check.md5 if [ ! $? == 0 ]; then echo -e "\e[31mMD5 GENERATION FAILED!\e[0m" else echo -e "\e[32mMD5 generated Succesfully\e[0m" fi exit 0
Create apt script to call kernel decompression script automatically
This is a one liner to create a script to call the auto_decompress_kernel script:
echo 'DPkg::Post-Invoke {"/bin/bash /boot/firmware/auto_decompress_kernel"; };' | sudo tee /mnt/writable/etc/apt/apt.conf.d/999_decompress_rpi_kernel
Verify Drive Performance
You can make sure everything is running correctly (and as fast as it should be) by running my quick storage benchmark. You can run the benchmark with the following one-liner:
sudo curl 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!
Fix (some) USB Adapter Problems Using Quirks
Some storage adapters don’t work very well with the Raspberry Pi 4. There is an option that can get a lot of them working using quirks. If your Ubuntu is booting to emergency mode but not in normal mode it’s worth giving quirks a try. 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 mode string to use we need to find the device ID string for your adapter and then add an entry to cmdline.txt telling the kernel to apply them on boot.
Find Your Adapter
To apply the quirks we first need to get the adapter id. We will use the sudo lsusb command:
$ sudo lsusb Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On line 2 we can see my ASM1051E SATA 6Gb/s bridge adapter (it’s the known working StarTech.com 2.5″ SATA to USB 3.1* adapter). You will see something very similar to mine when you run the command and it shouldn’t be too hard to figure out which device it is. If you need more information add a -v switch to make the command sudo lsusb -v. This can sometimes add some additional details to make it easier to figure out which one is your adapter.
If you’re still not sure, we have another command that between the two that can narrow things down. Type / paste the following:
sudo dmesg | grep usb [0.828535] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19 [0.828568] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.828597] usb usb3: Product: DWC OTG Controller [0.828620] usb usb3: Manufacturer: Linux 4.19.75-v7l+ dwc_otg_hcd [0.828644] usb usb3: SerialNumber: fe980000.usb [0.830051] usbcore: registered new interface driver uas [0.830182] usbcore: registered new interface driver usb-storage [0.836488] usbcore: registered new interface driver usbhid [0.836511] usbhid: USB HID core driver [0.971598] usb 1-1: new high-speed USB device number 2 using xhci_hcd [1.154217] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20 [1.154254] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [1.154281] usb 1-1: Product: USB2.0 Hub [1.301989] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd [1.332965] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 [1.332999] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [1.333026] usb 2-1: Product: ASM105x [1.333048] usb 2-1: Manufacturer: ASMT [1.333071] usb 2-1: SerialNumber: 123456789B79F
This is the dmesg log showing the hardware detection as hardware is activated on the Pi. If your log is really long you can generate fresh entries by just unplugging a device and plugging it back in and running the command again. Here we can clearly see that the ASM105x is what our StarTech adapter is being detected as.
Now we can go back to our first lsusb command and we want the 8 characters from the ID field that comes right after the Device:
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge
Our adapter’s ID is: 174c:55aa
Applying Quirks
To apply the quirks to our USB adapter we are going to edit /boot/firmware/cmdline.txt. Type:
sudo nano /boot/firmware/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 dwg_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc
Now reboot the Pi. If the Pi fails to boot you can plug the SD card into the computer and go to /boot/cmdline.txt and undo the change we did so you can boot back in with your SD card.
Verifying Quirks
Once you have rebooted after changing cmdline.txt we can verify the quirks have been applied by doing another dmesg | grep usb command:
sudo dmesg | grep usb [1.332924] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 [1.332957] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [1.332983] usb 2-1: Product: ASM105x [1.333006] usb 2-1: Manufacturer: ASMT [1.333028] usb 2-1: SerialNumber: 123456789B79F [1.335967] usb 2-1: UAS is blacklisted for this device, using usb-storage instead [1.336071] usb 2-1: UAS is blacklisted for this device, using usb-storage instead [1.336103] usb-storage 2-1:1.0: USB Mass Storage device detected [1.336479] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000 [1.336611] scsi host0: usb-storage 2-1:1.0
This time we can see in dmesg that UAS was blacklisted for the device and it has loaded with the usb-storage driver instead. This driver tends to be more compatible with the “problematic adapters” but the performance is usually significantly lower. It’s definitely worth a try though as some adapters do better with the quirks performance-wise. The only way to know for sure is to run a benchmark (see “Verify Drive Performance” section).
Other Resources
I compiled the 2022 Raspberry Pi Storage benchmarks which shows the fastest storage devices for the Pi
For easy headless imaging (does support Ubuntu) check out my Headless Raspberry Pi configuration guide
To find out where to get the 64 bit version of Raspberry Pi OS: where to get the 64 bit Raspberry Pi OS image
To find out how to add a UPS backup battery to your Pi check out my UPS for Raspberry Pi guide
THX for the guide.
I can confirm, the one liner script also works with Ubuntu Server 22.04
Hey BassT,
Thanks for confirming, enjoy!
I figured out something more;
with eeprom (latst stable) from 26.4.22, I do not need to change anything on the ubuntu disk (new made with pi imager). Only thing I changed is to add “BOOT_ORDER=0xf14” in eeprom-config file.
So external Drive work out of the box 😉
Chears
Hey BassT,
Yes Ubuntu does require the latest firmware to boot from SSD/USB for sure. Updating your enclosure and SSD firmware is also sometimes necessary!
Hi James,
Thank you very much for the detailed write-up. I managed to get my pi4 booted with a usb SSD ubuntu with your instruction before, but I accidentally lost SSH access and decided to reinstall the whole operating system on my SSD, but no matter what I do, I just can’t get it to boot again anymore. I get a solid green light if booting through usb3 or a 7 blinks green light through usb2.
Any ideas what’s going on? The SSD boots fine if it was a pi OS image on it.
Hey Fast Eater,
Great question! It’s actually even easier to get them to USB boot now than it used to be because in 20.04.2 or somewhere around there they did a bunch of fixes for this.
What happens though for people running Ubuntu is that your Pi’s firmware never gets updated. The first thing I would do is install Pi OS (or use one of the images you have that will boot from it from your testing) and do a:
sudo apt update && sudo apt full-upgrade -y
The “full-upgrade” part is important as that is what triggers the firmware updates. You can further confirm it has updated you to the latest version by running
sudo rpi-eeprom-update
which should spit out your current firmware version.
The next thing you should do is completely wipe the SSD. Old partitions can sometimes cause boot issues like this.
Those are the two most important things to try first. There is almost nothing to SSD booting Ubuntu now after around 20.04.2. It’s actually natively supported now. You can actually just image the SSD with the latest Ubuntu and it will boot with no additional changes.
That is only with the absolute latest firmware though and the last couple of people I’ve spoken to that had this happen with Ubuntu both had outdated firmware (as Ubuntu does not upgrade this routinely like Pi OS does so it’s normal). I’d definitely give those a try first here.
The other thing is if you have the latest firmware the Pi actually has a startup UEFI/BIOS looking menu. This will tell you what it is trying to do while it is booting. If you are not seeing this then you absolutely do not have the latest firmware. If you aren’t hooked up to a monitor it may be good to hook up to one and see what messages you are seeing during boot (as there should be some with the latest firmware). Hopefully that helps!
Thanks!
Hi James,
thank you very much for your blogs, they are so useful. I have a RPi4 with a Crucial MX500 2TB SSD in an Inateck FE2011 USB 3.0 enclosure, which I’m using for Eth2 staking. The staking is quite disk I/O intensive, and after 13 months my disk health according to hdsentinel is at 81%. I’m experiencing some random system hangs (maybe once per 2 weeks) which seem to get more frequent as the disk fills up (now at 60%) and improve if I prune the data. I made a reddit post here also and it seems that the lack of TRIM support from the FE2011 seems to be very problematic. A user there posted some firmware update process enabling TRIM, which is for the UA1002 but seems to have the same chipset. My lsusb output shows device ID 174c:55aa which is the same with other brands reported (StarTech etc?) What are your thoughts on this?
Sorry just realized that I might have posted it into the wrong place, maybe a better place to discuss this is here
No worries at all! There’s a lot of crossover between these posts and I often end up referring people between the two depending on what topics we are covering / what the issue is for sure.
Hey Panos,
Great questions! I think you’ve diagnosed this really well. You are definitely correct about everything here.
To explain what is happening basically when you delete something from the SSD it’s not really deleted. It’s just marked as “free space”. The data is still there however.
This means that when your drive wants to write something in that free space there is an additional operation now of *actually* deleting the data. This takes time. Noticeable time as you’ve demonstrated / seen.
The TRIM operation actually zeroes out all free space on the drive all at once basically ahead of time. This makes writes much faster as it no longer has to delete that old data that it left sitting there from before. It is able to just write them directly to the drive with zero delays. There are lots of adapters with broken TRIM support and this is definitely one of them.
Windows actually has this too. If you click to “optimize drives” it is actually running the TRIM operation when it’s a SSD (instead of a defrag like with a HDD). It’s (usually) automatically enabled in modern Windows (I want to say weekly) as a scheduled task. This exact same issue can happen there too. If you don’t have TRIM support within Windows it will tell you the drive cannot be optimized (essentially the same situation you have on Linux now).
I searched my storage benchmark site pibenchmarks.com for Inateck. There are definitely a lot of people that did get these working. I see lots of FE models but not your exact one. I should probably start testing or parsing to see if TRIM is enabled as a part of the benchmark as that would be a very useful addition to the storage benchmark.
I would say if you try Jeff Geerling’s steps and it won’t enable TRIM then it’s worth trying the generic flash (generic flash meaning you are flashing your adapter with another manufacturer or model’s firmware since there isn’t any available). There is some risk of the adapter having worse behavior afterward. I think in this case though you are going to have to replace that adapter if you can’t get TRIM enabled as it is causing you actual problems. We’ve only had a few cases where people started having some strange issues after trying a generic flash. Often it does nothing. If it’s close enough to the other firmware though we definitely have seen successful TRIM fixes.
I don’t think you have a lot to lose here. The worst case scenario is you will end up having to get an adapter that is TRIM compatible but judging by how many benchmarks are on pibenchmarks.com for these Inateck adapters I think it’s worth a try for sure. It’s possible none of them have TRIM enabled either but this topic has come up before and people have definitely had success fixing this issue in the past.
Hopefully that helps!
James,
thank you very much for you detailed reply. Yes I tried Jeff’s instructions but I get from the sg_vpd -p bl /dev/sda command I get:
Maximum unmap LBA count: 0 [Unmap command not implemented]
Maximum unmap block descriptor count: 0 [Unmap command not implemented]
which indicates that TRIM is not supported by the firmware (although it could be supported by the disk itself). I would definitely try flashing another firmware (do you think this will work even it was made for a different brand?) but I am a bit hesitant, as if anything goes wrong that could mean 2 or 3 weeks of downtime for my staking. I have ordered a StarTech SATA – USB 3.0 cable and will make a backup image from my drive before I proceed..
Hey Panos,
I would for sure wait in that case. We haven’t had anyone brick one yet on the site but I’d hate for yours to be the first on a staking machine. The StarTech should be a great adapter and support 100% of these features for sure.
To answer your question on whether it would work to flash another manufacturer’s firmware the answer is possibly. I tried to see if anyone had tried this with Inateck on the site and the closest I got was this post from 2 years ago. They didn’t end up going through with it ultimately and almost all of them ended up getting the StarTech in the end and never had a problem again pretty much.
There’s also the possibility it could make things worse. Like I said we’ve never had one brick but we have had one that started having issues when certain versions of USB devices were plugged into it here. In this case flashing the Sabrent firmware to a ELUTENG adapter made Paul start having some strange issues. Paul was willing to kill his adapter before trying this (and openly stated so).
For an example of it working. Another one is here (and this was actually a generic flash with the ODROID forum’s firmware).
I definitely couldn’t in good conscience recommend doing this in your situation although I’d love it if once the StarTech arrived you’d try it to see what would happen. Since we don’t have any reports for trying this with a Inateck yet though it’s definitely risky and I wanted to make that clear. I’d for sure wait for a staking machine and then try it once it comes would be my recommendation!
James,
thank you again for your detailed reply. I will follow up after I receive the StarTech for those experiments!
No problem at all! I think you are just waiting for that adapter to arrive and you will have 100% fully diagnosed and fixed this issue. It may be smart to wipe it and set it up fresh as there’s a chance there could be some preexisting disk corruption from the previous incidents but this may or may not be possible depending on what kind of mining/staking device we’re talking about.
I look forward to seeing how it turns out!
Hi James,
Its Bruno from Taiwan
you blog is such its name, Legendary
recenterly I had to do so work on RPI4, and this article is very useful and helpful.
may I forward your article from your website and translate to chinese in some private tech group?
I will note the source came form.
Hey Bruno,
I absolutely give you my permission to do that! I am actually listed on Baidu in China which was not easy for an American/Westerner and my account has like several identity red flags (I can’t verify as a person with all the ID #s and business #s they want) but it still lets me submit limited materials. It says I only get about 12 hits per week from Baidu (site-wide) according to my analytics and I’m sure a translation would be seen by many more people than this.
I’d love if you wanted to translate this / distribute it. I understand that as an American my reach into the “Eastern” world is limited due to both language and culture. I like to do everything I can to overcome this as all people in this world are worth reaching.
I would gladly accept if you’d be willing to do this and you can distribute it wherever you’d like to. Definitely feel free to do this!
It’s kind of political, as a Taiwanese, China’s Baidu is not the popular website for us. If you interesting, yoe can search Taiwan and China.
I feel sorry you are listed on Baidu and those flag, unfortunately, me too LMAO. even a Chinese may not know the reason.
the article you shared is surely helpful for all people in this world, and I will make this power can spread out in more place.
Thanks, keep in touch.
Hey Bruno,
That helps to know! I basically had just looked for the most popular international search engines and tried to list at all that I could but Baidu was absolutely by far the hardest. I can imagine that being Taiwanese would put you in an interesting grey area in some of these systems like this just due to history but I won’t pretend to understand it or even know the half of it.
I will say I would love to come and visit both Taiwan and China some day as I’m aware that my understanding of what it is actually like there through my cultural lens is most likely a mind-numbingly dumb and possibly even offensively stereotyping skewed view of what it’s really like. That’s why I’d love to see it for myself!
Thank you again and please definitely keep in touch as well!
Hi James:
I’ve tried your script a few times. I get the same results each time. it’ll do a first boot but not a reboot. I have it up and running now on a first boot and I’m afraid to turn it off. Any advice?
Hey Kevin,
Typically you don’t need to run the script on the newest versions if this is newer than 20.04.2 or so (I think that was when they finally fixed that).
Are you doing a:
sudo apt update && sudo apt dist-upgrade
before rebooting for the first time? If the answer is yes then your Pi may just need a firmware update to load correctly. I have a guide to update the firmware available here. I would try it without running the script and see if it will boot as well.
If the answer is no I would try that for sure as that should pull the latest versions down which should definitely boot correctly. Did you try the latest and that didn’t work and that led you to trying the script by chance? If so I remember someone else having that exact issue before a Pi firmware update (it might even be here in the comments too) so I would try that very first!
Bingo!!!
Thanks for the help!
Hey Kevin,
Excellent, I’m glad that got it for you! Take care!
I’m using Ubuntu 21.10 w/ kernel 5-13 btw
Hey James, thank you so much for putting this together! Looks like my rpi is booting correctly as I can see an “ubuntu” dhcp client id going through and acquiring an address. However, I’m doing a headless install and didn’t put much thought into how I would log into the pi after first boot. (facepalm) I was planning on migrating the content over once I had the boot from USB up and running (which it is). Is there a recommended way of migrating the users/passwords over? Can I simply copy /etc/[passwd,group,shadow] and /home from the SD to the USB? I only have a 2 users setup (other that system users) and I imagine this would do the trick, unless things have changed significantly between 20.04 (on the SD) and 20.10 (on the USB).
Hey John,
You have a few options that are totally possible to do from the SD card. Check out this guide on methods to configure Ubuntu headlessly here.
You will skip to approximately the middle part of the guide I linked which is the configuration part. You could configure the network-config file by placing a file on the SD card for example. If this is Ubuntu Server it probably will have SSH enabled automatically. If you can give it a network configuration that should probably do the trick.
Here’s a bonus guide which contains some more information on correctly preconfiguring (by creating files on the SD card before boot) netplan (tricky but mostly due to the fact that .yml files are tab and space sensitive and one wrong character breaks them so just be careful with spacing/tabs) and configuring SSH / remote access enabled upon boot here in this guide as well. I think this will be the easiest / fastest option probably. Hopefully that helps!
Thanks for the links. Invaluable! I’m no stranger to yaml (ansible, k8s, etc) and somewhat familiar with netplan. I’m setting up a 12 node cluster, so that second link will come in very handy. Once I have the first one booting correctly I’m planning on doing it another 11 times and hopefully not have to attach a monitor / keyboard (assuming none of them goes sideways straight out of the box). I did toy with the idea of creating a PXE image to start the installation, but I’d still have to boot each one of them at least once from the SD, run raspi-config to enable booting from network but at that point it starts to become more work than its worth. I think prepping the USBs prior to boot may be a straighter shot.
Thanks again!
Hey John,
No problem at all! I don’t think you will have any trouble since you have experience with bulk configuration and especially YAML. You should be able to do exactly what you want to do once you get a syntactically-correct YAML config file.
I do almost all of my Pi setups headless to be honest. It’s great for the Compute Modules as well. It’s honestly a little easier on Raspberry Pi OS since on that one you just create a wpa_supplicant.conf file and don’t have to deal with the YML syntax but it’s honestly not too bad if someone gives you the heads up that it’s super sensitive to spaces / tabs and one wrong one breaks them. Once people know that they’ll be careful and if something is wrong they’ll know the first place to look at least.
I’ve struggled with some of the same questions as you when doing bulk deployment. I also weighed PXE/an imaging server but honestly once I was able to solve the exact problem you are working on with essentially a preconfigured image that I was able to fully headlessly deploy I found it to be efficient enough to not ever go through with setting up something like PXE.
There’s still situations where PXE makes the most sense for sure. The Pi definitely does support PXE booting now right in the main bootloader firmware (if you have your firmware up to date) so it’s absolutely an option (without having to do anything strange or extraordinarily difficult that is, it’s just supported now at the firmware level but that didn’t used to be true).
The easiest way to preconfigure them would probably be the Raspberry Pi Imager. It has an option to apply the bootloader settings via a SD card image (to find this option open the Pi Imager and click the button to choose an operating system and go to “Misc Utility Images” –> “Bootloader” –> “Network Boot”). This means you would basically make a SD card image with the Pi Imager that all it will do is change the boot order to boot from network/PXE.
You would stick it in each Pi and turn the power on and after a few seconds (like 3 seconds or less) it will blink letting you know it’s done. This still requires one SD boot to change it initially but it’s not even a full boot into an OS and is definitely a lot less steps and work than manually going into raspi-config and setting them to PXE boot one by one.
It’s also an operation that is already headless-friendly as there is nothing to really see on the screen during this operation (the entire screen might turn from black to one shade of solid bright green when it finishes I vaguely recall, I’ve only had a monitor connected a few times by coincidence as it is not necessary) and you don’t have to interact with the Pi at all. The status lights on the board are used to communicate during this operation as it’s basically meant for situations like this.
You’d then remove the power and plug the power back in and it should go right to PXE. I could see this not adding much more effort than it would take to go plug them in initially as this would just add a little 5-10 second dance the first time you power them on essentially of sticking the card in there for a few seconds and then power cycling it again when it’s blinking to tell you it’s done and it’s good to go. Applying a USB boot mode this way is also possible although USB booting has been at least a fallback option by default for a while now but I thought I’d mention it.
Best of luck and let us know how the build turn out!