Jira ticket: AR-2453

Cannot reproduce: https://paste.armbian.com/ivezixuxof
However performed on bare metal, not gha.

@EvilOlaf given that the error is a "build host" error, I suspect that the machine where the build is performed has a lot, if not everything to do with the failure. I upgraded to Debian 12, and ran again, but still got the same issue.

What are the conditions for btrfs, and I can start there?

 Using prebuilt Armbian image as base for 'ubuntu-jammy' [ DOCKER_ARMBIAN_BASE_IMAGE: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌿] Docker info [ Docker 27.1.1 Kernel:6.1.0-23-amd64 RAM:62.74GiB CPUs:16 OS:'Debian GNU/Linux 12 (bookworm)' hostname 'buildbox' under 'Linux' - buildx:yes - loop-hacks:yes static-loops:no ]
[🌱] Creating [ .dockerignore ]
[🌱] Docker launcher [ enabling all extensions looking for Docker dependencies ]
[🌱] Extension manager [ processed 32 Extension Methods calls and 124 Extension Method implementations ]
[🌱] Extension: fs-cryptroot-support: Adding packages to host dependencies [ cryptsetup openssh-client ]
[🌱] Preparing rkdevflash host-side dependencies [ rkdevflash ]
[🌱] Creating [ Dockerfile; FROM ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌱] Armbian docker image [ already exists: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌱] Building [ Dockerfile via 'buildx build --progress=plain --load' ]
[🌱] -----------------Relaunching in Docker after 48s------------------ [ here comes the 🐳 ]
[🐳|🌿] Applying cmdline param [ 'PREFER_DOCKER': '(unset)' --> 'no' early ]
[🐳|🌿] Applying cmdline param [ 'BUILD_MINIMAL': '(unset)' --> 'yes' early ]
[🐳|🌿] Applying cmdline param [ 'ROOTFS_TYPE': '(unset)' --> 'btrfs' early ]
[🐳|🌿] Applying cmdline param [ 'ARMBIAN_BUILD_UUID': '(unset)' --> '2f98d726-1257-49d6-8090-a25740343ef1' early ]
[🐳|🌱] Skip     cmdline param [ 'ARMBIAN_RELAUNCHED': already set to 'yes' early ]
[🐳|🌿] Applying cmdline param [ 'HOST': '(unset)' --> 'print-tracker-cube' early ]
[🐳|🌿] Applying cmdline param [ 'BRANCH': '(unset)' --> 'current' early ]
[🐳|🌿] Applying cmdline param [ 'BOARD': '(unset)' --> 'nanopi-r2s' early ]
[🐳|🌿] Applying cmdline param [ 'SKIP_LOG_ARCHIVE': '(unset)' --> 'yes' early ]
[🐳|🌿] Applying cmdline param [ 'SET_OWNER_TO_UID': '(unset)' --> '1000' early ]
[🐳|🌿] Applying cmdline param [ 'RELEASE': '(unset)' --> 'bookworm' early ]
[🐳|🌿] Applying cmdline param [ 'KERNEL_CONFIGURE': '(unset)' --> 'no' early ]
[🐳|🌱] Starting single build process [ nanopi-r2s ]
[🐳|🌱] Sourcing board configuration [ /armbian/config/boards/nanopi-r2s.csc ]
[🐳|✅] change-tracking: after sourcing board file config/boards/nanopi-r2s.csc [ BOARDFAMILY='rockchip64' ]
[🐳|✅] change-tracking: after sourcing board file config/boards/nanopi-r2s.csc [ BOOTCONFIG='nanopi-r2s-rk3328_defconfig' ]
[🐳|✅] change-tracking: after defaulting LINUXFAMILY to BOARDFAMILY [ LINUXFAMILY='rockchip64' ]
[🐳|🌱] Starting main configuration
[🐳|🌱] Using REVISION from [ main VERSION file: '24.8.0-trunk' ]
[🐳|🌿] Enabling extension [ fs-btrfs-support ]
modprobe: FATAL: Module btrfs not found in directory /lib/modules/6.1.0-23-amd64
[🐳|💥] error! [ Filesystem type unsupported by build host: btrfs ]
[🐳|💥]     👇👇👇 Showing logfile below 👇👇👇 [ /armbian/.tmp/logs-2f98d726-1257-49d6-8090-a25740343ef1/006.000.do_main_configuration.log ]
e[1;30m[🐳|👉]    --> (0) INFO: Starting main configuration
e[1;30m[🐳|👉]    --> (0) INFO: Using REVISION from [ main VERSION file: '24.8.0-trunk' ]
e[1;30m[🐳|👉]    --> (0) INFO: Enabling extension [ fs-btrfs-support ]
e[1;30m[🐳|👉]    --> (0) ERROR: error! [ Filesystem type unsupported by build host: btrfs ]
[🐳|💥]     👆👆👆 Showing logfile above 👆👆👆 [ /armbian/.tmp/logs-2f98d726-1257-49d6-8090-a25740343ef1/006.000.do_main_configuration.log ]
[🐳|💥] Exiting with error 43 [ at /armbian/lib/functions/logging/traps.sh:1
                exit_with_error() --> lib/functions/logging/traps.sh:1
   check_filesystem_compatibility_on_host() --> lib/functions/configuration/main-config.sh:585
          do_main_configuration() --> lib/functions/configuration/main-config.sh:163
                do_with_logging() --> lib/functions/logging/section-logging.sh:85
    do_with_conditional_logging() --> lib/functions/logging/section-logging.sh:111
    prep_conf_main_build_single() --> lib/functions/main/config-prepare.sh:29
         cli_standard_build_run() --> lib/functions/cli/cli-build.sh:22
        armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136
                 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176
                           main() --> compile.sh:50
 ]
[🐳|💥] Cleaning up [ please wait for cleanups to finish ]
[🐳|🌿] ANSI log file built; inspect it by running: [ less -RS output/logs/log-build-2f98d726-1257-49d6-8090-a25740343ef1.log.ans ]
[🐳|🌿] Share log manually (or SHARE_LOG=yes): [ curl --data-binary @output/logs/log-build-2f98d726-1257-49d6-8090-a25740343ef1.log.ans https://paste.armbian.com/log ]
[💥] -------------Docker run failed after 49s-------------------------- [ 🐳 failed ]
[🌱] Cleaning up [ please wait for cleanups to finish ]

Ahh, I thought I recall BTRFS was never a kernel module, it was installed after the fact. Is it possible that ROOTFS_TYPE=btrfs was just being ignore before, and is now throwing an error? I suppose that doesn't explain why this is building fine on my macOS machine, but not my Debian 12 Github Actions runner.

if ! modprobe "$ROOTFS_TYPE"; then
    exit_with_error "Filesystem type unsupported by build host:" "$ROOTFS_TYPE"
else
    display_alert "Sucessfully loaded kernel module for filesystem" "$ROOTFS_TYPE" ""
fi

What are the conditions for btrfs, and I can start there?

I would say build host (kernel) needs to have support for btrfs

modprobe: FATAL: Module btrfs not found in directory /lib/modules/6.1.0-23-amd64

but it lack it.

@igorpecovnik hmm... am I looking in the wrong place?

$ sudo modinfo btrfs
[sudo] password for owner:
filename:       /lib/modules/6.1.0-23-amd64/kernel/fs/btrfs/btrfs.ko
softdep:        pre: blake2b-256
softdep:        pre: sha256
softdep:        pre: xxhash64
softdep:        pre: crypto-crc32c
license:        GPL
alias:          devname:btrfs-control
alias:          char-major-10-234
alias:          fs-btrfs
depends:        zstd_compress,raid6_pq,xor,libcrc32c
retpoline:      Y
intree:         Y
name:           btrfs
vermagic:       6.1.0-23-amd64 SMP preempt mod_unload modversions
sig_id:         PKCS#7
signer:         Debian Secure Boot CA
sig_key:        32:A0:28:7F:84:1A:03:6F:A3:93:C1:E0:65:C4:3A:E6:B2:42:26:43
sig_hashalgo:   sha256
signature:      9D:AC:19:DB:92:3D:4A:E8:57:2A:28:33:57:AC:6F:6A:F8:AC:89:64:
		0B:9E:6C:D6:AB:E2:C0:43:39:8F:F3:F0:53:1B:C3:A6:10:21:1E:D5:
		75:65:5D:05:1A:27:4D:3C:BD:C0:71:9D:B7:28:FB:9D:1D:B0:24:35:
		86:1B:99:42:5D:9A:80:45:2D:F2:5C:E9:55:78:16:EB:6F:1F:DE:8D:
		0A:78:2E:C0:95:F3:17:AB:A3:D1:C9:54:86:6E:64:0F:5D:78:9F:30:
		27:54:6D:98:F7:0A:86:F2:EA:43:50:86:4D:14:5D:3B:BC:19:25:05:
		B4:C3:05:3C:D9:AE:F2:F1:40:F3:33:DE:49:15:AB:87:88:72:38:61:
		E0:7A:0E:69:74:4C:4D:34:3C:BA:E7:00:0D:E5:E5:14:D6:26:7B:3C:
		32:01:D2:9A:B0:F0:29:AC:DB:55:6F:8D:EF:B2:39:3E:8B:51:4C:8E:
		56:1B:B2:C5:0F:06:1F:1D:27:E6:F0:BC:0C:52:DA:D9:D6:4E:90:6B:
		7B:EE:97:27:C7:57:F9:17:3C:0F:E8:98:E2:41:FF:50:2A:9D:C3:FD:
		A7:E1:A5:56:AC:A9:4B:82:6D:A8:D7:8B:D8:CA:6E:08:52:64:6C:18:
		EF:EE:24:AA:2D:23:48:08:2C:33:EF:AF:FE:4A:10:E0

Okay I think I found the issue. The ./compile script cannot be run as root, but the user (in this case owner) that is running the script cannot run modprobe.

$ modprob btrfs
bash: modprob: command not found

Running as root does work. If I change the script to this, it also works.

if ! sudo modprobe "$ROOTFS_TYPE"; then

$ modprob btrfs

Did you try modprob or modprobe? Since former does not exist the output makes sense.

@EvilOlaf oops, you're right. That must have just been a bad test on my part, I think my problem explanation is still legitimate though. When I added modprobe permissions for the owner user, the compile script started working again.

Does it makes sense to pop up a warning or something if the user doesn't have permission to register kernel modules.

I know from earlier days the build script asked for sudo password to avoid such situations. Not sure how this is handled today.
https://github.com/armbian/build/blob/e34789f90bde3f348b1912d5d1ef0ebac6a363d7/lib/functions/configuration/main-config.sh#L584C1-L584C8

@rpardini can you give some insights? tl;dr: modprobe btrfs fails due to lack of privileges.

By the way, I re-ran the test. It looks like even with the correct command name, I still get command not found if I don't have permissions to run the command.

$ modprobe btrfs
bash: modprobe: command not found

$ sudo modprobe btrfs
>

Try adding kmod package to host dependency.

modprobe btrfs fails due to lack of privileges.

build system elevates itself either by 1) sudo or 2) docker (which runs as root).
The modprobe in question is probably being done "too early", as in, the system is not elevated yet to root.
Refactor this to do it as late as possible while still in prepare_host phase.

@rpardini would that permissions issue also explain these errors that I just started getting recently on the 24.08 branch?

mkdir: cannot create directory ‘/home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/output/images’: Permission denied

I only get the error if I've already run my workflow one time. The first time works great, all subsequent times I get this permission denied error.

The only way to resolve is to run

$ rm -rf /home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/output/images

[🌱] Using prebuilt Armbian image as base for 'ubuntu-jammy' [ DOCKER_ARMBIAN_BASE_IMAGE: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌿] Docker info [ Docker 27.1.1 Kernel:6.1.0-23-amd64 RAM:62.74GiB CPUs:16 OS:'Debian GNU/Linux 12 (bookworm)' hostname 'buildbox' under 'Linux' - buildx:yes - loop-hacks:yes static-loops:no ]
[🌱] Creating [ .dockerignore ]
[🌱] Docker launcher [ enabling all extensions looking for Docker dependencies ]
[🌱] Extension manager [ processed 32 Extension Methods calls and 124 Extension Method implementations ]
[🌱] Extension: fs-cryptroot-support: Adding packages to host dependencies [ cryptsetup openssh-client ]
[🌱] Preparing rkdevflash host-side dependencies [ rkdevflash ]
[🌱] Creating [ Dockerfile; FROM ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌱] Armbian docker image [ already exists: ghcr.io/armbian/docker-armbian-build:armbian-ubuntu-jammy-latest ]
[🌱] Building [ Dockerfile via 'buildx build --progress=plain --load' ]
mkdir: cannot create directory ‘/home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/output/images’: Permission denied
[💥]     👇👇👇 Showing logfile below 👇👇👇 [ /home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/.tmp/logs-d9aa34bd-5a21-4c73-b4bd-c6[15](https://github.com/printtracker/armbian-build/actions/runs/10480753788/job/29028959032#step:8:16)73e2b63a/005.000.docker_cli_prepare_launch.log ]
[💥]     👆👆👆 Showing logfile above 👆👆👆 [ /home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/.tmp/logs-d9aa34bd-5a21-4c73-b4bd-c61573e2b63a/005.000.docker_cli_prepare_launch.log ]
[💥] Error 1 occurred in main shell [ at /home/owner/github-actions/actions-runner-2/_work/armbian-build/armbian-build/lib/functions/host/docker.sh:502
   prepare_docker_args_for_mountpoint() --> lib/functions/host/docker.sh:502
   loop_over_armbian_mountpoints() --> lib/functions/host/mountpoints.sh:95
      docker_cli_prepare_launch() --> lib/functions/host/docker.sh:5[16](https://github.com/printtracker/armbian-build/actions/runs/10480753788/job/29028959032#step:8:17)
                do_with_logging() --> lib/functions/logging/section-logging.sh:85
                 cli_docker_run() --> lib/functions/cli/cli-docker.sh:57
        armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136
                 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:[17](https://github.com/printtracker/armbian-build/actions/runs/10480753788/job/29028959032#step:8:18)6
                           main() --> ./compile.sh:50

BTRFS and WLS2 and Docker on the host - this is about 3 levels of complexity that isn't really needed for a successful build.

@sfx2000 I'm sorry, I don't understand what you mean.

This is a Debian host so no WSL. Docker is what does the compile.sh image build. And the armbian image is supposed to be btrfs which requires the kernel module to be loaded on the host. The build works fine, there's just these build script permissions errors when (1) loading btrfs kernel module which the build script already tries to do, and (2) when trying to write to the output/images directory when it already exists.

would that permissions issue also explain these errors

No. output/ directories, when created in 'elevated' sudo/docker mode, should be reset to the original (pre-sudo/docker) UID so they're accessible when the build is done. If you're doing something of the kind in config/extension make sure to trap and fix chown.

Try adding kmod package to host dependency. -- @igorpecovnik (#7052 (comment))

Not a solution on my end

I ran this build script on Arch Linux on a btrfs file system and encountered this problem, but I encountered a problem with the missing ext4 module. I just opened the /etc/mkinitcpio.conf file and wrote the missing module. As shown below

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=(btrfs ext4)

and run this

mkinitcpio -P

and not need root privileges to run this script

The approach of using /lib/modules to check supported filesystem type also makes Dockerized builds incompatible with NixOS (the shell.nix in the repo root suggests compatibility), which doesn't use /lib/modules/<kernel>, but /run/current-system/kernel-modules/lib/modules/<kernel>. For me, this means I can't proceed with Armbian.

The Armbian build system is a complex framework with numerous components that can run on a variety of systems. Many of these components have been contributed by community members. However, approximately 70% of hardware targets are not officially supported, as the Armbian team lacks the resources to maintain them. While adding new targets is relatively simple and low-cost, ensuring long-term functionality incurs significant challenges and expenses that cannot be covered solely through donations.

The same principle applies to different Linux host systems and userspace combinations. A member of the Nix community previously attempted to make the build system compatible with Nix but eventually lost interest. Given our existing workload, we cannot allocate resources to ensure full compatibility with Nix, nor do we have the capacity to officially support it. Since no core team members actively use Nix, anyone interested in making the build system work within the Nix ecosystem would need to take the initiative to address the necessary modifications. Even if we were open to making the build system more Nix-friendly, it is beyond our current capabilities.