Search the Community

Good that this is made default now for various boards. If a board/computer has no factory written bootloader, so only bootROM/maskROM, then this allows way more flexibility and also will get rid of endless topics and support issues that have their root cause in SD-card (failing, or worse fakes, fake brands, etc). As a scrub either done automatically or as support request on-demand/ad-hoc will tell. Also many operations can be done while the board/computer is kept running, no reboot needed. Like transferring rootfs OS from SD-card to NVME and many more great things. Like replacing an SD-card without reboot. Or rollback to know-good older snapshot after faulty update. I see I wrote some things about it here: https://forum.armbian.com/search/?q=CONFIG_CMD_BTRFS&quick=1 For boards/computers with factory written bootloader, so PCs with UEFI or BIOS or the strange Raspberries with their boot(EEP)ROM that need a 1st FAT, it is a different story. I figured out that for my computers that already use Btrfs for rootfs for years, even tiny/old RPi0/1, it is currently better alignment, so that I stick to heaving an extra boot partition still. It can be very small, I had defaulted to 40MiB some years ago for a single Linux OS VM (x86 or ARM), but just for some bootaa64.efi file that is already a lot. For RPi, 3MiB was enough, so you store only a bootcode.bin start* fixup* config.txt uboot.bin bootaa64.efi. But that extra boot partition is also easily very confusing, especially for RPi like methods where kernel+initramfs+DTB are copied. Also, I had Btrfs enabled U-Boot, an Ext4 bootpartition and Btrfs rootpartition while doing experiments (booting from Btrfs raid1 straight from U-Boot) on QEMU and AllwinnerH3. kernel+initramfs+DTB were accidentally read from Ext4 (/) instead of Btrfs (/boot) and more such confusion. So then I recompiled U-Boot without Ext4 (so only FAT,Btrfs), then fine. But generally I would keep Ext4 of course. With just 1 partition, then those issues are is avoided. Then simply 'U-Boot object' and 'rootfs object', where the latter can still be chosen Ext4. Btrfs U-Boot + rootfs also would make raw/flat images viable maybe. xz-compressed will certainly have smaller download file, but for full desktop variant images, there might be an overall advantage. If rootfs is written by Armbian build with let's say compress-force=zstd:9, only first MBR+bootloader sectors, the Btrfs metadata and some filesystem slack is not compressed. I think some statistics are needed first, maybe it is not worth the effort for mass-downloads also via torrents, mirrors, etc, but for own local builds I certainly see benefits. At least I force compress almost all newly written block-devices, so also a restore from backups. It can keep thin-provisioned volumes/images very small, also roughly halves the write-time for (slower/older) SD-cards.

Since there is a thread about adding ZFS support to the U-Boot build, I thought I'd post a similar request for btrfs. I was looking through the helios u-boot repo a few days ago and noticed that it isn't built with btrfs support. While I could make a separate ext4 /boot partition, it would be convenient to have the entire eMMC formatted as btrfs. This allows for me to make easy and fast backups using btrfs send/receive, and also allows for snapshotting prior to upgrades (via e.g. snapper), and rolling back to a different snapshot at boot. My turris onmia router uses u-boot with btrfs native root, and I've used the snapshot rollback support a couple of times. They have a fancy snapshot selection that can be done via the reset button without a serial console, but just having the ability to select previous snapshots at the u-boot menu would be quite convenient. I believe all that is needed is to enable CONFIG_CMD_BTRFS. https://github.com/u-boot/u-boot/blob/832bfad7451e2e7bd23c96edff2be050905ac3f6/cmd/Kconfig#L2047 Thanks for your consideration!

I managed to build u-boot-2024.10 with Btrfs for 32-bit (using systemd-nspawn). See: https://docs.u-boot.org/en/latest/build/index.html It would be more easy to do for native aarch64, but that I already knew when building for 'machine' 'qemu-arm64'. As example for my NanoPi-NEO, all in extra separate src/build folder: dpkg -L linux-u-boot-nanopineo-current - add/change CONFIG_CMD_BTRFS=y CONFIG_FS_BTRFS=y in nanopi_neo_defconfig make menuconfig and save the .config make -j8 - see platform_install.sh how and where to write the newly build u-boot-sunxi-with-spl.bin (about 570kByte, so fits in my MBR partition starting at sector 2048) So after merging boot files from the mmcblk0p1 Ext4 partition to a folder /boot on mmcblk0p2 Btrfs rootfs, I started fdisk and made Btrfs rootfs p1 (using the same start-end sectors), so only 1 partition. Same as you actually have on standard Armbian images. And comment out the line in fstab for mount of separate boot partition (or add nofail option maybe). Then reboot and restarted without problems. I did actually all via remote ssh, although i also had serial USB console cable connected as I wanted to see the boot log, but was as expected. A remark I saw was that it could not write environment to FAT. That is something I need to think about. Do I gain something if that is possible. Currently not on single OS SBCs for me I guess. A bootFAT might be more convenient for people who rely more or only on a Windows/MacOS computer as their main desktop. I use Linux so no issue with fixing SD-cards in case of non-boot because I messed up something testing or so. What went wrong afterwards is my backup script via ssh. For SoCs that use binary blob bootloader, I copy/compare/backup the first sectors till p1 (usually 2048 or so, so a 1 MiB file). That size determination went wrong, it created a 257MiB file in /tmp, so fails with a 512MiB SBC. But learning more now after 10+ years SBCs, I think I should do that smarter, just re-use platform_install.sh or so. I think I will have to look at 1st boot resize script(s). It is max SD-card, so all space gone for Ext4. I really hate that. Even more when done on fixed/soldered eMMC or NVME. Ext4 cannot be shrunk in a running system later on. Btrfs can, so last hack I did on an Ext4 downloaded image (RPiOS64 Lite) was double the image file, max Ext4 on that image and then convert to Btrfs with btrfs-convert. It also need kernel cmdline and fstab change still, but that is more or less it.

I've seen that in there too, but I've never been able to get a subvolume to boot without using a boot partition. There is also CONFIG_CMD_BTRFS and I could be completely off here, but my thought was maybe a command needs to be executed with a boot script in order for the subvolume to be read/found? I normally use extlinux and with CONFIG_FS_BTRFS & CONFIG_CMD_BTRFS enabled it has always been a no go for me. Maybe someone else here has a thought on the subject? EDIT I tried 3 times getting this working using a Radxa Zero and it was a no-go for a single partition. Once I added a boot partition, it booted right up. radxazero: ~ $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 253M 0 part /boot └─mmcblk0p2 179:2 0 29.5G 0 part / mmcblk1 179:32 0 14.6G 0 disk ├─mmcblk1p1 179:33 0 253M 0 part └─mmcblk1p2 179:34 0 14.3G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk zram0 253:0 0 1G 0 disk [SWAP] radxazero: ~ $ findmnt /boot; findmnt / TARGET SOURCE FSTYPE OPTIONS /boot /dev/mmcblk0p1 ext4 rw,relatime TARGET SOURCE FSTYPE OPTIONS / /dev/mmcblk0p2[/@] btrfs rw,noatime,compress=lzo,ssd,space_cache=v2,subvol