kernel-debs: run header_postinst.d from linux-headers postinst (DKMS order-safety)

[igorpecovnik]

Root cause (the package-level fix)

DKMS modules only ever got built from the linux-image postinst, via run-parts /etc/kernel/postinst.d (which includes dkms's autoinstall hook). Armbian's linux-headers postinst compiles the header tree but does not run /etc/kernel/header_postinst.d — unlike stock Debian, whose linux-headers postinst runs that directory, and where dkms ships /etc/kernel/header_postinst.d/dkms to (re)build modules when headers install.

Consequence: the linux-image / linux-headers configure order mattered. In a single apt transaction (a kernel install, or an armbian-config branch switch) apt is free to configure linux-image before linux-headers; the image postinst then runs DKMS autoinstall with no headers present and fails, and nothing rebuilds the module when the headers are configured moments later. The module is left unbuilt — and pre-#10766 the failed image postinst aborted before the boot-symlink relink, which could leave the board unbootable.

Observed on a Radxa Cubie A5E: current→edge switch failed because aic8800-sdio DKMS built with no edge headers; CI [autotests run 35497058533] recorded kernel-switch edge → dpkg_state=absent.

Fix

After compiling the header tree, run the same header hooks Debian runs — run-parts /etc/kernel/header_postinst.d with the kernel version as the argument. Now whichever of linux-image / linux-headers is configured last builds the DKMS modules, so install order no longer matters and the module is ready on the first pass. Non-fatal (|| true): a broken out-of-tree module must not stop the headers package from installing.

Verification (live, Radxa Cubie A5E)

With aic8800-sdio registered in the dkms tree but not built for the running kernel (the exact post-image-install state), running just the header hook:

# dkms status → aic8800-sdio ... added   (registered, not built)
DEB_MAINT_PARAMS=configure run-parts --arg=6.18.52-current-sunxi64 /etc/kernel/header_postinst.d
# → "Autoinstall ... succeeded"; dkms status → ... installed

The header hook rebuilt and installed the module first-try — exactly what this change wires into the headers postinst.

bash -n clean; rendered postinst fragment verified.

Relationship to the other fixes

• This PR = the root fix: DKMS builds regardless of package configure order (Debian-native behaviour Armbian had dropped).
• kernel-debs: relink /boot kernel symlinks even when postinst.d hooks fail #10766 = keep the board bootable (relink /boot symlinks) even if a postinst.d hook genuinely fails.
• configng#1026 = armbian-config installs headers before image; becomes belt-and-suspenders once this lands, and still helps on already-deployed images.

Signed-off-by: Igor Pecovnik igor@armbian.com

Summary by CodeRabbit

• Bug Fixes
  • Debian kernel header packages now run standard post-install header hooks after compilation, improving compatibility with systems that rely on these hooks.
  • Hook failures no longer interrupt the overall header package installation process.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: armbian/build/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 71a501fa-ceaf-40ed-ab81-3e9c3a249b58

📥 Commits

Reviewing files that changed from the base of the PR and between faa8a66 and 1e1b047.

📒 Files selected for processing (1)

• lib/functions/compilation/kernel-debs.sh

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

The linux-headers post-installation hook now runs Debian header hooks through run-parts, passes the kernel version family, and ignores hook failures.

Changes

Linux headers hook integration

Layer / File(s)	Summary
Header post-installation hook execution lib/functions/compilation/kernel-debs.sh	The generated post-installation script runs /etc/kernel/header_postinst.d with run-parts when the directory exists. It passes the kernel version family and allows hook failures without aborting package installation.

Priority: ⚪ Not assessed

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: amazingfate

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: running header_postinst.d from the linux-headers postinst to improve DKMS order safety.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rpardini]

Nice find. Still, I'm confused:

• Scenario A: linux-image installs first, linux-headers second
  • dkms build will still fail linux-image install, won't it?
• Scenario B: linux-headers installs first, linux-image second
  • worked before, keeps on working now; but are dkms built twice?

[igorpecovnik]

Current tests shows that kernel switching with DKMS driver works as expected. I installed ZFS to Rock 5 running vendor kernel, then run auto test, which switches to current and then back to vendor. ZFS followed.
https://github.com/armbian/autotests/actions/runs/35526001419/job/106118165309
ATM (nightly) repository packages were made from this PR.

rock-5b-plus · inplace · image 26.11.0-trunk.54 · 16 ✅ · 0 ❌ · 0 ⏭️

Module	Status	Time	Detail
upgrade	✅	27.3 s	nightly · 26.11.0-trunk.54 → 26.11.0-trunk.54
reboot	✅	62.5 s	power-cycle · up 29 s
kernel-switch	✅	23.1 s	branch=vendor · family=rk35xx · installed=26.11.0-trunk.54 · boot_image=vmlinuz-6.1.172-vendor-rk35xx · kernel_before=6.1.172-vendor-rk35xx
reboot	✅	52.4 s	power-cycle · up 26 s
hw-performance	✅	16.4 s	AES 1284 · mem 15700 · disk W 69 / R 81 MB/s · 51.8 °C · 1800 MHz
dvfs	✅	16.6 s	ondemand · 1800–1800 MHz (peak 2304)
network-iperf	✅	32.0 s	enP4p65s0 ↑941/↓941 (1GE) Mbps
store-versions	✅	4.5 s	26.11.0-trunk.54 · 6.1.172-vendor-rk35xx
kernel-switch	✅	649.6 s	branch=current · family=rockchip64 · installed=26.11.0-trunk.54 · boot_image=vmlinuz-6.18.52-current-rockchip64 · kernel_before=6.1.172-vendor-rk35xx
reboot	✅	55.5 s	power-cycle · up 30 s
hw-performance	✅	27.9 s	AES 1289 · mem 7100 · disk W 20 / R 2 MB/s · 60.1 °C · 1800 MHz
dvfs	✅	16.2 s	ondemand · 408–1800 MHz (peak 2400)
network-iperf	✅	31.5 s	enP4p65s0 ↑941/↓941 (1GE) Mbps
store-versions	✅	4.1 s	26.11.0-trunk.54 · 6.18.52-current-rockchip64
kernel-switch	✅	509.8 s	branch=vendor · family=rk35xx · installed=26.11.0-trunk.54 · boot_image=vmlinuz-6.1.172-vendor-rk35xx · kernel_before=6.18.52-current-rockchip64
reboot	✅	47.8 s	power-cycle · up 22 s

Power — min 0.90 W · avg 6.99 W · peak 14.30 W · 1272 samples

xychart-beta
    title "Power — Rock 5B Plus 01"
    x-axis "sample" 1 --> 1272
    y-axis "W" 0.5 --> 14.5
    line [3.65, 3.19, 3.86, 3.78, 4.37, 3.55, 3.76, 5.60, 9.56, 7.96, 11.25, 10.73, 5.08, 4.96, 9.51, 8.80, 9.34, 9.33, 6.59, 4.18, 3.49, 3.51, 3.59, 5.19, 7.01, 5.76, 6.12, 7.19, 6.61, 10.69, 11.74, 12.13, 8.48, 6.12, 9.78, 8.90, 11.61, 11.15, 6.78, 4.91]

Loading