Void Linux for the uConsole CM4

Hello,

over the summer, a friend of mine hit me up about porting Void Linux to his uConsole because he knew that I had some experience in building custom images for Raspberry Pi using Github Action Runners and workflows. He wanted Void so I put together a port for him and he was kinda blown away by how easy I made it look.

The truth is doing it all entirely with Github runners and even publishing the image to releases is a bit tricky; you have to keep the build times under 2 approximately two hours and you’re limited to about 1.2GB for the release image size. That said, the image itself is actually very barebones and only provides some essentials as well Ansible (which you can use to further provision the image using a mechanism I’ve built into the image that I’m referring to as a side loader;

Void Linux for the uConsole (bare image):

This includes building the kernel. The kernel source tree itself is actually added in-tree as a “subtree” not to be confused with submodule; and the commits are squashed to minimize the delta overhead. By minimizing the git overhead and consolidating the repository to a single repository this allows the Github action runner to obtain the entire source tree that is needed much faster than if it were to git clone the repository for the kernel src directly. The kernel is compiled using the host since cross compiling the kernel for ARM is relatively straight forward. A Docker container is used along with qemu-aarch64-user and BINFMT to build the rest of the operating system image; the problem with doing this is that it’s a little slow so it just worked out that the kernel was easy to cross compile using the host (much faster.)

My Ansible sideloader playbook:

Personally I like having a device that just has as much software as possible installed on it because frankly it’s useful sometimes.

So my friend just wanted the base image and he was pretty thrilled to get this particularly in the form that I provided it so he bought me my own uConsole as a gift…

does it work?

My friend has been using his since back in June or July without using Ansible at all. I think he prefers a minimalist setup, anyway and if I’m being honest Void is certainly much better for that. I’d be happy to improve it if somebody else has a use for it.

I used Ansible to get all the software I wanted installed for my own device but it does still need some work, particularly the disk repartitioning needs to be tested still and I haven’t had time to test it but I’ve at least got it to start and run Plasma Wayland, and I was even able to get the sound working: check the issues page on the repository

BTRFS without autodefrag is used for the root filesystem; autodefrag is disabled in the fstab options and ZSTD compression (max level) is used. I haven’t noticed any problems with this but there aren’t exactly a lot of good filesystem options out there which speak to the kinds of things I want in a filesystem. It is even possible to create a swapfile on BTRFS with the “NOCOW” attribute which in turn (and in theory) can be used for suspend to disk-- a feature I’m really looking forward to adding for this given the obvious advantages that it speaks to. I have an issue open for this, check the issues page on the repository.

Anotther thing my friend noticed right of the bat after he booted the first test image, was that I actually used aarch64-musl; which apparently was more than he had hoped for and he was also very thrilled that I was able to go the extra mile but it just seemed like naturally the right choice to make given that it’s essentially the one thing about Void that everybody loves. After all, your average Linux user hates systemd and even though I can’t relate personally, but afaik systemd won’t even build against musl libc last time I checked.

I have to say runit is not too terrible of an option. In fact, I started using runit way before I even knew what systemd was and aspired to replace my init with it before a systemd vs openrc was even something that people imagined would inevitably come into fruition. It is some would say a painfully simple process supervisor–but a process supervisor nonetheless; you won’t get any fancy hooks for setting cgroups, it’s designed to run a command and wait for it to exit–and that’s it basically.

Now, I’ve always really liked systemd and found it particularly useful which is frustrating because I feel like I’m probably the only one a lot of the time. I’d prefer systemd-networkd to NetworkManager, too but that’s certainly not an option here.

I’m a bit of a different breed of alternativist and my preference would be to FreeBSD; which is not unimaginable for the uConsole but it will require some work to get the display working. Another thing that could potentially demotivate me would be figuring out whether or not an image can be produced using Github Action Runners. Unfortunately Github doesn’t provide any FreeBSD action runners, though it is perhaps possible to use FreeBSD’s linux compatibility layer to run Github’s runner software (IIRC it is written in dotnet.) Personally it’s an option I’d like to explore a bit and have been in other aspects of my life as of late. Originally I picked up FreeBSD & OpenBSD back in the earliest 2000s, though they’ve kinda taken a backseat as most of what my career has demanded is Linux. I have to say I’m extremely impressed with how consistent BSD has been throughout the years. I"m also a bit put off as of late by the Linux community as of late, particularly with regards to how BCacheFS is being handled and I really wouldn’t mind trying to put FreeBSD in the hands of ordinary people again. Soon I will be coming up with a new desktop build to use for development in place of my Macbook Air that I’ve been using but you can be sure it probably won’t be Linux that is running on it =)

But like I said, I built this Void image for somebody because it’s a thing that my friend could relate to and that he appreciates and I’m happy to improve it for anybody if it means the same to them. So feel free to contribute or test it out (get a spare SD) and by all means feel free to open a ticket on the issues pages if you need help. I’ve tried to describe a lot in the README.md of each repository as much as I could but I’m sure it will need to be improved for some people so please do not hesitate to reach out.

-Paige

8 Likes

This is awesome, I am going to check it out. I am not necessarily a Void Linux fan, nor am I looking to eliminate systemd. However, I am looking for something better than the default image. It is very lacking.

I am a Linux System Administrator of a hosting company, and I just got my uConsole to use as a take everywhere, always connected, emergency admin workstation. I plan on adding better external antennas for both the Wi-Fi and the LTE, and 3D printing a custom hard carry case that is reminiscent of a Pelican case.

I think what you have done here is great, and I hope it turns into a launch pad for alternative Linux OS images for the device. I would love to have an image that is either Mint or Nobara, just because the the way everything works in those two just so perfectly match how I want my desktop and I only have to do about 3 or 4 days worth of tweaking rather than my typical month. I kinda see Nobara by Glorious Eggroll as the Linux Mint of Fedora, because it is to Fedora as Mint is to Ubuntu.

1 Like

Thanks :slight_smile: If you want, I have created other image builders for Raspberry Pi (in general, not the uConsole) that are debian-based:

This is also built using Github action runners. You could certainly make an image for the uConsole based on this work, though if you wanted to fork it. I’m happy to answer any questions about it that you may have as well. I’ve considered doing this a few times myself but I figured since I already did Void for a friend, I might as well go with it.

I have already screwed up my new device. Once I get this resolved:

I will go back to looking for alternative distros for the device. I will certainly keep and eye on this though.

1 Like

Awesome!

What would you say Void Linux brings to the table? Ditto for BSD – I haven’t used that since CD-R media was still common-place.

I published my sway configuration for the stock image some months ago. I want to take it further, but I want something beyond debian stable as a foundation. I’m considering NixOS, Yocto, or even Buildroot.

I think it’s super cool that you were willing to explore runnit as and musl. This sort of stuff really mattered to me several years ago, when I was doing embedded Linux development. The hardware in question was technically “application class”, but only just barely. Anything I could do to shave bytes off those images was worth it. If you view the uConsole as a test-bed for embedded Linux, then perhaps the value of having a bootable image based on an alternative stack like this is a bit more clear. And, crucially, the ability to reproduce such an image from source. If I can get it working on uConsole, then I can use that for prototyping until more concrete hardware becomes available.

The only insight I can offer you into all the systemd hatred is that it’s not really about the technology, it’s more political / personal. Lennart is particularly opinionated, and runs his projects on an all-or-nothing, take-it-or-leave-it basis. Pulse was like this, and systemd is more of the same – but even worse in the way it unilaterally subsumed a bunch of functionality that was historically more distributed. In short: it stepped on peoples toes, and changed system administration in fundamental ways, and ships with a bunch of scripts and configuration for every conceivable supported peripheral, most of which is dead weight on any given install. For a desktop or laptop install, who cares? Mainstream distros want things to Just Work ™, and systemd fits the bill as doing what upstart did, only better. But on something like the uConsole, where the hardware is more constrained, it’s potentially a waste of space, and you can probably get a runnit-based system to boot much faster, particularly if you’ve got a very narrow use-case in mind. And keep in mind, you can use a CM which boots off an SD card, you can swap out media to suit the use-case.

My record for booting on RPI 3 hardware was 7 seconds from power-on to my custom dashboard app, which ran as a DRM master, using buildroot to build the image. You can do better than that, but you really have to start yak shaving at that point, and buildroot has some real shortcomings.