x86, bcm27xx: is squashfs+f2fs layout (rather than ext4) actively supported?
luz at plan44.ch
Sun May 28 05:53:00 PDT 2023
sorry for asking again, but I'm really stuck and seeking help/hints
about how to proceed with two issues that break sysupgrade at least
for bcm27xx (RPi) targets which use squashfs+f2fs:
- sysupgrading from a smaller to a larger /boot partition size bricks
devices because something (f2fs?) keeps holding on the second
partition, preventing unmounting it, preventing mounting the larger
/boot (because it overlaps), preventing sysupgrade.tgz to be saved as
it should. Details in .
- sysupgrading can occasionally fail depending on data following the
squashfs part on disk, because there is no padding that would ensure
mount_root cannot possibly interpret that data as start of an f2fs.
Details in ,.
As there was very little response to [1..3], I wonder if using
squashfs+f2fs on bcm27xx (and x86) might be a not really supported
option at all? At least, it seems to be a very rarely used option?
I would like to contribute fixes for these issues, and spent a lot of
time to analyze both of them, and think I pretty much could find the
However I am stuck with  technically (no more ideas how to free the
busy partition), and while I could probably hack something for  on
bcm27xx, seeing that the same mechanism is used in x86's and serveral
other target's platform.sh, I'd prefer a more informed path of
I don't expect others to fix this, but I really need some input from
knowledgeable OpenWrt devs to get any further with this. And if it's
only stating squashfs+f2fs is something one should NOT actually use on
these non-mtd platforms at all.
Thanks in advance
Lukas Zeller, plan44.ch
luz at plan44.ch - https://plan44.ch
More information about the openwrt-devel