R01 OS Early Hints

I got my R-01 module the other day, and I gotta say it’s a weird mix of nostalgia and novelty. I frankly love the default twm + gkrellm look. It’s been a long time since I last used a real retro desktop. As I’ve been poking around at the OS, I’ve learned some things I want to share.

First, the sources.list is configured for devel instead of jammy. Fix that up with a quick sed command.

sudo sed -i 's/devel/jammy/g' /etc/apt/sources.list

Next, there’s something wrong with update-notifier. If you try to apt dist-upgrade and you watch what’s taking so long in htop you’ll notice that one of the problem is that some update-notifier scripts run lsb_release thousands of times. I have a suspicion that this is actually due to something not being enabled in the kernel. More on that later. But we don’t need it, so gonzo.

sudo apt remove update-notifier-common

I like to keep my systems minimal, so the next thing I did was install debfoster to trim it down. There’s a lot of stuff on the OS image you don’t need, like XFCE, GIMP, Inkscape and Chocolate DOOM, along with really a ton of others. It’s kind of astounding how much junk you don’t need is on here. You have to be careful because the devterm-* packages don’t necessarily require all the packages they need, but there’s a lot of fat you can trim if you want to. I like to do this before updating to reduce the number of updates.

Bootloader Configuration

There’s a “bug” mentioned on the wiki that an upgrade will overwrite your boot configuration in /boot/extlinux/extlinux.conf but there’s a backup file for you to use. It’s not really a bug, rather the system is configured to update the boot configuration when kernels are installed or uninstalled. You can stop that from happening by removing all the Ubuntu kernels:

sudo apt remove linux-*5.*

Then to make sure the right parameters are set in extlinux.conf if u-boot-update ever gets run for some reason, you can configure it properly in /etc/default/u-boot:

## /etc/default/u-boot - configuration file for u-boot-update(8)


U_BOOT_PARAMETERS="earlyprintk=sunxi-uart,0x02500000 clk_ignore_unused initcall_debug=0 console=ttyS0,115200 console=tty0 cma=8M LANG=en_US.UTF-8 fbcon=rotate:1"

And re-run u-boot-update to undo any mess made when removing the Ubuntu kernels.

Kernel CONFIG Deficiencies

There are other things that seem to be broken. For example you’ll see something like:

systemd-journald[103]: Failed to set ACL on /var/log/journal/a4f7484327ea45d0adefc49de6774111/user-1001.journal, ignoring: Operation not supported

That’s probably because:


It turns out there are a lot of kernel configs, required by systemd, that are not set but should be:

# CONFIG_FHANDLE is not set
# CONFIG_NET_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_SECCOMP is not set
# CONFIG_BPF_JIT is not set
# CONFIG_CGROUP_BPF is not set
# CONFIG_EFIVAR_FS is not set

It’s possible some of these just aren’t available yet for riscv64, but several of them seem to be resulting in systemd having issues.

systemd Woes

In general systemd seems to be ailing on this kernel. When I’ve tried to apply updates, systemd eventually gets broken so that you can’t talk to it at all. That makes your updates extremely slow as there are half a dozen calls to systemd for any package that runs a service.

I tried updating just systemd, udev, and related things first, then rebooting. It didn’t help systemd not fall over eventually anyway, so I suspect the kernel configuration is at fault. It still seems like a good idea to update those core services first though.

sudo apt update
sudo apt install udev
sudo reboot


Hold on to your butts!

This works, but it starts to not work if systemd falls over:

sudo apt update
sudo apt dist-upgrade

The best way I’ve found to kick it along is to run sudo htop in another window and be prepared to kill things that get hung. Running it in Tree mode helps you see what’s below the apt process.


These are awesome tips. I’d figured out a bunch of these (but not all) but I’ve not gotten around to posting my content anywhere yet. Thanks for sharing!

1 Like

Thanks @ajorg this is a good start on how to customize the default Ubuntu install. I’ve just spent a bunch of hours trimming the obscene fat of this Ubuntu install. I really don’t think the AMD or Nvidia video drivers are going to help me. I prefer the Debian/Devuan experience: start with the bare minimum and add what you want. But then when I go through the “dselect” phase I turn off EVERYTHING including the base packages. Then add on what I want.

Anyhow your tip about the boot breakage saved me some time in my effort to cut the fat. ALL of the installed kernels don’t match the one actually being used. I’ll save testing the new kernels for a later date. I would assume that Clockwork customized the kernel. In which case they really should make their own kernel packages and host all of the custom packaging on their own repo server.

Perhaps they do? I find surprisingly little official information available from Clockwork. A one page wiki? Really?!?! Am I missing some link?

After I finish my debuntuing recipe I can post it here if anyone else is interested.


Thanks for the tips! I tried every one of them, and now the unit won’t boot at all :smiley:

Does anyone know where I can get a canned archive copy of the Ubuntu image that went onto these SD cards? I need to re-flash mine.

:)) Backups are good! I have four uSD cards handy and a filesystem clone on my laptop… in case I mangle the software on a uSD too badly. You can go to the clockwork site and click “disk collection” under the “community” menu. Here’s the link to the image download:


You don’t have any way to mount the uSD on another Linux computer? If you can, its likely @ajorg’s “bootloader configuration” tip will recover the failed uSD.

This is awesome! Thanks! Turns out, Clockworks left a backup copy of the extlinux file in the boot, so all I had to do was rename the one I generated from his configuration instructions, and copy the CPi backup back to its original position, and the system booted again. Now… just to get the rest working again :smiley:

Ouch! Sorry my instructions didn’t work well for you. I tested them after figuring them out, but I might have missed something.

Glad you got things working again.

No worries, friend. It all worked out. I’m totally ok with it breaking :smiley: This is an “experimental model” after all. So, I expect things to break frequently. I was just sort of hoping Cpi would have had a bit more polish on the os before shipping…