This is a short one, I promise.
I just installed Windows on my desktop machine (for work, believe it or not?!), and… Let’s just say that the Windows installer UI isn’t great when it comes to identifying the different partitions and drives on the machine, and terrible UI usually leads to mistakes. Like nuking the EFI partition on my main Ubuntu drive rather than on the drive where I wanted to install Windows. Whoops?!
The astute reader might have noticed that this blog only has a handful of entries, with a pretty sizeable between the first and the rest. The reason is that, as I was attempting once more to write down some of my thoughts, experiences, opinions, I actually found the repo for one of my former attempts at doing so, presumably during the 2020 lockdown. I managed to salvage a single post from there, sending the rest to the scrap pile for reasons of really poor writing on topics that I’d like to revisit.
Sometimes, distro work takes you to some weird places… The following is an account of an investigation that took place in September 2025. Rather than going straight into the root technical issue, or even tracing a direct route between the initial report and its resolution, I’ll attempt to document the various twists and turns of the journey.
TL;DR: A simple strace rebuild on Ubuntu armhf mysteriously failed.
After lots of building and chasing down wrong leads, the culprit turns
out to be a malloc patch hitting a syscall normally handled by the vDSO,
which does not exist for 32-bit processes on Ubuntu arm64 kernels.
Lessons were learned, faces were palmed.
Today, I learned that the BPF syscall expects that, in a per-cpu value entry, each CPU-specific entry has an 8-byte multiple size. This post is mostly a short note to self, and perhaps to others that encounter similar issues.
I’ve checked the code on the 4.19 stable branch as well as the very recent 5.8, and the behavior is there in both cases.
The following data structure would be problematic: