Raspberry Pi 4 Ubuntu Server 18.04 Installation Guide

Ubuntu Server logo
Ubuntu Server logo

UPDATE 12/5/20 – New instructions are available for Ubuntu 20.04 or Ubuntu 20.10 installation and USB booting on Raspberry Pi 4 in my new article here

Ubuntu Server has been my favorite Linux distribution for years. On everything but the Raspberry Pi I run Ubuntu Server but felt stuck with Raspbian on the Pi. Until now! Ubuntu Server 18.04.2 has been released and major improvements have been made to the official Pi branch.

The Raspberry Pi 4 is not officially supported out of the box yet on the current Ubuntu Server Raspberry Pi images but you can get it working by manually updating the firmware. Solid state storage is also working but with the catch of having to use a micro SD card as a bootloader since the Pi 4 does not have official boot support yet. I describe how to do both in this article.

The Raspberry Pi’s peripherals such as WiFi / Bluetooth are now fully supported. Previous Ubuntu Server versions for Raspberry Pi (like many other distros) had broken or completely missing drivers for core components such as WiFi / Bluetooth. In the 18.04.2 update the firmware for the WiFi and other components is now included out of the box making it a fully functional distribution!

This is the first distribution besides Raspbian that feels like you can just image it and everything works. I’ll guide you through the process in this guide. It only takes a few minutes to set up.

Recommended Gear

I highly recommend upgrading to a solid state setup. The performance gains are gigantic. It’s now less than 30 bucks to take your Pi solid state. This is the best performance upgrade you can possibly get for a Pi.

With the new Raspberry Pi 4 it’s even more beneficial to use USB storage since a USB 3.0 bus was finally added in the Pi 4 letting it take full advantage of solid state drives. This is the setup I am currently using:

Raspberry Pi 4
Raspberry Pi 4

The Raspberry Pi 4 is available in different memory configurations all the way up to 8 GB. It’s about the size of a credit card and uses an extremely low amount of power making it ideal for all sorts of projects and ideas!

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*

Raspberry Pi 400 Kit
Raspberry Pi 400 Kit

The Raspberry Pi 400 kit includes everything you need for a full Pi 400 desktop build. The Pi 400 is the fastest Raspberry Pi ever released and comes in the form factor of a keyboard!

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*

Kingston A400 SSD
Kingston A400 2.5″ SATA SSD

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 Pi Benchmarks 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*

StarTech 2.5" SATA to USB 3.0/3.1 Adapter
StarTech 2.5″ SATA to USB 3.1 Adapter

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*

Or for a compact setup:

SanDisk Extreme Pro USB SSD
SanDisk Extreme Pro SSD

The SanDisk Extreme Pro USB SSD is a true solid state drive. This is different than a typical “flash drive” which uses extremely cheap memory and has very low random I/O performance/throughput compared to a real solid state drive. I’ve used both the USB 3.1 and USB 3.2 variants with the Pi successfully and they benchmark very well!

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*

SD Card Setup:

SanDisk Extreme A1
SanDisk Extreme A1

The SanDisk Extreme A1-A2 SD card has the best scoring SD card on Pi Benchmarks for years and is second in popularity only to the SanDisk Ultra (often included in combo kits). The application class (A1) means random I/O speeds (very important when running an OS) have to meet a higher standard. There’s no benefit on the Pi for A2 right now so get whichever is cheaper/available.

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*

These storage choices are ones that all scored highly on the end-user submitted Raspberry Pi Storage Benchmarks and will give you outstanding I/O performance on the Raspberry Pi. I also personally own all of them and recommend them knowing they are compatible and perform well on the Pi.

Getting Ubuntu Server

64 bit (aarch64)

I have a custom compiled prebuilt 64 bit image available for testing. This version supports addressing all 4 GB of RAM if available. The WiFi fix for bootflags3 is also already implemented into the precompiled version. Get my custom built kernel from the Ubuntu-Server-raspi4-unofficial GitHub page.

32 bit (armhf)

To get the 32 bit version head to the official Ubuntu Raspberry Pi page at https://wiki.ubuntu.com/ARM/RaspberryPi and scroll to the “Official Images” section. Until the official Raspberry Pi 4 image is released choose the Raspberry Pi 3B+ armhf release and follow the directions in the next sections to update the firmware for a Pi 4 boot.

Writing the Base Image

