allow building a minimal btrfs compressed image

[amazingfate]

Description

If the rootfs is not ext4 filesystem, we force to use a single boot partiton, while this is not necessary if bootloader supports the filesystem of root partition. So this pr will allow single root partition for all filesystem.

Then we can build a minimal image which can get flashed to a storage which is smaller than 512MB.

ArmSoM Forge1 has a on-board 512MB SPI NAND flash. Although uboot doesn't support booting from it now.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• ./compile.sh BOARD=armsom-forge1 BRANCH=vendor BTRFS_COMPRESSION=zstd BUILD_DESKTOP=no BUILD_MINIMAL=yes DEB_COMPRESS=xz FIXED_IMAGE_SIZE=500 INSTALL_ARMBIAN_FIRMWARE=no KERNEL_BTF=yes KERNEL_CONFIGURE=no KERNEL_GIT=shallow RELEASE=trixie ROOTFS_TYPE=btrfs
• boot fine from sd card on armsom forge1

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[coderabbitai]

Walkthrough

• config/boards/armsom-forge1.csc: Updated BOOTCONFIG from "generic-rk3506_defconfig" to "forge1-rk3506b_defconfig".
• lib/functions/image/partitioning.sh: Modified boot partition condition in prepare_partitions to no longer exclude ROOTFS_TYPE=ext4. Boot partition is now considered when boot size is non-zero or a boot partition is explicitly required, regardless of ROOTFS_TYPE. No other logic changes indicated.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• If rootfs placed on btrfs filesystem, place root on @ subvolume #8067 — Also changes lib/functions/image/partitioning.sh around root/boot partition handling (adds btrfs @ subvolume logic), overlapping in the same function area.

Suggested labels

size/medium

Suggested reviewers

• iav
• igorpecovnik
• leggewie
• chraac

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title clearly summarizes the primary change of enabling minimal btrfs compressed images by adjusting partition handling and configuration, and it is concise, specific, and directly relevant to the changeset.
Description Check	✅ Passed	The description directly explains the motivation for the partition logic change, how it enables minimal images for non-ext4 filesystems, and includes testing details, making it clearly related to the changeset.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 141432e and a45d24a.

⛔ Files ignored due to path filters (1)

• patch/u-boot/u-boot-rk3506/forge1-btrfs.patch is excluded by !patch/**

📒 Files selected for processing (2)

• config/boards/armsom-forge1.csc (1 hunks)
• lib/functions/image/partitioning.sh (1 hunks)

🧰 Additional context used

🧠 Learnings (3)

📚 Learning: 2025-09-14T06:29:18.958Z

Learnt from: amazingfate
PR: armbian/build#8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.

Applied to files:

• config/boards/armsom-forge1.csc

📚 Learning: 2025-09-14T06:10:25.610Z

Learnt from: EvilOlaf
PR: armbian/build#8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.

Applied to files:

• config/boards/armsom-forge1.csc

📚 Learning: 2025-09-11T06:12:54.213Z

Learnt from: SuperKali
PR: armbian/build#8609
File: config/boards/nanopi-r76s.conf:5-5
Timestamp: 2025-09-11T06:12:54.213Z
Learning: In the Armbian build system, board family configuration files (like config/sources/families/rk35xx.conf) can inherit kernel branch definitions from common include files (like config/sources/families/include/rockchip64_common.inc). Even if a branch like "edge" is not defined directly in the family conf file, it may be available through the sourced include file.

Applied to files:

• config/boards/armsom-forge1.csc

🧬 Code graph analysis (2)

config/boards/armsom-forge1.csc (1)

config/sources/vendors/mekotronics/mekotronics-rk3588.hooks.sh (2)

• post_family_config__meko_use_mainline_uboot (22-42)
• post_family_config__vendor_uboot_mekotronics (8-16)

lib/functions/image/partitioning.sh (2)

extensions/fs-cryptroot-support.sh (1)

• extension_prepare_config__prepare_cryptroot (10-22)

extensions/cloud-init/cloud-init.sh (1)

• extension_prepare_config__ci_compatibility_check (30-40)

🔇 Additional comments (2)

config/boards/armsom-forge1.csc (1)

4-4: LGTM! Board-specific defconfig is appropriate.

Switching from generic-rk3506_defconfig to forge1-rk3506b_defconfig follows the standard pattern of using board-specific U-Boot configurations, as seen in other board implementations.

lib/functions/image/partitioning.sh (1)

116-122: LGTM; unified boot partition logic is consistent.

Please verify that boards defining both BOOTSIZE≠0 and BOOTFS_TYPE (e.g. aml-c400-plus.conf, licheepi-4a.eos, longanpi-4b.csc, odroidc1.conf, radxa-cubie-a5e.csc, etc.)—which default to ext4 rootfs—are intended to now receive a separate boot partition.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[leggewie]

Is there a way this could be generalized so that other boards can profit from this feature?

[amazingfate]

Is there a way this could be generalized so that other boards can profit from this feature?

Declaring these options in board config file should work:

ROOTFS_TYPE=btrfs
BTRFS_COMPRESSION=zstd
FIXED_IMAGE_SIZE=500
INSTALL_ARMBIAN_FIRMWARE=no

[igorpecovnik]

generalized
Declaring these options in board config file should work:

And under condition that boot loader have btrfs enabled. Which in general is, but still, can be or can not be ...

This is hard to generalize for all boards. If we would have armbian-uboot.sh similar to armbian-kernel.sh but that is not worth developing.

[github-actions]

✅ This PR has been reviewed and approved — all set for merge!

[iav]

Seems it breaks, at least, ODroin-M1 (not tested anything else yet).
I assume you expected this. And perhaps you already know the best way to fix it?
To add BOOTPART_REQUIRED=yes into board config? But then boot will be added for ext4 fs too...

[amazingfate]

Seems it breaks, at least, ODroin-M1 (not tested anything else yet). I assume you expected this. And perhaps you already know the best way to fix it? To add BOOTPART_REQUIRED=yes into board config? But then boot will be added for ext4 fs too...

Before this PR all btrfs rootfs is booting from kernel inside a ext4 boot partition. If you want to keep the old state, declare BOOTPART_REQUIRED=yes or BOOTFS_TYPE=ext4 in board config.

If you want btrfs rootfs without boot partition, you have to enable btrfs in u-boot if it is supported.

[iav]

First of all, I want my devices to keep booting.
I don't know if their u-Boot supports booting from btrfs or not.
I'll try to revert to the old behavior using BOOTFS_TYPE=ext4 for my broken devices.

Thank you for hint.