build icon indicating copy to clipboard operation
build copied to clipboard
verified publisher icon armbian

[Bug]: Filesystem type unsupported by build host: btrfs

Open clarkmcc opened this issue 1 year ago • 21 comments

What happened?

I've been using the following build command for about a year

./compile.sh build BOARD=nanopi-r2s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm HOST=example ROOTFS_TYPE=btrfs

but I recently rebased the latest changes from this repo and now my Github Actions build fails with the error

[🐳|💥] error! [ Filesystem type unsupported by build host: btrfs ]
[🐳|💥]     👇👇👇 Showing logfile below 👇👇👇 [ /armbian/.tmp/logs-9b48c0c4-3b43-4014-ae93-ca60023915a7/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-9b[48](https://github.com/printtracker/armbian-build/actions/runs/10306021719/job/28528397475#step:8:49)c0c4-3b43-4014-ae93-ca60023915a7/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](https://github.com/printtracker/armbian-build/actions/runs/10306021719/job/28528397475#step:8:51)

The build happens in Docker, so it seems weird that there is a platform dependency for btrfs. I just found that by Github Actions runner is Debian GNU/Linux 11 (bullseye) and I see in that that is no an option for the OS selector below.

How to reproduce?

Not sure if it's a full reproduction, but running this command did it for me

./compile.sh build BOARD=nanopi-r2s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm HOST=example ROOTFS_TYPE=btrfs

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Other

Are you building on Windows WSL2?

  • [ ] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

clarkmcc avatar Aug 08 '24 17:08 clarkmcc

Jira ticket: AR-2453

github-actions[bot] avatar Aug 08 '24 17:08 github-actions[bot]

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

EvilOlaf avatar Aug 08 '24 17:08 EvilOlaf

@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 ]

clarkmcc avatar Aug 08 '24 17:08 clarkmcc

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

clarkmcc avatar Aug 08 '24 17:08 clarkmcc

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 avatar Aug 08 '24 17:08 igorpecovnik

@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

clarkmcc avatar Aug 08 '24 17:08 clarkmcc

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

clarkmcc avatar Aug 08 '24 18:08 clarkmcc

$ modprob btrfs

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

EvilOlaf avatar Aug 09 '24 05:08 EvilOlaf

@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.

clarkmcc avatar Aug 09 '24 17:08 clarkmcc

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.

EvilOlaf avatar Aug 10 '24 04:08 EvilOlaf

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
>

clarkmcc avatar Aug 14 '24 23:08 clarkmcc

Try adding kmod package to host dependency.

igorpecovnik avatar Aug 15 '24 11:08 igorpecovnik

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 avatar Aug 17 '24 11:08 rpardini

@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

clarkmcc avatar Aug 20 '24 23:08 clarkmcc

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 avatar Aug 21 '24 02:08 sfx2000

@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.

clarkmcc avatar Aug 21 '24 03:08 clarkmcc

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.

rpardini avatar Aug 23 '24 19:08 rpardini

Try adding kmod package to host dependency. -- @igorpecovnik (https://github.com/armbian/build/issues/7052#issuecomment-2291138265)

Not a solution on my end

Kreyren avatar Sep 04 '24 11:09 Kreyren

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

GrandDuke1106 avatar Nov 16 '24 08:11 GrandDuke1106

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.

kjkent avatar Mar 04 '25 00:03 kjkent

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.

igorpecovnik avatar Mar 04 '25 07:03 igorpecovnik

the problem discussed in this ticket can be fixed with "sudo modprobe btrfs", can it not?

time to close?

leggewie avatar Jun 22 '25 15:06 leggewie

the problem discussed in this ticket can be fixed with "sudo modprobe btrfs", can it not?

i this is already in the code. I think the problem here is anyway in the build host. Yeah, lets close.

igorpecovnik avatar Jun 22 '25 21:06 igorpecovnik