This part is easy. Extract the image from xz format to img format (7zip is great and free and can extract these). Now write the img to your media (Micro SD card, solid state drive, USB storage, etc). the same way you would for any other distribution!

Updating Firmware for Raspberry Pi 4

If you are using the CloudKernel 64 bit image you can skip to the “Boot Ubuntu Server” section as it already implements the updated firmware. If you are using the 32 bit image or the official Ubuntu Server preinstalled server image from Ubuntu’s web site you will need to update the firmware using these instructions.

Remove Existing Firmware

The firmware in the current release was not built with Raspberry Pi 4 support so we need to update the firmware on the /boot/ partition for the Pi 4 to be able to boot correctly.

Insert/mount the micro SD card in your computer and navigate to the “boot” partition. Delete everything in the existing folder so it is completely empty.

Download Latest Firmware

32 bit Firmware Instructions

If you are trying to run the 64 bit version of Ubuntu skip to the 64 bit instruction section next. For 32 bit versions of Ubuntu download the firmware from the official GitHib repository here: Raspberry Pi GitHub Official – master.zip

The latest firmware is everything inside master.zip “boot” folder (including subfolders). We want to extract everything from “boot” (including subfolders) to our micro SD’s “boot” partition that we just emptied in the previous step. Don’t forget to get the “overlays” folder as that contains overlays necessary to boot correctly.

The end result will look something like this on the “boot” drive:

$ ls
  COPYING.linux                bcm2711-rpi-4-b.dtb   kernel.img
  LICENCE.broadcom             bootcode.bin          kernel7.img
 'System Volume Information'   cmdline.txt           kernel7l.img
  bcm2708-rpi-b-plus.dtb       config.txt            overlays
  bcm2708-rpi-b.dtb            fixup.dat             start.elf
  bcm2708-rpi-cm.dtb           fixup4.dat            start4.elf
  bcm2708-rpi-zero-w.dtb       fixup4cd.dat          start4cd.elf
  bcm2708-rpi-zero.dtb         fixup4db.dat          start4db.elf
  bcm2709-rpi-2-b.dtb          fixup4x.dat           start4x.elf
  bcm2710-rpi-3-b-plus.dtb     fixup_cd.dat          start_cd.elf
  bcm2710-rpi-3-b.dtb          fixup_db.dat          start_db.elf
  bcm2710-rpi-cm3.dtb          fixup_x.dat           start_x.elf

64 bit Firmware Instructions

To boot Ubuntu Server in 64 bit mode we need to download the 64 bit version of the firmware. The .dtb files are different between 32 bit and 64 bit operating systems. Raspbian does not come with a 64 bit bootloader and one isn’t provided in the official GitHub repo either.

I have these 64 bit versions available in my Ubuntu Server precompiled image.

Create/Update config.txt and cmdline.txt

Navigate to the micro SD /boot/ partition. Create a blank cmdline.txt file with the following line:

dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

Next we are going to create config.txt with the following content:

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]

[all]

64 bit config.txt Configuration

To boot the Pi in 64 bit mode we need to add the following lines to the config.txt:

arm_64bit=1
enable_gic=1
armstub=armstub8-gic.bin 

The final configuration for 64 bit will look like this:

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]

arm_64bit=1
enable_gic=1
armstub=armstub8-gic.bin

[all]

These enable all the different 64 bit related options you need to perform a 64 bit boot on the Pi.

Boot Ubuntu Server

We are now ready to boot the device. Insert the micro SD card and power on the device.

Note: The very first startup can be very slow. Be patient. It can take up to a couple minutes with no activity lights then all the sudden everything will start blinking and SSH will open up.

Fix apt-get update / Prevent Further Updates

If you try to apt-get update now it will try to update your firmware with older firmware from the Ubuntu repository. The workaround for now is to remove that package so it keeps your existing firmware. Make a note to remember you did this step as later on we will want to reenable updates from the repository once support has been added.

sudo apt-mark hold flash-kernel

You may now run sudo apt-get update && sudo apt-get upgrade. I would avoid using dist-upgrade yet because the kernels in the repository it will update you to don’t support the Pi 4 yet. But this should get you all up to date on the packages!

Once the firmware in the apt repositories has been updated for the Pi 4 it will be safe to reinstall initramfs-tools and let it update through the normal process again.

Solid State Drive (SSD) Configuration (Optional)

