The xmonad package ships two sessions: xmonad.desktop runs the window
manager bare, and gnome-flashback-xmonad.desktop runs it inside a GNOME
Flashback session, which is the one that gets a session dbus, a polkit
agent and session management. Autologin hardcoded the bare one, so the
flashback session was never selected even where it was usable.
Pick it when it can actually start, and keep the old behaviour otherwise.
Its TryExec is gnome-flashback, from gnome-session-flashback, which is
not installed on every image, so both the .desktop and the binary are
checked. Images without it are unaffected.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
- add libssc v0.4.2 source tarball (git archive of upstream tag, commit 300a2a0)
alongside the prebuilt libssc_0.4.2-1_arm64.deb
- add Debian-style copyright file and provenance README
- libssc is GPL-3.0-or-later (upstream codeberg.org/DylanVanAssche/libssc);
shipping the binary together with its corresponding source satisfies the GPL
- add libssc_0.4.2-1_arm64.deb and xiaomi-sheng-thp_0.3.9_arm64.deb under packages/bsp/xiaomi-sheng/
- install both via install_deb_chroot in post_family_tweaks__xiaomi-sheng_enable_services(),
libssc first then the NT36532E touch host processor daemon; apt resolves deps from repo
armbian-resize-filesystem runs with DefaultDependencies=no and
Before=basic.target, so the entire boot waits for it. The script calls
partprobe, which waits for the udev queue to drain. A udev worker that
never finishes its event stalls that queue for the full 180s worker
timeout, and basic.target - together with dbus.service - is delayed by
the same amount.
That delay breaks DNS on the first boot. systemd-resolved is ordered
before sysinit.target, so it starts while dbus is still not up and
never acquires org.freedesktop.resolve1. NetworkManager hands DNS
servers to resolved over D-Bus only, so the DHCP-provided servers never
reach it and name resolution stays dead for the whole session, which is
exactly when armbian-firstrun and apt need it.
Resizing need not run that early: resize2fs operates online on the
mounted rootfs, and the only unit ordered against it is lowmem-mkswap.
Move both units to multi-user.target so a stalled udev queue can no
longer hold up the boot. armbian-firstlogin already waits for queued
jobs through systemctl is-system-running --wait, and the script
disables itself with systemctl disable, which follows the new [Install]
section on its own.
Claude-Session: https://claude.ai/code/session_01SWvjHEYMimjZVj1qy3aR2k
Every autologin console starts the setup at once and flock -n hands it to
whichever ran first. On an image with both HDMI and a serial console that is
usually the one nobody is sitting at: the setup waits for input on an empty
screen, while the session the user is on prints "already running in another
session" and drops to a shell.
Hand it to the session that arrived last instead. The holder names itself in
the lock file and is asked to step aside with SIGTERM, which its trap already
turns into the same clean exit as a power loss: FIRSTLOGIN_SUCCESS stays 0, so
the marker survives and the setup simply runs again in the new session. The
newcomer retries rather than reading the lock file once, so a holder that has
taken the lock but not yet published its pid is displaced on the next pass. A
single console is unaffected, it takes the lock on the first try.
The upstream AYN UCM brings the wcd9395 headphone amp up in CLS_H_ULP
with the compander on, which distorts badly and collapses at high
volume, and its HiFi carries a second Headphones section bound to the
speaker PCM that wins over the real one. Vendor a cleaned-up UCM in
the bsp tree instead of curling the fork zip at build time: a single
Headphones section on PCM 1, a Class-AB HiFi bring-up with HD2
compensation and no compander (the same operating point radxa ships
for the wcd938x Q8B, radxa-pkg/alsa-ucm-conf#18), an entrypoint for
the UEFI card name and slightly higher analog volume.
Signed-off-by: SuperKali <hello@superkali.me>
A fresh image logs root in on tty1, on the serial console and over ssh at
once, and every session runs the setup. Each one killed the other root
shells to get the prompts to itself, so a session could be killed while
sitting at a password prompt and the setup was left unfinished. Take a
lock instead and let the other sessions step aside.
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.
Address review feedback on the shipped 50-default.conf so it is a faithful
drop-in for the linux-sysctl-defaults package it now Provides:
- kernel.sysrq: 16 -> 438 (0x01b6), the value linux-sysctl-defaults ships on
both Debian trixie and Ubuntu. 16 (sync-only) would have disabled REISUB,
process kill and stack traces over serial -- the main recovery path on
headless SBCs.
- fs.protected_regular: 1 -> 2, matching the distro default (on trixie, where
the real package is Conflicts-removed, 1 was weaker than the distro value).
- add vm.max_map_count = 1048576, which the distro file also ships.
- rp_filter: drop the net.ipv4.conf.all.rp_filter line. Effective rp_filter is
max(all, per-interface), so forcing .all overrode per-interface choices;
the distro package only sets .default.
- prefix ping_group_range and net.core.default_qdisc with "-" (failure
tolerant) so old vendor kernels lacking ping_group_range / sch_fq_codel do
not log a sysctl error on every boot. Correct the header comment that
conflated this prefix with the newer glob-exclude syntax.
Also switch the BSP postinst from `sysctl -p` to `sysctl --system` so the
drop-in under /usr/lib/sysctl.d is applied on package upgrade instead of only
on the next boot (`-p` reads only /etc/sysctl.conf).
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Rather than pulling the distro's linux-sysctl-defaults into every image
(armbian/build#9698), ship its content in the board-support package and have the
BSP Provide/Conflict/Replace it - per @tabrisnet's suggestion on that PR.
- Add /usr/lib/sysctl.d/50-default.conf to packages/bsp/common: armbian's copy
of systemd's 50-default.conf (the primary win is net.ipv4.ping_group_range so
ping works without setuid/CAP_NET_RAW; plus fs.protected_* and the usual net
hardening). Kept in pre-glob syntax (explicit .all/.default, no `-key` unset
lines) so it parses on every systemd version Armbian ships. kernel.sysrq stays
at systemd's conservative 16.
- armbian-bsp-cli-deb: Provides + Conflicts + Replaces linux-sysctl-defaults, so
the dependency is satisfied without the external package and the file is taken
over cleanly if it was ever installed.
Supersedes #9698.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
This ensures the swapfile is created with the No_COW attribute.
Otherwise, swapon fails with "Invalid argument" and the kernel logs a
warning:
BTRFS warning (device mmcblk1p1): swapfile must not be copy-on-write
Signed-off-by: Darsey Litzenberger <dlitz@dlitz.net>
OPPs marked turbo-mode stay hidden until the cpufreq boost flag is set, so
writing a turbo frequency to scaling_max_freq is clamped without an error.
Raise the flag from a new BOOST key before the governor and the limits are
applied. It defaults to false, so no board changes behaviour unless it opts in.
Signed-off-by: SuperKali <hello@superkali.me>
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>
Ensure /root/.not_logged_in_yet is cleaned up automatically when the
firstlogin script exits, including when the desktop environment takes
over the TTY and sends SIGHUP. Prevents firstlogin from rerunning when
the user later logs in as root (e.g. via sudo -i).
The sm8550 DSP sound card has no usable ACP profiles, so WirePlumber fell
back to the Dummy Output sink and there was no sound. Disable ACP in
WirePlumber so real ALSA sinks are created, and add a boot-time systemd
unit that loads the HiFi UCM verb and enables the speaker amplifiers.
Add the ALSA UCM2 profile for the Xiaomi Pad 6S Pro (HiFi verb, speaker,
headphones, mics) and the kernel postinst hook that repacks and flashes
the ABL boot image on kernel updates.
* 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
The installer was redesigned as an armbian-config module (module_partitioner,
backed by module_install_engine) so its logic is unit- and loopback-tested in
CI instead of hand-verified on hardware.
- armbian-install becomes a thin wrapper that execs
`armbian-config --api module_partitioner "$@"`, preserving the historical
/usr/bin/armbian-install entrypoint and CLI.
- Drop the nand-sata-install symlink and the a10/a13/a20 NAND bootloader
assets (legacy sunxi NAND is no longer supported). exclude.txt is kept.
- armbianmonitor now also collects /var/log/armbian-install.log.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: igorpecovnik <6281704+igorpecovnik@users.noreply.github.com>
* armbian-firstlogin: restart ssh.service instead of reload
During firstlogin ssh.service may not be active yet (it is enabled but
not started on a fresh image). `systemctl reload ssh.service` errors out
on an inactive unit, and the previous `|| exit 1` aborted the script
before it reached the final `rm -f /root/.not_logged_in_yet`. The marker
was therefore left behind, causing firstlogin to loop on every reboot.
Switch to `systemctl restart ssh.service`, which (re)starts the unit
regardless of prior state, and replace `exit 1` with a logger call so a
transient failure does not strand the setup loop.
Ref: https://github.com/armbian/build/pull/9954
Signed-off-by: Mkirin <haohao.wang@seeed.cc>
* armbian-firstlogin: restart ssh.service instead of reload
During firstlogin ssh.service may not be active yet (it is enabled but
not started on a fresh image). `systemctl reload ssh.service` errors out
on an inactive unit, the `|| exit 1` aborts the script before it reaches
the final `rm -f /root/.not_logged_in_yet`, and the marker is left
behind — causing firstlogin to loop on every reboot.
Use `systemctl restart ssh.service` instead, which (re)starts the unit
regardless of prior state. The existing `|| exit 1` is kept so that a
genuine restart failure (e.g. invalid sshd_config) preserves the marker
and lets firstlogin rerun for recovery on next login, instead of
silently clearing it and leaving the system without a working SSH setup.
Ref: https://github.com/armbian/build/pull/9954
Signed-off-by: Mkirin <haohao.wang@seeed.cc>
---------
Signed-off-by: Mkirin <haohao.wang@seeed.cc>
Board bsp package and default ALSA state:
- vita-jack-switch: mute internal speakers while headphones are plugged
- vita-pad2key + toggle: gamepad-to-keyboard remap for desktop navigation
- vita-screen: X11-only rotation + touch mapping (Wayland uses the DRM
panel-orientation property natively)
- vita-offcharge: Android-style off-charge screen (the RK806 powers on when
a charger is plugged, a hardware behavior; a plug-in boot shows a battery
screen that powers off on unplug and continues to boot on power press)
- SDDM configured for its Wayland greeter; udev rule reclassifying the
ABS-only stick device from accelerometer to joystick
- default asound.state with speakers and headphone jack enabled
Signed-off-by: crackerjacques <jack@supremeoverlordjabs.co>
The option-5/6 bootloader-update paths call write_uboot_platform and then
print "Done." unconditionally. write_uboot_platform runs dd without checking
its exit status, so a failed write — a dying eMMC returning -110 on cache
flush, a write-protected or wrong target — is indistinguishable from success
and the bootloader is left silently stale.
Wrap the write in write_bootloader_checked(): capture the writer's output,
flush the target with a checked sync (some family writers omit conv=fsync, so
a queued writeback/cache-flush failure would otherwise pass), log it, and on
any non-zero status show an auto-sized failure dialog naming the target and
the error. The dialog no longer claims the old bootloader is intact — a
partial write may leave the board unbootable. "Done." and update_bootscript
run only on success, and options 5/6 propagate the failure as the script exit
status so callers (armbian-config, automation) see the error too.
Some families' write_uboot_platform prints required manual steps (e.g.
fastboot flashing) instead of doing a raw write; on success that captured
output is echoed back so the instructions are not lost behind "Done.".
Notice-only hooks that call the build-side display_alert (absent in this
runtime script) would otherwise fail with 127 and fire the FAILED dialog; a
minimal display_alert shim lets them print their message and return 0.
Assisted-by: Claude:claude-opus-4.8
Line 2 had `exec </dev/null </dev/null 2>/dev/null` - two stdin
redirections, the second of which was meant to be stdout. ShellCheck
flags this as SC2261 (multiple redirections compete for stdin), failing
the red-cross gate. Redirect stdin, stdout and stderr each once.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
The odroid.shutdown script is fully generic - it syncs, waits for mdadm, then
spins down and detaches every /sys/block/sd*, with zero odroid-specific logic -
but it was installed per-family (odroidxu4) and PR #9214 proposed a second copy
for the Odroid HC4. Per @tabrisnet's review, make it a common, opt-in BSP hook
usable by any of the many SATA-capable boards.
- Move packages/bsp/odroid/odroid.shutdown -> packages/bsp/park-sata-disks.shutdown.
(NOT under packages/bsp/common, which is rsynced to every image regardless of
board - the script must only install on opt-in.)
- armbian-bsp-cli-deb: install it into /lib/systemd/system-shutdown when a board
or family sets HDD_PARK_ON_SHUTDOWN="yes".
- odroidxu4: drop the hand-rolled install, set the flag at family level.
- odroidhc4: set the flag (2-bay SATA NAS) - the actual fix requested in #9214.
Supersedes #9214.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
* Helios4: drop tweak in BSP postinst that was fixed in Debian in 2020
https://bugs.debian.org/875918
truth be told, the fix in Armbian wasn't ever a proper fix as the changes
made would be overwritten by the next update of the Debian mdadm package
* Helios4: make BSP postinst more robust
don't blindly assume that the mdadm package is installed
* Helios4: fix incorrect build-time notification about BSP postinst
* Helios4: add a FIXME warning to what we are doing via BSP postinst
* feat(bsp/helios4): own fault-LED handling via systemd service, drop /etc/mdadm/mdadm.conf mutation
Helios4 ships a chassis red fault LED at /sys/class/leds/helios4:red:fault
that should signal mdadm array failures. Until now this was wired by having
the BSP postinst (a) append a PROGRAM /usr/sbin/mdadm-fault-led.sh line to
/etc/mdadm/mdadm.conf and (b) historically also patch
/usr/share/initramfs-tools/hooks/mdadm. The latter was dropped in the
previous commit; this one drops (a) as well and replaces it with a
self-contained systemd unit that owns the mdadm --monitor invocation.
Why this is better:
/etc/mdadm/mdadm.conf is not a dpkg conffile but it IS generated and
ucf-managed by the mdadm package's own postinst. Appending to it from
another package's postinst races with ucf on every mdadm upgrade and
is exactly the 'do not modify another package's configuration from
maintainer scripts' anti-pattern Debian Policy Appendix E warns about.
By driving the LED from our own service we leave mdadm.conf entirely
alone and let mdadm own its own state.
mdadm --monitor in daemon mode polls /proc/mdstat (default --delay=60s),
diffs state against the previous snapshot and fork+execs the program
passed via --program= with EVENT, MD-DEVICE and (where applicable)
COMPONENT-DEVICE as positional args. That is exactly the contract the
existing mdadm-fault-led.sh script was already written against, so no
handler change is needed for this commit. ConditionPathExists= gates
the service on the LED node actually being present, so the unit is a
no-op on the off-chance a non-helios4 system ends up with this BSP.
Assisted-by: Claude:claude-opus-4.7
* fix(bsp/helios4/mdadm-fault-led): light fault LED on cold-boot degraded array via NewArray probe
mdadm --monitor emits a 'NewArray' event (not 'DegradedArray') the first
time it sees each array after startup. If a disk failed while the system
was off, the array comes up already degraded, and the existing handler
silently misses it — the chassis fault LED stays dark even though the
array needs attention.
Probe state via 'mdadm --detail' on NewArray and light the fault LED if
the array reports a degraded/failed state. Ordinary clean-startup
NewArray events still leave the LED alone.
Assisted-by: Claude:claude-opus-4.7
* refactor(bsp/helios4/mdadm-fault-led): collapse event ladder into POSIX case, fix SC2166
Replace the ladder of 'if [ $EVENT = X ]; then ... fi' with a single
'case "$EVENT" in ... esac'. The case form is the natural POSIX
construct for dispatching on a string and drops the SC2166 warning
that the previous 'if [ X = Y -o A = B ]' triggered ('[ -o ]' is
obsolescent and not well-defined under POSIX).
Drive-by:
- quote "$TRIGGER" / "$BRIGHTNESS" expansions (best-practice, no
behavior change — neither expands to anything with whitespace)
- fix 'britghness' typo in the comments
- document the positional-arg contract from mdadm --monitor
No functional change: same events produce the same LED state transitions
as before.
Assisted-by: Claude:claude-opus-4.7
* fixup! feat(bsp/helios4): own fault-LED handling via systemd service, drop /etc/mdadm/mdadm.conf mutation
* refactor(bsp/helios4/postinst): anchor PROGRAM grep, quote vars, expand ucf-aware rationale
Address CodeRabbit's nitpick on the mdadm.conf PROGRAM append:
- Anchored grep ('^PROGRAM /usr/sbin/mdadm-fault-led.sh') matches only
the exact directive we add, not a comment or unrelated PROGRAM line
elsewhere in the file. The original '"PROGRAM"' substring match
would skip the append even if the user had commented our line out.
- Quote "$MDADM_CONF" expansions per shellcheck best-practice (no
behavior change today — the path doesn't expand to anything with
whitespace — but lints cleaner).
- Single-statement 'if grep ...; then' instead of '$?'-on-next-line.
- Drop the FIXME line: the comment block now cites the upstream
mdmonitor.service rationale for why PROGRAM-in-mdadm.conf is the
intended integration path (ucf preserves local edits across mdadm
upgrades — exactly the use case ucf was designed for). Pointing to
the upstream-documented contract is more useful than a generic
'this is a big no-no' warning.
Smoke-tested on real helios4 mdraid hardware: ' PROGRAM /usr/sbin/mdadm-fault-led.sh' line is appended once on first postinst, idempotent on re-run; mdadm --monitor (started by upstream mdmonitor.service / mdadm.service) honors the directive and forks our handler on real Fail/DegradedArray events; chassis red fault LED lights as expected.
Reviewers — the parent commit in this branch (fixup!) is a pure revert
of the earlier '.service' approach. This commit is where the content
sits; the parent has nothing to review.
Assisted-by: Claude:claude-opus-4.7
* feat(bsp-cli): EXTRA_BSPDEPS env-var for board-specific runtime Depends; fix helios4 to use it
armbian-bsp-cli-<board> is the natural place to express board-specific
runtime behavior — hwmon rules, services, kernel modules, and the
software it depends on. But the framework hardcodes its Depends list in
lib/functions/bsp/armbian-bsp-cli-deb.sh's reversion phase, with no
extension point for family/board configs to add board-specific deps.
PACKAGE_LIST_BOARD apt-installs packages into the rootfs at build time
but does NOT establish a dpkg-level dependency between the BSP package
and them. In a single apt transaction the order between armbian-bsp-cli-X
and an independent PACKAGE_LIST_BOARD entry like mdadm is undefined
(typically alphabetic: 'a' < 'm', so our postinst runs before mdadm's),
which races with any postinst logic that needs the dep configured first.
For deterministic ordering of postinst execution, deb-Depends is required.
Add an optional 'EXTRA_BSPDEPS' env-var read at reversion time:
Depends: ..., device-tree-compiler${depends_base_files}${EXTRA_BSPDEPS:+, ${EXTRA_BSPDEPS}}
Default-empty, so existing boards see no behavior change. Family/board
configs that need it declare 'declare -g EXTRA_BSPDEPS="pkg1, pkg2"'
in family_tweaks_bsp() (or anywhere before reversion runs).
Use it from helios4: the previous 'local DEPENDENCIES=...; sed -i
/^Depends:/ s/...' attempt has been dead code since at least 2018 (the
sed runs in family_tweaks_bsp BEFORE the framework writes the Depends:
line, so it never matches). Replace with EXTRA_BSPDEPS="fancontrol, mdadm"
so mdadm is guaranteed installed AND configured before our BSP's postinst
appends 'PROGRAM /usr/sbin/mdadm-fault-led.sh' to /etc/mdadm/mdadm.conf.
The dead-sed hack was introduced by commit e261c6f82 (PR #1487) which
replaced a previously working 'chroot $SDCARD apt-get install fancontrol
mdadm' with the sed in DEPENDENCIES.
Assisted-by: Claude:claude-opus-4.7
* fix(bsp/helios4/mdadm-fault-led): on RebuildFinished, keep LED on if array still degraded
The 2018 handler turned the fault LED off unconditionally on any
RebuildFinished event. But RebuildFinished is a generic 'rebuild
operation ended' transition — it covers both successful resync
(array=clean) and aborted resync (array still degraded, e.g. a freshly
added spare failed before completing). In the latter case the LED used
to go dark while the array was actually broken.
Probe array state via 'mdadm --detail' on RebuildFinished, same pattern
as the NewArray cold-boot probe added earlier in this stack. Keep the
LED solid red if state contains 'degraded' / 'FAILED'; only turn it off
on a truly clean array.
Discovered during smoke-test on real helios4 hardware: a --fail/--remove/
--add sequence on a fake md0 triggered abort (spare immediately failed
due to stale metadata), mdmonitor emitted RebuildFinished 60s later,
LED went off — but the array remained [_U] degraded.
Assisted-by: Claude:claude-opus-4.7
---------
Co-authored-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.
The zz-update-abl-kernel postinst hooks located kernel, initrd and dtb
paths via shell wildcards (/boot/vmlinuz-*-sm8250 etc). Once a second
kernel version is installed, the globs expand to multiple files:
- mkbootimg receives multiple ramdisk arguments and aborts with
"ValueError: Unrecognized arguments", failing the kernel postinst
- gzip/cat silently concatenate multiple kernels and dtbs into the
boot image
Debian kernel hooks pass the kernel version as $1, so use it to build
exact paths. When invoked manually without the argument, fall back to
the newest installed kernel (sort -V). Fail early with a clear error
if the kernel or ramdisk is missing. Initialise extraargs and
abl_boot_partition_label before sourcing armbianEnv.txt to satisfy
the shellcheck lint gate (SC2154).
Applies to all six ABL BSPs: xiaomi-elish, oneplus-kebab, ayn-thor,
ayn-odin2, ayn-odin2mini, ayn-odin2portal.
Fixes: https://github.com/armbian/build/issues/10108
Several call sites published ${_f}.tmp unconditionally — if the sed,
echo, or heredoc staging command failed or produced a partial file,
atomic_write() still moved it into place.
Wrap each unguarded staging command in `if staging; then atomic_write`
(and `else rm -f` for the new-file cases) so a failed staging does not
clobber the live config file. Sites already using the `if staging; then`
pattern (sshd_config, /etc/default/locale, /etc/locale.gen, armbianEnv)
are unchanged.
Touched sites:
* do_firstrun_automated_network_configuration() — netplan wifi/ethernet
YAML via echo+createYAML (2 sites)
* set_shell() — /etc/default/useradd and /etc/adduser.conf via sed
(2 sites)
* set_timezone_and_locales() — /etc/netplan/30-wifis-dhcp.yaml via
heredoc (1 site)
* add_user() — /etc/sudoers.d/armbian-firstlogin-psd via echo (1 site)
Addresses PR #9954 review discussion r3435610237 (CodeRabbit).
If chmod or mv fails inside atomic_write(), the function previously
continued and the caller had no way to know the write did not land.
A failed mv masked by a successful sync lets firstlogin proceed as if
critical configs (locale, sshd_config, netplan, sudoers) were committed
when they actually were not.
Add `|| return` after both chmod invocations and the mv so the function
short-circuits on failure. The final `sync -f ... || sync` already
had its own fallback and is left as-is.
Addresses PR #9954 review discussion r3435610220 (CodeRabbit).
If power loss occurs between the /etc/passwd write and adduser completing
home creation, the user exists in passwd but has no home directory.
The existing re-run detection in add_user() required BOTH a passwd entry
AND a home dir, so it missed this state and fell into the username prompt
loop. With PRESET_USER_NAME set, that loop infinite-deadlocks on
"already exists" because the user is already in passwd.
Three coordinated fixes:
* Drop the home-dir requirement from existing-user detection. Detect
the user from /etc/passwd alone; home repair is centralized at the
adduser call site.
* In the username prompt loop, break early when the user exists but
home is missing, so the home-repair branch below can recover it.
Without this, PRESET_USER_NAME infinite-loops.
* At the adduser call site, if the user exists but /home/<user> is
missing, rebuild it from /etc/skel with correct ownership so the
user can log in.
Addresses PR #9954 review discussion r3435610246 (CodeRabbit findings
on lines 573-577 and 615-618).
When firstlogin (running as root) appends locale exports to a user's
~/.bashrc or ~/.xsessionrc and the file does not yet exist, the
redirection creates it as root:root. The user's subsequent login shell
cannot read it cleanly under strict modes and ownership is wrong.
Create the file first with touch + chown to the target user before
appending. If the file already exists, leave ownership alone — the
user may have customized it.
Addresses PR #9954 review discussion r3443078088.
Per review feedback from @djurny: the `tty` command writes its error
message to stderr when stdin is not a terminal, but may also fail to
write to stdout in edge cases (e.g. when stdout is closed or piped to
a broken descriptor). In those cases `$(tty)` captures an empty string
even when stdin is a tty, so `[[ -n "$(tty)" ]]` silently treats a
real terminal as "not a tty" and skips the marker removal.
`tty -s` is the POSIX-standard terminal test: it exits 0 if stdin is a
terminal, non-zero otherwise, without touching stdout. Switching to it
makes the check robust against stdout state.
Applied to both the main firstlogin guard and the final marker removal
for consistency — same pattern, same bug.
Per review feedback (PR #9954), grant the psd-overlay-helper NOPASSWD
rule via /etc/sudoers.d/armbian-firstlogin-psd rather than modifying
/etc/sudoers directly. This removes the need for power-loss corruption
detection and dpkg-default restoration of /etc/sudoers — recovery is
simply "no drop-in" and the next firstlogin run recreates it.
The drop-in is written atomically with mode 0440 and overwrites any
existing copy on re-run, which is naturally idempotent and correctly
tracks the current user (the previous grep-based guard only kept the
first user's rule).
The fallback `sync "${dest}"` silently fails on older systems where
sync does not accept file arguments, defeating the crash-safety goal.
Use bare `sync` instead to ensure data is flushed even without -f.
Move atomic_write() from armbian-firstlogin into armbian-common so both
armbian-firstrun and armbian-firstlogin share one implementation, and
refactor the inline atomic-write logic in armbian-firstrun's MAC
randomization (#9937) to use it.
Also address review feedback on #9954:
- Use ${VAR} notation consistently in the newly added code
- Apply atomic_write() to /etc/default/useradd, /etc/adduser.conf and
/etc/default/locale (previously left with plain sed -i + sync)
- Add a note about the quoted heredoc tag ('SUEOF') disabling variable
expansion
- Drop the PermitRootLogin yes change from sshd_config editing (not in
the original code, and out of scope for this power-loss safety PR)
- Use a more permissive sed -E pattern for uncommenting AcceptEnv LANG
Change atomic_write() signature from (dest, [mode]) to (src, dest, [mode])
so call sites clearly show the data flow without relying on an implicit
.tmp naming convention. Use local variables to avoid repeating long paths.
Consolidate separate chmod calls into the mode parameter where possible.
Add atomic_write() helper that writes to a temp file, syncs, then
renames — surviving power loss at any point. Use it for all
armbianEnv.txt modifications (hostname, MAC, root password).
Guard atomic_write permission handling: only chmod --reference when
the destination exists; use explicit mode for new files. Guard
firstlogin marker deletion behind the same tty check as the main
setup block so non-interactive invocations don't remove the marker
without completing setup.
The AIC8800D80 combo's BT is UART HCI on ttyS1. Its firmware (loaded over
SDIO by aic8800_bsp) idles the BT core in low-power until BT_WAKE is
asserted, so a plain hciattach times out waiting for HCI_Reset. Assert the
wake via the btlpm sysfs knob, then attach the generic H4 line discipline.
Adds aic8800-bluetooth.service (stock bluez hciattach, no vendor blob),
installed and enabled by the family for boards that set SUN60IW2_UART_BT
(both Orange Pi A733 boards). Validated on the Zero 3W.
* orangepizero3w: Add community support for Orange Pi Zero 3W (A733)
sun60iw2: factor shared A733 board config into a common include
The 4 Pro and Zero 3W are the same SoC and share most of their board
config. Move the common vars, a single fetch_custom_uboot__orangepi hook,
and the SD-card boot writer into
config/sources/vendors/xunlong/sun60iw2-a733-common.inc. Each board file
sets XUNLONG_A733_DRAM_BLOB (its boot0_sdcard training blob), BOOT_FDT_FILE,
and any board-specific writer (the 4 Pro's SPI-NOR). The blob name feeds
UBOOT_HASH_EXTRA so the u-boot artifact repackages when it changes.
Checkin boot blobs
* Cleanup kernel patch header and filename
* Remove shared opi a733 include, there wasn't enough truly shared content to justify it
* Coderabbit feedback (comment + write_uboot error handling. Avoid constants in write_uboot_platform because it has to be runnable on device not only at build time
Debian forky demoted adduser from the essential/minimal set, so minimal
images ship without it and armbian-firstlogin fails at user creation
(adduser: command not found) — reported in armbian/os#470 on Forky minimal.
Switch to the passwd (Essential) tools, matching a6cb68a1f (addgroup ->
groupadd in rockchip family_tweaks):
- user creation: adduser --disabled-password --home ... --gecos ...
-> useradd --create-home --home-dir ... --shell "$SHELL_PATH"
--comment ... --user-group (per-user group, skel copy, disabled
password preserved; password is set right after as before)
- docker group: addgroup --system --quiet -> groupadd --system
(getent guard already present)
- /etc/adduser.conf DSHELL edit now guarded on the file existing;
useradd reads /etc/default/useradd, which set_shell already updates.
No new package needed; useradd/groupadd are Essential (passwd) so present
on every image including minimal.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
With the old armbian-install and smaller emmc storage, the swapfile
was too big to fit onto the root file system.
This would cause the installation onto the emmc to fail.
Removed the entire swapfile creation as it's not needed anymore (zram
is used for swap).
Signed-off-by: Pierguido Lambri <plambri@runbox.eu>
Igor Pecovnik
code002-2
Viacheslav Bocharov
enthropy7
SuperKali
Tomaz Zaman
Darsey Litzenberger
chainsx
Mkirin
EvilOlaf
Alex Ling
Łukasz Sobala
Mkirin
crackerjacques
Igor Velkov
Rolf LeggewieandIgor Velkov
Rory Standley
mingzq
James S
saschabuehrle
Pierguido Lambri