[Bug]: Khadas oowow image generation with BTRFS is broken

[lockheed]

What happened?

The image is generated and seen in OOWOW as valid, but after flashing it by OOWOW, there's just bootloop with black screen.

Here's the command line:

./compile.sh EXPERT="yes" ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd EXT="image-output-oowow" KHADAS_OOWOW_BOARD_ID=VIM1S

resulting image can be downloaded here.

I also tried generating an image without ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd and it booted fine.

Maybe it's something to do with UBOOT not supporting BTRFS for boot drive, but the last time I've seen that claimed was 5+ years ago, and since they that should have been fixed.

How to reproduce?

Generate an image with root on BTRFS.

Branch

main (main development branch)

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

Ubuntu 22.04 Jammy

Are you building on Windows WSL2?

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

Relevant log URL

No response

Code of Conduct

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

[github-actions]

Hey @lockheed! 👋

Thanks for opening your first issue with the Armbian project — we’re glad to have you here! 🧡
Your input doesn’t just help us improve the project — it benefits everyone who uses Armbian.

If you'd like to stay informed about project updates or collaborate more closely with the team,
you can optionally share some personal contact preferences at armbian.com/update-data.
This helps us keep in touch without relying solely on GitHub notifications.

Also, don’t forget to ⭐ star the repo to support the work — and welcome aboard! 🚀

[github-actions]

Jira ticket: AR-2692

[igorpecovnik]

Maybe it's something to do with UBOOT not supporting BTRFS for boot drive, but the last time I've seen that claimed was 5+ years ago, and since they that should have been fixed.

VIM1S is not using mainstream u-boot and in such cases we need to lower expectations. Booting from BTRFS is probably not supported, u-boot is from 2019 ... This is pretty much corner case, which could cost a lot of time with resources we don't have and with unsure results. If u-boot is some old fork, it was usually setup by one person once and even its open source, its not maintained by anyone else except by Khadas engineers, here and there for more critical problems. Upgrade to modern mainstream is often mission impossible. It has to be done from scratch and can take years to completion. Until this hardware doesn't get that - we can't invest not even hours, while months are needed ... use what works: ext4

[lockheed]

Is it not possible to just upgrade uboot on the user side?
If not, then what needs to stay on ext4? Just /boot?

[igorpecovnik]

Is it not possible to just upgrade uboot on the user side?

u-boot is a tool and OS that helps you (preparing to) boot some hardware. In order to bring this SoC up, you need to add and enable certain drivers and tools. Most of this is done in proprietary way. Porting this to modern u-boot is often - mission impossible - depending how ugly initial code was made, avail resources and interest. It's not near to "just upgrade", but its a serious development and porting, often completely rewriting the code as changes to u-boot structure and drivers significantly changed in years. And once code is ported, someone with advanced and expensive knowledge needs to maintain it. There are tons of cheap SoCs out there, containing proprietary u-boot machinery. Remember - vendor does not want you to use anything else. They support that initial firmware while modern based u-boot is only community based effort.

This only happens when big enough common interest, persistence and luck comes into right position. I won't be doing research to tell you exact numbers, but many, also popular boards (Odroid C1, already old and deprecated hardware, is such example), will never receive (stable, maintained, supporting all functions) modern u-boot support. In many cases mainline u-boot does not support advanced features such as booting from network as the one who did this, didn't finish the job or there are different NIC and not all are supported ... there are many places where things can and does go wrong. Remember that someone needs to volunteer weeks to months in first place.

Upgrade on user side is only possible, when there is support with old factory u-boot and also with a modern variant. But even that can be challenging as we have variety of boot scripts methods, which might also needs to be updated, when we change u-boot from 2016 to 2025 or something like that. U-boot updates are, in Armbian case, limited to upgrades on mainline (2025.1 -> 2025.5 ... ) , which is usually safe and when some enhancement or bug-fixes are applied to the code. In Armbian, u-boot is just a .deb package that already contains a flashing mechanism. But is not executed automatic - with additional parameter as upgrade of critical fw must be controlled elsewhere (armbian-config).

If not, then what needs to stay on ext4? Just /boot?

Yes, I think so. IMO try this way: https://docs.armbian.com/User-Guide_Getting-Started/#installation Should be doing this for you.

[lockheed]

Yes, I think so. IMO try this way: https://docs.armbian.com/User-Guide_Getting-Started/#installation Should be doing this for you.

I already tried that in the past. Choosing root as Btrfs results in Vim1S not booting at all, just stuck at blank screen.

Is it possible to network-boot on Vim1s?

[igorpecovnik]

Choosing root as Btrfs results in Vim1S not booting at all, just stuck at blank screen.

Serial console logs are must have to debug this kind of operations. This method should in theory work and sometimes is perhaps easily fixable if logs are provided.

Is it possible to network-boot on Vim1s?

Don't know - attach serial console / check on router if it gets IP address when no boot media is attached. This is rarely default enabled option, but some boards (boot loaders) does support that. But how-to from here - again don't have an answer. Check forums and (official Khadas docs) for clues. Standard in custom hardware world is that there are no standards ...