USB booting has not been added into the Raspberry Pi 4 firmware yet but is being worked on right now. In the mean time you can use your micro SD card as a bootloader and still boot the whole operating system (rootfs) from the solid state drive giving you the full USB 3.0 speed increases system wide. Once the Pi USB booting is officially released you should be able to boot directly from the device without any makeshift bootloader SD card necessary.

First create a fully imaged and booting micro SD card following the earlier steps in the tutorial. After you have created the micro SD installation you should now image your SSD / USB drive with the same Ubuntu image you used to create the SD card.

Now navigate to the “boot” partition on the newly created SSD / USB drive and remove everything in there just like we did with the SD card earlier. Now copy the “boot” folder from the micro SD card to the solid state drive. This is necessary because even though the files in “boot” are read off our micro SD card initially some firmware files in the later load stages are read off the mounted drive and if the necessary firmware files are missing the system won’t boot.

Now that you’ve created the SSD / USB drive partitions and copied the “boot” partition from the SD card to your new drive we need to update your SD card’s cmdline.txt to point to the SSD / USB drive’s partition.

dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

The key part we need to change here is the “root=/dev/mmcblk0p2” section. mmcblk0p2 is a hardware identifier for micro SD storage. We need to change this to the device your storage is detected as.

If you are using a USB to solid state drive adapter it’s very likely your drive will be addressed as /dev/sda2. Therefore we will change the root=/dev/mmcblk0p2 to root=/dev/sda2

root=/dev/sda2

The final line will be:

dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 rootwait rootflags=noload net.ifnames=0

Plug both the micro SD and the solid state drive into the Pi and boot it up.

Remember: the first boot can take 2-3 minutes for first startup so give it some time before assuming it didn’t work.

Wireless Fix

The current non-free Raspberry Pi firmware had the wrong bootflags3 for quite a while for the Raspberry Pi 4 and these firmware files are definitely out there. Here is a one liner I wrote to replace the Raspberry Pi 3 boot flags in this driver with the Raspberry Pi 4 one:

sudo sed -i "s:0x48200100:0x44200100:g" /lib/firmware/brcm/brcmfmac43455-sdio.txt

Restart the system afterward.

Configuration

Default User / Password

The username and password for your initial login to Ubuntu Server will be:

user: ubuntu
password: ubuntu

You will be required to change your password after logging in for the first time. Make sure on the prompt you enter the current “ubuntu” password before typing in your new password or the device will kick you out completely and you’ll have to log in again.

Set Time Zone

To configure the correct time zone for Ubuntu Server use the following command:

sudo dpkg-reconfigure tzdata

This will take you to a very easy to follow menu to select your correct time zone and applies it to the system.

Update System

For best stability, security and performance you should immediately update your system and packages to the latest version. This will also grab all of the latest fixes/improvements making your Raspberry Pi Ubuntu experience much better.

This part is easy. Type:

sudo apt-get update && sudo apt-get upgrade

Change Default GPU Memory Split

The default amount of memory allocated to the GPU on the Raspberry Pi is around 76 MB of our 1 GB. In 2 GB and 4 GB models the amount gained from this is negligible but is still worth it for the 1 GB model.

If you type the command “free” you will see that your Raspberry Pi is missing this memory under the “total” column. We can reclaim most of this memory back by setting the GPU memory split to 16 MB. If you are planning on installing a GUI in the future you should not make this change.

This option is set in the config.txt file. It’s exactly the same file as Raspbian uses but it is located at /boot/firmware/config.txt instead of /boot/config.txt. Open config.txt with the following command:

sudo nano /boot/firmware/config.txt

We will add the following line at the bottom of config.txt:

gpu_mem=16

Press Ctrl + X and type yes to save the file. Now restart the Pi by typing

sudo reboot

After the reboot finishes type “free” again and you will see that your total available memory has increased and can now be used by the system and your applications!

Benchmarking / Testing Storage

If you want to verify your drive’s performance you may want to run my storage benchmark with:

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

If you search for the model of your drive on Pi Benchmarks you can compare your score with others and make sure the drive is performing correctly!

Conclusion

I’m very excited to see my favorite Linux distributions continue to evolve to the point where they are comparable in performance and stability to Raspbian. I’ve been testing extensively on Ubuntu Server 32 bit and 64 bit for my Raspberry Pi Minecraft Server project and not only is it on par with Raspbian but starting to do things so well it sometimes makes Raspbian feel a little dated.

If you have any questions or suggestions don’t hesitate to leave me a comment on the post or use my contact form to message me privately! I’m good about responding quickly and my articles are constantly revised to address questions or do something a better way that a reader pointed out.

