diff --git a/559/404.html b/559/404.html new file mode 100644 index 000000000..44231b874 --- /dev/null +++ b/559/404.html @@ -0,0 +1,1639 @@ + + + +
+ + + + + + + + + + + + + + + + + + ++ This topic should give you as new board maintainers a brief overview about what you should do, must do, and can do. What you as maintainer can expect from Armbian and what we expect from you. +
+ ++
+ Even though you became a maintainer already just to make sure everything is set. +
+ +If you are a new maintainer, please make sure you have submitted your IDs and information using our maintainer registry form: Here
++
+ So all requirements are met and you are a maintainer now. Now what? +
+ ++ Maintainers must not necessarily be persons with development experience. They act as a intersection between end-users and the development team and serve the developers in best-effort manner. They are encouraged to answer basic/simple user questions (if possible, also best effort) without having to bother the development team. They are allowed to record bugs but are not allowed to escalate bugs. Team leaders do. +
+ ++ Take note that it is still up to development team's discretion what gets attention since Armbian has to plan carefully how to spend its very limited resources. +
+ ++
Low priority issues are usually attended to and patched by the community. If the issue has existed for more than a release, you can create a Jira ticket for it. However the expectation is the issue will be low priority and may not be processed for some time. Issues such as, but not limited to, should be considered low priority:
+For high priority items you can create a Jira ticket so that when developers are able, they can process it. If you are going to create a Jira ticket, please be sure to collect as much information about the issue as possible first. If more information will be needed to process the issue, you should reply to the user asking for that additional information and make sure it is included in the ticket. Issues like these should be considered a higher priority:
+What should you do if you run into an issue on the forum?
+What should you do if there is a long standing Jira ticket?
++
+ As mentioned in the board support rules the support status of a board will be revoked for at least the current and upcoming release cycle(s) if a "must" of the Maintaining section above is not fulfilled. +
+ ++ As an example: August 30th is release date for 22.08 release, sign-off dead line is 21th. If maintainer misses the RC sign-off window the board is demoted to CSC for both 22.08 and 22.11 releases. +
+ ++ The development team may grant exceptions on their discretion. +
+ ++
If you have questions about maintainer-ship or want to learn more deeper insights about the build framework and such Armbian will provide you with all information in best-effort. If time allows we can explain and teach you personally various aspects about the project. Otherwise, if you want to learn more about the build framework, dive in, play with it and read the documenenation. Also if you have other concerns please do not hesitate to reach out via forums, IRC or Discord. Armbian cares about the people who care about Armbian
+ + + + + + + + + + + + + + + +Framework can build generic Armbian or custom Linux image.
+Utility for configuring:
+Armbian OS assembly line:
+Armbian OS community assembly line:
+Armbian OS with pre-installed applications:
+Armbian short announcements are done via 𝕏 (formerly known as Twitter): https://twitter.com/armbian and https://fosstodon.org/@armbian
+As announced in the forums everyone interested can communicate in realtime using the internet relay chat (or IRC for short).
+Well known IRC clients for CLI are Weechat or Irssi and for GUI Hexchat or Konversation.
+Mature clients for Matrix: Element or FluffyChat.
Besides that communication is also possible via Discord or Matrix (closed beta).
+Libera network:
+irc.libera.chat
6697
/ non-encrypted: 6667
OFTC network:
+irc.oftc.net
6697
/ non-encrypted: 6667
#armbian
and #armbian-announcements
are available onlyIn order to enter main #armbian
channels registration with Nickserv is mandatory on Libera. Check Libera Chat documentation for further information.
Simply click here: https://discord.com/invite/armbian
+Channels starting with #armbian-
are relayed between Discord and Libera IRC so it does not matter if you join IRC or Discord as both ends receive your messages. Check #welcome-and-rules
for more information.
+The main #armbian
channel and #armbian-announcements
are relayed between Discord, Libera, OFTC and Matrix.
matrix.armbian.com
#armbian:matrix.armbian.com
and #armbian-announcements:matrix.armbian.com
are available onlyForums registration terms and rules apply for our chats: https://forum.armbian.com/terms
+#armbian
is the project’s main channel. Issue tracking, peer-to-peer user support or upcoming release planning talks.#armbian-announcements
: important messages from the Armbian team. You definitely want to idle here. Moderated channel#armbian-devel
: build engine development topics#armbian-desktop
: desktop environment development#armbian-csc
unsupported/stating board talk#armbian-allwinner
Allwinner-related SoC talk#armbian-amlogic
Amlogic-related SoC talk#armbian-broadcom
Broadcom-related SoC talk#armbian-rockchip
Rockchip-related SoC talk#armbian-offtopic
General chit chat, whatever that does not fit other channels#armbian-commits
Whenever a new interaction with a repository on Github happens it will be announced. Moderated channelBesides the services offered by IRC (like Nickserv or Chanserv) Armbian has set up some own services (on Libera only).
+ArmbianGithub
DC-IRC
#armbian-
as well as #armbian
.ArmbianHelper
,g Allwinner H6 panfrost
.nonprofit
, .sed
, .contribute
, .rtfm
, .fortune
, .sunxi
, .meson
, help
, help irc
, .tvboxes
--
at the beginning and the bot will translate your message regardless of the source language into English.@armbian/staff/lanefu
or @user/username
?/away [reason]
command as intended. For an explanation please have a look at the ZNC Wiki.If you have any questions, comments regarding the IRC channels and/or services or found an issue in this documentation for think you can enhance it get in touch with Werner either via forums, IRC or Discord.
+ + + + + + + + + + + + + + + + + + +There are no detailed instructions on how to add a new board or even a whole new board family to the build script yet. However there are a few commits / pull requests that give clues how to achieve that like
+ + + + + + + + + + + + + + + + +Builds kernel and device tree (where applicable) and places it to the output/debs
Usage: +
Bash | |
---|---|
Automatically call kernel’s make menuconfig
(add or remove modules or features)
Usage: +
Bash | |
---|---|
Validate dts files and improve board & patch development overall.
+This option validates the dts/dtb file for the selected board against the device tree bindings and outputs the validation logs to the user. It can be used when adding a new board, developing or improving a dts file.
+Usage: +
Bash | |
---|---|
Outputs a one-board-per-line CSV inventory of boards.
+Sets TARGETS_FILE
to something that doesn’t exist, so the default-targets.yaml
is used (so same list for everyone, save for userpatched-boards)
Usage: +
Bash | |
---|---|
Builds only DTB and outputs full preprocessed dts source
+Outputs preprocessed DTS source for the board in question to output/
+also outputs the same preprocessed DTS source, ran through dtc
with input and output DTS formats for “normalized” comparisons
Usage: +
Bash | |
---|---|
Prepares git, applies patches to git, and rewrites them back from git +same as kernel, it does git archeology for mbox-less patches, etc.
+Usage: +
Bash | |
---|---|
Prepares git, applies patches to git, and rewrites them back from git +same as kernel, it does git archeology for mbox-less patches, etc.
+Usage: +
Bash | |
---|---|
Generates output/info/git_sources.json file containing URL, branch, and commit hash combo.
+The easiest way to generate file for all devices is to run ./compile.sh targets
. Then, at the time of release, we will copy the output/info/git_sources.json file to config/sources/git_sources.json. Once the file is copied, the hash information from the file will be used to fetch resources for git repositories where branches are specified instead of tags or commits.
Usage: +
Bash | |
---|---|
Note
+--branch=v24.11
gitGraph
+ commit
+ commit
+ checkout main
+ commit id: "v24.08" tag: "v24.08"
+ branch v24.08
+ commit
+ commit
+ commit
+ commit
+ checkout main
+ commit id: "v24.11" tag: "v24.11"
+ branch v24.11
+ commit
+ commit
+ commit
+ commit
+ checkout main
+ commit
+ commit
+ commit
+ commit
+ commit
+ commit
+ commit id: "main" type: REVERSE tag: "Trunk"
+Run framework:
+Bash | |
---|---|
Comprehensive list of build Options
+Example:
+Bash | |
---|---|
Interpretation?
+This command will generate Ubuntu 24.04 Noble based Gnome desktop environment image for Intel based hardware (uefi-x86). Besides bare desktop, it will contain packages from browsers and desktop_tool sections and it will use unchanged kernel from current kernel branch.
+If you do not own the proper equipment to build images on your own, you can use our GitHub action.
+ + + + + + + + + + + + + + + +These parameters are meant to be applied to the ./compile.sh
command. They are all optional. They can also be added to your build configuration file to save time. Default values are marked bold if applicable.
BOARD ( string
)
Set the name of the board manually to skip the dialog prompt. Name of the board is a filename without extension.
+BRANCH ( string
)
vendor
legacy
current
(recommended)edge
Set kernel and U-Boot branch manually to skip dialog prompt
+Note
+Some branches may not be available for all devices.
+RELEASE ( string
)
bookworm
trixie
sid
jammy
noble
Set packages release base manually to skip dialog prompt. Check here for currently available releases.
+Note
+Only stable and/or LTS upstream Debian or Ubuntu releases are officially supported. Others might work or not.
+BUILD_MINIMAL ( string
)
yes
: build a bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP="yes"
no
: (default)BSPFREEZE ( string
)
yes
: freeze (from upgrade) armbian firmware packages when building images (U-Boot, kernel, DTB, BSP)no
: (default)INSTALL_HEADERS ( string
)
yes
: pre-install kernel headersno
: (default)NETWORKING_STACK ( string
)
network-manager
systemd-networkd
none
(to not-add any networking extensions)Installs desired networking stack. If the parameter is undefined, it sets systemd-networkd
for minimal images (MINIMAL=yes) and network-manager
for the rest. Time synchronization is also changed; chrony is installed with network-manager, while systemd-timesyncd is used with systemd-networkd. In both cases, we control network settings using Netplan.
Build switch example
+Text Only | |
---|---|
EXPERT
+yes
Show development features and boards regardless of their support status in interactive mode.
+CLEAN_LEVEL (comma-separated list)
+Defines what should be cleaned. Changing this option can be useful when rebuilding images or building more than one image
+make-atf
= make clean for ATF, if it is built.make-uboot
= make clean for uboot, if it is built.make-kernel
= make clean for the kernel if it is built. very slow.debs
, alldebs
= delete all packages in “./output/debs”images
= delete “./output/images”cache
= delete “./output/cache”sources
= delete cache/sources
(all downloaded sources)oldcache
= remove old cached rootfs except for the newest 8 filesextras
= delete additional packages for the current release in output/debs/extra
CARD_DEVICE ( string )
+/dev/sdX
Set to the device of your flash media / SD card. The image will be burned and verified.
+PREFER_DOCKER ( string )
+yes
(default)no
Docker assisted compilation is on by default. Set to no
if you prefer running compilation natively.
DOCKER_ARMBIAN_BASE_IMAGE ( string )
+ubuntu:jammy
(default)ubuntu:noble
debian:bookworm
Defines the build host when using a Docker container (default). Here, you can see which other options are available.
+If enabled (true
), the Docker build container will receive Docker credentials from the host
+(${HOME}/.docker/config.json
) and the OCI_TARGET_BASE
environment variable.
lib/functions/configuration/main-config.sh
)Select the target for pull/push OCI cached images. If not set, default is used.
+The default mirror address for ghcr.io, set by GHCR_MIRROR=dockerproxy
, is ghcr.dockerproxy.com. When this address is unavailable, an alternative address can be set with GHCR_MIRROR_ADDRESS
.
Example: +
Text Only | |
---|---|
The compiler used to compile the kernel. Usually, this option is set by the board config, but it can be set to clang
to use LLVM to compile the kernel.
Example: +
Text Only | |
---|---|
Manage OpenSSH host key regeneration at armbian-firstrun service.
+Example: +
Text Only | |
---|---|
ROOTFS_TYPE ( string )
+ext4
(default)f2fs
btrfs
nilfs2
xfs
nfs
Create image with different root filesystems instead of default ext4
. Requires setting FIXED_IMAGE_SIZE
to something smaller than the size of your SD card for F2FS
BTRFS_COMPRESSION ( string )
+lzo
none
zlib
(default)zstd
When choosing ROOTFS_TYPE=btrfs
, select btrfs
filesystem compression method and compression level. By default, the compression is zlib
.
Note
+The script does not check the legality of the input variable (compression ratio). Input like zlib:1234
is legal to the script but illegal to the kernel. Beware that setting this option does affect image creation only (shrinking disk size) and will not adjust /etc/fstab
, so it is up to the user to later edit /etc/fstab
if compression in daily operation is also wanted (beware of severe performance penalties with random IO patterns and heavy compression algorithms!).
CRYPTROOT_ENABLE ( string )
+LUKS (Linux Unified Key Setup) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy. LUKS uses the kernel device mapper subsystem via the dm-crypt module.
+When enabled, you need to provide additional information: | |
---|---|
Tips and warnings
+$USERPATCHES_PATH/dropbear_authorized_keys
or they will be generated in output/images/*.key
file=
; separate switches with spacesINCLUDE_HOME_DIR ( string )
+yes
no
(default)Include directories created inside /home in final image.
+ENABLE_EXTENSIONS (c omma-separated list )
+Extensions allows to extend the Armbian build system without overloading the core with specific functionality. Extensions, stored in folder extensions
are called
Build switch example
+ +CONSOLE_AUTOLOGIN
+yes
(default)no
Automatically login as root for local consoles at first run. Disable if your security threat model requires.
+DO NOT USE! Obsolete documentation, new documentation above is in progress.
+kernel-patch
/ uboot-patch
/ atf-patch
CLI commands instead.
+ - yes: prompt right before the compilation starts to make changes to the source code for both U-Boot and kernel. From these changes, patch files will be created and placed in the output
directory. If you want these patches included in a normal run (without CREATE_PATCHES to say), these files must be copied to the appropriate directories. Also, see user-provided patches.string
): bind mount cache/rootfs to defined folderstring
): bind mount cache/toolchain path to defined folderuserpatches
folder$DEST/ccache
as ccache home directoryoutput/debug/*.log
yes
in containers, but can be overriddengooglesource.com
mirror for downloading mainline kernel sources, which may be faster than git.kernel.org
depending on your locationgit.denx.de
depending on your locationinteger
): create an image file of this size (in megabytes) instead of minimalinteger
96 ): set size (in megabytes) for separate /boot filesystem. Used if ROOTFS_TYPE set to non-ext4sha,gpg,7z
IPv4 address
): the DNS resolver used inside the build chroot. Does not affect the final image. Default: 1.0.0.1
china
| bfsu
): select download mirror for toolchain
and debian/ubuntu packages
+ - china
: use mirrors.tuna.tsinghua.edu.cn
; it will be very fast thanks to Tsinghua University
+ - bfsu
: use mirrors.bfsu.edu.cn
, the mirror of Beijing Foreign Studies Universitygoogle
| tuna
| bfsu
): select mainline mirror of linux-stable.git
+ - google
: use the mirror provided by Google, the same as USE_MAINLINE_GOOGLE_MIRROR=yes
+ - tuna
: use the mirror provided by Tsinghua University
+ - bfsu
: use the mirror provided by Beijing Foreign Studies University, which is similar to tuna
+ - leave empty to use the official git.kernel.org
, which may be very slow for mainland China usersgithub
| gitee
: select mainline mirror of u-boot.git
+ - github
: use the mirror provided by github, the same as USE_GITHUB_UBOOT_MIRROR=yes
+ - gitee
: use the mirror provided by Gitee, a Chinese git services
+ - leave empty to use the official source.denx.de
, which may be very slow for mainland China usersfastgit
| gitclone
| cnpmjs
): select download mirror for GitHub hosted repository
+ - fastgit
: use the mirror provided by fastgit.org
+ - gitclone
: use the mirror provided by gitclone.com
+ - cnpmjs
: use the mirror provided by cnpmjs.org
+ - leave empty to connect directly to GitHub, which may be very slow for mainland China userschina
): select mirrors based on regional setting, will not overwrite explicitly specified mirror option
+ - china
: MAINLINE_MIRROR=tuna
, UBOOT_MIRROR=gitee
, GITHUB_MIRROR=fastgit
, DOWNLOAD_MIRROR=china
+ - leave empty to use default settingsThis method works for building u-boot and kernel packages as well as building full OS images.
+Note!
+To write fresh-builded image directly to sdcard or other block device you have to enable
+Docker run in privileged
mode.
+Uncomment line DOCKER_FLAGS+=(--privileged)
in file userpatches\config-docker.conf
or your own docker-config file.
Building additional packages (EXTERNAL_NEW
) is not supported.
Installation (https://docs.docker.com/engine/install/)
+There are 3 options to start build process:
+1. By passing configuration file name (config-<conf_name>.conf
), stored in userpatches
directory, as an argument:
+
Text Only | |
---|---|
compile.sh
after docker
:
+Text Only | |
---|---|
Text Only | |
---|---|
The process creates and runs a named Docker container armbian
with two named volumes armbian-cache
and armbian-ccache
,
+and mounts local directories output
and userpatches
.
Options 1 and 2 compile the same as without Docker but in separate environment to prevent changes to the base system.
+The dockerfile of the created container is placed in userpatches
directory, and all container-related options can be changed
+in userpatches/config-docker.conf
file. Templates of both files are located in the config/templates
directory.
The docker-shell interactive mode is useful for when you need to do more than just “make an image.” This mode allows you to edit +U-Boot and kernel sources before and after applying patches, investigate compilation errors, and so on.
+This mode also allows you to manually run individual steps of the build process.
+First, start docker-shell on the host build system: +
Text Only | |
---|---|
RELEASE=bullseye BOARD=rockpi-4a BRANCH=edge
are passed into shell and will be set into
+envirounment variables.
+Next, we can simply start building an image: +
Text Only | |
---|---|
For example, to compile U-Boot, prepare the environment with: +
Text Only | |
---|---|
Text Only | |
---|---|
Text Only | |
---|---|
In order to build an Armbian image from scratch, whether for development purposes or to apply user customizations on top of a base image, a build environment is required. Per the Armbian documentation, Ubuntu 22.04 is the officially supported build platform.
+Multipass that is designed for quick and painless provisioning of Ubuntu VMs.
+Multipass is available for macOS, Windows and Linux platforms.
+Once you have multipass installed, a Jammy (22.04) instance with 4 CPUs, 4GB of RAM and 25GB of space available can be provisioned with a single command:
+Bash | |
---|---|
You can run commands direct on the instance to clone the build repo:
+Bash | |
---|---|
Then you can get a shell to the instance and run the build as needed:
+Bash | |
---|---|
The recommended way to share data between your host and an instance with Multipass is the command:mount +
+Mounts: /my/dir => /my/dir
+From this point on will be available inside the instance./my/dir
+ + + + + + + + + + + + + + + +post_family_config
¶++give the config a chance to override the family/arch defaults
+
This hook is called after the family configuration (sources/families/xxx.conf
) is sourced. Since the family can
+override values from the user configuration and the board configuration, it is often used to in turn override those.
Also known as (for backwards compatibility only):
+config_tweaks_post_family_config
user_config
¶++Invoke function with user override
+
Allows for overriding configuration values set anywhere else. It is called after sourcing the lib.config
file if it
+exists, but before assembling any package lists.
extension_prepare_config
¶++allow extensions to prepare their own config, after user config is done
+
Implementors should preserve variable values pre-set, but can default values an/or validate them. This runs after +user_config. Don’t change anything not coming from other variables or meant to be configured by the user.
+post_aggregate_packages
¶++For final user override, using a function, after all aggregations are done
+
Called after aggregating all package lists, before the end of compilation.sh
. Packages will still be installed after
+this is called, so it is the last chance to confirm or change any packages.
Also known as (for backwards compatibility only):
+user_config_post_aggregate_packages
post_determine_cthreads
¶++give config a chance modify CTHREADS programatically. A build server may work better with hyperthreads-1 for example.
+
Called early, before any compilation work starts.
+Also known as (for backwards compatibility only):
+config_post_determine_cthreads
add_host_dependencies
¶++run before installing host dependencies
+
you can add packages to install, space separated, to ${EXTRA_BUILD_DEPS} here.
+fetch_sources_tools
¶++fetch host-side sources needed for tools and build
+
Run early to fetch_from_repo or otherwise obtain sources for needed tools.
+build_host_tools
¶++build needed tools for the build, host-side
+
After sources are fetched, build host-side tools needed for the build.
+pre_install_distribution_specific
¶++give config a chance to act before install_distribution_specific
+
Called after create_rootfs_cache
(prepare basic rootfs: unpack cache or create from scratch) but
+before install_distribution_specific
(install distribution and board specific applications).
Also known as (for backwards compatibility only):
+config_pre_install_distribution_specific
pre_install_kernel_debs
¶++called before installing the Armbian-built kernel deb packages
+
It is not too late to unset KERNELSOURCE
here and avoid kernel install.
post_install_kernel_debs
¶++allow config to do more with the installed kernel/headers
+
Called after packages, u-boot, kernel and headers installed in the chroot, but before the BSP is installed.
+If KERNELSOURCE
is (still?) unset after this, Armbian-built firmware will not be installed.
post_family_tweaks
¶++customize the tweaks made by $LINUXFAMILY-specific family_tweaks
+
It is run after packages are installed in the rootfs, but before enabling additional services. It allows implementors
+access to the rootfs (${SDCARD}
) in its pristine state after packages are installed.
pre_customize_image
¶++run before customize-image.sh
+
This hook is called before customize-image.sh
is executed and before the overlay is mounted. It thus can be used
+for the same purposes as customize-image.sh
without the overlay.
Also known as (for backwards compatibility only):
+image_tweaks_pre_customize
post_customize_image
¶++post customize-image.sh hook
+
Run after the customize-image.sh script is run, and the overlay is unmounted.
+Also known as (for backwards compatibility only):
+image_tweaks_post_customize
post_post_debootstrap_tweaks
¶++run after removing diversions and qemu with chroot unmounted
+
Last chance to touch the ${SDCARD}
filesystem before it is copied to the final media. It is too late to run any
+chrooted commands, since the supporting filesystems are already unmounted.
Also known as (for backwards compatibility only):
+config_post_debootstrap_tweaks
pre_prepare_partitions
¶++allow custom options for mkfs
+
Good time to change stuff like mkfs opts, types etc.
+Also known as (for backwards compatibility only):
+prepare_partitions_custom
prepare_image_size
¶++allow dynamically determining the size based on the $rootfs_size
+
Called after ${rootfs_size}
is known, but before ${FIXED_IMAGE_SIZE}
is taken into account. A good spot to
+determine FIXED_IMAGE_SIZE
based on rootfs_size
. UEFISIZE can be set to 0 for no UEFI partition, or to a size in MiB
+to include one. Last chance to set USE_HOOK_FOR_PARTITION
=yes and then implement create_partition_table hook_point.
Also known as (for backwards compatibility only):
+config_prepare_image_size
post_create_partitions
¶++called after all partitions are created, but not yet formatted
+
format_partitions
¶++if you created your own partitions, this would be a good time to format them
+
The loop device is mounted, so ${LOOP}p1 is it’s first partition etc.
+pre_update_initramfs
¶++allow config to hack into the initramfs create process
+
Called after rsync has synced both /root
and /root
on the target, but before calling update_initramfs
.
Also known as (for backwards compatibility only):
+config_pre_update_initramfs
pre_umount_final_image
¶++allow config to hack into the image before the unmount
+
Called before unmounting both /root
and /boot
.
Also known as (for backwards compatibility only):
+config_pre_umount_final_image
post_umount_final_image
¶++allow config to hack into the image after the unmount
+
Called after unmounting both /root
and /boot
.
Also known as (for backwards compatibility only):
+config_post_umount_final_image
post_build_image
¶++custom post build hook
+
Called after the final .img file is built, before it is (possibly) written to an SD writer.
+${FINAL_IMAGE_FILE}
+ It is the last possible chance to modify $CARD_DEVICE
.run_after_build
¶++hook for function to run after build, i.e. to change owner of
+$SRC
Really one of the last hooks ever called. The build has ended. Congratulations.
+extension_metadata_ready
¶++meta-Meta time!
+
Implement this hook to work with/on the meta-data made available by the extension manager. Interesting stuff to process:
+"${EXTENSION_MANAGER_TMP_DIR}/hook_point_calls.txt"
contains a list of all hook points called, in order.${EXTENSION_MANAGER_TMP_DIR}/hook_point.orig.md
contains the hook documentation at the call site (inline docs),
+ hopefully in Markdown format.
+ - ${EXTENSION_MANAGER_TMP_DIR}/hook_point.compat
contains the compatibility names for the hooks.
+ - ${EXTENSION_MANAGER_TMP_DIR}/hook_point.exports
contains exported environment variables.
+ - ${EXTENSION_MANAGER_TMP_DIR}/hook_point.vars
contains all environment variables.${defined_hook_point_functions}
is a map of all the defined hook point functions and their extension information.${hook_point_function_trace_sources}
is a map of all the hook point functions that were really called during the
+ build and their BASH_SOURCE information.${hook_point_function_trace_lines}
is the same, but BASH_LINENO info. After this hook is done,
+ the ${EXTENSION_MANAGER_TMP_DIR}
will be removed.++“I’m gonna create a
+prepare_bootloader
hook [in core] so we can refactoru-boot
[into an extension]”
The extensions framework allows the board/family developers, extension authors, and users to extend the Armbian build system without overloading the core with specific functionality.
+It’s a simple framework, written in Bash, that works based on function naming conventions. It provides the core and the extensions with tracing and debugging, (error control,?) inline documentation and very simple dependency resolution.
+lib/
directory plus compile.sh
and some others. It’s the spine of the build system.extensions/
or userpatches/extensions/
directory, but could one day be in a separate repository too.call_extension_method()
. This will discover all enabled extension methods implementations, order them, and call them one by one.
+ - The Armbian core already has quite a few of these in strategic spots.
+ - More are coming as they’re identified.The Armbian core build system has an extension method called run_after_build
, also known as the “run_after_build
hook”. You can find it in lib/main.sh
around line 546.
Consider the following function:
+Bash | |
---|---|
Such a function is an “extension method implementation” called say_congratulations
for the extension method run_after_build
.
A file userpatches/extensions/be-festive.sh
containing the above function is an “extension” called be-festive
.
An user of the build system can enable that extension by adding a call to enable_extension "be-festive"
on his configuration file, or by passing ENABLE_EXTENSIONS=be-festive
as a parameter to the build.
An extension method implementation is just a Bash function that follows the pattern run_after_build__say_congratulations
where
run_after_build
is the name of the extension method.__
is a marker/separator – very important – two underscores, not one, not three.say_congratulations
is the name of the extension method implementation, and should be unique.The system will “magically” compose a single run_after_build()
function, based on all the hook functions that begin with run_after_build__
.
Hook functions will be sorted by their numerical value; hook functions that do not begin with a number will receive 500_
prefix automatically.
So the examples run_after_build__do_this
and run_after_build__500_do_this
are equivalent, and will run
run_after_build__900_do_smth_else
run_after_build__300_do_even_another_thing
A extension is Bash source file that contains exclusively:
+__
separator)
+ - other internal functions (for structure and clarity if needed)enable_extension "another-extension"
at the top of the file.
+ - that’s a very simple dependency system, one extension can enable another.Specifically, extension files should not contain any code outside of functions – they should do nothing when sourced.
+Extensions can be official Armbian fragments and live in /extensions
, or can be user-specific
+in /userpatches/extensions
.
An extension could be implemented in any of the following file/dir structures:
+/extensions/our-ext.sh
- an official, single-file extension./userpatches/extensions/my-ext.sh
- a user-specific, single-file extension./extensions/our-dir-ext/our-dir-ext.sh
- an official, directory-based extension./userpatches/extensions/my-dir-ext/my-dir-ext.sh
- a user-specific, directory-based extensions.The official extensions can be used by boards, family includes, etc, while the user-specific extensions can only be used by userpatches code or via ENABLE_EXTENSIONS=my-ext,my-dir-ext
build parameter.
They’re the same, except:
+${EXTENSION_DIR}
environment variable.${EXTENSION_DIR}
allows for easy moving and PR’ing of user extensions.graph LR
+ A[./compile.sh] --> B{Change<br>kernel<br>config};
+ B ---> |yes| C["HW"];
+ B ---> |no| C["HW"];
+ C ---> |branch| D["legacy<br>vendor<br>current<br>edge"];
+ D --> |base| E["Debian<br>Ubuntu"];
+ E ---> |type| F["CLI"];
+ F ---> |type| G["Server"];
+ F ---> |type| H["Minimal"];
+ E ---> I["Desktop"];
+ I ---> K["XFCE"];
+ I ---> L["Gnome"];
+ I ---> M["Cinammon"];
+ I ---> N["KDE Neon"];
+Check other similarities, advantages and disadvantages compared with leading industry standard build software.
+Function | +Armbian | +Yocto | +Buildroot | +
---|---|---|---|
Target | +general purpose | +embedded | +embedded / IOT | +
U-boot and kernel | +compiled from sources | +compiled from sources | +compiled from sources | +
Board support maintenance | +complete | +outside | +outside | +
Root file system | +Debian or Ubuntu based | +custom | +custom | +
Package manager | +APT | +any | +none | +
Configurability | +limited | +large | +large | +
Initramfs support | +yes | +yes | +yes | +
Getting started | +quick | +very slow | +slow | +
Cross compilation | +yes | +yes | +yes | +
You can add your own patches outside build script. Place your patches inside appropriate directory, for kernel or u-boot. There are no limitations except all patches must have file name extension .patch
. User patches directory structure mirrors directory structure of patch
. Look for the hint at the beginning of patching process to select proper directory for patches. Example:
Text Only | |
---|---|
1 +2 |
|
Patch with same file name in userpatches
directory tree substitutes one in patch
. To replace a patch provided by Armbian maintainers, copy it from patch
to corresponding directory in userpatches
and edit it to your needs. To disable a patch, create empty file in corresponding directory in userpatches
.
If file userpatches/lib.config
exists, it will be called and can override the particular kernel and u-boot versions. It can also add additional packages to be installed, by adding to PACKAGE_LIST_ADDITIONAL
. For a comprehensive list of available variables, look through lib/configuration.sh
. Some examples of what you can change:
Text Only | |
---|---|
1 +2 +3 |
|
If file userpatches/linux-$LINUXFAMILY-$BRANCH.config
exists, it will be used instead of default one from config
. Look for the hint at the beginning of kernel compilation process to select proper config file name. Example:
Text Only | |
---|---|
1 +2 |
|
If file userpatches/sources/$LINUXFAMILY.conf
exists, it will be used in addition to the default one from config/sources
. Look for the hint at the beginning of compilation process to select proper config file name.
+Please note that there are some exceptions for LINUXFAMILY like sunxi
(32-bit mainline sunxi) and sunxi64
(64-bit mainline sunxi)
Example:
+Text Only | |
---|---|
1 |
|
You can run additional commands to customize created image. Edit file:
+Text Only | |
---|---|
1 |
|
and place your code here. You may test values of variables noted in the file to use different commands for different configurations. Those commands will be executed in a chroot environment just before closing image.
+To add files to image easily, put them in userpatches/overlay
and access them in /tmp/overlay
from customize-image.sh
Be advised that even though you are compiling an image on an amd64 machine, any additional apt packages you configure or commands you run in customize-image.sh will be automatically installed/executed/virtualized for the architecture of the build target SBC.
+In case you define $FIXED_IMAGE_SIZE
at build time the partition containing the rootfs will be made of this size. Default behaviour when this is not defined is to shrink the partition to minimum size at build time and expand it to the card’s maximum capacity at boot time (leaving an unpartitioned spare area of ~5% when the size is 4GB or less to help the SD card’s controller with wear leveling and garbage collection on old/slow cards).
You can prevent the partition expansion from within customize-image.sh
by a touch /root/.no_rootfs_resize
or configure the resize operation by either a percentage or a sector count using /root/.rootfs_resize
(50%
will use only half of the card’s size if the image size doesn’t exceed this or 3887103s
for example will use sector 3887103 as partition end. Values without either %
or s
will be ignored)
Overview:
+Log output is stored in output/logs
and provided in a few different formats. ANSI coloring is applied to both the screen and the log files themselves.
+Please add SHARE_LOG=yes
to automatically upload logs to our paste service and provide us with the given url when reporting issues.
+That will allows us to check the logs on a web browser and keep to correct formatting.
General CLI syntax: ./compile.sh PARAM=value OTHER_PARAM=other_value [<configfile> <configfile> ...] [<command>]
command
defaults to build
if not specified; could also be kernel-config
or u-boot
etc…<command>
(system will check & bomb if so)default
config – you have to be explicitdocker
config – Docker is fully auto-managed now. The system will complain if you have one.PARAM=value
, <configfile>
or <command>
can be applied in any order.config-default.conf
, config file name needs to be specified in the command line¶userpatches/config-xyz.conf
– but the name has to be provided to the build system to,
+ like ./compile.sh BOARD=xxx xyz
; otherwise works the same.The armbian/build
system is currently undergoing refactoring to improve its structure. Previously, the build system
+was a single, very complex bash script that mixed the building of .deb
packages with the creation of images.
This was reworked into a 1-to-N
image-to-artifact dependency tree; a certain image build will depend on N possible
+“artifacts”. Artifacts are either .deb
packages, a .tar
of multiple .deb
packages, or a rootfs.tar.zstd
. Each
+artifact can be individually built, and has a specific name and a version.
Each artifact is also now cached by default using OCI storage at ghcr.io (GitHub Container Registry). To achieve +consistent caching, each artifact produces a version that includes hashes of its composing files, variables, +patches, hooks, external git SHA1 references, etc. That way we can consistently check the remote OCI cache for previously-built +artifacts, and possibly save image builders from having to build heavy packages just to produce an image.
+KERNEL_ONLY=yes
and KERNEL_ONLY=no
are deprecated. Use the kernel
CLI command instead.ARTIFACT_IGNORE_CACHE=yes
can help with false positives. Please also report the problem, with a complete logfile.compile.sh
will prefer to use Docker if it detects Docker is installed and working.
+ - This handles Docker Desktop and Rancher Desktop (in Docker emulation mode) under macOS/Darwin, including Apple
+ M1/M2.
+ - You don’t need and actually can’t have the old docker config file.sudo
to run the build as root.sudo
.During the build, depending on which local or remote caches are hit, it might be necessary to build the Linux Kernel from scratch.
+The kernel’s git repo is huge. Most build systems resort to fetching “shallow” trees directly from upstream git servers,
+to save bandwidth. Unfortunately that creates immense extra CPU load on the git servers. To avoid this problem,
+Armbian produces daily automated git tree exports cached in ghcr.io OCI repositories, and only uses git fetch
to
+update the relatively small new changes from the upstream git server.
There are two types of cached Kernel git trees:
+full
is a complete git tree, including all of Torvald’s master
and all of the currently-supported stable
+ branches.
+ - full
is very large download and requires a lot of disk space.
+ - full
is more useful over time and when building multiple different kernels on the same machine, like for CI
+ servers or developer workstations.shallow
is a shallow tree for a specific stable
branch
+ - shallow
is a much smaller download and requires less disk space
+ - shallow
is appropriate for restricted devices like SBCs which will build a single kernel**TL;DR: ** KERNEL_GIT=full
or KERNEL_GIT=shallow
or let the system decide for you.
Before cloning the repo, consider forking it first. This will allow you to make changes and submit pull requests. +You will need a GitHub account to do this; +see GitHub’s documentation for more +information. +If you fork, make sure to keep your fork up-to-date with the main repo, by rebasing your fork.
+This is (by far) not a complete list:
+We can build u-boot twice, using UBOOT_TARGET_MAP
. Some example I did in https://github.com/armbian/build/blob/main/config/boards/odroidhc4.conf#L15-L20 may help.
+ This topic should give you as a developer a brief overview about what you should do, must do, aswell as can and can not do. What you as devepoler can expect from Armbian and what we expect from you. +
+
+ Even though you may already be a developer, just to make sure, here is an outline of the expectations for this process: +
+ | Review | +Approve | +Merge | +
---|---|---|---|
Github ID | ++ | + | + |
Armbian Github Organisation Collaborator | ++ | + | + |
Armbian Github Organisation Member | ++ | + | + |
Armbian Organization Members are required to have:
You should know development basics like how to get an Armbian image running on your hardware, do basic debugging, building a kernel and how to use the Armbian build system.
+
+ Some helpful guidelines for pull requests and code reviews +
+ It has often been said that programming is part art, part science - that is because lots of times there is no single, simple solution to a problem. Or if there is, we might not know about it. There is also an infamous joke that if there are n developers in the room, then there are n+1 opinions on how things should be done. That being said, here are some guidelines that should prevent friction when submitting or reviewing code. +
Unless you open a PR (“pull request”) as a work in progress, the code should be built and tested on a device or emulator. Do not rely on CI test automation!
If you have touched the build files and changed build setup, it is useful to test the whole build from scratch (clean build) and all of the types and flavours. If you updated external libraries, test the pertaining features. If you changed the build version, make a build and test that the version is correct.
Having people review your code is one thing, but you should not expect them to also test the code for you when not explicitly asked for.
One important thing that lots of guidelines forget to mention is the context of the pull request: Sometimes it is a big refactor, sometimes it is a new feature, sometimes it is a bugfix. Some of those might be more urgent than others, and sometimes you might be under pressure to ship ASAP so the code might not be perfect or there will not be any tests or code might not be extendable. That is ok.
If a pull request is fundamentally ready, but needs only trivial fixes (such as typos), consider demonstrating a bias for action by making those changes directly without going back to the author. You can do this by using the suggest changes feature to apply your own suggestions to the pull request.
Note that:
Authors are not authorized to merge their own pull requests and need to seek approval from another maintainer / developer to merge.
If you have questions about being a developer or want to learn more and deeper insights about the build framework, Armbian will try to guide you to the appropriate documentation or information in a best-effort fashion. If time allows, at our descrection, we will try our best to explain and teach you personally various aspects about our processes. If best effort guidance is not enough, contact us for professional assistance.
If you have any concerns please do not hesitate to reach out via forums, IRC or Discord. Armbian cares about the people who care about Armbian
TLDR; Keep task discussions in the forum. GitHub Issues are just for task metadata.
+Tasks associated with code will have an issue created in GitHub, but all dialog regarding tasks will reside on the forum in a topic containing the github Issue ID of the task.
+A task is something actionable that results in some sort of tangible output. ex: code, documentation, QA findings.
+Example sources of tasks include: feature requests, bugs, QA, general following of development roadmap.
+Not all support issues are tasks, but a support issue can generate a task.
+[ISSUE_ID] - Issue Name
+ - Create comment on GitHub Issue with the following Content:
+Text Only | |
---|---|
1 +2 +3 |
|
-
+Lock comments on GitHub Issue
+GitHub Issues provide an easy method to track and filter tasks by using tags and milestones. Issues also make it easy to easily associate commits and merge requests with a task. Effectively we just use GitHub issues for the metadata for reporting.
+Use labels identify the purpose of a task.
+bug
is used to tag tasks that address Armbian-level bugsnot-our-bug
is used to identify tasks that are bugs in upstream code. They are not Armbian bugs, but may impact Armbian.enhancement
is used to identify tasks that are new features for Armbian.Use milestones to divide tasks into claimed and unclaimed work.
+claimed tasks
milestone contains tasks which have been assigned.unclaimed tasks
milestone contains tasks that need an owner.Sometimes support discussions can become tasks. A forum admin can assist in moving the topic to Tasks forum group. A cooresponding issue will need to be created.
+Enhancements desired for this process (This should be a task!)
+Ideally we can have a forum topic created upon issue creation. This will save some time.
+ + + + + + + + + + + + + + + +Core automation for generating images for release are held at armbian/os
+Recommended images on download pages are defined via regular expression mapping file exposed.map
:
Example:
+Text Only | |
---|---|
They have definitions on what kind of images we want to build - for section or for one specific board:
+YAML | |
---|---|
From those templates we are autogenerating YAML files, which are passed to build matrix as input. Make sure to review generated YAML files if they have wanted build targets with correct exensions enabled.
+Autogeneration is excluded for boards that are on blacklists:
+YAML | |
---|---|
We do this if we are not happy with the automation outcomes and want to define build targets in the template.
+Each board variant can have additional extensions and they are defined in this file:
+Text Only | |
---|---|
Example:
+Text Only | |
---|---|
Manual executing permissions are tied to release manager role.
+This build workflow is executed manually when making:
+Notes:
+Bump version: Select if you want to trigger system wide version bump. +Version override: Set version under which you want to release images.
+Images versions are stored in JSON files: +- https://github.com/armbian/os/blob/main/stable.json +- https://github.com/armbian/os/blob/main/nightly.json
+(Workflow takes around 15 minutes to complete. In case of network issues it can also take hours)
+Generated images are uploaded to incoming folder https://rsync.armbian.com/incoming/ under your GitHub username and once they are confirmed working, please notify @igorpecovnik to move them to official download pages. Once images are moved to main download section, automation refreshes download pages index within 15-30 minutes.
+Generates stable images defined in targets-release-standard-support.yaml.
+We are generating several images for each download / hardware target. They are automatically sorted by sections:
+Images generation can be customized:
+This build workflow is executed manually when making:
+Notes:
+Version override: Use this feature if you want to keep them under the same version, but not lower then last released.
+(Workflow takes around 15 minutes to complete. In case of network issues it can also take hours)
+Generated images are hosted at GitHub https://github.com/armbian/distribution/releases and released at once. Automation refreshes download pages within 15-30 minutes after/if workflow finished succesfully.
+ +Generates dedicated application images defined in targets-release-apps.yaml. This file is autogenerated from targets-release-apps.template. (You always edit template)
+Images generation can be customized:
+This pulls packages from build framework OCI cache located at GitHub and from various 3rd party repositories such as Chrome, Chromium, Code, Discord, (latest) ZFS, Thunderbird, Zoom, … and pushes them to:
+apt.armbian.com
(only new packages are added)beta.armbian.com
(whole repository is recreated from scratch)Action is executed automatically when artifact generations completes. Or manually.
+When +- [ ] Add https://netcup.armbian.com/partial/ to stable repo
+is selected.
+(Workflow takes around 60 minutes to complete)
+Generates all build artifacts cache for targets defined in targets-all-not-eos.yaml. This build job runs every 8 hours and can also be run manually when needed.
+This build job needs to be successfully completed in order to proceed generating any OS images!
+Generates all nighly (Rolling Release) images defined in targets-release-nightly.yaml. This file is autogenerated from targets-release-nightly.template.
+This build job runs every day at 9 a.m. UTC and can also be run manually when needed. Download pages are refreshed automatically after successful build.
+ +Runs every 15 minutes and re-trigger failed builds six (6) times before finally gives out. This addresses various instabilities when building many artifacts on different hardware:
+Smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Our test case is constructed of three steps:
+ +Automatically label new pull request based on the paths of files which are being changed. Configuration file can be found in:
+Text Only | |
---|---|
1 |
|
Generates all supported build combinations (minimal, cli, desktops) for x86 architecture to check package level changes inconsistency and dependencies.
+Options:
+Generates artifacts at Pull Requests code. Build starts when label of Pull Request is set to “Build”. Requires administration privileges.
+Run ShellCheck on changed shell scripts and report problems within. Linting runs automatically on pull requests.
+Some of our scripts download tools from a repo. These cannot be bumped by Dependabot, so this workflow is a self-created Dependabot to bump versions of those tools to stay up-to-date. This workflow only creates a PR if the version was actually updated. To add a new tool, it just needs to be added to the matrix in the script by filling out all the variables.
+Scorecards is an automated tool that assesses a number of important heuristics (“checks”) associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.
+This analysis checks kernel configs and run if changed. There are plenty of security hardening options for the Linux kernel. A lot of them are not enabled by the major distros. We have to enable these options ourselves to make our systems more secure.
+ + + + + + + + + + + + + + + +If it is a new feature request, do not start the coding first. Remember to open an issue to discuss the new feature. If you want to add code to someone else pull request. Also check collection of git tips which will make your life easier.
+If you are struggling, check WEB or CLI step-by-step guide on contributing.
+There are no detailed instructions on how to add a new board or even a whole new board family to the build script yet. However there are a few commits / pull requests that give clues how to achieve that like
+If you are interested in being a maintainer please review Board Support Rules. Then apply here and wait for acceptance. Once accepted you will be added to our infrastructure. For this reason we need additional information to complete your registration process.
+Requirements?
+Maintainers must not necessarily be persons with development experience. They act as a intersection between end-users and the development team and serve the developers in best-effort manner. They are encouraged to answer basic/simple user questions (if possible, also best effort) without having to bother the development team. They are allowed to record bugs but are not allowed to escalate bugs. Team leaders do.
+Take note that it is still up to development team’s discretion what gets attention since Armbian has to plan carefully how to spend its very limited resources.
+What are we looking for?
+If something does not work, this is fine and normal. The important part is that it is documented and we get notified about the issues. Known problems should be placed into the Jira ticket and link placed to the board download page. While not required, you should have a build environment setup so you can build images with the most recent images and test them right away. Your feedback, either positive or negative, is very welcome. You are free to add comments to every commit and pull request.
+Ideally you have multiple microSD cards laying around to test regular updates on current releases and nightly without having to re-flash the same card every time to switch between branches.
+Alternatively you can use auto-built images - they are placed at the ever end of each board download pages under “Rolling releases”.
+This role has additional permission that allows preparation of images for release.
+Release managers: +https://github.com/orgs/armbian/teams/release-manager
+ + + + + + + + + + + + + + + +Jira where development work is entered and prioritized. https://armbian.atlassian.net/
+When creating issues, try to assign issue type most appropriate. Issue type can be changed later so don’t worry too much. If possible assign to a “Fix Version” aka Release.
+The easiest way to follow the work queue Upcoming Release Kanban Board. This board lists only work select for the upcoming release.
+ +Use the filter buttons at top to quickly see unassigned work, work assigned to you, bugs, and work recently updated.
+Work is listed in 3 columns, and sorted by priority.
+Columns: +* Todo + * Work prioritized to be done next + * Pick up any task from this column +* In Progress + * Work In Progress +* Done + * Shows recently completed work. Has time limit to keep board clean
+All issues for an upcoming release are assigned a “Fix Version” to indicate release number.
+With the Kanban Board, there are 2 states for the Upcoming Release backlog.
+All issues for an upcoming release are assigned a “Fix Version” to indicate release number.
+Armbian provides automated daily rolling releases of small selection of images for all supported targets. Images are available at respective board download pages: https://www.armbian.com/download. Armbian also populates its own packages repository so updates are available as an upgrade for existing installations.
+Armbian runs “train” based point releases. Whatever is ready to board the train, does so. Whatever is not has to wait for the next train. This enables us to have a predictable release cycles making it easy to plan. It also puts the responsibility on developers to make sure they have features ready on time.
+Armbian releases quarterly at the end of February, May, August, November. Offset is because we all know that nothing happens for half of December. At the beginning of a release cycle, we have a planning meeting and two weeks before the end of the release we freeze integration of new features.
+Releases last three months. Each release starts with a meeting for planning. After planning, developers and development teams build their deliverable using whatever methods (scrum, kanban, waterfall, … ) they want but shall commit their code frequently, leading up to the last 2 weeks. The project does not accept “dumps” of code at the end. Commit early and often on master. Two weeks before the release date, we halt feature integration and only allow bug fixes. At some point during those two weeks, we start the release candidate process. This process starts by pulling a branch off master that will become the release branch. That frees up master for development on the next release. On the release candidate branch we work on bug fixes, and choose “release candidate”, RC, tags. The software at that tag is a candidate for release, and it is submitted to automated and manual tests on real hardware. If automated tests are passing, we can officially tag it as the release. If it does not, we enter another bug fix cycle and create a new release candidate. We iterate until we have a candidate that can be the formal release. Usually, this takes 2-3 cycles and 1-3 weeks of time.
+Development epics, stories and bugs for each release are tracked through Jira.
+Branches in Armbian follow this convention:
+main
branch. This is the latest and greatest branch, but is always “stable” and “deployable”. All tests always pass on this branch.Each Armbian release will have the following version format:
+Format: <major>.<minor>.<revision>
<major>
and <minor>
version are incremented at the end of the release cycles while <revision>
is incremented for a fix.
version | +codename | +release month | +work | +
---|---|---|---|
19.11 | +Vaquita | +November | +done | +
20.02 | +Chiru | +February | +done | +
20.05 | +Kagu | +May | +done | +
20.08 | +Caple | +August | +done | +
20.11 | +Tamandua | +November | +done | +
21.02 | +Urubu | +February | +done | +
21.05 | +Jerboa | +May | +done | +
21.08 | +Caracal | +August | +done | +
21.11 | +Sambar | +November | +cancelled | +
22.02 | +Pig | +February | +done | +
22.05 | +Jade | +May | +done | +
22.08 | +Yapok | +August | +done | +
22.11 | +Goral | +November | +done | +
23.02 | +Quoll | +February | +done | +
23.05 | +Suni | +May | +done | +
23.08 | +Colobus | +August | +done | +
23.11 | +Topi | +November | +done | +
24.02 | +Kereru | +February | +done | +
24.05 | +Havier | +May | +done | +
24.08 | +Yelt | +August | +done | +
24.11 | +Stirk | +November | +planned | +
25.02 | +Iiwi | +February | +planned | +
25.05 | +Caiman | +May | +planned | +
25.08 | +Dunnart | +August | +planned | +
25.11 | +Brach | +November | +planned | +
26.02 | +Goa | +February | +planned | +
by https://www.codenamegenerator.com from unusual animals
+ + +A release starts as a RC branch cut from main
at freeze time. Once a RC branch is cut, main
can be unfrozen and development can continue. RC branch is a rolling release that accepts bug fixes. The bug fixes should be cherry-picked back to main
branch. Once the RC is stable, a final release as a branch named after its version. A release is never merged to main
. Once a release is complete, it only should be updated for severe bugs and security vulnerabilities. A release is only maintained until the next release.
Armbian 24.02 (Kereru) Release Thread
version-rc
ex: v20.02.0-rc
main
branch version to the NEXT release version with -trunk
ex. If RC is v20.02.0-rc main
becomes v20.05.0-trunkArmbian Linux provides optimized Debian and Ubuntu Linux images for ARM-based SBCs. There is an incredible ecosystem of small computing platforms that are powerful alternatives to the Raspberry Pi. Armbian’s mission is to provide a uniform system offering that is trustworthy to run on any of the dozens of OS-neglected ARM single board computers.
+Raspbian has dozens of contributors to focus on a single SBC platform. Armbian has a dozen contributors to focus on 100+ SBCs spread over 30 platforms.
+Given the point above, resources are thin. Armbian developers have to focus on the core mission of maintaining the Armbian Build Platform. We heavily rely on other members of the community to support each other. Although Armbian does provide a lot of user friendly features, the reality is that Armbian is for more advanced users. If you are really struggling with your SBC, you may want to consider first getting more comfortable with Raspbian Linux on the Raspberry Pi.
+SBC and TV Box manufacturers love to design and ship new products. Unfortunately they do not like to spend time on software and instead rely on community projects such as Armbian to fill in the gaps.
+BASH or ZSH shell, standard Debian/Ubuntu utilities. Common and specific features can be with minimalistic menu-driven utility. Login is possible via serial, HDMI/VGA or SSH.
+No bloatware or spyware. Special utilities are completely optional. Suitable for newcomers and professionals.
+A distributed image is compacted to real data size and starts at around of 1G. Size is optimized for SD card usage. Bigger is better. Installing applications later severely reduces the life of your SD card. They were not designed for this type of usage.
+Boards are optimized on kernel and userspace level. DVFS optimization, memory log caching, browser profile memory caching, swap usage tuning, garbage commit delay. Our system runs almost read-only and is one of the the fastest Linux for many development boards in just about every case.
+Security level is on a stock Debian/Ubuntu level and can be hardened with the configuration utility. It provides a good starting point for industrial or home usage. The system is regularly inspected by professionals within the community. Each official stable build is thoroughly tested. Images are a direct base for all 3rd party builders.
+Providing long term updates, security fixes, documentation, user support.
+Deep understanding how boards work, how operating system work and how hardware should be designed to run better. Involved in board design. Experience in Linux since early 90’. Specialized in ARM development boards since 2013.
+Open source build script and kernel development, maintenance and distribution for more than 30 different ARM and ARM64 Linux kernels. Powerful build and software development tools. Can run in fully parallel mode. Can run under Docker.
+ + + + + + + + + + + + + + + +If you are interested in being a maintainer please review Board Support Rules. Then apply here and wait for acceptance. Once accepted you will be added to our infrastruture. For this reason we need additional information to complete your registration process.
+Requirements?
+Maintainers must not necessarily be persons with development experience. They act as a intersection between end-users and the development team and serve the developers in best-effort manner. They are encouraged to answer basic/simple user questions (if possible, also best effort) without having to bother the development team. They are allowed to record bugs but are not allowed to escalate bugs. Team leaders do.
+Take note that it is still up to development team’s discretion what gets attention since Armbian has to plan carefully how to spend its very limited resources.
+What are we looking for?
+If something does not work, this is fine and normal. The important part is that it is documented and we get notified about the issues. Known problems should be placed into the Jira ticket and link placed to the board download page. While not required, you should have a build environment setup so you can build images with the most recent images and test them right away. Your feedback, either positive or negative, is very welcome. You are free to add comments to every commit and pull request.
+Ideally you have multiple microSD cards laying around to test regular updates on current releases and nightly without having to re-flash the same card every time to switch between branches.
+Alternatively you can use auto-built images - they are placed at the ever end of each board download pages under “Rolling releases”.
+6.1-rkr3
: sync FriendlyElec’s DTs from vendor (common, R6S, R6C, T6, CM3588) + add T6-LTS DT by @rpardini in armbian/linux-rockchip!209BPI-M4-Zero
updates, fixups and rev2 support by @pyavitz in armbian/build!7317sun50i-h616-light
dt overlay fix to 6.10 by @JohnTheCoolingFan in armbian/build!7204curl
with --fail
flag so server 400/500 errors actually trigger a retry by @rpardini in armbian/build!7487Fixup U-Boot and Linux DTS/DTSI and add WiFi / BT overlay
by @pyavitz in armbian/build!7332Improve support
by @pyavitz in armbian/build!7355improve SDIO WiFi speeds
by @pyavitz in armbian/build!7193BOOTPATCHDIR
and bump to 2024.10 by @ColorfulRhino in armbian/build!7377lib/tools/shellfmt.sh
by @github-actions in armbian/build!7255lib/tools/shellfmt.sh
by @github-actions in armbian/build!7433WIREGUARD
once and for all by @EvilOlaf in armbian/build!7452iostat
error on MINIMAL
by @EvilOlaf in armbian/build!7454sun50i-h616-light
device tree overlay by @JohnTheCoolingFan in armbian/build!7183update to u-boot-v2024.07
by @pyavitz in armbian/build!7328CONFIG_KPROBES
by @rpardini in armbian/build!7162CONFIG_INPUT_PWM_BEEPER=m
by @rpardini in armbian/build!7167dt
folder overwrite pre-existing files (DTs that landed upstream) by @rpardini in armbian/build!72710001-general-add-overlay-support.patch
by @rpardini in armbian/build!7240<&fan>
alias for device tree by @alexl83 in armbian/build!7151wip/sc8280xp-6.11
(final) from -rc5 by @rpardini in armbian/build!7260Userspace
Switching armbian-config to new generation. by @igorpecovnik in armbian/build!7189Userspace
: UX changes at MOTD and first login by @igorpecovnik in armbian/build!7174current
branch (6.8) by @ColorfulRhinoadd_host_dependencies
by @rpardinii2c8-m2
overlay by @rpardinicurrent
kernel branch for some boards by @ColorfulRhinoNETWORKING_STACK
to control network exts; allow “none”; fix typo by @rpardinidts-check
command and use Pip for some Python packages instead of APT by @ColorfulRhinoorphan_file
(FEATURE_C12
) for ext4 filesystems on 1.47+ e2fsprogs host by @rpardiniTask
template for project management by @ColorfulRhinocsc
status by @rpardini#
prefix by @ColorfulRhinofw version 0xb5d66dcb
by @pyavitz-u
: rationalize paste server retrying, use ANSI dmesg by @rpardinimedia
boards into the rockchip64
family by @ColorfulRhinoBOARDFAMILY
rk322x
(now integrated into the rockchip
family) by @ColorfulRhinopackages/extras-buildpkgs
by @ColorfulRhinoedge
branch (6.9.y) by picking DT from linux-rockchip#for-next & using Kwiboo’s 24.07 u-boot by @rpardiniwireless at firstlogin script
by @igorpecovnikpipetty
in place of unbuffer
by @rpardinis5p6818
board family by @ColorfulRhinonext-dev-v2024.03
by @rpardinilegacy
kernel target from board configs by @ColorfulRhinolegacy
kernel 4.4 support by @ColorfulRhinofixups
by @pyavitzNETWORKING_STACK
in main config and add armhf support to Trixie by @ColorfulRhinoshellfmt
and add board configs to formatting list by @ColorfulRhinowip/sc8280xp-6.10-rc6
; add fprintd back to Trixie; fixes by @rpardiniu-boot-radxa-rk35xx
scheme by @rpardiniu-boot-radxa-rk35xx
scheme by @rpardinicommit
mount option for btrfs and ext4 to 120 by @ColorfulRhinolegacy
4.19 to current
6.6 kernel by @ColorfulRhinowip/sc8280xp-6.10-rc7
by @rpardini6.10-rc7
by @rpardiniBump u-boot to v2024.07
by @pyavitzupdate to BL v1.0.8
by @pyavitzuboot_cflags
variable to before its first use by @ColorfulRhinoFixups
by @pyavitzlib/functions/general/shellcheck.sh
by @github-actionslib/functions/general/oci-oras.sh
by @github-actionslib/functions/general/bat-cat.sh
by @github-actionsHOME
to be set (fixes download-artifact
) by @rpardiniwrite_uboot_platform
: eMMC Support by @pyavitzuse actual u-boot.bin
by @pyavitzdrv-spi-spidev-remove-warnings.patch
by @alexl83drv-spi-spidev-remove-warnings.patch
by @alexl83CONFIG_SECURITY_DMESG_RESTRICT
kernel option by @alexl83build@armbian
for kernel builds by @ColorfulRhinoedge
kernel from 6.10 to 6.11-rc and current
from 6.8 to 6.10 by @efectnCONFIG_SECURITY_DMESG_RESTRICT
kernel option by @alexl83rfkill-bt
device node to Radxa Rock-5B by @alexl83remove fan control
by @pyavitzRe-brand as Amper & update u-boot to v2024.04
by @pyavitzSolved Bugs
+Updated images for Orangepi Zero
+Solved Bugs
+ +Solved Bugs
+Closed Tasks
+ZFS updated to v2.0.4 (tested on 32bit Odroid HC1 and 64bit N2, Focal and Bionic userland) +Added Hirsute CLI images with EDGE Linux 5.12.y for most of the boards
+Solved Bugs
+Finished projects
+Closed Tasks
+Added Nvidia Jetson Nano (community supported target)
+Rebuild images for Odroid N2, H4, HC4
+All kernels received upstream updates
+All images has been rebuilt
+Fixed reboot troubles on meson64 family (Odroid N2, C2, H4, HC4)
+ZSH upgrade fixed
+Type-C DP support for the NanoPC T4
+Allwinner a20 fail to init hdmi in many cases / fixed (all images need to be rebuilt)
+All kernels received upstream updates
+Finished projects
+Solved bugs
+Closed task
+All images rebuild due to torrent system corruption
+Broken Nanopi Neo buster image rebuild, adding Station M1 and P1 legacy images, Odroid XU4 update
+all images were rebuilt - we had a few corrupted ones in previous build
+AR-566 - Add Nanopi R4S preview images
+Bugfix release
+Finished projects
+Solved bugs
+Closed tasks
+Added WIP images for Odroid HC4 +Updated images for Odroid C4, N2, C2, Lafrite, Lepotato, KVIM1
+Known bugs:
+Finished projects
+Solved bugs
+Closed tasks
+never released/skipped
+Kagu
+Finished projects
+Solved bugs
+Closed tasks
+Chiru
+Tasks
+Bugs
+Stories
+ +Tasks
+Bugs
+Stories
+Build script:
+Armbian-config:
+Build script:
+Armbian-config:
+Build script:
+Armbian-config:
+Infrastructure:
+Changes overview:
+General:
+vm.swappiness
has been changed from 0 to 100 (if you run databases on your board you might want to revert this change in /etc/sysctl.conf
),Family:
+Board:
+Build script:
+Infrastructure:
+Known bugs:
+linux-source-${BRANCH}-${LINUXFAMILY}
, i.e. linux-source-sunxi-next
)Desktop images:
+armbian-config:
+armbian-config
Build script:
+End of support notice
+Following boards are no longer receiving support and updates since this version:
+armbian-add-overlay
helper for compiling and activating DT overlays (new images only)/var/log
contents on shutdown/etc/default/armbian-motd
for disabling MOTD componentsarmbian-config
dialog-based configuration program (WIP)End of support notice
+Following boards are no longer receiving support and updates since this version:
+Known problems:
+sun7i-a20-bananapi-m1-plus.dtb
, boot script adjusting may be required for existing imagesDesktop images:
+Build script:
+LD_LIBRARY_PATH
Known problems:
+Desktop images:
+VDPAU_OSD=1
Build script:
+Added additional packages, not installed by default:
+Known problems:
+u-boot
and armbian-install.sh
fixes)Images:
+Build script:
+Known bugs:
+sudo armbianmonitor -b
)sudo h3disp
in a terminal to get the idea.and a bunch of small fixes.
+Images:
+Script:
+Images:
+Build script:
+Bash | |
---|---|
Install kernel headers:
+Text Only | |
---|---|
1 |
|
Download driver sources:
+Text Only | |
---|---|
1 +2 |
|
Build and install:
+Text Only | |
---|---|
1 +2 |
|
Text Only | |
---|---|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 + 64 + 65 + 66 + 67 + 68 + 69 + 70 + 71 + 72 + 73 + 74 + 75 + 76 + 77 + 78 + 79 + 80 + 81 + 82 + 83 + 84 + 85 + 86 + 87 + 88 + 89 + 90 + 91 + 92 + 93 + 94 + 95 + 96 + 97 + 98 + 99 +100 +101 +102 +103 +104 +105 +106 +107 +108 +109 +110 +111 +112 +113 +114 +115 +116 +117 +118 +119 +120 +121 +122 +123 +124 +125 +126 +127 +128 +129 +130 +131 +132 +133 +134 +135 +136 +137 +138 +139 +140 +141 +142 +143 +144 +145 +146 +147 +148 +149 +150 +151 +152 +153 +154 +155 +156 +157 +158 +159 +160 +161 +162 +163 +164 |
|
Load driver for test
+Text Only | |
---|---|
1 |
|
Check dmesg
and the last entry will be:
Text Only | |
---|---|
1 |
|
Plug the USB wireless adaptor and proceed with network configuration
+Minimal:
+Bash | |
---|---|
Full featured:
+Bash | |
---|---|
Test if Docker works correctly:
+Bash | |
---|---|
If you get that kind of output, then Docker install went fine:
+ + + + + + + + + + + + + + + + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+graph LR
+ A[Network] --> B[Add / Change interface];
+ A[Network] --> O[Revert to defaults];
+ A[Network] --> P[Show configuration];
+ B ---->E[Wired];
+ B ---->F[Wireless];
+ E -->R[DHCP];
+ E -->T[Static];
+ E -->S[Spoof MAC];
+ F -->X[Station];
+ F -->W[Access point];
+
+
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +In order to configure your network devices, they need to be supported the kernel.
+To verify, use command:
+Bash | |
---|---|
It is usually something like eth0, enp4s3 or lan.
+In order to configure your wireless network devices, they need to be supported the kernel.
+To verify, use command:
+Bash | |
---|---|
It is usually something like wlan0
, wlo1
or wlx12334c47dec3
. If you get blank response, it means your WiFi device / dongle is not supported by the kernel.
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Switching between kernels might change functionality of your device.
+It might fail to boot!
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @viraniac @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author:
+Status: Preview
+This will open /boot/armbianEnv.txt file to edit +CTRL+S to save +CTLR+X to exit +would you like to continue?
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Preview
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+This will enable Armbian read-only filesystem. Reboot is mandatory?
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+This will disable Armbian read-only filesystem. Reboot is mandatory?
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+This will switch system wide shell to BASH
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+This will switch system wide shell to ZSH
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Status: Active
+This will enable Armbian kernel upgrades that are currently put on hold.
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Disable Armbian kernel/firmware upgrades
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+This will switch OS to rolling releases.
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+This will switch OS to stable releases
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+flowchart LR
+ A[armbian-config] -----> B["System"];
+ A[armbian-config] -----> C["Network"];
+ A[armbian-config] -----> D["Localistation"];
+ A[armbian-config] -----> E["Software"];
+ A[armbian-config] -----> F["Help"];
+
+Utility for configuring your board, adjusting services, and installing applications. It comes with Armbian by default.
+To start the Armbian configuration utility, use the following command: +
Text Only | |
---|---|
Please check example of adding a new software title. Principle is the same.
+ + + + + + + + + + + + + + + +This operation will install Docker Minimal.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+ +What is Docker? Docker helps developers build, share, run, and verify applications anywhere - without tedious environment configuration or management.
+ + +This operation will install Docker Engine.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+This operation will purge Docker.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+This operation will delete all Docker images, containers, and volumes.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+Portainer simplifies your Docker container management via Portainer web interface. It enables faster deploy of the applications and it gives real time visibility.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 9002:
+http://<your.IP>:9002
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Watchtower is an application that will monitor your running Docker containers and watch for changes to the images that those containers were originally started from. If watchtower detects that an image has changed, it will automatically restart the container using the new image.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +Every day watchtower will pull the latest images and compare it to the one that was used to run the certain container. If it sees that the image has changed it will stop/remove containers and then restart it using the new image and the same docker run options that were used to start the container initially.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Pi-hole is a DNS sinkhole with web interface that will block ads for any device on your network.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface of Pi-hole can be accessed via:
+http://<your.IP>/admin
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+The Qbittorrent project aims to provide an open-source software alternative to µTorrent. qBittorrent is based on the Qt toolkit and libtorrent-rasterbar library.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8090:
+https://<your.IP>:8090
/armbian/qbittorrent
/armbian/qbittorrent/config
/armbian/qbittorrent/downloads
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Deluge is a lightweight, Free Software, cross-platform BitTorrent client.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8112:
+https://<your.IP>:8112
/armbian/deluge
/armbian/deluge/config
/armbian/deluge/downloads
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Transmission is designed for easy, powerful use. Transmission has the features you want from a BitTorrent client: encryption, a web interface, peer exchange, magnet links, DHT, µTP, UPnP and NAT-PMP port forwarding, webseed support, watch directories, tracker editing, global and per-torrent speed limits, and more.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 9091:
+https://<your.IP>:9091
/armbian/transmission
/armbian/transmission/config
/armbian/transmission/downloads
/armbian/transmission/watch
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Sabnzbd makes Usenet as simple and streamlined as possible by automating everything we can. All you have to do is add an .nzb. SABnzbd takes over from there, where it will be automatically downloaded, verified, repaired, extracted and filed away with zero human interaction.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8080:
+https://<your.IP>:8080
/armbian/sabnzbd
/armbian/sabnzbd/config
/armbian/sabnzbd/downloads
/armbian/sabnzbd/incomplete
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Medusa is an automatic Video Library Manager for TV Shows. It watches for new episodes of your favorite shows, and when they are posted it does its magic.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8081:
+https://<your.IP>:8081
/armbian/medusa
/armbian/medusa/config
/armbian/medusa/downloads
/armbian/medusa/downloads/tv
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Sonarr (formerly NZBdrone) is a PVR for usenet and bittorrent users. It can monitor multiple RSS feeds for new episodes of your favorite shows and will grab, sort and rename them. It can also be configured to automatically upgrade the quality of files already downloaded when a better quality format becomes available.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8989:
+https://<your.IP>:8989
/armbian/sonarr
/armbian/sonarr/config
/armbian/sonarr/tvseries
/armbian/sonarr/client
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Radarr - A fork of Sonarr to work with movies à la Couchpotato.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 7878:
+https://<your.IP>:7878
/armbian/radarr
/armbian/radarr/config
/armbian/radarr/movies
/armbian/radarr/client
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Bazarr is a companion application to Sonarr and Radarr. It can manage and download subtitles based on your requirements. You define your preferences by TV show or movie and Bazarr takes care of everything for you.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 6767:
+https://<your.IP>:6767
/armbian/bazarr
/armbian/bazarr/config
/armbian/bazarr/movies
/armbian/bazarr/tv
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Lidarr is a music collection manager for Usenet and BitTorrent users. It can monitor multiple RSS feeds for new tracks from your favorite artists and will grab, sort and rename them. It can also be configured to automatically upgrade the quality of files already downloaded when a better quality format becomes available.
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8686:
+https://<your.IP>:8686
/armbian/lidarr
/armbian/lidarr/config
/armbian/lidarr/downloads
/armbian/lidarr/music
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Readarr - Book Manager and Automation (Sonarr for Ebooks)
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8787:
+https://<your.IP>:8787
/armbian/readarr
/armbian/readarr/config
/armbian/readarr/books
/armbian/readarr/client
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Prowlarr is a indexer manager/proxy built on the popular arr .net/reactjs base stack to integrate with your various PVR apps. Prowlarr supports both Torrent Trackers and Usenet Indexers. It integrates seamlessly with Sonarr, Radarr, Lidarr, and Readarr offering complete management of your indexers with no per app Indexer setup required (we do it all).
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 9696:
+https://<your.IP>:9696
/armbian/prowlarr
/armbian/prowlarr/config
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Jellyseerr is a free and open source software application for managing requests for your media library. It is a fork of Overseerr built to bring support for Jellyfin & Emby media servers!
+ + +Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+ +The web interface is accessible via port 8444:
+https://<your.IP>:8444
/usr/share/openhab
/etc/openhab
/etc/default/openhab
/var/lib/openhab
See also openHAB file locations.
+Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Home Assistant is an open source smart home platform that allows you to connect your smart home devices like your TV, fan, cameras, thermostats, lights, and sensors. As a user, you can build intricate automation using Home Assistant’s user-friendly, unified web-based user interface.
+Perfect to run on any single board computer with 4 cores and at least 512Mb of memory. Armbian installation is optimised to run from SD/eMMC media, but it is recommended to use SSD.
+The web interface is accessible via port 8123:
+https://<your.IP>:8123
Home Assistant on Armbian runs supervised in a Docker container. This secures same functionality as stock HAOS.
+/usr/share/haos
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Preview
+ +Functionality | +HAOS | +Armbian with HA | +
---|---|---|
Automations | ++ | + |
Dashboards | ++ | + |
Integrations | ++ | + |
Add-ons | ++ | + |
One-click updates | ++ | + |
Backups | ++ | + |
General purpose server | ++ | + |
Running on exotic hardware | ++ | + |
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Preview
+This operation will install Cockpit. +cockpit cockpit-ws cockpit-system cockpit-storaged
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+ +Introducing Cockpit +Cockpit is a web-based graphical interface for servers, intended for everyone, especially those who are:
+Thanks to Cockpit intentionally using system APIs and commands, a whole team of admins can manage a system in the way they prefer, including the command line and utilities right alongside Cockpit.
+ + +This operation will purge Cockpit.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @Tearran
+Status: Stable
+ +The web interface is accessible via port 10000:
+https://<your.IP>:10000
This operation will install Plex Media server.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+This operation will purge Plex Media server.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+This operation will install Emby server.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+This operation will purge Emby server.
+Command: +
Text Only | |
---|---|
Author: @schwar3kat
+Status: Stable
+Stirling-PDF is a robust, locally hosted web-based PDF manipulation tool using Docker. It enables you to carry out various operations on PDF files, including splitting, merging, converting, reorganizing, adding images, rotating, compressing, and more. This locally hosted web application has evolved to encompass a comprehensive set of features, addressing all your PDF requirements.
+ + +Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +The web interface is accessible via port 8077:
+https://<your.IP>:8077
/armbian/stirling
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Syncthing replaces proprietary sync and cloud services with something open, trustworthy and decentralized. Your data is your data alone and you deserve to choose where it is stored, if it is shared with some third party and how it’s transmitted over the Internet.
+ + +Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +The web interface is accessible via port 8884:
+https://<your.IP>:8884
/armbian/syncthing
/armbian/syncthing/config
/armbian/syncthing/data1
/armbian/syncthing/data2
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Nextcloud gives you access to all your files wherever you are.
+
+Where are your photos and documents? With Nextcloud you pick a server of your choice, at home, in a data center or at a provider. And that is where your files will be. Nextcloud runs on that server, protecting your data and giving you access from your desktop or mobile devices. Through Nextcloud you also access, sync and share your existing data on that FTP drive at the office, a Dropbox or a NAS you have at home.
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +The web interface is accessible via port 443:
+https://<your.IP>:443
/armbian/nextcloud
/armbian/nextcloud/config
/armbian/nextcloud/data
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ownCloud is a free and open-source software project for content collaboration and sharing and syncing of files in distributed and federated enterprise scenarios.
+ + +Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +The web interface is accessible via port 7787:
+http://<your.IP>:7787
/armbian/owncloud
/armbian/owncloud/config
/armbian/owncloud/data
Bash | |
---|---|
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+ +The web interface is accessible via port 3001:
+https://<your.IP>:3001
Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Netdata is a partially open source tool designed to collect real-time metrics, such as CPU usage, disk activity, bandwidth usage, website visits, etc., and then display them in live, easy-to-interpret charts.
+ + +Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @igorpecovnik
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+Command: +
Text Only | |
---|---|
Author: @armbian
+Status: Stable
+flowchart LR
+ A[Software] ----> B["Containerlization"];
+ A[Software] ----> C["Desktops"];
+ A[Software] -----> D["DNS blockers"];
+ A[Software] -----> E["Home Automation"];
+ A[Software] ------> F["Monitoring"];
+ A[Software] ------> G["Development"];
+ A[Software] ------> J["Network tools"];
+ A[Software] ----------> H["Remote Management tools"];
+ A[Software] ----------> I["Media Servers"];
+To start the Armbian software section, use the following command and choose software
section:
+
Text Only | |
---|---|
First try to install application manually. If it works on Debian or Ubuntu, proceed. In this example we will be using test
.
Text Only | |
---|---|
Predict which commands you expect to have in the menu. For installing an application, we usually need two, install
and uninstall
. Armbian-config stores menu in JSON files, so you need to select appropriate file.
+This one we will place under Software -> Management
.
File location: tools/json/config.software.json | |
---|---|
Field name | +Function | +Notes | +
---|---|---|
id |
+unique identifier |
+Select higher number. If you will select existing, application will fail to run | +
description |
+menu descriptor |
+This will be displayed in the menu | +
prompt |
+confirmation text |
+Some features needs confirmation before proceeding | +
command |
+executes function |
+What should be run after we select and agree (optional) | +
status |
+Stable|Disabled |
+Control if function is shown to users in the menu | +
author |
+GitHub handle |
+Developer or maintainer of this functionality | +
condition |
+controlling display |
+Under what conditions we show this menu item | +
Note
+Pay attention to JSON structure. JSON validator at pull request will break in case spaces or commas will be placed wrong.
+Place module functions, each into its file, following by file naming convention, into one of the folders:
+ +Note
+Pay attention to coding style structure. If you use modern IDE, this will be done automatically.
+Whenever you are making changes to the JSON or modules structure, make sure to join JSON segments into main JSON file and fun. This you do with a command: +
Python | |
---|---|
Bash | |
---|---|
This part is optional but highly recommended for at least install functionality. Our CI infrastructure will test this feature at pull request, on general code changes (push to main branch) and daily. It will test feature on latest Debian and Ubuntu images. +Unit tests have simple design:
+Name of the config file is function id (unique identifier) CON004.conf
File location: tests/CON004.conf | |
---|---|
Variable | +Function | +Description | +
---|---|---|
ENABLED | +false / true | +If test is live or not | +
PREINSTALL | +cmd to run | +specific test dependencies | +
CONDITION | +main test verification | +must return 0 for test success | +
RELEASE | +bookworm:jammy:noble” | +run on specific or leave empty to run on all | +
When your solution works locally and you prepare unit tests its time to submit a pull request. Fix your code and unit tests until all pull request checks becomes green.
+Examples:
+ +Documentation is generated automatically after your pull request is merged. But as automated documentation might not be satisfactory, you can add cover image, header and footer. You can use markdown elements with enhancements from https://squidfunk.github.io/mkdocs-material/
+Once code works perfectly, look for cover image. It can be .png or .webp. Place image to the tools/include/images/CON004.webp
Header: tools/include/markdown/CON004-header.md | |
---|---|
Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, UART, …) don’t have a mechanism for detecting and identifying devices connected to the bus, +so Linux kernel has to be told explicitly about the device and its configuration details.
+While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT +in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
+Note: from the Linux kernel maintainer perspective all unused in-circuit type interfaces that use GPIO pins should be disabled by default and all pins on pin headers or soldering pads will be configured as standard GPIOs.
+Note: from the Linux kernel maintainer perspective all dedicated interfaces like USB, Ethernet or analog audio that are wired to soldering pads or a pin headers instead of specialized sockets (like USB socket, Ethernet socket or 3.5mm jack) will be left disabled by default.
+README.<soc-id>-overlays
in /boot/dtb/overlay/
(32-bit SoCs) or /boot/dtb/allwinner/overlay/
(64-bit SoCs) for a list of provided overlays, their required and optional parametersoverlays=
line in /boot/armbianEnv.txt
, separated with spaces/boot/armbianEnv.txt
, one per line/boot/armbianEnv.txt
if you want to change the default value, one per line.dts
extension) on the devicecompatible
string to match your SoC if necessaryarmbian-add-overlay <overlay_file.dts>
as root, i.e. sudo armbian-add-overlay sht15.dts
overlay_prefix
- prefix for the DT and overlay file names, set at OS image creation timeoverlays
- list of overlays to activate from kernel directoryuser_overlays
- list of overlays to activate from /boot/overlay-user/
directoryparam_*
- overlay parametersOverlays can be loaded from 2 locations:
+/boot/dtb/overlay/
(/boot/dtb/allwinner/overlay/
for 64-bit SoCs) - kernel provided overlays/boot/overlay-user/
- user provided overlaysMain differences between these locations:
+<prefix>-<name>
, for example sun8i-h3-i2c0.dtbo
, where sun8i-h3
is the prefix and i2c0
is the namei2c0
), and the prefix is set at OS image creation timeadafruit13m.dtbo
overlay name would be adafruit13m
DT overlays are activated by editing u-boot environment file /boot/armbianEnv.txt
overlays
variableuser_overlays
variableoverlays
line and one user_overlays
line can be present in the environment fileSome overlays have additional parameters that can be set.
+Parameters marked as “Required” have to be set if overlay with these parameters is activated, other parameters are not mandatory if default value is suitable.
+Parameters are set by adding their name and value to /boot/armbianEnv.txt
, each parameter should be added on a new line.
Please refer to README.<SoC_prefix>-overlays
files in /boot/dtb/overlay/
(/boot/dtb/allwinner/overlay/
for 64-bit SoCs) directory for supported parameters, i.e. README.sun8i-h3-overlays
for H3 based boards.
Parameters of type pin
require special format:
P
, a letter that signifies the pin bank and a number of the pin in the bankPA9
, PG12
; bad - pa2
, PG08
SoCs may contain multiple bus controllers of the same type, i.e. Allwinner H3 contains 2 SPI controllers and Allwinner A20 contains 4 SPI controllers.
+Please refer to your board documentation and schematic to determine what pins are wired to the pin headers and thus what bus number should be used in each case.
+Some controllers may share the SoC pins in some configurations. For example on Allwinner H3 UART 3 and SPI 1 use the same pins - PA13
, PA14
, PA15
, PA16
.
+In this case activating both UART 3 and SPI 1 would result in a conflict, and on practice only one interface (either SPI or UART) will be accessible on these pins.
Please check the SoC specific README, board schematic, SoC datasheet or other documentation if you are unsure about possible conflicts if activating multiple overlays for the controllers that use shared (muxed) pins.
+Overlays for devices that use addresses or similar mechanisms (i.e. SPI chip selects) can’t be activated simultaneously if addresses (chip selects) are identical.
+For example A20 SPI controller 1 has only one hardware chip select, so spi-spidev
and spi-jedec-nor
overlays cannot be activated both if they would use the same bus number and chip select.
Device Tree overlays for different platforms and SoCs are not directly compatible. +This, for example, means that overlays for H3 may need some changes to work on A20, and that Raspberry Pi overlays will need adjustments in order to be used on Allwinner based boards.
+Rework may include changing labels, references (phandles) and pinconf bindings.
+Activating a device on SPI or I2S bus may require more than one overlay.
+In case a bus overlay like spi0
or i2s0
exist for the target SoC they need to be activated in addition to a slave device overlay (provided or custom/user-made).
+Please note that these overlays (spi0
, i2s0
) do not enable any slave devices (like spidev or I2S codec).
+In some cases it might be necessary to change param_spidev_spi_bus
to 1
.
As overlays and overlay parameters are applied by the u-boot, it is impossible to get any debugging information (such as error messages) from the OS.
+Serial console on UART 0 is required to debug DT overlay related problems.
+/boot/armbianEnv.txt
contents:¶Text Only | |
---|---|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 |
|
Text Only | |
---|---|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 |
|
It is possible to configure your device automatically at first boot. Settings like: root password, IP address, connecting to wireless.
+After flashing an image to boot media, mount it and add a file containing your config to /root/.not_logged_in_yet
You may also mount the image and edit it prior to flashing, if this is preferable.
+It is also possible to load this config file from a remote server, as above, however the only directive you should include is:
+/root/.not_logged_in_yet | |
---|---|
key="value"
format. Caution
+No validation of this network config is performed, wrong settings will lead to broken network.
+Armbian supports netplan.io, this is the preferred config method.
+See netplan guides for various example configurations.
+Netplan config is stored in /etc/netplan/
.
Configuration directive | +[default] | option |
+Description: | +
---|---|---|
PRESET_CONFIGURATION |
+http://path/to/config/file |
+See Loading a remote config | +
PRESET_NET_CHANGE_DEFAULTS |
+[0] | 1 |
+Change default network settings if unset, no network changes will be applied |
+
PRESET_NET_ETHERNET_ENABLED |
+0 | 1 |
+Enable Ethernet, ignored if WiFi enabled | +
PRESET_NET_WIFI_ENABLED |
+0 | 1 |
+Enable WiFi, takes priority over Ethernet | +
PRESET_NET_WIFI_SSID |
+MySSID |
+WiFi SSID | +
PRESET_NET_WIFI_KEY |
+MyWPA-PSK |
+WiFi Pre-Shared Key (Password), stored in plaintext | +
PRESET_NET_WIFI_COUNTRYCODE |
+CC |
+Country code, required for WiFi e.g. GB , US , DE ; see Wikipedia/ISO_3166 |
+
PRESET_CONNECT_WIRELESS |
+Y | n |
+Set to Y for interactive mode, n uses values from file |
+
PRESET_NET_USE_STATIC |
+[0] | 1 |
+Use the static IP provided, DHCP is the default Leaving any value unset will result in a broken config |
+
PRESET_NET_STATIC_IP |
+xxx.xxx.xxx.xxx |
+Static IPv4 address, dotted decimal notation | +
PRESET_NET_STATIC_MASK |
+xxx.xxx.xxx.xxx |
+Subnet mask, typically 255.255.255.0 |
+
PRESET_NET_STATIC_GATEWAY |
+xxx.xxx.xxx.xxx |
+Default gateway address | +
PRESET_NET_STATIC_DNS |
+x.x.x.x x.x.x.x |
+DNS Servers to use, separated by a space. If unsure: CloudFlare is 1.1.1.1 1.0.0.1 Google is 8.8.8.8 8.8.4.4 |
+
SET_LANG_BASED_ON_LOCATION |
+Y | n |
+“Set user language based on your location?” | +
PRESET_LOCALE |
+locale |
+Locale e.g. en_GB.UTF-8 , de_DE.UTF-8 , zh_TW.UTF-8 |
+
PRESET_TIMEZONE |
+timezone |
+Timezone e.g. Etc/UTC , |
+
PRESET_ROOT_PASSWORD |
+[1234] | password |
+Preset root passwordStored in plaintext, SSH keys are safer! |
+
PRESET_ROOT_KEY |
+https://path/to/key.file |
+Fetches public key from specified URL for root user |
+
PRESET_USER_NAME |
+username |
+Username to create | +
PRESET_USER_PASSWORD |
+password |
+Preset created user password Stored in plaintext, SSH keys are safer! |
+
PRESET_USER_KEY |
+https://path/to/key.file |
+Fetches public key from specified URL for created user | +
PRESET_DEFAULT_REALNAME |
+Real Name |
+RealName to use for created user | +
PRESET_USER_SHELL |
+shell |
+Currently only bash (default) or zsh (armbian-zsh ) supported |
+
The following is an example configuration, it may be used as a template
+If you want to use first run automatic configuration at build time, check this GitHub pull request.
+tl;dr;
+cp extensions/preset-firstrun.sh userpatches/extensions/
userpatches/extensions/preset-firstrun.sh
according to your situationENABLE_EXTENSIONS=preset-firstrun
First aid video guide:
+ + +If you are experiencing at least one of these problems:
+lsusb
output)and you are using a stable Armbian image, then most likely you have one of two common problems - powering issue or SD card issue.
+Note that
+If you experience strange network problems, especially if you are running several of these SOC-boards with the same operating system, then the problems may be sourced by not having a real hardware MAC address. The operating systems try to generate a hardware MAC address from the CPUid, but what if that SOC has no CPUid either?
+Then you have to do it manually. Depending on system and network installation, there are several possibilities:
+/boot/armbianEnv.txt
and add a line:Text Only | |
---|---|
1 |
|
but that file is interpreted by u-boot, which happens early in boot process, but not every u-boot is able to read that file.
+/etc/network/interfaces
. Add these lines:Text Only | |
---|---|
1 +2 +3 |
|
/etc/Networkmanager/system-connections
is a file Wired connection 1.nmconnection
. Change entry cloned-mac-address of group [ethernet] :Text Only | |
---|---|
1 +2 +3 +4 +5 +6 |
|
Some combination of boards/kernel versions does not support 4k resolution. This may cause black screen on connecting the board to 4k resolution devices. A workaround to solve this without changing the kernel is forcing the video mode to 1080p. Add this directive to the /boot/armbianEnv.txt
and reboot your system:
Text Only | |
---|---|
1 |
|
Support definitions, criteria and relationships for:
+ +Platinum support is reserved for business relationships with the Armbian project and is out of the scope of this document.
+Please contact Armbian management for more information.
+For a SBC to be considered supported:
+Community maintained devices are not under active supervision or development. Support status is unknown to Armbian team. It represents combined former CSC (community supported configuration) and EOS (end of support). Can be removed from Armbian code base at any time. Left as a courtesy in case a community member wants to attempt to resurrect maintenance.
+Community maintained SBCs are exclusively supported by the community.
+Work in progress (WIP) status is for when a maintainer has committed to a SBC, but is not ready to ship stable images.
+All benefits of Community Supported SBCs apply to Staging as well.
+This information is mainly for new/inexperienced users but could be useful for others too.
+Not per se. Armbian is a build framework that allows users to create ready-to-use images with working kernels in variable userspace configurations for various single board computers (SBCs).
+We do provide various prebuilt images for some boards, but mostly for users convenience.
+x86 architecture always has a traditional BIOS or UEFI. This provides a standard framework for operating systems to interact with the hardware. Most SBCs do not. ARM is improving the situation with ARM Server Ready and ARM System Ready certificates, but most SBC vendors are not yet incentivized to meet these standards.
+Without such standards, many vendors quickly fork low-level bootloaders such as u-boot and make the bare minimum modifications needed.
+ +Making free licence software also requires best people, expensive infrastructure, tooling. It has as much or more costs as proprietary while generating no income from the licence.
+tl;dr: We are asking for help that developers and project maintainers do not lose their generosity and humanity which are the driving force that generates a value. For all of us! A great deal of our work represent a big pressure on our very limited private resources. We ask you to share that burden with us.
+We are covering a large swath of diverse, custom designed ARM hardware in ways, extents, and under conditions nobody else does. Keeping this service up, keeping these low end hardware functional is laborious. When releases are approaching and a lot of testing and fixing is going on, this gets up, stress intensifies. This means we have to invest let’s say at least 3.000 - 4.000 EUR of our time on top of fixed costs into this service every day just to keep it up. Without developing any serious features users wish to have. Fulfilling many of these wishes would easily cost tens of thousands in development time, which we don’t have and which we can’t get back due to it being free software. Nobody needs to buy licence for using it, and yet only a few people decide to respect the time and attention they are receiving from developers on forums.
+We have to maintain our infrastructure where biggest costs are - once again - people’s time, followed by electricity, then hardware itself. Often we get free hardware and very rare break even with electricity costs and with people that would maintain this for us. A new sponsored board usually brings us more costs then benefits – since benefit is anyway public.
+The software is given, released free. However support, development, and documentation costs time, effort, hardware and technical ability, which incurs costs.
+Each question that is directed towards our team is generating opportunity costs and taking away from development time. Some we are happy to cover, but not all. Especially when it goes for repetitive questions and demands.
+Questions associated with missing features represent another hit and miss for us. Complicated and critical upstream functions are missing (like video acceleration within a web browser, supporting a board that had very poor initial support and no community backing, etc.). This functionality is unique to hardware and implementing is extremely labor intensive and requires unique expertise. Our team is 10-15 volunteers that maintain this project during their own time. We cannot cover the job of Google Chromium team, Collabora, ARM, Rockchip and other vendors which have not provided sufficient support for their products.
+All our work is done in public and we provide all sources which we are changing in the process. All our work is patent free and released under a free licence so anyone can re-use it further. The scale of SBCs Armbian supports is hard to beat, and consequently our work is repackaged and reused by other projects and vendors. Unfortunately the burden of support is often directed to us, while they focus on revenue.
+Vendors develop hardware specific support on fixed (usually old LTS) kernel and U-Boot fork and only do minimal adjustments to make board features work. Besides the fact that those adjustments are almost never pushed back to mainline they usually do not update their sources (if available at all) and pre-made kernels/boot loaders as well.
+Armbian moves things forward and follows mainline kernel as much as possible, to provide both its features as well as security updates. The downside is that some features do not work since nobody ported specific drivers to recent mainline, and they can also break. Armbian can only afford to do brief testing of images and check if basic functions (boot-up, network, USB, etc.) work due to lack of both human and financial resources.
+We need many different profiles of people to run this project and just about any help is appreciated, not just help on development. Since otherwise developers have to fix web pages, developers have to run projects, developers have to seek for money, developers have to maintain servers, developers have to maintain forum, developers have to moderate forums, developers have to maintain infrastructure, developers have to maintain relations with partners, developers have to waste time on repeated support question, developers have to deal with “customers”, …
+The Armbian project has very limited human and financial resources so it can focus on a few up-to-date operating system releases only.
+Currently supported userspaces from Debian and Ubuntu (latest only).
No.
+However some community members are commited to tinkering with these devices. They discuss their findings in a dedicated space in our forums. Take note that there is no support from the Armbian development team whatsoever.
+General advice: Do not buy (cheap) tv boxes!
There are some manufacturers who produce better quality than the others. In general they provide more or less accurate schematics and they have some engineers that are available for general public and you can ask them things here and there. Most of them try to keep up with the highest standards of hardware development. With proper documentation and minimal support, costs of software development are significantly lower. This is especially important, because we waste our precious private time to secure proper hardware functioning through the time.
+However, in vast majority of cases, TV boxes are lacking any documentation. There are frequent changes of components without notice whatsoever, boot mechanisms are closed source and almost all Armbian builds that exist in the wild are unofficial community hacks. Market is huge but since public does not have interest in covering of support - which in this case is even bigger - involvement in providing support is simply insane and stupid. It only eats our personal time and finances.
+Maybe. It depends on things like available documentation from both the vendor as well as SoC manufacturer, production samples to play with, available BSP and last but certainly not least human resources. To say a Maintainer within the Armbian development team to agree taking care. Also if vendors decide to support Armbian there is certainly a higher chance to get it fully supported.
+Normally on Debian or Ubuntu you would do something like sudo apt-get build-dep linux linux-image-$(uname -r)
.
+However Armbian’s way of building kernel images is slightly different than the standard distribution method. The best way is to follow the procedures in the Developer Guide.
Each kernel Armbian offers has a custom patchset on top which would be impossible to maintain compatibility to each and every kernel version out there. Therefore the choice is usually limited to up to three branches: legacy, current and edge. Depending on board/family the versions behind these branches may differ. You can lookup them in the source code.
+Note: Upgrading the Armbian core packages like kernel, firmware and boot loader and the chosen userspace are independent processes. Former is simply done with apt update && apt upgrade
.
Armbian does not offer a standardized way nor do we encourage users to upgrade their userspace, like Focal to Jammy, Jammy to Noble, Bullseye to Bookworm, Bookworm to Trixie. We would love to do that but the reason why we cannot is simply the lack of ressources in time and devices to test such upgrades in various random scenarios.
+You can try to upgrade your userspace by following official ways from Debian/Ubuntu but make sure to freeze your firmware packages via armbian-config
beforehand. Also please do not blame/complain (at) Armbian if something goes wrong or have other issues with an upgraded system.
Unless you have an existing arrangement with the Armbian, you will need to contact Armbian for a paid engagement.
+You may also add support by yourself if criteria is satisfied. See Board Support Rules for further information.
Check here.
+armbian-config
on my device.¶If you are using a minimal
variant this tool is not pre-installed. However you can simply install it via sudo apt update && sudo apt install armbian-config
which will also handle all necessary dependencies.
+If you are not using an minimal
image and the tool is still missing make sure your image is genuine.
Absolutely not. Quite the contrary. This behaviour is called heartbeat trigger
and is controlled by the kernel. When the load increases the flashing speed will increase as well. If the flashing stops the kernel either froze or were unloaded by either reboot or shutdown.
+Unhappy? Keep reading below :-)
Maybe. Some boards have certain functions hard-wired to the onboard leds. Others allow to control the led functions from userspace.
+Try to find trigger
files for the leds in /sys
.
+Example for an Orange Pi One:
+
Text Only | |
---|---|
cat
on the trigger
file to both check its current behaviour, which is highlighted with [brackets], and which functions are supported. Then use echo
to adjust the behaviour.
+Example for disabling a led:
+It would be VERY ressource intensive and just insane to pre-create and provide images for all possible combination of kernels, userspaces and desktops/CLI for all available boards and last but not least provide support for them. We simply cannot afford doing this since our ressources in both human and financial are limited. Therefore we provide a small selection for each board only.
+However with the Armbian build framework it is very easy and convenient to create an image of your desire by yourself.
+If there is enough public interest for a certain combination we may occasionally adjust our build targets.
Text Only | |
---|---|
1 |
|
In some cases, e.g. when your keyboard standard is not available in previous command, you may also need to set your keymap config:
+Text Only | |
---|---|
1 +2 +3 +4 +5 |
|
Text Only | |
---|---|
1 +2 +3 +4 |
|
Text Only | |
---|---|
1 |
|
Text Only | |
---|---|
1 |
|
Text Only | |
---|---|
1 +2 +3 +4 +5 +6 +7 +8 |
|
The name of HDMI sound output may change accordingly to the device. If you don’t wanna deal with different names you can:
+Text Only | |
---|---|
1 |
|
The command to define the default sound output is not persistent, to make it persistent add it to the file ~/.bashrc
Text Only | |
---|---|
1 +2 +3 +4 +5 +6 +7 +8 +9 |
|
Find matching HDMI output:
+Text Only | |
---|---|
1 |
|
Calculate VESA CVT mode lines (example for 1440x900)
+Text Only | |
---|---|
1 |
|
Sample output:
+Text Only | |
---|---|
1 +2 |
|
Create new mode (example):
+Text Only | |
---|---|
1 |
|
Add resolution (example):
+Text Only | |
---|---|
1 |
|
Set current resolution (example):
+Text Only | |
---|---|
1 |
|
If it works as expected add it to Xorg by editing /etc/X11/xorg.conf.d/40-monitor.conf
and add (example):
Text Only | |
---|---|
1 +2 +3 +4 +5 |
|
Restart Xorg or reboot
+Some boards allow to adjust CPU speed
+Text Only | |
---|---|
1 |
|
Alter min_speed or max_speed variable.
+Text Only | |
---|---|
1 |
|
By default Armbian implements ZRAM (writing nothing to ‘disk’ but compressing memory pages in RAM) but in case you often run into out of memory errors and your device has some capable storage (e.g. a securely attached NVMe or SATA SSD) you might want to use ZSWAP instead.
+Check whether your kernel has zswap enabled (dmesg | grep zswap
should output something) and if so create a swapfile or swap partition the traditional way, edit/uncomment /etc/default/armbian-zram-config
so that it reads SWAP=false
, reboot and you’re done.
Zswap performs a lot better than the combination of ZRAM and ‘swap on disk’ in parallel.
+This is useful when you need to fall back to previous kernel version.
+Text Only | |
---|---|
1 |
|
This example is for H3 legacy kernel. Check this page for others.
+Edit and change boot parameters in /boot/boot.cmd
(not recommended) or variables in /boot/armbianEnv.txt
:
Text Only | |
---|---|
1 +2 |
|
To disable console entirely (not recommended) set console to none
.
Recompile boot.cmd to boot.scr if it was changed:
+Text Only | |
---|---|
1 |
|
Reboot.
+Serial console on imx6 boards are ttymxc0 (Hummingboard, Cubox-i) or ttymxc1 (Udoo).
+Using Armbian 5.05 to 5.20 you would need to touch/rm /boot/.force-verbose
to increase boot verbosity. With more recent Armbian builds you would have to alter the verbosity=
line in /boot/armbianEnv.txt
(defaults to 1 which means less verbose, maximum value is 7).
When your SBC behaves strange first step is to check power supply and integrity of boot media (armbianmonitor -c "$HOME"
). Then look into your kernel logs. We made a tool that grabs info and pastes it to an online pasteboard service. Please increase boot verbosity as shown above (verbosity=7
), reboot and then run
Text Only | |
---|---|
1 |
|
Copy and past URL of your log to the forum, mail, …
+To get Wi-Fi working simply use nmtui
, a simple console based UI for network-manager (an example how to set up an AP with network-manager can be found here). To deal with different Ethernet/Wi-Fi combinations there are six predefined configurations available, you can find them in those files:
Text Only | |
---|---|
1 +2 +3 +4 +5 +6 |
|
By default /etc/network/interfaces is a copy of /etc/network/interfaces.default
+nmtui
/nmcli
or using the GUI)You can switch configuration with copying.
+Text Only | |
---|---|
1 +2 |
|
(x = default,hostapd,bonding,r1)
+Then check / alter your interfaces:
+Text Only | |
---|---|
1 |
|
Armbian has its own apt repository and mirrors for armbian-specific packages. The default of http://apt.armbian.com
is a round-robin to all mirrors. If you are having trouble updating or slow speeds you may want to choose a specific mirror.
Do the following:
+Assure jq
is installed
apt install -y jq
Get a list of available mirrors from our https://apt.armbian.com/mirrors
endpoint.
Bash | |
---|---|
You will see a result set similar to this, listing mirrors by region: +
Edit /etc/apt/sources.list.d/armbian.list
and replace the url http://apt.armbian.com
with your preferred mirror.
New users
+Please, make sure you have:
+The download for each image consists of three separate files:
+How to check download authenticity?
+All our images are digitally signed and therefore it is possible to check their authenticity. You need to issue these commands (Linux/macOS, you might need to install dependencies first, eg. sudo apt-get install gnupg
on Debian/Ubuntu or brew install gnupg
on macOS. on windows install the current simple gnupg Gnupg:
WARNING: This key is not certified with a trusted signature!
.
+How to check download integrity?
+Since it might happen that your download got somehow corrupted we integrate a checksum/hash for the image. You can compare the image’s SHA-256 hash with the one contained in the sha256sum.sha
file.
On Windows, you can download and use the QuickHash GUI and follow the instructions in the gui.
+while on Linux/macOS, in the directory in which you have downloaded the files ,you would do this
+ +For each board we usually provide various image types:
+For some boards we provide only minimal images due to their hardware limitations.
+If you have no special preferences that require specific versions, we recommend Ubuntu based Armbian.
+In some cases we provide images with different firmware. They differ in level of hardware support. Focus into:
+And use those if they are the only one / for testings:
+The level of kernel support however always depends on the board family. If in your specific case something does not work well, you are always free to try an image with an other kernel included or change kernel within armbian-config.
+Rolling releases are suitable for Linux enthusiasts who want cutting edge packages and have the skills to fix damage that a bad update might cause. If you want stability in a production environment or low headaches as a novice user, skip rolling releases. They are only at, build and ship, Debian testing / Arch / Manjaro / Suse Tumbleweed / Kali / Gentoo support quality level!
+graph LR
+ A[Hardware] --> B{Armbian kernel};
+ B -->|legacy| C["rolling release"];
+ B -->|vendor| C["rolling release"];
+ B -->|current| C["rolling release"];
+ B -->|edge| C["rolling release"];
+ B -->|legacy| X["point release"];
+ B -->|vendor| X["point release"];
+ B -->|current| X["point release"];
+ B -->|edge| X["point release"];
+
+
+ C ---->|minimal| E[Debian or Ubuntu];
+ C ---->|server| F[Debian or Ubuntu];
+ C ---->|desktop| G[Debian or Ubuntu];
+
+ X ---->|minimal| E[Debian or Ubuntu];
+ X ---->|server| F[Debian or Ubuntu];
+ X ---->|desktop| G[Debian or Ubuntu];
+Danger
+Do not use rollling or edge images in a productive environment. Their purpose is testing and providing constructive feedback to developers.
+Important note: Make sure you use a good, reliable and fast SD card. If you encounter boot or stability troubles in over 95 percent of the time it is either insufficient power supply or related to SD card (bad card, bad card reader, something went wrong when burning the image, card too slow to boot – ‘Class 10’ highly recommended!). Armbian can simply not run on unreliable hardware so checking your SD card with either F3 or H2testw is mandatory if you run in problems. Since counterfeit SD cards are still an issue checking with F3/H2testw directly after purchase is highly recommended.
+Write the .xz compressed image with a tool USBImager or balenaEtcher on all platforms since, unlike other tools, either can validate written data saving you from corrupted SD card contents.
+Also important
+Most SD cards are only optimised for sequential reads/writes as it is common with digital cameras. This is what the speed class is about. The SD Association defined Application Performance Class as a standard for random IO performance.
+Application Performance Class | +Pictograph | +Miniumum Random Read | +Minimum Random Write | +Minimum Sustained (Seq. Write) | +
---|---|---|---|---|
Class 1 (A1) | ++ | 1500 4k IOPS | +500 4k IOPS | +10MBytes/sec | +
Class 2 (A2) | ++ | 4000 4k IOPS | +2000 4k IOPS | +10MBytes/sec | +
We recommend at least A1 rated SD-Cards (A2 rated cards need yet lacking driver support and therefore show lower overall and especially random IO performance). For example:
++
In case you chose an SD card that was already in use before please consider resetting it back to ‘factory default’ performance with SD Formatter before burning Armbian to it (explanation in the forum). Detailed information regarding ‘factory default’ SD card performance.
+Insert SD card into a slot and power the board. (First) boot (with DHCP) takes up to two minutes with a class 10 SD card and cheapest board.
+First boot will log you automatically on HDMI or serial console while for SSH login you need to login as root and use password 1234. You will be prompted to change this password. You will then be asked to create a normal user account that is sudo enabled (beware of default QWERTY keyboard settings at this stage). Please use this tool, to find your board IP address.
+These settings can be pre-loaded, see Autoconfig
+In case you have no wired network connection and there is a wireless adaptor detected, it will prompt you to connect.
+Text Only | |
---|---|
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 +10 +11 +12 +13 +14 +15 +16 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 +31 +32 +33 +34 +35 +36 +37 +38 +39 +40 +41 +42 +43 +44 +45 +46 +47 +48 +49 +50 +51 |
|
Required condition for eMMC/SATA/USB/NVME:
+Start the install script and follow the lead:
+Text Only | |
---|---|
1 |
|
Armbian installer provides those scenarios:
+You can choose the following file system options:
+Text Only | |
---|---|
1 +2 |
|
Update process can take some time in case of using old & cheap SD card and/or under heavy load.
+If the kernel was upgraded during this process you will be prompted to reboot at next login.
+First you need to update all packages described in a previous step. Then run:
+Bash | |
---|---|
Select:
+Install/Update the bootloader on SD/eMMC
+Armbian provides firmware package freeze to give you an option to upgrade all packages but firmware. This prevents unplesant surprises on functionality regressions that comes with kernel upgrades. To enable / disable this feature, look for Enable Armbian kernel/firmware upgrades / Disable Armbian kernel upgrades
within armbian-config.
When a new userspace is out, we recommend to start with a fresh image. However, it is possible to upgrade, but the process is largerly in the domain of underlaying Debian or Ubuntu user space. However we provide experimental Distribution upgrades
within armbian-config
Danger
+Userspaces distribution upgrades are neither tested nor supported. Therefore Armbian cannot provide support if something goes wrong.
+Hardware configuration is available within armbian-config utility.
+Follow bug reporting form available here and learn how to collect necessary information and where provide to put your report depending on type of issue. Reports lacking fundamental diagnostics are ignored.
+ + + + + + + + + + + + + + + +Armbian uses Netplan.io to describe networking configurations. Netplan is a utility to easily configure Linux networking, using a declarative approach. +If you want to configure your network manually, it is as simple as editing and creating Netplan yaml files (see the yaml configuration reference at the Netplan docs).
+Netplan is used to configure networks on all Armbian images since Release 24.05, no matter if minimal, CLI or desktop, Debian or Ubuntu. However, the networking backends are different based on if you choose a minimal image or not.
+Netplan renderer: networkd
+Minimal images are using the systemd-networkd
backend, which has a smaller footprint compared to Network-Manager
which is used in all non-minimal images. systemd-networkd
is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service is great for simple connections, but can also be useful to set up complex network configurations.
All ethernet interfaces are configured for DHCP and will automatically receive an IP address from your router.
+/etc/netplan/10-dhcp-all-interfaces.yaml
:
YAML | |
---|---|
The following example configures a static IP 192.168.1.199
for the eth0
interface. Please adjust as necessary.
How to find your device’s Ethernet interface?
+Use command:
+Bash | |
---|---|
eth0
, enp4s3
or lan
.
+/etc/netplan/20-static-ip.yaml
:
YAML | |
---|---|
See also the Netplan docs for reference.
+It is recommended to make a separate config file for wireless network.
+Create the following file:
+sudo nano /etc/netplan/30-wifis-dhcp.yaml
:
YAML | |
---|---|
Replace SSID
with the name of the network you want to connect to and wlan0
with the wifi interface used on your system.
How to find your device’s WiFi interface?
+Use command:
+Bash | |
---|---|
wlan0
, wlo1
or wlx12334c47dec3
. If you get blank response, it means your WiFi device / dongle is not supported by the kernel.
+See also the Netplan docs for reference.
+Once you are done configuring your network, it is time to test syntax and apply it.
+According to the Netplan docs, the permissions must be restricted to the root
user.
Bash | |
---|---|
This will verify the syntax and test if your device can connect
+Bash | |
---|---|
Bash | |
---|---|
Netplan renderer: Network Manager
+Server CLI and desktop images are using the Network-Manager
backend. You can use similar methods for configuring your network as with the networkd
backend used on minimal images.
The following example configures a static IP 192.168.1.199
for the eth0
interface. Please adjust the example to your likings.
How to find your device’s Ethernet interface?
+Use command:
+Bash | |
---|---|
eth0
, enp4s3
or lan
.
+/etc/netplan/20-static-ip.yaml
:
YAML | |
---|---|
See also the Netplan docs for reference.
+Alternatively, you can also use Network-Manager directly via the command line or GUI tools on your desktop:
+Bash | |
---|---|
Replace eth0
with the name of your Ethernet Interface.
For connecting to a wireless network, you can use the same method as mention above for use with networkd
on minimal images. Just make sure to replace renderer: networkd
with renderer: NetworkManager
.
Alternatively, you can also use Network-Manager directly via the command line or GUI tools on your desktop:
+Bash | |
---|---|
Replace SSID
with the name of your wireless network.
Important: If you came here since you cannot get Armbian running on your board please keep in mind that in 95 percent of all cases it is either a faulty/fraud/counterfeit SD card or an insufficient power supply that is causing these sorts of does not work issues!
+The following are presented in (more or less) increasing levels of despair. But keep heart! :) And proceed in order.
+If you broke the system you can try to get in this way. You have to get to u-boot command prompt, using either a serial adapter or monitor and usb keyboard.
+After switching power on or rebooting, when u-boot loads up, press some key on the keyboard (or send some key presses via terminal) to abort default boot sequence and get to the command prompt:
+Bash Session | |
---|---|
Enter the following commands, replacing root device path if necessary.
+boot.cmd
for your device for commands related to legacy kernel.For serial:
+Bash Session | |
---|---|
For monitor:
+Bash Session | |
---|---|
Then:
+Bash Session | |
---|---|
System should eventually boot to bash shell:
+Bash Session | |
---|---|
Now you can try to fix your broken system.
+When something goes terribly wrong and you are not able to boot the system (and cannot gain access via u-boot as outlined above), this is the way to proceed. You will need some Debian based Linux machine where you can mount the failed SD card. With this procedure you will reinstall the kernel and hardware settings. In most cases this should be enough to unbrick the board.
+It is recommended to issue a filesystem check before mounting. Replace X
and Y
below with your device and partition(s), respectively (if not a flash based device, it may even be /dev/sdXY
, etc).
Bash Session | |
---|---|
Mount the SD card.
+ +Make another temporary directory somewhere else (in our example ~/tmp/recovery
) and download the Linux root, kernel, firmware and dtb packages for your board and currently used OS.
Extract all the Debian packages (.deb
files) to the mounted sd card.
Bash Session | |
---|---|
Navigate to /mnt/sdcard/boot
and create symlinks:
Bash Session | |
---|---|
If you upgrade from some very old build, you might need to update your boot script.
+u-boot-tools
package on your host system.Bash Session | |
---|---|
Unmount SD card.
+ +Move it to the board and power on. Check serial output for errors if problems persist.
+Sometimes we need to flash boot loader from some other Linux. Attach an SD card reader with your SD card and proceed this way:
+Move it to the board and power on. Check serial output for errors if problems persist.
+ + + + + + + + + + + + + + + +