ugly surprises with raspbian buster and external file systems


A while back I wrote about adding an SSD to a Raspberry Pi 4 and modifying /etc/fstab so that it would automatically mount when it booted. This is different than having it automount through /media/pi, since that type of automount only occurs after the OS is fully up and then scans for attached devices, such as those on USB. For nearly all use cases you can’t tell one from the other. But for those very few use cases where you need the kernel to mount the attached storage device before the rest of the system comes up, you need to define it in /etc/fstab.

That wasn’t a problem with Raspbian Buster up until just recently. Before that time, I had an entry for my SSD in fstab that started out like this:

/dev/sda1 ...

It worked just fine, until one day after a recent update that included the kernel, it didn’t. No warning that this was going to happen, none at all. After the update and subsequent reboot, the Raspberry Pi refused to boot, and instead dropped me into a prompt waiting for me to log in as root to fix the problem. Oh, wait, root is disabled by default in Raspian, so that just put me in an endless boot loop.

It took two attempts rebuilding a minimal boot micro SDXC before I finally figured out what was happening. Fortunately, that second micro SDXC card was a new one with a minimal Raspbian system, so it didn’t take too much effort to see that adding the entry to /dev/sda1 was causing it to fail to boot. Fortunately for me I have other Linux systems (my ten-year-old Samsung R580 running Ubuntu 18.04.04 came to the rescue) that allowed me to mount both micro SDXC cards, edit fstab and remove the entries. Once removed, both micro SDXC cards booted just fine in the Raspberry Pi 4.

Once I got back in I enabled root with ‘sudo passwd root’ and gave it a password. Now, if I have a problem where a Raspbian boot failure wants to dump me into the root account in single user mode, I can actually log in at that point.

The other problem was getting the USB SSD to mount. Here’s what I did to fix that. But first, a tiny bit of background.

The kernel in Raspbian buster uses what’s now known as a PARTUUID to identify a storage device instead of the old school device name in /dev. To find out what that PARTUUID is, you have to run this command at the command line in a terminal window:

pi@rpi4-4-01:~ $ sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="69D5-9B27" TYPE="vfat" PARTUUID="d9b3f436-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="24eaa08b-10f2-49e0-8283-359f7eb1a0b6" TYPE="ext4" PARTUUID="d9b3f436-02"
/dev/sda1: LABEL="SSD" UUID="ad89d540-a007-4d0a-887b-0b0dbefe3e8e" TYPE="ext4" PARTUUID="937a0120-01"
/dev/mmcblk0: PTUUID="d9b3f436" PTTYPE="dos"

Since I already know the label on my SSD is “SSD” it’s quickly identifiable in blkid’s output. Copy the PARTUUID at the end of the entry, and use that in the fstab entry for the drive, like so:

PARTUUID=937a0120-01 /ssd ext4 defaults,auto,users,rw,nofail,x-systemd.device-timeout=30 0 0

Note that the quotes are not added to the entry. Also note all the flags I use, especially the shortened timeout (systemd.device-timeout=30) to shorten the wait during boot in case the SSD isn’t plugged in. The default is 90 seconds.

The primary reason I want the SSD mounted is because that’s where I put swap. In /etc/dphys-swapfile I add the following line:

# where we want the swapfile to be, this is the default
#CONF_SWAPFILE=/var/swap
CONF_SWAPFILE=/ssd/swap

I want my swap on the SSD because testing has shown the SSD is an order of magnitude faster than the boot micro SDXC. I use the Raspberry Pi 4’s as development and native build machines, rather than set up an emulation and cross-compile tool chain on my Mac. Believe it or not, it’s a lot simpler the way I have it set up. This is a decent compromise that doesn’t require me to put the entire OS on the SSD and then configure the Raspberry Pi to boot off the SSD. There are some significant problems with that, such as the Rasberry Pi 4 wasn’t set up to do that for quite some time after its release, and the fact that once configured that way, you can’t go back. So I put swap on the SSD, then cd onto a work area on the SSD and develop and build away.

This all gets back to the bigger question: why did this change, and when did it change? I use the same type of setup, and the same SSD, on the Jetson Nano, and it’s running a tweaked version of Ubuntu 18.04.04, complete with the Ubuntu graphical desktop. The fstab entry for that is the regular device entry, /dev/sda1.

Oh well. I just keep reminding myself that this is just a hobby, and I’m retired.

working with ubuntu for iot on a raspberry pi 4

Raspberry Pi 4 2GB memory sitting on a 4GB memory Pi.

I spent some time this Thanksgiving holiday taking Ubuntu for IoT for a quick spin on a Raspberry Pi 4 with 2GB of memory. I have three Raspberry Pi 4s, one each of 1GB, 2GB and 4GB memory capacity. The 4GB is the primary “development” system with the latest version of Raspbian Buster installed. I had the 2GB version mounted inside a Flirc case sitting on the shelf, unpowered and without an OS. I decided to experiment with that one, as I hadn’t used it since the very early days of the Raspberry Pi 4 hardware release and initial release of Raspbian Buster. Once the 4GB Raspberry Pi 4 arrived, I transferred all my work to it and ignored the other two. The 1GB board is back in its anti-static bag and in its original box. I need to pull it out and put it back to work as well. But I digress…

Setup

  • Raspberry Pi 4 with 2GB of memory
  • Firmware version – 000137ab
  • SanDisk Ultra Plus 64GB µSD card, V10, XC I, C10, A1
  • Monitor – Samsung S22C300H 1920 x 1080, 21.5 inch monitor
  • Keyboard – Logitech MK710 wireless
  • Mouse – Logitech MX Ergo trackball

