Open
Description
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
- I agree to follow this project's Code of Conduct
Activity
github-actions commentedon Aug 8, 2024
Jira ticket: AR-2453
EvilOlaf commentedon Aug 8, 2024
Cannot reproduce: https://paste.armbian.com/ivezixuxof
However performed on bare metal, not gha.
clarkmcc commentedon Aug 8, 2024
@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?
clarkmcc commentedon Aug 8, 2024
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.igorpecovnik commentedon Aug 8, 2024
I would say build host (kernel) needs to have support for btrfs
but it lack it.
clarkmcc commentedon Aug 8, 2024
@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 commentedon Aug 8, 2024
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 runmodprobe
.Running as root does work. If I change the script to this, it also works.
EvilOlaf commentedon Aug 9, 2024
Did you try
modprob
ormodprobe
? Since former does not exist the output makes sense.clarkmcc commentedon Aug 9, 2024
@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 theowner
user, thecompile
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.
EvilOlaf commentedon Aug 10, 2024
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.
clarkmcc commentedon Aug 14, 2024
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 >
igorpecovnik commentedon Aug 15, 2024
Try adding
kmod
package to host dependency.rpardini commentedon Aug 17, 2024
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.
clarkmcc commentedon Aug 20, 2024
@rpardini would that permissions issue also explain these errors that I just started getting recently on the 24.08 branch?
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
sfx2000 commentedon Aug 21, 2024
BTRFS and WLS2 and Docker on the host - this is about 3 levels of complexity that isn't really needed for a successful build.
clarkmcc commentedon Aug 21, 2024
@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.
rpardini commentedon Aug 23, 2024
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.modprobe "$ROOTFS_TYPE"
is not a reliable way to check supported filesystem type by host #7175Kreyren commentedon Sep 4, 2024
Not a solution on my end
framework: Adjust fs module checking
GrandDuke1106 commentedon Nov 16, 2024
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 belowand run this
and not need root privileges to run this script
kjkent commentedon Mar 4, 2025
The approach of using
/lib/modules
to check supported filesystem type also makes Dockerized builds incompatible with NixOS (theshell.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.compile.sh
amends user's global git config; fails if it can't #7907igorpecovnik commentedon Mar 4, 2025
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.