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
Hello Jim, just wanted to say thanks for this info and script. I to have the Argon M.2 case with a Kingston 240 gig Sata SSD. The Argon M.2 will not do NVMe. I installed 20.10 desktop using your instructions and script with no problem. Then I chickened out and felt I wanted LTS. So I did server then installed the desktop so far so good. Now I just need to figure out turning overscan turned oh on my 4K monitor and I should be good. I plan to make this my developers workstation per DroneBot Workshops guide 🙂
I’ll let you know if anything goes nutty 🙂
Thanks again really appreciate it.
Hey Kyle,
Thanks for letting us know about the Argon One case not supporting NVMe!
I totally understand about using LTS. I basically always use LTS on the desktop and for servers! It can be frustrating when the changes to support new Pi stuff take a lot longer to make their way to it but I expect this to continue to improve over time.
For your overscan issue I have heard of issues like this on ultra high resolution displays like 4K including it ignoring the overscan configuration settings. I believe you have a couple of options. Most displays that are in that category have ways to disable overscan although it’s usually called something different in the options. It may be worth googling your model of TV and seeing if there’s a way to disable overscan from the TV side on your model.
You could also try setting the overscan manually. This is an older workaround for buggy TVs and from times when 4K support was very poor. Check out this thread and the last reply to see how you can set essentially a manual override and set your own overscan settings to the pixel.
Definitely let us know how the developer workstation and your config works out!
James
I’ve followed your tutorial on installing Ubuntu 20.04 on my Pi4.
When I try to boot the new OS from the Samsung BAR Plus flash drive, the installation proceeds until it hang on the login after printing information about cloud-initial.
I am using my iPad as a wireless hotspot and it’s clearly not connecting. I did not have this issue when I originally installed 20.04 on an SD card.
When I did that installation and installed the imager to the SD card the Ubuntu tutorial stated that the network-config file on the card had to be modified to include my network name and password. So I did the same on the USB drive, however, as I’ve said, it appears the installation on the USB drive hangs because the internet connection fails.
I do not have access to an Ethernet connection to the Internet.
Any suggestions as to how I can get the installation to recognise my hotspot Internet connection?
Hey Rob,
Would you be willing to try 20.10 as a test? I’m curious if you will experience this behavior on both versions.
It’s tricky because normally I would say to manually connect using the command line tools but they aren’t installed by default in Ubuntu.
If you press Ctrl+C can you get a command prompt to log in even if it’s stuck on cloud-init?
James
Thanks for your reply and suggestions.
I should have added to my original reply that I found the explanations and instructions in your tutorial extremely clear and helpful.
I should also have added, by way of explanation, that I am currently using my RPi4 running Ubuntu desktop over Ubuntu 20.04 OS on a trial basis in parallel to my Windows 8.1 desktop with the intention of eventually dumping the Windows 8.1 desktop. Consequently, I am experimenting with the Pi4 and have loaded several apps and configurations. I was hoping to boot from the USB and copy my configuration from my working sd card, rather than a new installation.
Following your suggestions, I decided to do the following, in order:
1. Try, again, to load from the USB that is causing the issue. It failed again.
2. Copy the sdf2 writable partition from my currently operating sd card using the ‘dd’ command. The result was that the Pi4 booted to the Ubuntu desktop login screen, but I could not log in as the keyboard and mouse were inoperative. I noticed during that startup that numerous other features failed.
3. Finally, I decided to do a complete reinstall. I downloaded and installed the Raspberry Pi4 OS (64 bit edition). Although I’m unsure whether it made any difference, I also followed the suggestion to select the boot from USB option in the Raspberry OS raspi-config file before removing the sd card.
I then erased the USB drive using the Raspberry Imager on my Windows desktop then downloaded the Ubuntu 20.04 (64 bit) OS image. I made the changes advised by the Ubuntu installation tutorial to the network-config file using a text editor to allow installation over wi-fi.
When I removed the sd card and inserted the USB drive and started the Pi4, to my surprise, it successfully went through the installation process. It did hang again over the cloud-init comment. I waited for several minutes, then hit enter. Immediately, the login screen appeared. I logged in, changed the password, then completed the installation, then installed Ubuntu desktop.
I did have to then configure my 50-cloud-initial.yaml file to enable File Manager to manage my wi-fi hotspot connection through both my iPad and iPhone.
Although I had to then reinstall apps and configure my system again, I now have a Ubuntu 20.04 LTS OS that is happily booting from my USB device.
I also have the same configuration on my original sd card as a backup, which still works.
I haven’t measured the performance improvement, but the USB boot is noticeably quicker.
I have detailed my experience in the hope that it might assist and or encourage others who want to experiment with the RPi.
Thanks again for your assistance. Truly appreciated.
Hey Rob,
That’s a very interesting sequence of steps you went through and I’m glad you got it to a better place! I’d be curious what your raw performance numbers would break down to but it’s definitely a good sign that you can feel the performance difference and just tell without measuring it.
Thanks for posting such a detailed explanation of your steps, this will no doubt help others as well!
James
I went to do the performance tests that you mentioned, but did an update and upgrade first.
When I did the upgrade, I received the following response, which I suspect is related to the changes to the USB boot.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up initramfs-tools (0.136ubuntu6.3) ...
update-initramfs: deferring update (trigger activated)
Setting up flash-kernel (3.103ubuntu1~20.04.1) ...
Using DTB: bcm2711-rpi-4-b.dtb
Installing /lib/firmware/5.4.0-1028-raspi/device-tree/broadcom/bcm2711-rpi-4-b.d
tb into /boot/dtbs/5.4.0-1028-raspi/./bcm2711-rpi-4-b.dtb
Taking backup of bcm2711-rpi-4-b.dtb.
Installing new bcm2711-rpi-4-b.dtb.
flash-kernel: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.136ubuntu6.3) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-1028-raspi
Using DTB: bcm2711-rpi-4-b.dtb
Installing /lib/firmware/5.4.0-1028-raspi/device-tree/broadcom/bcm2711-rpi-4-b.d
tb into /boot/dtbs/5.4.0-1028-raspi/./bcm2711-rpi-4-b.dtb
Taking backup of bcm2711-rpi-4-b.dtb.
Installing new bcm2711-rpi-4-b.dtb.
Installing /lib/firmware/5.4.0-1028-raspi/device-tree/broadcom/bcm2711-rpi-4-b.d
tb into /boot/dtbs/5.4.0-1028-raspi/./bcm2711-rpi-4-b.dtb
Taking backup of bcm2711-rpi-4-b.dtb.
Installing new bcm2711-rpi-4-b.dtb.
flash-kernel: installing version 5.4.0-1028-raspi
Taking backup of vmlinuz.
Installing new vmlinuz.
Taking backup of initrd.img.
Installing new initrd.img.
Generating boot script u-boot image... /usr/sbin/flash-kernel: 553: mkimage: not
found
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 12
7
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
initramfs-tools
Files have not changed, Decompression not needed
E: Sub-process /usr/bin/dpkg returned an error code (1)
I’ve tried autoremove, autoclean and forced upgrade, but still get this response.
Can you suggest a fix?
Regards.
Rob
That looks like it’s possibly an issue with your “boot” partition. On Ubuntu that partition is mounted in /boot/firmware which is where flash-kernel is copying updated files to. I would run a full fsck on both the boot partiton (usually /dev/sda1) and the root partition (/dev/sda2). Clear any issues and remove the “dirty” bit if it is set otherwise the partition will be mounted as read-only. You can verify this yourself by going to the /boot/firmware folder and seeing if it lets you change any files (you can try editing config.txt as a test). If it says it’s read only your partition is damaged and needs an fsck.
Yours is a little strange because I’m also seeing a line that says the “mkimage” utility was not found. You should have this already I believe as I have never had any trouble upgrading them and nobody else has reported this issue but usually the mkimage utility can be installed with:
sudo apt install u-boot-tools
It has been years since I’ve had to do this but that used to be the package. It may be worth grabbing that and seeing if flash-kernel can finish successfully after that. If it isn’t letting you install anything (for example if apt is broken and won’t work until this is resolved, often the case in situations like this) you can try to resolve it with a:
sudo apt install --fix-broken
and let it remove whatever packages are causing the conflict breaking apt so you can download this package. At that point try upgrading again (make sure you didn’t skip the fsck, that is a very nasty looking error that a lot of others would be getting unless this is a very recent change).
Definitely let us know!
James
Thanks again for your suggestions.
Being impatient, I tried various solutions, including removing previous Linux-images, fixing broken packages, forced install, etc, with no resolution.
What does appear to have resolved the issue (so far – fingers crossed) was to:
sudo rm initramfs-tools
sudo apt clean
sudo apt autoremove
sudo apt install initramfs-tools
This was one of the solutions mentioned on askubuntu
I’ll let you know if the solution hold.
I also ran the performance tests. In summary, the score for the SanDisk High Endurance 64GB SD card was 1,130 and the Samsung BAR Plus 3.1 USB drive was 2,830. A significant improvement with the USB drive.
I hope this information assists others who encounter a similar issue.
Regards.
Rob
Very nice score, that is a significant improvement!
It sounds like you had a corrupted package in your apt cache. It may have also been one of the dependencies that got cleaned by your sudo apt autoremove after removing initramfs-tools. Very nice tricks!
That original error you posted took me pretty far back in time as well to the Pi 3 era etc. with the mkimage utility. I would not at all be surprised if this is a known issue in Ubuntu that has been fixed in newer versions. The 20.04 64 bit server image is the most finicky/worst working so far of the lot (even the 32 bit 20.04 images were easier to get working correctly)!
It must not happen to everyone but it has happened to other people that I was able to find references to so it’s great that you’ve posted this here as I’m sure someone out there is also going to get burned by this. Thanks again for your feedback and all the tips you’ve left to help others!
James
Couldn’t help myself, so I’ve used the dd command to copy my whole system from the Samsung BAR Plus 3.1 USB drive to a Kingston A400 240GB SSD with the StarTech USB adapter that I bought today and the performance score has gone from 2,830 (Samsung) to 7,035 (Kingston) – a further significant improvement.
Seems to be functioning correctly, except that I had to extend the writable partition (sdg2 on my system) on the Kingston SSD from 64GB (on the Samsung) to 240Gb on the Kingston BEFORE I did the dd copy. My first effort by not extending the writable partition first was that I stuffed-up that partition trying to extend it AFTER the dd copy.
Thanks again for your extremely helpful tutorial and subsequent support.
Rob
Fantastic results Rob! That’s very interesting results copying with dd. Going from a 2830 to a 7035 is literally a different league of performance!
I’m very happy with those results and 7000 is a great score and puts it among the higher performing drives!
I had the same experience (Ubuntu on Raspberry Pi 4B), same initramfs error message on upgrade, your solution fixed it for me.
Thank you very much.
Hello James
Thanks for the reply. I did find that installing server then desktop left a lot of things lacking, so reinstalled 20.10 and found that to be much more complete and it seemed a good fit for running 64 bit. My issue became the resources that were being used made using it trying. Each core of the CPU ran from 15% to 60% all the time. I let it sit for awhile to see if things were just “settling in” but it just kept going. The Pi was running much hotter than normal it seemed too. Unfortunately I reverted back to PiOS for the time being and will come back to this later. It is nice having a full desktop but just too slow. By the way I am using a 8Gig Pi with Argon 40/M.2 addon case. I’ll check back later to see if maybe I messed something and you can point me in the right direction. Thanks again this is a great tutorial you’ve done here.
Hey Kyle,
That sounds about right. On Kali Linux there is an apt command of apt install kali-linux-full which installs the full suite. I don’t think Ubuntu has the same thing though such as a apt-get install ubuntu-desktop-full unfortunately which would install the rest of the default full-featured desktop experience vs. upgrading to desktop with apt.
It’s interesting that they don’t have a desktop 20.04 image in the Raspberry Pi image tool or on their web site. I think they don’t even offer it because of this issue. It was also significantly tougher to get 20.04 64-bit to boot than just about any other one of the images so it doesn’t seem as well supported for desktop.
Thanks for letting us know your experience, I’m sure it will help others as well who may be weighing these same options!
Thanks so much for this tutorial! Confirmed that Ubuntu MATE 20.10 also boots from USB natively (maybe not surprising to many). Also, may be obvious to others, but I still had to:
sudo nano /etc/default/rpi-eeprom-update
FIRMWARE_RELEASE_STATUS="stable"
sudo rpi-eeprom-update -a
sudo -E rpi-eeprom-config --edit
BOOT_ORDER=0xf41
under Raspberry Pi OS before the Pi would boot to USB. The “rpi-eeprom-config” change was mentioned in the previous tutorial, but missing from this one.
Now booting successfully using the Argon One M.2 case and Samsung 860 EVO M.2 SSD.
One issue I’ve encountered (may be specific to the Argon One or may be common to USB boot in general) is that the Pi will freeze whenever it is put into suspend (automatically through power management, or manually from a menu), requiring a hard reset. I haven’t confirmed if this is the case with USB boot generally.
Hey Chad,
Thanks for letting us know! I actually have never tried Mate with this method so your information is very helpful. Mate is on my to-do list to try!
Hey James thanks for this. One issue I’m having is when imaging ubuntu 64bit 20.04 server to a 4tb ssd with the raspberry pi imager, ubuntu is only using 1.7tb (about half the drive). lsblk shows the disk as being 3.7tb though but root partition is only 1.7tb. Is there a way to use the entire drive? Everything boots fine it’s just that one issue.
Check if it is using LVM – my Ubuntu 20.10 server installation used LVM and only setup about 200GB on a 1TB drive. Here’s what I did:
# View the current logical disk space
sudo df -h /home/
# **Avail** column is disk space remaining on this logical disk
# View the disk’s LVM disk space
sudo pvs
# **PFree** column is remaining disk available to you
# See Logical Volume info
sudo lvdisplay
# To extend your logical disk to use all available space do the following…….
# Extend your logical volume – the last arg is the Filesystem in df -h command
sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
# Resize the Filesystem to match – the last arg is the Filesystem in df -h command
sudo resize2fs -p /dev/mapper/ubuntu--vg-ubuntu--lv
# see that it worked – **Size** should now be larger
sudo df -h /home/
Wow, very interesting!
So traditionally Ubuntu has performed resize2fs as part of the initial setup. I wonder if this step isn’t happening for some reason or is picking wrong values for larger drives. Maybe it’s expecting a SD card and isn’t properly resizing a SSD since you two seem to have widely varying sizes of hard drives and both did not use the full space.
It must be performing some sort of resize step since you both ended up with different size partitions. Maybe the LVM partitions are based on values that don’t make sense outside of SD cards or with very large sizes?
Thanks for posting these steps, these look pretty painless!
Ok I figured out the issue. The rpi ubuntu images use MBR instead of GPT disk partition tables, and MBR only supports 2tb or smaller drives. As far as I can tell there is no way to boot from larger than a 2tb disk with ubuntu rpi image. Raspberry pi os does support GPT but ubuntu rpi images do not. That is a shame. If you want to use ubuntu on a 4tb disk you will still need an sd card to boot from and move root to the usb disk, same as the old way.
Great discovery minnix!
I actually had not tried this on a > 2 TB drive. This is a little disappointing for sure (it never feels good to have unprovisioned disk space or to not take full advantage of hardware due to technical limitations) and hopefully this will get addressed now that USB booting is officially released.
They definitely need to fix that and update the base images to not require so many tweaks/modifications to get them to boot in the first place! If I were to guess we will probably see changes like this for the first time in whatever comes after 20.10 with 20.10 itself being the second most likely place for them to show up first.
Historically the changes haven’t been backported to other versions but technically other versions weren’t “officially supported” at the time so I would love to see all these things fixed in the images and backported all the way back to LTS!
There is an alternative if you’d like to use a 64bit OS with a disk over 2tb. Akeo (the creator of the Rufus disk imager) has laid out a method to install Debian bullseye using the netinstall iso directly to USB drive. Basically you format the drive with gpt partition table and create about a 350mb bootable partition (esp fat32, or in fdisk just use option 1 which is EFI partition which is what I did), then copy over the contents of the latest RPI EFI firmware and the contents of the debian netinstall iso into the new partition as well. Plug in the drive and turn on the Rpi 4 and you will be greeted by the debian installer, no SD card needed. Worked fine for me. He laid it out on the rpi forums.
I kind of prefer this to ubuntu as I don’t need a desktop (even though you can install one if you’d like) and wanted something light and fast for server usage.
That’s a very clever trick by Akeo. I’m definitely familiar with Rufus and have used it countless times over the years!
Thanks for sharing this. I have actually had fantastic experiences with Debian on the Pi. It was even a fantastic experience back on Debian Jessie! I’m sure it’s in part because Raspberry Pi OS / Raspbian is a derivative of Debian and is basically downstream from it but it’s a fantastic experience and I could see why you’re possibly even beginning to prefer it now!
I did a default 64-bit Ubuntu Server install, and it must be doing this as some sort of almost thin provisioning, allowing me to choose later if I want to expand the same volume or alternatively make a separate/additional volume. But it seems backwards from previous experience. I had this just happen on five X64 systems with 3 different disk sizes – all made a single 200GB volume, leaving the rest unallocated. Weird.
Hi James! Thank you very much for the guide, it is really helpful.
Just somethings i’d like to add hoping they can help others to overcome any issues with the installation process. I followed the guide using a Raspberry 4b 8Gb, using both scenarios, meaning flashing a USB 3 stick with Ubuntu Server 20.04 with Etcher and Raspberry imager, i had a boot issue in the last step where the PI complained about the SSD not being inserted, to fix this i was missing to set the option “Boot with USB if SSD is not present or has a problem” under the Advanced menu in raspi-config.
Enabling this allowed the boot from the USB as expected. There is some UDEV issue on boot where some process gets stuck and it takes around 3mins for it to resume loading Ubuntu, more about it here.
The solution was to run
systemctl mask systemd-udev-settle
. After the system boots there is no ETH0 connection, the ethernet card simply won’t work but what i did is connect my raspberry to my wifi and run a distro-upgrade, after upgrading the system it seems that netplan gets fixed and automatically you get ethernet working along with wifi.Hey Andres,
Thanks for the great tips! I think the reason that is fixing your ethernet is that it’s upgrading the firmware. Whatever firmware is shipping on Ubuntu 20.04 64-bit (funny enough the 32 bit one works) is way too old to USB boot Ubuntu and have networking. Again.
I say again because I’ve had to fix their images for years to be bootable with all accessories working and unfortunately it looks like 20.04 isn’t going to change that. See my Raspberry Pi 18.04 precompiled image to see the lengths I had to go to previously to get everything to work! 20.10 is a much better experience and doesn’t need any of this.
I’d rate LTS support (especially 64-bit) as EXTREMELY poor on the Pi (not even USB bootable with ethernet still in 2021) but people need to use it for a bunch of various reasons so I’ll provide a fix here. It’s definitely not the “LTS” experience of desktop. The newer one you use the better your Pi will work at the moment (which is pretty much the exact opposite of x86_64 Ubuntu). You’ve done very well getting all those fixes in there!
I’m going to make the script update the firmware for 20.04 64 bit here but it’s definitely pretty janky compared to if Ubuntu would just update their base images. It’s basically a hack, where I copy the 20.10 firmware over the top of the 20.04 firmware. It would be better for everyone if they would update it themselves but it doesn’t look like it’s happening any time soon! They *never* updated 18.04 or any of those images but now that they’re officially supported maybe they’ll recompile a new base 6 months to a year from now.
That is a really interesting solution with masking systemd-udev-settle, thank you for sharing! I have not seen that fix before and it will definitely help a lot of people out!
Hi James,
I followed your example using an RPi4 8Gb, installing rOS first and ran the RPi Imager choosing 20.04 LTS Server 64bit, installed it on myUSB3 SSD. Success. Then I did the manual steps regarding lsblk and finally ran the script. Success. Removed SD for booting Ubuntu…
It stop with a “Kernel Panic – Not syncing! : Can not allocate SWIOTLB buffer earlier and can’t now provide you with the DMA bounce buffer”
Any suggestions?
Hey Stigh,
I think someone else was recently having trouble with the 64 bit Ubuntu 20.04 image as well. I need to get it fired up on one of my Pis and see what has changed. It could also be your storage adapter. Which one are you using?
Just for a test can you try with the 20.10 image? If that works then the script must need some changes here for whatever they did with the 64 bit Ubuntu 20.04 image!
Hey James,
Currently writing to 20.10 Server 64-bit to the SSD for testing….
Question; when I run the script and files are downloaded and written to ‘a’ partition – is this to the SD or SSD?
As I retried the 20.04, I suddenly realized looking further up in the process there is insufficient space, probably causing the issue.
Quite a noob still, espcially on linux partitions structure. Sorry for my dumb question.
Resolving deltas: 100% (3641/3641), done.
error: unable to write file modules/5.10.6+/kernel/net/netfilter/nf_conntrack_sip.ko
…and a bunch more ‘unable to write…’
PS; I am running rOS from a regular thumbdrive and a SSD from another USB but this shouldn’t matter?
Hey Stigh,
It sounds like either that disk/drive may be failing or the partition table is corrupt on it. Can you try running fsck against both partitions?
Are you booting with them both plugged in at the same time? The output you posted said it’s unable to write to the drive. If both are plugged in it may be selecting the wrong drive.
There’s also differences between how Ubuntu and Raspbian boot that could complicate things. Ubuntu always uses the root label partition of “writable” and doesn’t use partition IDs like Raspbian as well as some other subtle differences in how they boot. The official Ubuntu images usually boot using u-boot for example which is a totally different process altogether. The drive being full/out of space is another possibility but I really doubt it in this case.
Theoretically it should work, but this type of boot support is brand new and so when troubleshooting this I would stick with the standard configuration for testing and to narrow this down. I’d try only with one plugged in if you aren’t doing this already just to rule out anything crazy like that!
The partition might also be in “read-only” mode because it detected an issue with the partition table and won’t mount it in write mode until you run fsck on it. This happened to me once or twice during testing where my partitions were being mounted as “read-only” like this due to an error requiring fsck to correct. The other possibility is that the disk/drive is physically failing and that’s why it can’t write to those sectors/areas of the drive.
I encountered partitions that needed an fsck a few times when I was preparing and testing this article originally. It definitely happens! Let’s start there and see what you’re getting.
Hey James,
I will try fsck tomorrow.
I booted with the USB thumbdrive inserted only, then I inserted the SSD.
After that I ran the PRi Imager and wrote the image to the SSD.
From there, I start with your guide.
I’m using the new Argon ONE M.2 case so I’m not sure what “adapter” it uses.
Hey Stigh,
Thanks for the additional info. I think fsck is for sure the place to start.
I’d definitely try with Ubuntu 20.10 just in case as a test even if you 100% intend to stay on LTS. It has newer firmware and has solved issues in the past with certain drives/configurations. I may be able to fix the firmware issues as well if the newer image is working. I’m getting my Ubuntu imaging test station set back up here to give this one a try since this is the second issue with the 64 bit 20.04 image specifically that has come up recently.
Another person was having an issue until they enabled “quirks” mode from this guide. I don’t have the Argon One case specifically but let’s see what you find out during your testing because that will narrow things down significantly!
Hey James, then I got everything working – the fault was using the ‘base’ rOS on a thunbdrive, even if I installed without connecting the SSD, where connecting the SSD after booted into rOS on the thumbrive. So a suggested addon in the guide, do NOT try to install and run rOS onto a thumbdrive, then inserting the SSD and continue. It will fail.
Using a SD card, it worked straight forward, testing both 20.04 LTS Server 64 bit and 20.10 Desktop 64 bit.
A final question; do you recommend running 20.04 or 20.10 on the RPi ?
Hey Stigh,
That’s excellent news! That’s a great find. I’ll get that added in the guide here.
It makes sense on some level since they are both USB mass storage devices. When we change it to boot from USB mass storage there’s nowhere we really specify which mass storage device to use (yet that I know of). I’m guessing this will get fixed over time as more people try this!
At the moment I recommend 20.10 even though I’m a hardcore LTS fan usually. The reason is that LTS gets a really long time to get the firmware updates. Usually this is good because it ensures you have a nice stable experience.
Right now though with all these new features coming to the Pi I would set it up with 20.10 so you can take advantage of them without waiting for them to go through the long testing process to make it into LTS. I think a year from now my recommendation will be LTS again once all the firmware supporting the new features makes it’s way through the process! If you are trying to USB boot you will definitely have an easier time. The eth0 port seems to be missing on the 20.04 64 bit server version right now (which I’m in the process of investigating from other comments here) for example but works fine in 20.10.
In the past I have compiled images with newer firmware but I may update the BootFix script to give it a copy of 20.10’s firmware or something like that to fix the eth0 issue. But for the easiest/least frustration definitely 20.10 for the moment!
Hopefully that helps!
Hey James,
Thank you for replying and for pointing me to test the SD card rather than thumbdrive 🙂 This was actually a quite ‘natural’ thought as when the Argon One-case are assembled, you can’t access the SD card slot. So, when using this case, keep it open until scripts are open and you can remove the SD card before finally rebooting to start Ubuntu.
Hey Stigh,
No problem at all! I haven’t tried that case yet (link if people are wondering what we’re talking about) but I can see the appeal. I like my setups to be clean and streamlined. Having a giant long M.2 stick dangling loose off a cable definitely does not meet that goal.
The enclosures would be a second place. They’re not nearly as “messy” and are designed to lay flat and stay still and can be tucked out of the way but they still add an extra cable and external “piece” basically.
This type of setup is definitely first place for being clean and streamlined. You have M.2 solid state storage right underneath the Pi with a little USB connector connecting the M.2 board with one the Pi’s USB 3.0 ports. No extra cables!
I’m sure I’ll get one eventually but I just got the “Icy Box” recently and realized all my NVMe drives are in use for other projects! It’s probably time to upgrade one of the 256GB drives in my main tower now that solid state prices for large sizes have dropped significantly which will give me another project NVMe drive!
Thanks for leaving the tip for others. I know I’ve heard of this case before and I think I’ve seen it appear in some of the storage benchmarks so there are definitely other people who will be setting it up like this!
Hi James, regarding the Argon case, I think I read somewhere that is doesn’t support NVMe M.2’s – if this casing are to be considered, please check this thoroughly.
A note for overclocking:
It is still possible to overclock your pi in ubuntu by changing arm_freq in config.txt BUT the boot partition isnt necessarily in /boot. For me (by running mount | grep boot) my boot partition is in /boot/firmware, which is where i found config.txt.
Im a noob and it took me 3 hours to figure this out
Bought an ROG STRIX Arion and Crucial P1 for a minecraft server.
I followed all the instructions and after rebooting i was met with ‘no sd card, please insert’. Had this issue for 3 hours while i messed around trying to get it working. eeprom was up to date, tried 20.10/04 and 18, manually doing the script steps, the img straight from the website, different ports, different cables, nothing worked.
Finally to test if my firmware was correct i grabbed a thumb drive and followed the steps. Rebooted straight into ubuntu and it worked first time. Shutdown, removed the thumb drive and inserted the external enclosure (which had a clean flash of 20.04.1 and script run from my earlier tests), rebooted and it booted into ubuntu with no issues.
I have absolutely no idea why this worked but here i am.
Thank you for the fantastic walkthrough!
Hey Ben,
I think you’re on to something here. I think some people may have recovery.bin on their main SD card’s boot partition and it is booting from that instead of the old version.
You broke the cycle by not booting with the SD card so it booted off your “real” firmware instead of the recovery.bin on the SD card. Check out the documentation here for a source and some more background (the recovery.bin section).
Can you check your SD card for recovery.bin? I’m curious if you will have it. I have a hunch that some of the people encountering this have something like this file on their SD card. Apparently when you have it it boots using that image and ignores your real one!