Have fun!

207 thoughts on “Raspberry Pi 4 Ubuntu Server 18.04 Installation Guide”

  1. Avatar for Garry

    I’m trying to get WiFi to work but sadly coming up empty. I’ve tried edit the yaml in /etc/netplan/ but just not succeeding.

    ubuntu@ubuntu:~$ sudo netplan --debug generate
    DEBUG:command generate: running ['/lib/netplan/generate']
    ** (generate:1121): DEBUG: 20:55:06.237: Processing input file /etc/netplan/50-cloud-init.yaml..
    ** (generate:1121): DEBUG: 20:55:06.237: starting new processing pass
    ** (generate:1121): DEBUG: 20:55:06.238: wlan0: adding wifi AP 'pax-5'
    ** (generate:1121): DEBUG: 20:55:06.238: wlan0: adding wifi AP 'pax-2.4'
    ** (generate:1121): DEBUG: 20:55:06.238: wlan0: setting default backend to 1
    ** (generate:1121): DEBUG: 20:55:06.238: Configuration is valid
    ** (generate:1121): DEBUG: 20:55:06.238: eth0: setting default backend to 1
    ** (generate:1121): DEBUG: 20:55:06.238: Configuration is valid
    ** (generate:1121): DEBUG: 20:55:06.239: Generating output files..
    ** (generate:1121): DEBUG: 20:55:06.239: NetworkManager: definition eth0 is not for us (backend 1)
    ** (generate:1121): DEBUG: 20:55:06.239: wlan0: Creating wpa_supplicant configuration file run/netplan/wpa-wlan0.conf
    ** (generate:1121): DEBUG: 20:55:06.240: Creating wpa_supplicant service enablement link /run/systemd/system/systemd-networkd.service.wants/netplan-wpa@wlan0.service
    ** (generate:1121): DEBUG: 20:55:06.240: NetworkManager: definition wlan0 is not for us (backend 1)

    ubuntu@ubuntu:~$ iwconfig
    eth0 no wireless extensions.

    wlan0 IEEE 802.11 ESSID:off/any
    Mode:Managed Access Point: Not-Associated Tx-Power=31 dBm
    Retry short limit:7 RTS thr:off Fragment thr:off
    Power Management:on

    lo no wireless extensions.

    ubuntu@ubuntu:~$

    below is my Netplan file :
    # This file is generated from information provided by the datasource. Changes
    # to it will not persist across an instance reboot. To disable cloud-init's
    # network configuration capabilities, write a file
    # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
    # network: {config: disabled}
    network:
    ethernets:
    eth0:
    dhcp4: true
    match:
    macaddress: dc:a6:32:4f:44:a3
    set-name: eth0
    version: 2
    renderer: networkd
    wifis:
    wlan0:
    optional: true
    access-points:
    "pax-5":
    password: "xxxxx"
    "pax-2.4":
    password: "xxxxx"
    dhcp4: true

    1. Avatar for James A. Chambers

      Hey Garry,

      I think I can help. The .yaml file is extremely sensitive to spaces. I can’t see any spaces in the post but the formatting may have not carried over. One wrong space will break it. *Any* tab will also break it. Can you validate your yaml at yaml-validator? You just paste it in and hit validate and it will see if there’s any issues.

      I would also try issuing a sudo ifconfig wlan0 up command. This has brought it up before for me when it was behaving similar to yours!

      1. Avatar for Joe

        JAMESACHAMBERS, THANK YOU!!!

        The yaml validator was EXACTLY what I needed. I’ve been struggling for two days to get WiFi working on my P3b with Ubuntu Server 18.04 and it was the yaml file, which I had gone over and over and everything seemed right.

        In my case it wasn’t even spacing or anything like that. It simply didn’t like the name of my AP, which started and ended with 4 hashes (#### MY AP ####). I changed it to three stars instead and it liked it fine. It didn’t actually tell me that the issue was with the name, but with that particular line, so I just took a shot in the dark.

        Thanks again!

        Joe

        1. Avatar for James A. Chambers

          Hey Joe,

          I’m very glad to have helped! I’ve also lost many hours to YAML validation errors, i’ll make sure to include that tip in future articles since I know it’s helping!

  2. Avatar for Joe

    I see there’s a Raspberry Pi image for Ubuntu server 19.10.1 which already has the Pi 4 firmware configured and I have it running on the sd card on my Pi 4. Unfortunately, the cmdline.txt edit doesn’t seem to be working to get 19.10.1 running on an SSD. Have you figured out how to get it to work?

    Thanks for the great guides!

    1. Avatar for James A. Chambers

      Hey Joe,

      Getting some instructions up for the new Ubuntu is on my todo list! It uses uboot and I’ve tried to walk people through it before on the comments but it is tricky so I’m working on a full guide for this!

  3. Avatar for Tony

    I’m curious about the additional cmdline.txt boot option called out here as”dwc_otg.fiq_fix_enable=2″. I see a lot of documentation about this lowering excessive interrupts back around 2012 and the switch was set to 1. I can’t find any documentation about setting it to 2. First question is, is this option still needed today? Second question is what does a setting of 2 do compared to a setting of 1?

    Thanks,
    Tony

    1. Avatar for James A. Chambers

      Hey Tony,

      Great question and I definitely didn’t know the answer when you asked it. I had to go DEEP into the kernel source tree to solve this mystery.

      I found the answer and the answer is….. fiq_fix_enable is a bool in the source code which means there is no difference between 1 and 2. The only values that matter is 0 (false) and anything else (true). So there is no difference between 1 and 2.

      Now for the other part of the question as to whether it is still needed: the answer is maybe. If you are using Raspbian it is not needed anymore because it is included by default. If you are using *any* other distro it’s probably a good idea to have this turned on as if they haven’t enabled it by default in their config you will lose about 10% USB performance (especially with solid states).

  4. Avatar for Cam

    I’m a basic linux user, my desktop has a Ubuntu Mate&windows10, dual booting with Refind (boot menu system Rod Smith). Similar to the booting from SD card in Raspberry4, I boot my pc into windows/ubuntu by having a bootable usb thumb drive and I select the OS at boot up. I like this approach, seems to keep things tidy.

    Now using James’ guide,(boot from ssd) i’ve installed Rasbian onto a 250gb ssd drive (resized down to 32gb). I want to install the ubuntu 18.04 as the guide suggests, and have it run from the SSD, just like the Rasbian.

    My Guess is that I require a boot menu system (like Refind)perhaps grub, on the SD card. to point the start up to /bootRasbian or /bootUbuntu *on the SD card*(renamed, because they both can’t be /boot) and the commandline.txt in each folder would point to the PartUUID that is on each corresponding root partition on the ssd. Close?

    Again, So /boot ->has a *choice (add other installs later)* to go to /bootRaspian (my directory name ) and it would point to the /rootRaspian on SSD using its corresponding PartUUID, OR the /boot could elect to go to /BootUbuntu (SD card), instead, eventually getting to /rootUBuntu on the SSD card, using the same mechanism. I hope I making myself clear.

    1) Can this be done?
    2) Should it be done with my limited experience?
    3) what tools would be the better choices
    4) any other resources that might be helpful?
    5) Better way than I proposed?

    1. Avatar for James A. Chambers

      Hey Cam,

      It is possible to use Grub by editing the partition flags (Pi doesn’t support EFI) as described here but instead of going that route I strongly suggest you instead consider using BerryBoot which will give you a nice list to select from and should be exactly what you’re looking for!

  5. Avatar for Yos

    Hi James,

    Recently I updated my version 17 to version 25, somehow it has problem when I need to compile with cmake (which was okay before the update). Now it cannot find openGL and throw this error:

    Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
    OPENGL_INCLUDE_DIR)

    I am not sure if this is also caused by the update on mesa-dev or only because of the kernel update, I reinstalled the version 17 again and it can work well with cmake compile etc.
    do you have any idea about this?

    Thanks a lot!

    1. Avatar for James A. Chambers

      Hey Yos,

      I think I can help! In version 17 we were still using the x-swat repository for the 3d driver and the new one is using oibaf/graphics-drivers.

      # Add updated mesa repository for video driver support
      sudo add-apt-repository ppa:ubuntu-x-swat/updates -ynr
      sudo add-apt-repository ppa:oibaf/graphics-drivers -yn

      Above is the current configuration. If you wanted to keep the old mesa setup you could do something like this:

      sudo add-apt-repository ppa:ubuntu-x-swat/updates -yn
      sudo add-apt-repository ppa:oibaf/graphics-drivers -ynr

      The r at the end stands for remove, so this would add back the old mesa repository from the v17 era and drop the current one. This would restore the old package provider.

      Note that it could break things to try and downgrade back down but if you were doing this on the test images that you have been installing to troubleshoot this it would be worth experimenting with the different repositories and see if that helps narrow down exactly what is providing these missing headers from the old config that the new one isn’t providing or otherwise provide a clue or solution.

      It could also be a difference at how they bundle and distribute packages from the two different repos. Maybe there’s a mesa-dev package in the newer repository that would replace the missing headers that is installed by default in the old x-swat one? It may be worth checking which dev packages you need and see if you can just install the newer versions from the new repository with an apt install package-dev or something like that!

  6. Avatar for Jeff

    Is it correct to assume that the above does not work if you are trying to start with the ubuntu images linked in this forum post.

    The first post in this thread links to some new images from Canonical with fixes for the various issues with Ubuntu 19.10 on the Pi4.

    I was able to get them working, and I was trying to follow your instructions to get this configured to boot from the SSD. The part that I run into that differs from your instructions is that there is no cmdline.txt – but btcmd.txt appears to be similar. However, the line in there that you show does NOT say root=/dev/mmcbkl0p2 — instead it says root=LABEL=writable. I tried changing this line to root=/dev/sda2 but this doesn’t work. It all boots up with the SSD connected, but it seems that the pi is still booting off the SDcard.

    Any suggestions?

    Thanks!

    1. Avatar for James A. Chambers

      Hey Jeff,

      I believe the different behavior is because the official image is using uboot instead of initramfs-style booting. Instead of mounting by root=PARTUUID=d34db33f (like Raspbian) or root=/dev/device it is looking for a partition with the label of “writable”.

      I think the easiest thing to try would be do to a Raspbian style PARTUUID mount (follow my guide here as if you were on Raspbian to get the PARTUUIDs and make sure they are different, etc). Basically you would change the btcmd.txt (make sure that’s the one it’s using in config.txt) line from root=LABEL=writable to root=PARTUUID=d34db33f-02.

      I think I was also able to get this working by using either fdisk or gdisk’s advanced options menu to change the partition labels and changing the SD card’s label from writable to something else. However, this is not as simple as it sounds, because there are differences between MBR and GPT partitions and labels and there are tons of pitfalls to watch out for. If you want to try changing the partition labels yourself do it with a test image you set up that you don’t mind breaking until you’re sure you’re doing it correctly!

      If none of this works still, /dev/mmcblk0p2 might be compiled (hard coded) into the uboot configuration. If you have changed the partition labels correctly and it still keeps booting from the SD card then this is likely true in the newest image you linked to. In order to change this you need to change the config file and then rebuild the uboot image. This isn’t as bad as I’m making it sound but it’s not an easy or fast process either. Instructions on how uboot for Raspberry Pi works (a little outdated, definitely not for the image you’re talking about but it should be similar enough to stumble through) are available here if you want to give reconfiguring uboot a shot!

      1. Avatar for Jeff

        Awesome – I will give this a shot (probably start with the UUID method, since I had done that with Raspbian previously and I think I understand the process. Is it necessary to edit the fstab file too? I am thinking that may be where the labels of writable and system-boot are coming from.

      2. Avatar for Jeff

        Well – I got it to work. It turns out that i needed to edit the nobtcmd.txt file (and not the btcmd.txt file – but I left that one modified too).

        I just used the root=/dev/sda2 line instead of the PARTUUID, as the latter option didn’t seem to work.

        The one odd thing I notice is that if I run findmnt, it appears to show that /boot/firmware is coming from /dev/sda1, when I expect that it should be coming from /dev/mmcblk0p1 if i understand all this correctly. In order to get this to work, i had to mount /dev/mmcblk0p1 temporarily to edit the SDcard’s nobtcmd.txt file.

        Do i need to modify the /etc/fstab file to make apt update work correctly (like we have to do on raspbian)? That file doesn’t show any PARTUUID’s like it did in Raspbian. Just labels.

        1. Avatar for James A. Chambers

          Hey Jeff,

          That’s fantastic, good find! That’s the same way I do my image but in the new Ubuntu version they have cmdline.txt broken up into the bt and nonbt versions.

          The only thing you want to check is to make sure the micro SD card is mounted for partition 1 (boot) so that any firmware updates that come down from apt actually get used when you boot your device. If the updates are going to the SSD’s boot partition they won’t be utilized in the boot process so any fixes/enhancements that come down won’t get used on your device!

Leave a Comment

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

Type here..

Exit mobile version