Generic GRUB setup adds an Intel-only parameter to arm64 and loong64
images. Restrict it to amd64 while keeping the common Plymouth options.
Signed-off-by: SuperKali <hello@superkali.me>
Replace the ad-hoc cat | sha256sum of the copied board BSP files with
Armbian's calculate_hash_for_files helper — the same one artifact-kernel.sh
uses for the kernel config. It hashes each file's SRC-relative path and
content, sorted and order-independent, avoiding the concatenation-boundary
ambiguity of a raw cat.
KERNELSOURCE was identical to Armbian's MAINLINE_KERNEL_SOURCE default
(the kernel.org linux-stable tree), and hardcoding it opted the kernel
fetch out of the tuna/bfsu/google mirror resolution. Drop it and let the
default apply; KERNELBRANCH stays pinned to the 6.12.103 commit, which
lives in that same stable tree.
Separately, the kernel cache key folded this extension's own source
(declare -f) but not the content of the board BSP files it copies into
the tree (sfp-led.c, leds-lp5812.*, the parent Kconfig/Makefile and the
board Kconfig patch). Editing one produced a different kernel that reused
the cached artifact. Fold their content hash in too.
opts_* changes and the ASK pin already invalidate the kernel artifact
hash — opts auto-fold into kernel_config_modifying_hashes, and the pin
via ask_modules= — and the overlay synthesis is source-hashed through
extension_hooks_to_hash. The non-opts wiring in custom_kernel_config__ask_modules
(module-source copy, Kconfig/Makefile stitching) was the one path not
covered, since custom_kernel_config is not in extension_hooks_to_hash.
Fold the function's own parsed source into the hash so pure code changes
there rebuild the kernel. declare -f is comment/whitespace-insensitive,
so comment edits do not cause spurious rebuilds.
linux-ls1046a-current.config is a family-level config shared by every
LS1046A board. ASK offload depends on licensed NXP FMan firmware, so a
future non-ASK LS1046A board may run plain mainline — and the SDK/offload
symbols only exist once this extension stages the SDK overlay. Move the
DPAA/FMan/QBMan and ASK-module symbols out of the checked-in config and
force them from the extension's opts arrays instead, keeping the family
config mainline-clean.
Kconfig defaults are not safe to rely on: FSL_DPAA_1588 defaults n,
FSL_SDK_DPA defaults n, and FSL_DPAA_ETH_MAX_BUF_COUNT defaults 128 (we
need 640), so set them explicitly via opts_y/opts_val.
depmod builds the modules.dep/aliases indexes that autoload mlan before
moal. Masking its exit with || true let dpkg report a successful install
even when indexing failed, leaving the driver unable to autoload. Drop
the mask in postinst so the failure surfaces. postrm keeps || true so
package removal still succeeds if the kernel dir is already gone.
Address CodeRabbit review:
- Fail loud if drivers/staging/fsl_qbman is absent after the 005 SDK
overlay. The post-patch wiring is the only registration path once patch
110's staging hunks are stripped, so a silently-skipped wiring would ship
a kernel with no SDK QBMan driver and no error.
- Force the SDK DPAA/FMan stack (FSL_SDK_FMAN/BMAN/QMAN) explicitly on, and
the competing mainline FSL_FMAN off, via the kernel config opts arrays,
instead of relying on Kconfig defaults. ASK_CDX depends on FSL_SDK_FMAN
(which requires !FSL_FMAN); if a future mainline enabled FSL_FMAN by
default, olddefconfig would silently drop ASK_CDX and a non-offloading
kernel would build green. Mainline FSL_DPAA_ETH depends on FSL_FMAN, so
disabling FSL_FMAN keeps it off transitively.
Address CodeRabbit review: the mwifiex compat patch guarded
set_monitor_channel's net_device parameter on 6.12.103, but the cfg80211
change was backported to the 6.12.y stable series in v6.12.101 (verified:
v6.12.100 old signature, v6.12.101 new). The old guard would select the
wrong signature on 6.12.101 and 6.12.102. Regenerate the patch at 6.12.101
and rename it version-agnostically.
The Mono Gateway DK takes an optional PCIe 88W9098 (u-blox JODY-W3)
WiFi+BT combo card. Build the NXP mlan/moal fullmac WiFi driver as a
standalone kernel-module .deb (gateway-dk-wifi) against the kernel
headers, ship it with the 9098 combo firmware, and bake it into every
image (inert when no card is present).
- gateway-dk-ask.sh: pre_customize_image__002_build_wifi fetches the
driver (nxp-imx/mwifiex) and firmware (nxp-imx/imx-firmware, sparse
checkout of just the 9098 image), builds mlan.ko/moal.ko (PCIe-9098,
cfg80211 fullmac, STA + uAP), and packages the modules + firmware +
module autoload into gateway-dk-wifi. The .deb depends on the exact
linux-image version (the prebuilt modules are vermagic-locked) and
recommends the hostapd/wpa/iw/regdb userspace.
- mwifiex-cfg80211-mainline-6.12.103.patch: the driver gates
set_monitor_channel's net_device argument on cfg80211 >= 6.13, but
stable 6.12.103 backported that one API; lower the guard so the driver
builds against the in-kernel cfg80211 (OpenWrt sidesteps this via
mac80211 backports). It is the only cfg80211 op 6.12.103 backported.
The combo firmware also carries the BT blob, so the board's DTS-declared
btnxpuart controller initializes cleanly instead of erroring. Validated on
hardware: the 9098 enumerates two phys with STA + AP interfaces.
Switch the LS1046A family off the NXP vendor kernel (tag lf-6.12.49-2.2.0)
onto stock mainline linux-6.12.y, pinned at v6.12.103. The DPAA/FMan/QBMan
SDK that mainline does not carry is fetched from NXP at the ref the ASK
release pins and synthesized into an overlay patch at build time, with the
ASK hook + fix series (010-110) staged alongside; nothing SDK-related is
committed to the tree.
- ls1046a.conf: KERNELSOURCE -> kernel.org stable, KERNELBRANCH pinned to
the exact commit the ASK patch series targets.
- gateway-dk-ask.sh: fetch the NXP SDK (fetch_from_repo, at the ref read
from ASK's pins/nxp-sdk-srcrev.inc), overlay the driver source into its
mainline locations, and synthesize two patches into userpatches for the
Armbian patcher: 005 (SDK) and 006 (board device tree). The SDK-flavour
DPAA dtsi go into a private arch/arm64/boot/dts/freescale-sdk/ dir (wired
via subdir-y) so mainline's shared freescale/ dtsi are never overwritten
and the sibling QorIQ boards are unaffected.
- Drop drivers/staging/{Makefile,Kconfig} hunks from the ASK series (the
Armbian driver harness echo-appends out-of-tree drivers to those files
before the series, breaking patch context) and re-add the fsl_qbman
wiring post-patch.
- Remove the committed 001/002/004 kernel patches: INA234 (001) and the
libbpf const-correctness fix (004) are both already in mainline 6.12.103;
the board device tree (002) now comes from ASK.
- Carry the in-tree ASK module parent Kconfig/Makefile in the BSP (ASK 1.0.0
dropped them from its root, as OpenWrt/Yocto build the modules out-of-tree).
Kernel boots on the Mono Gateway DK; DPAA/FMan hardware offload runs at 10G
line rate.
On Debian desktop images the Armbian GRUB wallpaper was replaced by
Debian's theme image (Trixie: ceratopsian). Armbian only appended its
WALLPAPER to /usr/share/desktop-base/grub_background.sh, which desktop-base
ships and owns as a conffile — on Debian desktop images desktop-base is
installed and its version of that file wins, pointing GRUB at
/usr/share/images/desktop-base/desktop-grub.png. Ubuntu doesn't overwrite
it, so the Armbian image survived there.
Set GRUB_BACKGROUND in Armbian's own 98-armbian.cfg. 05_debian_theme
(grub-common) gives GRUB_BACKGROUND precedence over the sourced WALLPAPER,
so the Armbian image is used on both Debian and Ubuntu regardless of
desktop-base.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
v4l2loopback only builds against current kernels from 0.15.3 onwards. Earlier
releases call v4l2_fh_add() with the pre-signature-change argument count and
fail the DKMS build with "too few arguments to function 'v4l2_fh_add'". Debian
trixie still ships 0.15.0-2 in main, so gate on the apt candidate version and
skip the extension rather than failing the whole build.
The candidate lookup goes through chroot_sdcard_custom_with_apt_logic. A plain
apt-cache call cannot work here: the host-side apt lists are bind-mounted into
the chroot only for the duration of a chroot_sdcard_apt_get* call, and the
image's own /var/lib/apt/lists is not filled in until much later in the build,
so this early in post_install_kernel_debs apt-cache sees an empty index and
reports nothing at all. That runner mounts the lists, and pins LC_ALL=C, which
keeps the gettext-translated "Candidate:" label parseable. It logs stdout
rather than returning it, hence the redirect to a file read back host-side.
Both the query and the parse are kept clear of errexit. apt-cache exits 0 even
for an unknown package, but the runner around it can fail -- apt-cacher-ng
restart, the cache bind mounts, the chroot itself -- and an unreadable policy
file would abort from a command substitution; either would kill the build
instead of reaching the fallback. The policy file is removed before the query
so a leftover can never be read as this query's answer, parsed only when the
query succeeded, and removed again afterwards so a partial file is not shipped.
An unreadable candidate is treated as inconclusive and installs as before,
rather than skipping. A silent skip drops the module from the image behind one
warning line, which is a worse failure than letting apt refuse out loud.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* extensions: add @description headers and a list generator
Add a one-line `# @description` header near the top of every extension in
extensions/ (85 files), each ~35-45 words / 3 sentences, source-verified
against the extension's actual behaviour. Two extensions with a dedicated
docs page also carry a `# @doc-page` link.
Add lib/tools/gen-extensions-list.py, which scans extensions/**/*.sh for
these headers and prints the Markdown extensions reference consumed by the
documentation repo. The list is no longer hand-maintained: edit an
extension's `# @description` and the generator brings the change over.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* extensions: correct descriptions flagged in review, validate @doc-page
Seven @description headers claimed more than the code does:
cleanup-space-final-image zerofree globs ${LOOP}p?, so p10+ is not covered
image-output-abl one recovery image from ABL_DTB_LIST[0], not per-DTB
marvell-tools binaries-marvell and cryptopp track branches, not pins
nvidia also skipped without a working headers package
odin2-preset-firstrun ships hardcoded 1234 root/user passwords
preset-firstrun static networking is on by default, not optional
uefi-edk2-rk3588 acpi=off is a default, not forced
Reword each to match, and call out the two credential hazards explicitly
rather than leaving them implied.
In the generator, restrict @doc-page to site-relative paths. The value goes
into a Markdown link target on the published docs site and Python-Markdown
does not sanitize URL schemes, so a "javascript:" target would survive into
the page; unusable values are now dropped with a warning on stderr.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* gen-extensions-list: close two holes in @doc-page validation
DOC_PAGE_RE accepted "//external.example/x". "/" is in the character class, so
after the required leading slash a second one matched happily -- the protocol-
relative case the comment claimed to reject sailed straight through. Add a
negative lookahead.
The annotation parser also matched a single \S+ token, so "@doc-page /guide
extra" and a bare "@doc-page" failed to match at all and were dropped in
silence, with no warning. Capture the whole value instead and let validation
reject it, so malformed annotations are reported rather than ignored.
Output over the current extensions/ tree is byte-identical.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
---------
Signed-off-by: Igor Pecovnik <igor@armbian.com>
post_build_image__900_convert_to_abl_img() ran `losetup -f -P --show` and then
immediately `blkid ... ${loop}p1`. losetup -P scans partitions asynchronously,
so blkid races the p1 device-node creation; when the node isn't ready it exits
2 and the image build dies with "Error 2 occurred in SUBSHELL at
image-output-abl.sh:28". It passes on the docker-run retry once the node is
there, which is why sm8250 (xiaomi-sheng) ABL images fail intermittently.
Call the framework's check_loop_device on ${loop}p1 after losetup (5 retries,
plus CONTAINER_COMPAT mknod), so the node is guaranteed present before blkid
and mount. Same pattern partitioning.sh already uses.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
v4l2loopback (0.15.3) now builds against the newer kernels: it compiles
cleanly on 7.1.9-edge (module built and installed in-chroot), so there is no
need to skip it for 6.12..7.1.x anymore. Raise the "kernel too recent" guard
from >= 6.12 to >= 7.2 so those kernels get the module again; 7.2+ stays
skipped until verified.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Bring the MT7623n Banana Pi R2 back onto the current Armbian toolchain and
mainline kernels, dormant since the 2024 CSC bring-up.
u-boot / boot:
- bump boot sources to v2026.07 (mainline) and rebase the board's
enable-boot-from-ext4 patch onto it (defconfig tail + mt7623.h env).
- eMMC boot is a known limitation: modern mainline u-boot boots from SD but
hangs in early board_init_f on eMMC. v2024.07 and v2026.07 fail identically
while only the old vendor u-boot ever booted eMMC, so it's a toolchain/
build-env difference, not a u-boot regression. SD is the supported path.
kernel:
- current -> 6.18 (was 6.6); add a new edge -> 7.1 target.
- enable CONFIG_PINCTRL_MT2701: the mt7623 pinctrl DT node binds this driver;
without it the board hangs after "clk: Disabling unused clocks".
networking:
- drop the pre-baked bridge/br0 preconfig; let users configure the DSA switch.
- match bare 'wan'/'lan' DSA port names (not just wanX/lanX) in the default
networkd netplan so the switch ports get DHCP out of the box. Verified on
hardware: wan + lan0 both lease, routable, gateway/internet/DNS ok.
board:
- add current+edge targets and adopt igorpecovnik as maintainer.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
The lockup/hung-task detectors, SCHED_STACK_END_CHECK and KALLSYMS_ALL all
depend on DEBUG_KERNEL. Most family configs get it selected via EXPERT=y,
but the ones without EXPERT (e.g. mvebu-legacy) had every tier option
silently dropped by olddefconfig. DEBUG_KERNEL itself is only a menu gate.
kexec-tools loads the crash kernel using the VMCOREINFO note in
/proc/kcore (PHYS_OFFSET, VA_BITS) and the _text symbol from
/proc/kallsyms (page_offset). Armbian arm64 configs have neither:
without PROC_KCORE kexec falls back to /proc/iomem, and without
KALLSYMS_ALL kallsyms only covers [_stext,_etext] so _text is missing and
kexec -p logs "Can't get the symbol of _text" and builds the vmcore ELF
header with page_offset=0. crash and drgn on a live kernel need
/proc/kcore and full symbol coverage as well.
Both belong to the tier that already exists for post-mortem data
(pstore), so enable them there. Cost is a larger kallsyms table.
The extension deploys and enables a systemd service that runs `hciattach` to
bring up Bluetooth. On mainline branches (edge, current, bleedingedge) the
kernel binds the BT UART via serdev, so hci0 comes up with no userspace attach
-- the service is redundant there and fails on every boot (reported in #10395,
seen on the Orange Pi 5B).
Guard the deploy and enable functions so the service is only created/enabled on
BSP branches (vendor*/legacy*, which also covers vendor-rt). Keeping the guard in
the extension means no board file needs changing and it fixes every board that
uses the extension at once. The bluetooth packages (bluez/rfkill) are left
unconditional -- still wanted on mainline for the serdev-bound radio.
Branch match (vendor*/legacy*) per maintainer guidance in #10395.
Signed-off-by: defcom5-rockchip <286489597+defcom5-rockchip@users.noreply.github.com>
post_family_config also runs under `config-dump-json` (CONFIG_DEFS_ONLY=yes),
which the build-engine inventory runs in parallel for every board x branch.
This extension is the only aic8800 one that fetches a vendor driver from git
(the others install prebuilt DKMS debs), and it did so unconditionally in
post_family_config - so the inventory triggered a real fetch that has no
kernel tree to feed and raced on the global git config:
git --no-pager config --global --add safe.directory \
/armbian/cache/sources/aic8800-milkv-duos/<ref> -> exit 128
That failed config-dump-json for both milkv-duos boards and took down the
whole "Generate build engine inventory" job.
Guard the fetch with CONFIG_DEFS_ONLY (the framework's own idiom, already used
by main-config.sh / cli-docker.sh, and mirrored by this extension's kernel
hook via `[[ ! -f .config ]]`). AIC8800_SRC_DIR is still declared for the real
build, where post_family_config runs without CONFIG_DEFS_ONLY and the fetch
happens before custom_kernel_config copies from it.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* Add Milk-V DuoS, an aarch64+riscv64 board
* sophgo-sg200x: give our own patches real authorship headers
The 34 patches written for this port carried the placeholder header the
autopatcher emits - "From: Armbian <info@armbian.com>" over a made-up Date -
which says nothing about who wrote them or when. Review asked for something
meaningful.
Each now names its real author and carries the date of the commit that last
changed that patch's content on the development branch, so the header matches
the history the patch actually has. Where a patch was revised after it was
first written - 0044 and 0052/0053 for the DT changes, 0046 for the regenerated
comment - the date is that of the revision, not the original.
The all-zero commit hash on the first line stays: these patches have no upstream
commit to point at, and that is what the rest of the tree uses to say so.
Header lines only; no patch payload was touched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* sophgo-sg200x: header the arm64 patches that had none
Ten patches went in as bare diffs - no From, no Date, no Subject, just a blank
line and the payload. They are the arm64 counterparts of 0040/0042/0044/0046/
0048, written in the same commits as their riscv twins and touching only files
this port creates, so they are ours to sign.
Each now carries the same header its twin does, dated to the commit that last
changed it - which for 0045 and 0047 is the commit that revised the pair, so the
two architectures stay in step. The body is one line pointing at the riscv twin
rather than a copy of its reasoning; the same change against the other DTS does
not need the argument made twice.
The two aic8800 patches had a real author but a placeholder Date of midnight UTC;
they now carry the date they were written.
Header lines only; no patch payload was touched. Every patch in this series now
has a From, a Date and a Subject.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* sophgo-sg200x: cut the comment wall in the family include
Review asked for the absolute minimum here, and it was fair: 515 of the file's
988 lines were comment, several blocks running twenty or thirty lines to argue
a case rather than state one.
What is left says what each line does, and nothing else. Where a value looks
arbitrary the comment names the constraint behind it - boot.cmd rather than
boot.scr, CHIP_ARCH through the environment, "riscv" rather than "riscv64" -
in a clause, not a paragraph. The reasoning that was dropped is not lost; it
belongs in the port documentation rather than in a config file.
135 comment lines remain, down from 515, and the file is 607 lines rather than
988. Comments only: stripping comments and blank lines from this revision and
from the original gives identical files. shfmt and bash -n are clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* board: cut the Milk-V Duo S configs to the house format
The first line of a board config is a one-line hardware description and nothing
else. These carried a twelve-line preamble explaining the two-core split, the
slide switch and how to read the boot log, plus a link to the vendor page.
Both are now a single line in the form the rest of config/boards uses, with the
core naming the only difference between them. The explanation of why one board
ships as two configs is a thing to write down once, not in both files.
* sophgo-sg200x: follow the tree's release candidate pin
The bleedingedge branch pinned KERNELBRANCH to tag:v7.2-rc5 locally. That is
the tree's decision, not a family's: config/sources/common.conf only calls the
mainline_kernel_decide_version hooks when KERNELBRANCH is still empty, so the
local pin suppressed the whole chain in mainline-kernel.conf.sh - including the
hook that points KERNELSOURCE at Linus's tree when the stable mirrors have not
caught up with the tag yet.
Dropping it lets this family track the global pin, which is bumped weekly,
instead of sitting on whichever candidate happened to be current the day it was
written.
* trim family config comments
* remove nonexistent package removal from board configs
* move kernel_comp_addr_r to 0x88000000
* implement a better fip.bin size guard. Unlikely to ever be needed
* address Rabbit's concern
* address Rabbit's concerns about USB gadget
* fix btrfs potential failure
* address the easy nitpick comments
* reorder board family lines
* Changes to the Bluetooth service addressing Rabbit's concerns
* move the Duo S Bluetooth extension to a proper directory
* address more of Rabbit's concerns about size
* extensions: add docker-ce and applications-{ha,kali,omv}
Promote four previously user-local extensions into the tracked extensions/
tree so they ship with the build system:
- docker-ce - install Docker CE from the upstream repo
- applications-ha - Home Assistant Supervised (enables docker-ce)
- applications-kali - Kali repository + tools
- applications-omv - OpenMediaVault via armbian-config module_omv
Fix a latent collision in the kali extension: its config hook was named
extension_prepare_config__docker (copy-paste from docker-ce), which would
clash once both live in the shared extensions/ dir. Renamed to
extension_prepare_config__kali. applications-ha still enables "docker-ce" by
its unchanged name.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* applications-kali: also source kali.sh from root's .zshrc
Root got the /etc/armbian/kali.sh helper sourced from .bashrc but not .zshrc,
while /etc/skel got both. Add the matching /root/.zshrc entry so a root zsh
session shows the Kali tools hint too.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* applications-kali: default HOST instead of overwriting user value
HOST was set unconditionally, clobbering any hostname supplied by user
configuration before the hook runs. Use HOST="${HOST:-armbian-security}" so
it only applies when unset; alert and image suffix are unchanged.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* applications-kali: drop commented-out VENDOR line
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* applications-ha: edit boot files under ${MOUNT} in pre_umount_final_image
At the pre_umount_final_image hook rootfs-to-image.sh has already rsynced
${SDCARD}/boot into ${MOUNT}, so the armbianEnv.txt / extlinux.conf branches
must edit ${MOUNT}/boot to actually land in the image -- editing ${SDCARD}/boot
there is a no-op (stale staging copy). The RPi cmdline.txt branch already used
${MOUNT}; switch the u-boot branches (and the error path) to match.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* applications-ha: set apparmor extraargs for all non-RPi targets
HA_UBOOT_EXTRAARGS was only set for the rk3588 vendor kernel, so every other
u-boot board expanded it empty and never got 'apparmor=1 security=apparmor' on
the cmdline (AppArmor is required for HA Supervised). Initialize it for all
non-Raspberry Pi targets (BOARDFAMILY!=bcm2711); RPi is handled directly via
cmdline.txt in the pre_umount hook, and the rk3588 vendor case keeps the same
value. The armbianEnv.txt / extlinux.conf consumers now expand the real value.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
---------
Signed-off-by: Igor Pecovnik <igor@armbian.com>
The live UEFI ISO builder located the image kernel by globbing only
/boot/vmlinuz-*. That misses arm64 images whose kernel is installed as
vmlinux-* — e.g. BOARD=uefi-arm64 BRANCH=cloud, which ships
/boot/vmlinux-6.18.42-cloud-arm64. GRUB boots it fine (grub-mkconfig's
10_linux already picks up vmlinux-*), but the extension aborted with
"image-output-iso: no kernel found under .../boot" (error 43).
Glob both vmlinuz-* and vmlinux-*; sort -V keeps preferring vmlinuz-*
when both are present, so nothing changes for the common case.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
ISO is an output format alongside qcow2/vhdx/ovf/utm/etc., so move it into the
image-output-* family for discoverability (per review). Rename the file, hooks
and user variables (SKIP_ISO, ISO_VOLID, ISO_COMP, ISO_TIMEOUT, ISO_KEEP_IMG);
behaviour is unchanged.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Fixes from @iav's review:
- grub-mkstandalone runs the target binary in the chroot, but update_initramfs
already undeployed the static qemu by pre_umount_final_image, so a cross build
(arm64) died with "Exec format error". Deploy/undeploy qemu around the call.
- The .img drop ran before the CARD_DEVICE write (rootfs-to-image.sh), so
CARD_DEVICE=/dev/sdX silently wrote nothing. Keep the .img when CARD_DEVICE is
set. Also drop the ${version}.img.txt removal — it is created after this hook.
- Gate on BOARDFAMILY, not BOARD, so qemu-uefi-x86 (BOARDFAMILY=uefi-x86, BOARD
starts with qemu-) — the board you'd build for KVM/QEMU — is not disabled.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Add the uefi-iso extension: it converts a UEFI image into a bootable live .iso
that boots from a BMC/IPMI virtual CD-ROM (cloud, IPMI, KVM). Booting from a
virtual CD means everything must live inside the ISO9660, like Ubuntu Server's
ISO: kernel + initrd + a squashfs of the rootfs, live-boot in the initrd, and a
self-contained GRUB (grub-mkstandalone, all modules embedded). Boot the live
system, then install to disk with the new armbian-config installer.
Details:
- inject live-boot so the initrd mounts the squashfs with a RAM overlay (inert
on a normal disk boot, so the .img still boots normally);
- self-contained GRUB over a serial+VGA console with the Armbian wallpaper
(font/image embedded, so no external-module failures); configurable timeout;
- keep the pseudo-fs mount-point dirs in the squashfs, neutralize /etc/fstab
and mask GRUB boot-record + Trixie systemd generators in the squashfs only
(all restored afterwards) for a clean live boot;
- arch-aware: amd64 (x86_64-efi/BOOTX64.EFI), arm64 (arm64-efi/BOOTAA64.EFI),
riscv64 (experimental); warns and disables itself on non-UEFI boards;
- drops the .img by default (the ISO carries the rootfs); host deps xorriso,
squashfs-tools, mtools, dosfstools.
Requires the grub extension. ISO is UEFI-only and needs Secure Boot disabled
(GRUB/kernel unsigned).
Signed-off-by: Igor Pecovnik <igor@armbian.com>
image-output-arduino.sh fetched the Qualcomm QDL flash binaries (qcombin)
from a post_family_config hook. That config-phase hook fires for *every*
config-prepare, including `download-artifact` and `artifact-config-dump-json`,
not just image builds. Those run with a throwaway/absent $HOME (e.g. the
parallel debs-to-repo-download workers use HOME=/armbian/.tmp/work-<uuid>), so
`git config --global --add safe.directory` inside fetch_from_repo fails with
exit 128:
Error 128 ... git config --global --add safe.directory .../qcombin
git_ensure_safe_directory() -> git.sh
fetch_from_repo() -> git.sh
post_family_config__fetch_qcombin() -> extensions/image-output-arduino.sh:7
The old hook only guarded CONFIG_DEFS_ONLY (config-dump); download-artifact was
left unguarded. arduino-uno-q is the only board doing a git fetch at
config-prepare time, so it is the only one that hits this.
qcombin is consumed solely by post_build_image__900_convert_to_arduino_img
(assembling the QDL flash archive), so move the fetch there, at the point of
use. It then only runs during real image builds - which have a proper $HOME and
network - and the CONFIG_DEFS_ONLY guard is no longer needed.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Complete matching the forum's proven-working A3720 firmware: pin mv-ddr-marvell
to 7bcb9dc (carries a gcc build fix) and mox-boot-builder (CZ.NIC WTMI secure
firmware) to 14f39dd, instead of tracking branch:master. Reproducible builds and
the exact blob set the working espressobin-bootloader ships. mv-ddr is shared
with MacchiatoBin (best-effort); mox-boot is EspressoBin-only.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Upstream MarvellEmbeddedProcessors/A3700-utils-marvell (branch:master) is
abandoned and no longer builds/links on a current gcc/ld: sys_init fails first
on the C23 'bool' keyword ('typedef int bool') and then on a "dangerous
relocation: unsupported relocation" in main() (main.c:349).
Point marvell-tools at bschnei's fork, pinned to f423ac6 - the exact commit the
working espressobin-bootloader (quiseleve fork) uses - which fixes both (its
message is literally "fix the jump instruction in main()"). This supersedes the
earlier -std=gnu11 sed workaround (dropped), since the fork fixes 'bool' at the
source. Only EspressoBin uses marvell-tools (WTP); MacchiatoBin is unaffected.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
SWIG 4.3.0 added a third parameter (is_void) to SWIG_Python_AppendOutput(),
so old U-Boot pylibfdt interfaces that call it with two arguments fail to
compile on Debian trixie (SWIG >= 4.3):
scripts/dtc/pylibfdt/libfdt_wrap.c: error: too few arguments to
function 'SWIG_Python_AppendOutput'
make[2]: *** [scripts/dtc/pylibfdt/Makefile:33: rebuild] Error 1
This breaks every board still on a pre-v2026.07 U-Boot on trixie, e.g.
the Radxa fork boards (branch:rk35xx-2024.01, station-m2/rock-3/etc.),
mainline v2024.04, and older.
Add an auto-enabled extension that, before the U-Boot build, rewrites the
2-arg SWIG_Python_AppendOutput(resultobj, ...) calls in the pylibfdt SWIG
interface to the version-agnostic SWIG_AppendOutput() macro - the same
change dtc/U-Boot made upstream in v2026.07. Patches both pylibfdt
locations (scripts/dtc and lib/libfdt) and any pre-generated wrapper;
no-op once the source already uses SWIG_AppendOutput.
Mirrors the sibling uboot-binman-fix-pkg-resources extension. Can be
removed once all BOOTBRANCH versions are >= v2026.07.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* docker: skip unavailable cross-compilers on riscv64 hosts
When generating Dockerfiles on native riscv64 hosts, skip cross-compiler
packages (gcc-x86-64-linux-gnu, gcc-aarch64-linux-gnu, gcc-arm-linux-*)
that don't exist in riscv64 package repositories.
This fixes generate-dockerfile failures on riscv64 hosts that tried to
install non-existent cross-compilation toolchains.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* docker: detect host architecture for cross-compiler selection
When generating Dockerfiles, detect the actual host architecture using
dpkg --print-architecture and pass it to early_prepare_host_dependencies.
This ensures that cross-compiler packages that don't exist on certain
architectures (e.g., riscv64) are properly skipped during Dockerfile
generation.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* docker/riscv64: fix cross-compiler availability checks
Fix cross-compiler package selection for riscv64 hosts in both Docker
generation and extensions:
- docker.sh: Detect host architecture and pass it to dependency
resolution functions
- extensions: Check host_arch and skip cross-compilers unavailable on
riscv64 (g++-aarch64-linux-gnu, gcc-arm-linux-gnueabi)
This fixes generate-dockerfile failures on native riscv64 hosts where
cross-compilation toolchains for other architectures don't exist in
the package repositories.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* docker/riscv64: skip mvebu64 32-bit compiler on riscv64 hosts
Same pattern as sunxi-tools.sh and arm64-compat-vdso.sh — the mvebu64
family unconditionally adds gcc-arm-linux-gnueabi via the
add_host_dependencies__mvebu64_add_32_bit_c_compiler hook, which fails
on riscv64 hosts (the 32-bit ARM cross-compiler is not available in
Debian/Ubuntu RISC-V repositories).
Guard the dependency addition with a host_arch check, emit a warn alert
when skipping. mvebu64 boards (helios64, macchiatobin etc.) are still
built normally on amd64/arm64 hosts.
Assisted-by: Claude:claude-opus-4.7
* extensions/c++: fail fast if arm64 cross-compiler declared but missing
Mirror arm64-compat-vdso.sh: add a host_dependencies_ready hook that, on
hosts where the arm64 c++ cross-compiler is declared (i.e. not riscv64),
asserts the g++-aarch64-linux-gnu binary (aarch64-linux-gnu-g++) is
actually present after the dependency phase, and errors early otherwise.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* kernel: fail fast with clear message when (cross-)compiler is missing
Per @iav's riscv64 testing on #9589: cross-building an arm64 target on a
riscv64 host silently skips the unavailable gcc-aarch64-linux-gnu at the
host-dependency phase, then dies deep in kernel_determine_toolchain with a
cryptic "env: 'aarch64-linux-gnu-gcc': No such file or directory" (Error 127).
Add a command -v pre-check before the -dumpversion probe so the missing
toolchain surfaces as a readable, actionable error naming the compiler, the
target ARCH and the host arch. It checks the actually-resolved compiler, so
clang builds validate clang (not the gcc) and native builds are unaffected.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
---------
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Co-authored-by: Igor Velkov <325961+iav@users.noreply.github.com>
Cumulative kernel debug-information tiers for headless boards that need
on-device debugging through the serial console:
KERNEL_DEBUG_TIER=0 no-op (extension loaded but kernel-side disabled)
KERNEL_DEBUG_TIER=1 printk timestamps + lockup/hung-task detection
(default — cheap, no board prerequisites)
KERNEL_DEBUG_TIER=2 + pstore/ramoops (needs DT or bootarg reservation)
KERNEL_DEBUG_TIER=3 + KGDB/KDB over serial (needs kgdboc= bootarg)
By itself the extension does nothing visible at runtime; it bakes enough
information into the kernel image that operator-console facilities like
SysRq tracebacks and KGDB sessions are actually useful instead of streams
of hex addresses. Pair with `sysrq-serial-trigger` (separate extension)
to also enable the operator-control surface itself.
extension_prepare_config validates the tier value, hard-fails with a
helpful message on KERNEL_BTF=no + KERNEL_DEBUG_TIER>=1 (BTF is required
for hung-task tracebacks and KGDB symbol resolution; either set
KERNEL_BTF=yes or KERNEL_DEBUG_TIER=0 to opt out of the kernel side),
and forces KERNEL_BTF=yes for tier>=1 when not explicitly set.
Signed-off-by: Igor Velkov <325961+iav@users.noreply.github.com>
Enable Magic SysRq through the serial console for headless ARM boards
(Helios64, etc.). Mainline ships MAGIC_SYSRQ_SERIAL_SEQUENCE empty,
disabling BREAK-triggered SysRq; this extension fills it with a
deliberate sequence after BREAK so the operator on the serial console
can sync/remount-RO/reboot from any kernel state where interrupts flow.
Also overrides distro kernel.sysrq=176 to 1 (full command set) and
extends u-boot autoboot delay so the prompt is actually catchable.
Pair with the companion `kernel-debug-tiers` extension to make the
tracebacks reachable via SysRq actually informative (BTF, hung-task,
KGDB symbol resolution).
Signed-off-by: Igor Velkov <325961+iav@users.noreply.github.com>
* extensions/nvidia: auto-detect highest nvidia-dkms available per distro
Drops the hardcoded NVIDIA_DRIVER_VERSION=580 default (with its
honest @TODO comment about per-release / Debian-vs-Ubuntu drift).
The post_install hook now resolves the package set against the
chroot's actual apt index at install time:
1. If NVIDIA_DRIVER_VERSION is set explicitly (env or config), pin
to it — operator override always wins.
2. Otherwise, ask apt for the highest `nvidia-dkms-<N>` available
in the target distribution/release. Common Ubuntu shape across
noble / resolute / etc. — versions vary (535, 550, 560, 580, ...).
3. Fall through to the unversioned Debian metapackage `nvidia-dkms`
if no numeric variants exist (bookworm, trixie).
4. None of the above — skip with a warning instead of crashing the
build on an opaque 'package not found'.
Closes the long-standing @TODO and removes the silent build failures
on releases that don't ship nvidia-dkms-580 specifically.
* nvidia: runtime auto-disable on hosts without NVIDIA hardware
The previous solution lived in
packages/bsp/common/usr/lib/armbian/armbian-firstrun as a single
line:
[[ -n "$(dmesg | grep "No NVIDIA GPU found")" ]] && \
sudo apt-get -y -qq purge nvidia-dkms-510 nvidia-driver-510 \
nvidia-settings nvidia-common \
>> /dev/null
Two reasons it was unreliable:
1. dmesg-grep for "No NVIDIA GPU found" only sees the line if the
driver actually bound far enough to print it. On many boots the
line never appears (driver couldn't load at all) or has already
rotated out of the kernel ring buffer by the time firstrun runs.
2. Hardcoded nvidia-dkms-510 / nvidia-driver-510 — wrong on every
distro/release that ships a different driver branch, and
especially wrong now that the install path auto-picks the
highest available version.
Replace it with a build-time-installed detector + systemd one-shot
under extensions/nvidia.sh:
- /usr/lib/armbian/armbian-nvidia-autodetect
probes the PCI bus directly (lspci -nn, vendor 10de). Works
regardless of whether any driver module loaded.
If no NVIDIA hardware found:
a. drops /etc/modprobe.d/armbian-nvidia-disabled.conf
(blacklist nvidia / nvidia_drm / nvidia_modeset / nvidia_uvm)
so the driver doesn't try to load on the next boot.
b. dpkg-query's the actually-installed nvidia-dkms-* /
nvidia-driver-* / nvidia-settings / nvidia-common packages
(no hardcoded version!) and apt-purges them. DKMS stops
rebuilding the module on every kernel update.
- /etc/systemd/system/armbian-nvidia-autodetect.service
Type=oneshot, runs Before=display-manager.service /
graphical.target. WantedBy=multi-user.target — fires every
boot. Cheap (early exit when NVIDIA present), idempotent (no-op
on a system where the packages are already purged), and handles
hot-pluggable scenarios (eGPU added later → reverse direction
handled by removing the modprobe.d file manually).
Removes the dmesg-grep line from armbian-firstrun and leaves a
breadcrumb pointing at the new location.
* extensions/nvidia: pull pciutils so lspci is guaranteed at runtime
The runtime armbian-nvidia-autodetect helper in this extension calls
lspci to probe the PCI bus for an NVIDIA card. lspci lives in
pciutils, which isn't in the Debian/Ubuntu base install and isn't
guaranteed to be pulled by every desktop metapackage transitively.
The helper defensively no-ops when lspci is missing — which would
leave images without auto-disable on no-GPU hosts (the exact thing
this PR is meant to fix).
Append pciutils to PACKAGE_LIST_ADDITIONAL in
extension_finish_config so it lands in the rootfs alongside the
other build-time prerequisites.
* extensions/nvidia: also purge unversioned nvidia-dkms / nvidia-driver
The runtime autodetect's dpkg-query argument list used only the globs
'nvidia-dkms-*' and 'nvidia-driver-*' for the numbered Ubuntu shape.
The trailing dash makes those globs miss the bare 'nvidia-dkms' /
'nvidia-driver' metapackages — which the install branch deliberately
falls through to on Debian (case 3 of the resolver added in this PR).
Add the exact names alongside the globs so the purge covers both
shapes. Without this fix a Debian image installed with the extension
on a host that turns out to have no NVIDIA GPU would correctly drop
the modprobe blacklist but leave the package set behind, defeating
the DKMS-rebuild-avoidance half of the autodisable design.
* extensions/nvidia: || true on the apt-cache pipeline so case-3 is reachable
chroot_sdcard wraps its argument with `bash -e -o pipefail -c …`, so
the pipeline `apt-cache pkgnames … | grep … | sed … | sort | head -1`
returns 1 when grep finds no numbered nvidia-dkms-<N> entries — the
exact Debian shape that the install resolver's case-3 fall-through
was designed to handle.
Under the build framework's outer `set -e` (compile.sh) the
substitution `latest=$(chroot_sdcard …)` then aborts the build at
that assignment, which means case-3 (unversioned `nvidia-dkms`
metapackage) was unreachable in practice.
Append `|| true` to the inner pipeline so the substitution always
succeeds with `$latest` empty on no-match, and the `if/elif` chain
below can pick case-2 (number found), case-3 (Debian fallback) or
case-4 (skip with warn) on real data.
Reproduced and verified locally — without `|| true` the assignment
aborts; with it, latest='' and the fallback executes.
* extensions/nvidia: drop PACKAGE_LIST_ADDITIONAL+=pciutils (readonly + redundant)
Two reasons:
1. PACKAGE_LIST_ADDITIONAL is sealed `readonly` by the time
extension_finish_config__* hooks run, so the
`declare -g PACKAGE_LIST_ADDITIONAL+=" pciutils"` line aborted
the build with:
/armbian/extensions/nvidia.sh: line 20: declare:
PACKAGE_LIST_ADDITIONAL: readonly variable
2. It was redundant anyway. `pciutils` is already listed in
config/cli/common/main/packages.additional, which ships in
every non-minimal CLI image. This extension early-returns on
BUILD_MINIMAL=yes, so we never reach a context that wouldn't
have pciutils already present.
Replace the now-broken line with a comment pointing at the canonical
source so a future maintainer doesn't try to add it again.
* extensions/nvidia: move autodetect install to post_family_tweaks hook
post_install_kernel_debs runs BEFORE armbian-bsp-cli is installed in
the chroot (per its own docstring at the call site). Anything we
wrote into /usr/lib/armbian/ or /etc/systemd/system/ there was
getting clobbered by the BSP install or swept by later rootfs steps
— operator reported the autodetect script + service simply weren't
in the resulting rootfs even though the firstrun edit shipped
(because firstrun ships through the BSP package which is
dpkg-tracked).
Split the responsibilities:
- post_install_kernel_debs__build_nvidia_kernel_module
keeps doing the apt-get install of nvidia-dkms-* / nvidia-driver-*
(works fine before BSP — dependencies resolve, dkms builds).
- post_family_tweaks__build_nvidia_kernel_module_autodetect (NEW)
calls install_armbian_nvidia_autodetect_helper. post_family_tweaks
fires AFTER `install_artifact_deb_chroot "armbian-bsp-cli"` so
/usr/lib/armbian/ already exists with BSP-owned content and our
untracked drop sits beside it without being overwritten.
The autodetect remains extension-gated (only on images built with the
nvidia extension enabled), not BSP-common — per operator preference,
to avoid every SBC's bsp-cli carrying nvidia-related plumbing it has
no use for.
* extensions/nvidia: dump apt state when nvidia-dkms detection fails
The case-3 fallback ("No nvidia-dkms package in ... apt sources")
hits on noble even though nvidia-dkms-* lives in restricted/, where
the rootfs is supposed to include the restricted component. Without
seeing the chroot's apt state at the moment of failure, there's no
way to tell whether:
- restricted is missing from sources.list.d at all,
- it's listed but the indices were never fetched,
- or apt-cache pkgnames is filtering everything else for some
arch / component reason.
Before the existing "skipping nVidia install" warn, dump:
- `apt-cache pkgnames | grep -c ^nvidia` from inside the chroot
- listing of /etc/apt/sources.list.d/
- sources files that mention "restricted"
- apt/lists entries containing restricted/multiverse (proves
whether indices were refreshed)
All purely diagnostic; no behaviour change on the happy path.
* extensions/nvidia: || true on every debug-dump chroot pipeline
chroot_sdcard wraps the inner command with `bash -e -o pipefail -c`.
The debug-dump pipelines added in the previous commit had grep/ls
calls that legitimately return rc=1 when nothing matches; pipefail
propagates that as the pipeline's exit, the outer set -e aborts the
build mid-function, and bash emits a confusing
pop_var_context: head of shell_variables not a function context
instead of the actual diagnostic.
Tail every chroot_sdcard "..." with `|| true` so empty matches stay
rc=0 and the diagnostic lines actually print.
Also simplify the "restricted" probe from `grep -lE '(^|\s)restricted(\s|$)'`
to `grep -lF restricted` - the regex form was both fragile under
nested double-quote escaping and overkill for what we need (presence
of the literal word in a sources file).
* extensions/nvidia: refresh chroot apt indices before pkgnames lookup
apt-cache pkgnames reads from /var/cache/apt/pkgcache.bin, which is
built from /var/lib/apt/lists/. If the rootfs was cached before
`restricted` was added to ubuntu.sources, or if the framework hasn't
run `apt-get update` since the final sources.list was finalized, the
indices for the restricted component are simply absent - and pkgnames
returns nothing for nvidia-dkms-*, even though sources.list lists
the component.
Verified locally that on a stale chroot the pkgnames pipeline returns
empty; after `apt-get update`, it returns the full nvidia-dkms-N set.
`apt-get update -qq || true`: quiet on success, doesn't abort the
build if the proxy hiccups or one of the suite indices fails (apt
returns non-zero on partial failures).
* extensions/nvidia: clear modprobe blacklist when GPU detected
If a previous boot ran on the same rootfs without NVIDIA hardware,
the autodetect helper wrote /etc/modprobe.d/armbian-nvidia-disabled.conf
to keep the kernel modules from auto-loading. When the same rootfs
later boots with NVIDIA hardware (card added, SSD swapped into a
GPU-equipped host), the early `exit 0` left that file in place, so
the modules still wouldn't load even though they're present and the
GPU is wired up. The detector was effectively one-way.
When lspci finds [10de:], clear the blacklist file if it exists
(rm -f is idempotent for the common case where it never existed).
Log via systemd-cat so the action shows up in `journalctl -u
armbian-nvidia-autodetect` for triage.
Deliberately /not/ auto-reinstalling NVIDIA packages on the recovery
path - proprietary driver auto-install without operator consent, and
without guaranteed network/apt-sources, is out of scope for a
boot-time detector. If packages were previously purged the operator
runs apt install manually; the freshly-cleared blacklist file makes
that work the next boot.
* extensions/nvidia: pre-ship modprobe blacklist; remove + modprobe at boot when GPU is found
Previous flow on a host without an NVIDIA GPU:
- First boot: kernel modules auto-load from initrd udev → probe
fails → noisy dmesg ("nvidia: probe failed", DKMS rebuild
artefacts in journal, etc.)
- armbian-nvidia-autodetect runs in userspace → writes blacklist
+ purges packages
- Second boot: clean
Inverting the default so the first boot is also clean:
1. Build-time write of /etc/modprobe.d/armbian-nvidia-disabled.conf
BEFORE the apt install. nvidia-dkms postinst triggers
update-initramfs which now bakes the blacklist into initramfs,
so initrd udev doesn't try to load nvidia* at all.
2. Boot-time autodetect:
- lspci finds [10de:] → rm -f blacklist file + modprobe
nvidia_drm modeset=1 (pulls nvidia + nvidia_modeset via
deps; Wayland-friendly KMS). Display-manager (we're
Before= it) sees the driver loaded.
- No [10de:] → keep blacklist + purge packages (unchanged).
Self-healing for hosts that gain a GPU later: rootfs blacklist file
deleted on first NVIDIA-detected boot; next kernel upgrade
regenerates initramfs from the (now blacklist-free) rootfs, so
subsequent boots are clean directly from initrd. Until that kernel
upgrade, the runtime modprobe covers the gap each boot.
|| true on modprobe handles the edge case where packages were
previously purged on a no-GPU run, then the operator swapped in a
GPU but hasn't re-apt-installed. Operator runs apt install manually
in that case; the cleared blacklist makes it work on next boot.
- builds rkusbboot from RadxaNaoki/rkusbboot
- looks for `u-boot-rockchip-usb471.bin` and `u-boot-rockchip-usb472.bin` in u-boot directory
- thus, requires recent mainline u-boot
- runs on `run_after_build` -- so `BOARD=x BRANCH=y uboot EXT=rkusbboot` works
- automatically enables `CONFIG_ROCKCHIP_MASKROM_IMAGE` in u-boot config, or bombs if it can't
- doesn't really "flash" anything -- everything in in RAM
- serial/u-boot console can then be used to flash image via eg UMS or network
The guard skipped the aic8800 dkms from 7.1 onward. It builds fine on 7.1,
so raise the cutoff to 7.2. Kernel 7.2 is untested, keep it out for now.
Signed-off-by: SuperKali <hello@superkali.me>
post_build_image__900_jethub_burn looked for the u-boot .deb in
${SRC}/output/debs, but BETA builds (BETA=yes, used by the nightly) place
reversioned debs in output/debs-beta (DEB_STORAGE). The Amlogic burn
conversion therefore failed with "u-boot deb not found for <board>".
Use ${DEB_STORAGE} with a fallback to the previous path.
With CONFIG_RUST_INLINE_HELPERS=y kbuild links every Rust module object
with rust/helpers/helpers_module.bc, so headers built with that option
need the helper bitcode too. The option is EXPERT-gated and requires a
clang-compatible LLVM, so it is absent from default Armbian builds; the
glob simply finds no files there.
Addresses Codex review on PR #171.
Assisted-by: Claude:claude-fable-5
With CONFIG_RUST=y the headers package advertises Rust support via
auto.conf, but the Armbian headers file list in kernel-debs.sh knows
nothing about rust/: out-of-tree Rust module builds against the
installed headers fail with E0463 "can't find crate for core".
Add a pre_package_kernel_headers hook that copies the prebuilt crate
artifacts into the package. The file set was determined empirically by
stracing an out-of-tree Rust module build against a fully built tree:
rustc reads exactly rust/*.rmeta (crate metadata) plus rust/*.so
(proc-macro dylibs). Host-side rlibs (proc_macro2, quote, syn) are only
needed to rebuild the proc macros and are not read, so they are not
shipped. The crate set varies per kernel version, hence the glob.
A CONFIG_RUST=y tree with no artifacts fails the build: packaging
headers that advertise Rust without them is broken-by-construction.
Proc-macro .so files execute on the build host; after cross-compilation
they will not load on the target, so a warning is emitted. rmeta files
add ~25 MiB xz-compressed to the package.
Verified on 7.2/rockchip64/arm64 (simulated headers package: module
builds, fails with E0463 when artifacts removed, plain C module
unaffected) and on a real 6.18/mvebu/armhf kernel package build
(artifacts present in the .deb, cross-build warning fires).
Assisted-by: Claude:claude-fable-5
- before this, ask extension would stage a userpatch during post_family_config,
if it was not in CONFIG_DEFS_ONLY mode
- this would cause hashing to differ between matrix-prepare and actual build
- matrix patches hash wouldn't have the patch
- actual-build patches hash would
- this caused infinite rebuilding of the kernel in CI
- previous commit introduced a new hook made for this purpose
- implement it here -- unconditionally, as it only ever run in actual build
- also implement a cleanup (in post_family_config) so any leftovers are
removed and won't affect further
- remove claims that userpatches are gitignored (they aren't) and that they
don't survive across builds (they do, unless handled as explained above)
SuperKali
Tomaz Zaman
Igor Pecovnik
Igor Velkov
defcom5-rockchip
Łukasz Sobala
EvilOlaf
Darsey Litzenberger
Yi Ding
Ricardo Pardini
Viacheslav Bocharov
Andrei Aldea