Normally I use an LG 34UM61-p 2560 x 1080 monitor with my RPi 4 because Raspbian Buster is capable of driving it. But Ubuntu IoT won’t, neither in text nor graphics (desktop) mode. While the Logitech MK710 comes with its own mouse, I use the Ergo because it’s easier for me. I’ve begun to develop arthritis in my right wrist, and it’s easier for me to keep my hand still and at a 30% tilt from horizontal, and just move the track ball with my thumb.

Installing 64-bit Ubuntu Server IoT

The reason for installing 64-bit Ubuntu Server IoT on the 2GB memory RPi 4 board is that it currently will not work on the 4GB memory board.

I followed the directions on the Ubuntu site (https://ubuntu.com/download/raspberry-pi), flashing the 64-bit Ubuntu Server image to the µSD card using balenaEtcher (https://www.balena.io/etcher) on my Mac. If you don’t use balenaEtcher (on Linux, macOS, or Windows) then you’re only making it harder on yourself. balenaEtcher is incredibly simple to use and nearly foolproof.

Bootup was bit peculiar compared to Raspbian command line. It took awhile for the Ubuntu image to completely boot. When it finally presented a login prompt and I logged in, it had converted all the empty space on the µSD card into a Linux volume. The total amount of disk space that Server took for itself on that volume was less than 2GB, which isn’t bad at all.

Logging in the first time was annoying. The login prompt would appear, then get wiped as late starting services would announce themselves as via text to the console. I learned to wait until startup was truly finished before attempting to log in.

I had the Pi connected to my network via a wired cable. The server image doesn’t have everything necessary to turn on WiFi on the board. I had to install network tools in order to make wireless work, and I had to create by hand an initial wpa_supplicant.conf configuration file with my wireless networks SSID and password. At the next reboot the WiFi network came up and Ubuntu IoT was running in 64 bit mode with WiFi. After that it was ‘apt update’ and more waiting. Bringing up WiFi is very simple, and very easy, with Raspbian. It can be done either with a text tool or on the desktop. Ubuntu Server IoT could take a page from the Raspbian setup manual on how it should be done.

Now I know that security is a Big Deal with the Ubuntu IoT crew. I really get that. But forcing me to change my password into something long and complex is a royal pain in my behind. I hate that crap. Trust me: if and when I decide to deploy based on this (which at this time I won’t, but keep reading) then I’ll harden login. I didn’t fall off the turnip truck to get here. And I certainly don’t need such a sledgehammer reminder as the one in Ubuntu Server IoT right off the bat.

Installing a Desktop

After installing Server I followed the direction’s advice and installed Lubuntu Desktop. That took some time as a large number of packages had to be installed, and many others updated. When it finished and the RPi 4 rebooted, it showed a graphical login screen. I logged in and beheld a typical Linux graphical desktop.

It was, for the most part, rather uneventful, which is a Good Thing. I noticed that the applications installed were rather sparse, which is another Good Thing. There were no ancient games, for example. What I did find unusual is that LibreOffice was installed. I don’t need an office suite installed on a RPi development board. That’s why I never install the full Raspbian desktop plus applications, only the basic Raspbian desktop.

I also discovered that gcc isn’t installed either. I understand not having it with the Server image, but the desktop image should have the development tools as part of the overall package. Python 3 was there as was Vim, so I could have taken off with that if I’d wanted to. And yes, I can certainly apt install all the development tools. But still…

I did like the look of Lubuntu, but not necessarily it’s operation. The desktop software operated in a halting, janky sort of fashion. I’d move the mouse across the desktop and watch it stutter a bit. It wasn’t all the time, and it didn’t get in the way of getting work done. But compared to Raspbian, it didn’t feel quite as polished while using it.

I spent a half hour poking about, looking at things, and appreciating it was actually running in 64-bit mode. That’s my biggest complaint about Raspbian, that it’s still 32-bit. Once set up I shut it down and attempted to bring it back up with the LG monitor. While Ubuntu Server came up, the monitor stayed dark. I could ping it and ssh into it, but the graphical desktop was non-functional. In the end I pulled out the µSD card, put it away, and brought the 2GB RPi 4 in up-to-date Raspbian.

Thoughts

I’m not sure what to say. It feels rough, especially the desktop. My advice there is to pick just one desktop, and then to tailor it more towards development, including such applications as gcc and supporting development tools.  Or if you don’t want to bloat the desktop meta package then create a Languages Development meta-package that has everything needed, while trimming back the desktop package.

Ubuntu Server IoT has a lot of promise and I will tinker with it some more in the near future, but for now, based on my very limited experience, if you’re starting out with the Raspberry Pi, then chose Raspbian. There are three Raspbian images; one minimal command line, one basic desktop, and a desktop with all sorts of additional goodies. I personally use the first two. But I can’t ignore the fact that Ubuntu Server has a 64-bit foundation. They’re all good and solid and will get you up and running with a minimum of fuss.

One other positive aspect about Ubuntu Server plus desktop. It’s disk footprint is noticeably smaller than Raspbian, even with the desktop meta package installed. I certainly appreciated that. It’s memory footprint also is rather small as well. Again, another aspect to appreciate.

I’m not giving up on Ubuntu Server IoT. I just need to think of the best way to use it in the future.