Logbook

Fedora on Raspberry Pi 5: whole lot of patches needed

Peter Robinson has been looking at supporting Fedora on the Pi 5, and shares his early observations here in a message to the Fedora Project's "fedora-arm" mailing list of Saturday, 18 November 2023.

https://lists.fedoraproject.org/archives/list/[email protected]/message/ER5R4CSDCZENQSVSPULNGSAFK63SQZDK/

So the long story short is ATM nothing will work with vanilla upstream kernel yet unless you could serial console and display. I'm hoping that various kernel people will start to poke around and get pieces upstream, the biggest individual piece of work is definitely the PCIe end point to AXI bridge driver piece as without that nothing on the RP1 chip will work.

Kernel subsystems that will need a fair bit of work include everything that will touch the new RP1 peripheral handling chip. Peter again:

The vast majority of everything else hangs of the RP1 chip which is a uses a weird PCIe-EP to AXI bus bridge thing which AFAICT needs a MFD driver to be upstreamed to unlock the fairly generic IP that provides the rest.

Fortunately for us mortals who are happy enough running the official supported distribution, there is a Raspberry Pi OS based on Debian Bookworm. There are still changes there - Wayland, PipeWire and NetworkManager are new components - but the Pi folks have done the necessary kernel-mucking in their distro to support the new hardware.

https://www.raspberrypi.com/news/bookworm-the-new-version-of-raspberry-pi-os/

Small Arm-based single-board computers have a very long track record of not booting a vanilla upstream kernel, in part due to weird custom boot loaders, in part due to the slow process of upstreaming component support. The Pi has been easier to use than most due to a huge amount of users and a steady base of support for old models, but (in general) you can't treat any of these little boards like it was an off-the-shelf server and plug in and boot a standard distribution off of USB.

