ODroidM1: add BOOTFS_TYPE=ext4 into board config to fix after #8751#8829
ODroidM1: add BOOTFS_TYPE=ext4 into board config to fix after #8751#8829iav wants to merge 2 commits intoarmbian:mainfrom
Conversation
WalkthroughAdded a new board configuration variable Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (25)📓 Common learnings📚 Learning: 2025-10-24T04:46:22.901ZApplied to files:
📚 Learning: 2025-08-30T06:48:09.091ZApplied to files:
📚 Learning: 2025-05-07T20:49:40.969ZApplied to files:
📚 Learning: 2025-06-12T21:14:36.024ZApplied to files:
📚 Learning: 2025-10-14T05:08:11.785ZApplied to files:
📚 Learning: 2025-09-01T06:11:43.476ZApplied to files:
📚 Learning: 2025-07-27T13:03:53.146ZApplied to files:
📚 Learning: 2025-07-23T07:30:52.265ZApplied to files:
📚 Learning: 2025-08-30T06:56:33.372ZApplied to files:
📚 Learning: 2025-07-27T13:03:53.146ZApplied to files:
📚 Learning: 2025-09-12T21:44:09.061ZApplied to files:
📚 Learning: 2025-06-04T23:45:38.860ZApplied to files:
📚 Learning: 2025-09-12T19:28:38.491ZApplied to files:
📚 Learning: 2025-03-31T22:20:48.475ZApplied to files:
📚 Learning: 2025-09-14T06:32:29.806ZApplied to files:
📚 Learning: 2025-09-14T11:37:35.089ZApplied to files:
📚 Learning: 2025-07-17T04:12:33.125ZApplied to files:
📚 Learning: 2025-09-07T17:39:32.272ZApplied to files:
📚 Learning: 2025-08-02T05:46:10.664ZApplied to files:
📚 Learning: 2025-03-31T22:20:41.849ZApplied to files:
📚 Learning: 2025-07-27T15:53:30.629ZApplied to files:
📚 Learning: 2025-05-07T20:49:40.969ZApplied to files:
📚 Learning: 2025-07-25T03:51:50.830ZApplied to files:
📚 Learning: 2025-07-25T03:51:50.830ZApplied to files:
🔇 Additional comments (1)
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. Comment |
github-actions
bot
added
size/small
|
✅ This PR has been reviewed and approved — all set for merge! |
|
This looks like it's forcing a separate /boot partition to address the btrfs case. |
igorpecovnik
added
Work in progress
github-actions
bot
added
Needs review
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 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.
📒 Files selected for processing (1)
lib/functions/image/partitioning.sh(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
lib/functions/image/partitioning.sh (1)
extensions/cloud-init/cloud-init.sh (1)
extension_prepare_config__ci_compatibility_check(30-40)
| # Check if we need boot partition | ||
| # Specialized storage extensions like cryptroot or lvm may require a boot partition | ||
| if [[ $BOOTSIZE != "0" && (-n $BOOTFS_TYPE || $BOOTPART_REQUIRED == yes) ]]; then | ||
| if [[ $BOOTSIZE != "0" && ( $BOOTFS_TYPE != "$ROOTFS_TYPE" || $BOOTPART_REQUIRED == "yes" ) ]]; then |
There was a problem hiding this comment.
What about the condition that user just want a seperate boot partition with same filesystem type as root? There are other declarations like BOOTFS_TYPE="ext4" in config/boards.
There was a problem hiding this comment.
User just want a separate boot partition with same filesystem can use BOOTPART_REQUIRED == "yes".
Other declarations like BOOTFS_TYPE="ext4" in config/boards will work, I suppose.
BOOTFS_TYPE I test, it works. If you worries about other declarations — just say, will think about it.
BOOTFS_TYPE have to be filled in boadrconfigs for boards that can boot only from ext4 or fat fs.
There was a problem hiding this comment.
I would like to remind you that sometimes, albeit rarely, not only ext4 and btrfs fs are used.
There was a problem hiding this comment.
Here is the build log before this change: https://paste.armbian.com/gatonibeha.
Here is the build log after this change: https://paste.armbian.com/eqohipewax.
This change will let us not create seperate ext4 boot partition if there is BOOTFS_TYPE="ext4" declared in board config. And the reason of declaring this should be that u-boot of this board doesn't support single root partition well. We should not break this logic.
There was a problem hiding this comment.
Yeah. Seems to me the information needed is "what kinds of filesystems is u-boot able to boot from?" and "how well can u-boot tolerate a mixed root/boot filesystem (prefix handling)?"
If u-boot directly supports btrfs, a separate /boot is not required (but possible/optional).
Unless we make btrfs default somehow, I wouldn't go introducing separate /boot where there wasn't one.
For boards that currently have an ext4 rootfs, and an ext4 bootfs, it shouldn't be changed either (prefix-challenged case).
There was a problem hiding this comment.
That could be a compromise, but I still think introducing a separate /boot per default, when using an ext4 rootfs, is a regression.
Again: the board/u-boot should advertise that it can or not boot btrfs (and what to use instead), and the brtfs-enabling code should adapt to that, only when using a non-default arrangement.
There was a problem hiding this comment.
the board/u-boot should advertise that it can or not boot btrfs (and what to use instead), and the brtfs-enabling code should adapt to that
What to you mean "should advertise" in context of build system?
If you mean info in boardconfig file — then it is what I want andI believe that this is what should be done.
In case I am wrong — please, еxplain your wish with more details.
There was a problem hiding this comment.
We could introduce something like:
declare -A -g BOARD_BOOTLOADER_FS_BOOT_SUPPORT=()
BOARD_BOOTLOADER_FS_BOOT_SUPPORT+=(["ext4"]="yes"]) # supports booting from ext4
BOARD_BOOTLOADER_FS_BOOT_SUPPORT+=(["btrfs"]="ext4"]) # does NOT support booting from btrfs, use ext4 insteadAnd use that information in the brtfs/fsfs/whatever code and partitioning code to determine the ideal setup given the restrictions of the bootloader for that board.
There was a problem hiding this comment.
Further, since u-boot artifact is available when building image, one could even peek into the final defconfig and decide based on things like CMD_BTRFS being available or not.
There was a problem hiding this comment.
but I still think introducing a separate /boot per default, when using an ext4 rootfs, is a regression.
ok, don't need to do that, there will be no regression if do this:
if [[ $BOOTSIZE != "0" && ( $BOOTFS_TYPE != "ext4" ||$BOOTFS_TYPE != "$ROOTFS_TYPE" || $BOOTPART_REQUIRED == "yes" ) ]];
Looking inside the uBoot artifact is way, way too complicated, in my opinion. I definitely can't code it.
|
@rpardini then return check for |
|
Hmm, the plot thickens. In this case, maybe add support for BTRFS to odroidm1's u-boot? Should be simple to do, using That way everyone (with this board) is happy and you get full BTRFS goodness without needing a separate /boot? |
|
If the issue is personal to me, then I can simply set any necessary setting in my config in userpatches, easy. I started this topic because it seemed wrong to me that every person (except for the one who build image with rootfs to which his uboot can boot correctly but fs != ext4 - but such devices are probably few and far between) after #8751 will get an inoperable image, if he doesn’t know in advance that in addition to specifying the root file system type, he should also specify that there should be a separate /boot, and, possibly, the file system type /boot. But if I'm wrong, then okay, you know better. |
|
Search for |
Armbian's default is ext4 root. If user is building a custom image, with a custom root filesystem, then they should be aware of the implications: either make sure the bootloader supports it, or adapt their config to use a separate, supported, boot partition. Making life worse for default/ext4 users (which are unaware of btrfs even existing), by introducing a separate /boot, is not the solution. It was bad enough when we had fat32 /boot.
Yes, and?... Other boards do the equivalent by patching the defconfig, which makes bumping u-boot versions much harder as defconfigs change upstream constantly and then patches need to be re-worked. |
I add into |
|
Hmm. Get (ofc...) u-boot UART logs, and poke around the partitions and filesystems ( My odroidm1 is in production role so I can't test with this exact device but might try on some 3588 also with mainline u-boot to see. How do I build a BTRFS image? |
|
build log https://paste.armbian.com/ofaxufuxic try to boot log http://paste.armbian.com/piyonofoxu.vbnet what can I try more? |
|
I tried with a 3588 using mainline 2025.10 + From your logs seems like you're falling into unrelated traps (u-boot with btrfs support not being used; remember it is never loaded from USB or NVMe, instead only from SPI/eMMC/SD). Here's me fiddling with it: I also notice the image ends up missing |
|
So my mistake was that I used a USB drive for testing, instead if sdcard or emmc. Then I have another question: in case btrfs is available at least on "fresh" devices with fresh uboot, are there a reason to not switch btrfs support in uboot on where possible? |
|
I flash my image to microsdcard, remove usb flash disk and emmc module. But when I see into output/debs folder on builder computer, I see file Does it mean it not used uboot from sdcard at all? then where it is? And if it not used uboot from boot device — then I can't boot from btrfs image, even if btrfs supported by uboot on image? |
|
From the logs it seems your machine is loading u-boot from SPI. Again, none of this is related to BTRFS support. |
|
Seems ODroidM1 run uboot from MTD, not from sdcard. Ok, you right, thank you. However, for this to be true, special preparation of the device was required. I don't think this is the same as simply creating a working system image. |
|
are there a reason to not switch btrfs support in uboot on where possible (excluding tiny devices)? |
That's always true of ODROID devices, which come from factory with MTD (SPI-NOR) infected with "Petitboot".
No reason, except the fact in Armbian we've fragmented u-boot configs, some done in patches, some done in hooks, some done nowhere, some boards using mainline uboot, some boards using vendor, etc. So this is effectively per-board. My suggestion for now is to enable as we go. |
|
This PR is probably deprecated now due to #8857 ? |
yes. |
5 participants
After #8751 ODroid-M1 not boots.
With this string it boots again.
How Has This Been Tested?
Build image for ODroid-M1 with root on btrfs without patch. System not boots from image.
Build image for ODroid-M1 with root on btrfs with patch. System boots from image.
Checklist: