Arch Linux Image for MNT Reform

stephano · January 10, 2026, 7:02am

I’m generating an Arch Linux image for the MNT Pocket Reform.

I patched the kernel for all the MNT Reform SoMs, so in theory this should work, or at least boot, on all of them. I only have the i.MX8M Plus Pocket to test on (for now).

I’ve been running Arch on both an SD Card (for testing) and on my NVMe drive for several months now and it runs well with Sway.

The next step here is to get the reform tools installed in full, but at least for now, I added the LPC (reform2_lpc) and qcacld (wlan) kernel modules so WiFi and the display work well.

Comments, questions, issues, and PRs all welcomed.

josch · January 10, 2026, 7:20am

Nice! If you have any specific questions that you think i can answer as the author of these scripts for debian or as the author of reform-tools, please do not hesitate to @-mention or ping me directly! (or email of course also always works)

TwoWheeledIdiot · January 18, 2026, 9:16pm

Hey @stephano I can’t seem to generate dkms modules for this kernel

stephano · January 18, 2026, 9:46pm

@TwoWheeledIdiot what errors are you seeing? If memory serves you can find the errors in /var/lib/dkms/<module>/<ver>/build/make.log.

Please paste the errors and the following info:

uname -r
readlink -f /lib/modules/$(uname -r)/build
ls -1 /lib/modules/$(uname -r)/

A few common culprits:

Ensure you’ve installed the right kernel headers and they are installed at /lib/modules/$(uname -r)/build (you can get those from the release artifacts, or if running Arch, from GitHub - cetola/linux-mnt-pocket-headers: Kernel headers for building modules on the MNT Pocket Reform running Arch)
Ensure there is not a kernel release string mismatch (should be “-mnt-pocket”)
Not sure which distro you’re using. Technically you could use this kernel with any aarch64 compiled filesystem you can get working. Be sure your distro doesn’t expect certs/signing_key.pem or scripts/sign-file to exist under /lib/modules/.../build.

TwoWheeledIdiot · January 18, 2026, 10:02pm

So I figured out one part of the problem, ulimit was set to 1024. I increased the file limit to fix it. A new problem has reared its ugly head dkms now starts but it segfaults after 8 seconds. As a note I am using void, your kernel is the only one that I can get to boot on my pocket (edit: grammer and structure)

stephano · January 18, 2026, 10:15pm

Oh I see the issue. I need to update the gen-headers script as it is shipping sources, generated headers, Module.symvers, AND host-built executables. So you have a bunch of x86_64 executables that the DKMS build is trying to call.

I’ll have to think about the best way to fix this. I’m relatively new to cross compiling kernel headers.

TwoWheeledIdiot · January 18, 2026, 10:22pm

That would explain the segfaults, For now Ill just compile the kernel on device. you could try installing an arm arch install to a directory on your x86 machine then with the binfmt service installed and enabled you should be able to compile the kernel without any non-arm code ending up in the kernel

stephano · January 18, 2026, 10:51pm

Good idea, and thanks for the feedback / trying out the kernel. I’ll probably use binfmt as a backup path. I use it to run dracut when generating the Arch image and it works great for that.

I’ve been debating a native Arm EC2 Spot Instance rather than the x86 one I’m using now. I think that would be best long term.

Issue created:

github.com/cetola/mnt-build

Kernel headers package includes x86_64 host binaries, breaking DKMS on ARM

opened 10:58PM - 18 Jan 26 UTC

cetola

