e1000e-dkms-lts515

Category: private (arch/private/e1000e-dkms-lts515). arch=('any') — this is a DKMS source package, not a compiled binary: package() just installs the driver source + dkms.conf under /usr/src/, and the actual kernel module compile happens at install time on the target machine via a pacman post-transaction DKMS hook, against whatever kernel headers are present. makepkg/repo_release.sh never actually compiles the module, so a clean build here says nothing about whether the driver itself compiles against a given kernel.

Currently 3.8.7-3, already published on archlinuxaba for every arch (including pentium4, i486, i686, x86_64, and the arm/aarch64/ riscv64 set) since it’s arch=any.

2026-08-27: confirmed actually DKMS-buildable against linux-lts515 (pentium4)

Since packaging success is meaningless for a DKMS module, tested the real compile: made a throwaway copy of the archlinuxaba-pentium4 archbuild chroot (sudo cp -a /var/lib/archbuild/archlinuxaba-pentium4/root /tmp/e1000e-test-pentium4), arch-chroot’d in (bind-mounted /proc+/sys, copied /etc/resolv.conf), and did a normal pacman -Sy dkms linux-lts515 linux-lts515-headers + pacman -S e1000e-dkms-lts515.

The pacman hook first tries (and fails, expected/irrelevant) to DKMS-build against the host’s running kernel (7.1.8-arch1-3 — not installed in the chroot, no headers for it, harmless “Error!” in the hook output). But linux-lts515-headers’ own install hook separately triggers dkms install --no-depmod e1000e/3.8.7 -k 5.15.217-1-lts515 for the actual target kernel, and that one succeeded silently. Confirmed via:

dkms status → e1000e/3.8.7, 5.15.217-1-lts515, x86_64: installed (Original modules exist) (the “x86_64” tag is just uname -m of the host kernel shared with the chroot — irrelevant to whether the compiled module itself is 32-bit; don’t take it as a sign the wrong arch was built)
The actual module file exists: /usr/lib/modules/5.15.217-1-lts515/updates/dkms/e1000e.ko.zst
Decompressed and ran file on it to confirm it’s a genuine 32-bit build, not accidentally compiled with the host’s 64-bit toolchain: ELF 32-bit LSB relocatable, Intel i386 — confirms the chroot’s own i486/pentium4-targeted gcc was used via linux-lts515-headers’ KDIR, not the host compiler.

Chroot copy destroyed afterward (umount both /sys mount layers arch-chroot adds internally + the manual bind mount, then rm -rf). No changes made to the persistent archlinuxaba-pentium4 template chroot — this test only touched the disposable copy.

Conclusion: yes, e1000e-dkms-lts515 3.8.7-3 DKMS-builds cleanly against linux-lts515 5.15.217 on pentium4. No PKGBUILD/patch changes needed. If linux-lts515 gets a future point-release bump, re-run this same throwaway-chroot check if there’s ever reason to doubt it (e.g. a kernel API used by the e1000e-3.8.7_coalesce_interface.patch changes signature) — nothing here is pinned to 5.15.217 specifically, just last verified against it.

Throwaway-chroot DKMS test recipe (reusable for other dkms packages)

sudo cp -a /var/lib/archbuild/<repo>-<arch>/root /tmp/<pkg>-test-<arch>
sudo mount -t proc proc /tmp/<pkg>-test-<arch>/proc
sudo mount --bind /sys /tmp/<pkg>-test-<arch>/sys
sudo cp /etc/resolv.conf /tmp/<pkg>-test-<arch>/etc/resolv.conf
sudo arch-chroot /tmp/<pkg>-test-<arch> pacman -Sy --noconfirm dkms <target-kernel> <target-kernel>-headers <dkms-pkg>
sudo arch-chroot /tmp/<pkg>-test-<arch> dkms status
# decompress+file the .ko(.zst) under /usr/lib/modules/<kver>/updates/dkms/ to confirm real arch
sudo umount /tmp/<pkg>-test-<arch>/sys   # run twice -- arch-chroot itself adds a second ro bind on top
sudo umount /tmp/<pkg>-test-<arch>/proc
sudo rm -rf /tmp/<pkg>-test-<arch>

Expect (and ignore) two categories of noise: the pacman hook trying (and failing) to build against the chroot host’s own running kernel if it’s not one of the installed targets, and the mkinitcpio vconsole.conf/failed to detect root filesystem errors during the post-install initcpio rebuild — both are cosmetic chroot-test-install noise, same pattern already documented in memory/linux-lts515.md, not real failures.