(Yes, I have a Pi 5 on order, it's going to run the official OS. I am not your kernel hacker.)

hello world, an annotated history (gist)

See https://gist.github.com/vielmetti/3360df282d7cbadf579a09ebb74d536a for an annotated list of "Hello World" style one-liners using a variety of tools, sorted by the date that the code is available.

I'll come up with a better place to publish this - it turns out that Typepad is not the best spot to post code.

Asahi Linux on MacBook Air M1 - an update

Previously: Asahi Linux alpha on M1 MacBook Air / Apple Silicon, first impressions

After a few months of idleness, I decided to revisit my Asahi Linux installation on my MacBook Air. As you may remember, Asahi Linux is adapted for the Apple Silicon (M1 and M2) chips, and is based on Arch Linux. It installs in a partiton on your Mac and you can dual boot it (long press the power key at start to bring up a menu).

The first snag in getting online was logging in. I am sure that I picked an easy to remember yet secure password five months ago, so easy to remember and so secure that I didn't write it down. Oops. Couldn't remember it, the usual tries didn't work, so it was time to break in.

Fortunately, Arch Linux has a nice primer on resetting a lost root password which jogged my memory as to what was possible. When you edit the boot sequence so that the init process is replaced with a shell - e.g "init=/bin/sh" - it's straightforward to boot into a single-user mode and run "passwd" to fix up the situation. Make sure that the drive in question is mounted read-write, and make sure you "sync" a few times after doing the edits so that the buffers are flushed to disk.

That little problem disposed with, it was time to update the system. Arch uses the "pacman" package manager, and the command "pacman -Syu" is all you need to trigger a complete update. There were 800+ packages that had updates. To be extra sure that everything was all in sync after all of those changes, I did a reboot and the system came up just fine.

When last I tried this, the Chromium browser didn't work because it didn't support the 16K pages that Asahi (and the Mac hardware) provides. Since then that bug has been fixed and Chromium starts just fine, with the caveat that it throws a couple of GPU related complaints along the lines of "Exiting GPU process due to errors during initialization" when starting. This is Chromium 104.0.5112.101 installed with "pacman -S chromium". Chromium did work well enough that a little bit of web browsing worked ok, but I didn't try anything very complex (the usual show-stopper is Youtube).

I had previously installed Firefox and that seems to continue to be just fine.

One goal I have on this system is to get some Electron based apps up and running, notably Obsidian. Obsidian has an "Appimage" flavor of distribution for arm64, so I tried that, and it immediately crashed with a segmentation fault (16K pages again). I can't tell at a glance which version of Electron that Obsidian ships with, but with a similar discussion for VSCode the winning version seems to be some flavor of Electron 19. I did not pursue trying VSCode out, but the VSCode issue Update to Electron 19 looks like the cutting edge of discussion. I'll make a point to try to get that working next time I'm in.

Asahi doesn't start up out of the box with an ssh daemon installed, so I put opensshd on the system and enabled it. Together with Tailscale, this got me to the point where I successfully logged into Asahi from my Android phone. A next step will be to enable "Tailscale ssh" on Asahi, but I stopped before adding that step.

My usual observations about the Linux desktop user interface still hold - everything feels just a little bit less precise than the Mac desktop (or even the Windows desktop) that I am used to, and there are enough key bindings that I am also used to that are different enough to make things confusing for occasional use.

All in all a good evening's exercise, good to have a system in reserve for when you need to see how things are. I'm not ready though to have Asahi as a daily driver.

Asahi Linux alpha on M1 MacBook Air / Apple Silicon, first impressions

Some installation notes from getting Asahi Linux (alpha) running on an M1 MacBook Air (Apple Silicon).

Asahi Linux is a Linux distribution for Apple Silicon. The alpha installer release came out on 18 March 2022, and being brave, I decided to give it a try.

https://asahilinux.org/2022/03/asahi-linux-alpha-release/

Before you do the install, you need to upgrade your Apple Silicon machine to macOS Monterey 12.3 or better. MacRumors reports that if you have had your logic board replaced recently there are bricking issues with this release. My upgrade went smoothly, but if your MacBook has been in the shop recently you should take extra care.

https://www.macrumors.com/2022/03/17/macos-monterey-bricking-macs-logic-boards/

The install process itself went smoothly. In the course of doing it, the script will do a "live resize" of your existing MacOS partition to make room for a new partition that has Asahi Linux on it. The configuration supports a dual boot setup, so you can pick at boot time which OS you are running.

The installer downloads Asahi Linux, and if your network is not 1000% stable you might see this message

Error downloading data (<urlopen error [Errno 60] Operation timed out>), retrying

The progress indicator here is a series of +++ signs, as long as those continue to appear you'll be fine. If your network is not great it might take a long time, expect to download between 700MB and 4GB of data.

Follow the reboot instructions precisely after doing the install. "You need to fully shut down your machine, then boot by holding down the power button until you see “Entering startup options”, choose your new OS in the boot selector menu, and follow the prompts."

You'll boot into Asahi Linux, which is a derivative of Arch Linux ARM. There is an installer with a few options (pick your time zone, pick your keyboard layout, set an initial password) and you'll be into a desktop based on KDE Plasma. One of the things you'll pick is a system name; I chose a name distinct from but related to the main name of my MacBook to make it distinct.

https://archlinuxarm.org

If you haven't used Arch before, the package manager is "pacman", and there's a helpful "Rosetta" table which will help you figure out how to translate commands from other package managers into this one.

https://wiki.archlinux.org/title/Pacman/Rosetta

Plasma is a desktop environment from KDE, providing a familiar windows-icons-mouse environment. Coming from the Mac, you will notice that some keyboard bindings are different, for me notably this is cut/copy/paste which I always get confused in Linux systems. You may find Plasma familiar if you come from Kubuntu, which is a Ubuntu distro that uses Plasma instead of GNOME.

https://kde.org/plasma-desktop/

Firefox is a supported browser in Asahi Linux. What I noted was that the Retina display on my MacBook Air gave me teeny tiny text on the screen. You can bump up the magnification in the window to make the browser readable, but that's not quite enough to get the whole UI larger. Arch has a detailed article on "high DPI displays" (HiDPI) which specifies all of the various tweaks to the various applications that might be necessary to make the display just the way you like it.

https://wiki.archlinux.org/title/HiDPI

The first application I installed was Tailscale, a VPN that I use to connect my various and sundry systems together. The install went quickly using the Arch Linux instructions, even though those instructions promise only 64-bit x86 support.

https://tailscale.com

Feeling brave, the next thing I tried was getting Obsidian up and running. Obsidian is a personal notebook structured as a wiki based on Markdown. I keep lots and lots of notes in Obsidian, and if I'm going to use Asahi for any length of time I'll want to have it running. The options provided for Linux for arm64 are "Appimage", tar, and deb formats. Arch Linux ARM does not appear to have a prepackaged Obsidian ready to install, so I grabbed the tarball and gave it a try. The immediate error message was "segmentation fault".

https://obsidian.md

Obsidian is based on Electron and Chromium, and there are notes in the Asahi alpha distribution that Chromium is not supported due to its lack of support for 16K page sizes. Different aarch64 chips support different memory allocation configurations, with 4K pages being relatively universal and 64K pages originally found in RHEL and CentOS configurations. The M1 hardware supports 16K and 4K pages, and the Asahi team is starting with the 16K configuration for performance reasons as well as to shake out any remaining software bugs for the relatively few systems remaining that hard code a page size. The Chromium bug was first found by the Debian team as they were doing a port.

https://bugs.chromium.org/p/chromium/issues/detail?id=1301788

The identification of a PAGE_SIZE bug generally affecting aarch64 systems dates back at least as far as 2015, when the Go language was seen hard-coding a 64K page for that architecture. That bug in Go was fixed in 2016, after it was seen impacting the Docker overlay filesystem.

https://github.com/golang/go/issues/13191

The Asahi team has a short list of other software affected by the 16K page size issue, with status towards patches. The Chromium bug affects a whole set of Electron based applications. FEX, an x86 emulation library, is known to have issues that may be difficult to resolve in practice due to the deep-seated assumptions about the 4k page size in the x86 architecture. Emacs (good old Emacs) makes some assumptions about the page size being defined at compile time instead of at run time.

https://github.com/AsahiLinux/docs/wiki/Software-known-to-have-issues-with-16k-page-size

Overall impressions:

Installation was very smooth and painless for an "alpha" release, no complaints.

The general arm64 Linux ecosystem is in pretty good shape, which is reassuring and bodes well for a server style installation of Asahi Linux.

2022 is the year of Linux on the desktop, and cut/copy/paste key bindings still trip me up.

Page size bugs are the bugs that keep on giving, and are still affecting aarch64 software development years after they were first described and identified.