The currently published kernel headers for our custom ARM64 kernel unintentional…ly include **x86_64 host-built executables** under `scripts/` (e.g. `fixdep`, `modpost`, `conf`, `sign-file`, `dtc`, etc.). These binaries were built on an x86_64 build host and copied verbatim into the headers package. When users attempt to build DKMS modules on an ARM system, the kernel build system tries to execute these tools and fails with errors like: ``` cannot execute binary file: Exec format error ``` This makes DKMS unusable out of the box for users running the kernel on ARM (e.g. Arch Linux ARM), even when all required dependencies are installed and the headers otherwise appear correct. **Root cause:** * Kernel headers are generated on an x86_64 host. * The headers packaging process copies the entire `scripts/` directory, including host-built tools. * These tools are built with `HOSTCC` (native to the build machine), so they end up as x86_64 ELF binaries. * DKMS expects these tools to be executable on the target ARM system. **Impact:** * DKMS module builds fail on ARM with `Exec format error`. * Users must manually prune x86 binaries and rebuild host tools on-device, which is error-prone and undocumented. * This deviates from the behavior users expect from distro-style kernel headers packages. **Proposed fix:** Generate kernel headers in a **native ARM environment** so that all host tools under `scripts/` are built as `aarch64`. Specifically: * Use a native ARM64 AWS EC2 instance (spot instance is sufficient and cost-effective). * On that ARM instance: * Use the exact kernel source and `.config` corresponding to the released kernel. * Run `make prepare` / `make modules_prepare`. * Package the resulting headers tree. * Publish these headers instead of (or in addition to) the x86-generated ones. This ensures: * All required host tools are ARM-native. * DKMS works out of the box without user intervention. * The headers package matches established distro expectations. **Alternative / future improvement:** As a follow-up, we may also update the headers packaging process to explicitly exclude host-built executables and rely on `modules_prepare` being run on the target. However, generating headers on native ARM hardware is the most robust and user-friendly immediate fix. **Expected outcome:** * DKMS modules build successfully on ARM systems using the provided headers. * No `Exec format error` due to architecture mismatches. * Reduced user support burden and clearer correctness guarantees.

stephano · February 16, 2026, 3:00am

@TwoWheeledIdiot I finally had a chance to dig into building kernel headers. It turns out there’s a script in the kernel tree scripts/package/install-extmod-build. It is an upstream kbuild helper that assembles the minimal kernel build tree required for compiling out-of-tree modules (e.g., via DKMS), including generated headers, Module.symvers, and necessary build scripts. It is used by the kernel’s deb-pkg and rpm-pkg targets to create the linux-headers/kernel-devel package contents. It also knows about CROSS_COMPILE unlike my previous hacky attempt.

I’m going to use it to test a clean, upstream-aligned way of producing a DKMS-compatible headers tree without manually copying and pruning the full build directory. Even though it introduces a dependency on upstream packaging internals, it provides a well-defined and actively maintained baseline for validating that external module builds work correctly.

Arch in particular does not do this, but rather ships the whole build tree minus some pruning. Since the point here is for me to learn, I should probably do that. However I’d rather focus on other tasks for now, like porting reform-tools over to a PKGBUILD for Arch (see @josch I remembered ).

I’m testing a fresh build of 6.18.9 out and will report back if it fixes the DKMS issue you were seeing. Of note, I’ve upgraded to the A311D chip, so I’m also testing the kernel & header builds on a new SoM. Why change one thing when you can change 4?

stephano · February 28, 2026, 12:29am

DKMS is fixed. Or at least fixed well enough that my “hello world” module builds across multiple kernel upgrades.

I’ve also started work on porting the reform-tools (hi @josch). The images will not contain these tools by default while they are still in “beta” form, but you can install manually or via the PKGBUILD. You can also find them on the AUR repo.

I’ve started tarring / installing the kernel, wlan, and lpc modules separately now. I’ve created a table in the README.md for all the available PKGBUILDs.

I’ll move the PKGBUILDs to AUR as they mature, but since reform-tools was already there and out of date I figured an update was worth it.

josch · February 28, 2026, 11:19am

Wonderful! Send me your bugs and feature requests related to Arch.

Tools like reform-check are currently apt/dpkg-only but they should be distro agnostic. If you send me a patch to make reform-check work for Arch, Ill merge it. There is for example a WIP MR for Void Linux here: Draft: Update reform-check to work with Void linux (!115) · Merge requests · Reform / MNT Reform Tools · GitLab

stephano · February 28, 2026, 2:30pm

I’ll give some thought to a more distro agnostic approach. I started to look at scripts like reform-check. Ideally we’d avoid giant case statements, but I haven’t had enough time and coffee to think about a good way around this.

josch · February 28, 2026, 9:23pm

See the MR for more ideas on how to architect this.

stephano · February 28, 2026, 9:56pm

After reading the MR I really like the idea of templating. I haven’t used jinja in a little over a decade so I’ll have to dust off that knowledge a bit.