Works great on Ubuntu 26.04 / kernel 7.0.x, but needed a workaround for a broken linux-headers package — sharing in case it helps

[ebanavorio]

Short version:

First of all, thank you for this driver — it's the only thing that made my MIDI Express 128 usable on Linux at all, and once everything was in place, all 8 MIDI ports work flawlessly. 🙏

I wanted to share my experience getting it running on Ubuntu Studio 26.04 (kernel 7.0.x), since the README mentions it's only been tested on 5.x. I ran into a few hurdles along the way, but none of them turned out to be actual bugs in motu.c — they were all related to an incomplete linux-headers package on this Ubuntu version. I'm documenting the whole path here in case it saves someone else some time, or in case a short note in the README about newer kernels would be useful. No pressure at all if this isn't a priority — just wanted to share this since the driver has been so useful to me.

Details:

Environment:

• Ubuntu Studio 26.04 "Resolute", kernel 7.0.0-30-generic
• GCC 15.2.0-16ubuntu1, Binutils 2.46

What I ran into, and how I worked around it:

1. The manual build instructions kept failing with missing files inside /usr/src/linux-headers-7.0.0-30-generic/ (arch/x86/tools/cpufeaturemasks.awk, arch/x86/entry/syscalls/syscall_32.tbl, arch/x86/tools/relocs_32.c and a few related files, tools/include/tools/le_byteshift.h):

   make -C /lib/modules/`uname -r`/build M=$PWD

   I confirmed via apt-get source linux-image-unsigned-7.0.0-30-generic that these files exist in the full kernel source — they just aren't shipped in the -generic headers package for this particular kernel build. Seems to be an Ubuntu packaging issue rather than anything related to this project.

2. Worked around it by building against the full downloaded kernel source instead of the packaged headers (make olddefconfig + make modules_prepare, after installing dwarves and rustc/bindgen to match the running kernel's official .config).

3. Ran into a separate, minor issue: the downloaded source reports its own upstream version (e.g. 7.0.12) rather than the Ubuntu build string (7.0.0-30-generic) in VERSION/PATCHLEVEL/SUBLEVEL/EXTRAVERSION, which caused a vermagic mismatch. Fixed by editing those fields in the top-level Makefile to match uname -r.

4. Even after that, I got Exec format error / Invalid relocation target on insmod for a while — this turned out to be stale build artifacts from my own earlier mixed attempts, not a driver issue. A clean make clean + rebuild sorted it out.

5. To make it survive kernel updates, I set up DKMS with a custom dkms.conf pointing MAKE[0] at the full source tree rather than the default /lib/modules/$kernelver/build, since the latter still hits the same incomplete headers package. Here's the one I ended up using, in case it's a useful starting point for anyone else (this assumes the full source tree has already been prepared as described in step 2 above):

   PACKAGE_NAME="motu"
   PACKAGE_VERSION="1.0"
   BUILT_MODULE_NAME[0]="motu"
   DEST_MODULE_LOCATION[0]="/updates/dkms"
   AUTOINSTALL="yes"
   # Points explicitly at a full, patched Ubuntu kernel source tree (with
   # modules_prepare already run) instead of the default DKMS
   # /lib/modules/$kernelver/build, because the linux-headers package for
   # this kernel was missing files needed for external module builds.
   # After a kernel update, this will need to be repeated for the new
   # kernel version (download/patch the matching source, run
   # modules_prepare, update the path below) until the headers package
   # itself is fixed upstream.
   MAKE[0]="make -C /path/to/full-kernel-source M=\$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build modules"
   CLEAN="make clean"
   

I didn't get a chance to try debpkg.sh — I'd guess it might hit the same missing-files issue on this Ubuntu version since it likely also builds against the packaged headers, but I haven't verified that, so please double-check before relying on it.

Thanks again for maintaining this — without it, this device would simply be unusable on Linux.