@aparcar @Ansuel @hauke could you take a look at this PR?
Also there is a fstools patch included to support EROFS + overlayfs, but I'm not sure how to submit upstream.

Thanks for continuing the thing... I find it impressive that erofs now is actually smaller than squashfs

.... Resolve a build issue due to the lack of dependency of libtool...

...
checking dependency style of ccache /__w/openwrt/openwrt/openwrt/staging_dir/host/bin/gcc... (cached) gcc3
./configure: line 6150: LT_INIT: command not found
checking pkg-config m4 macros... yes
...
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: 'man/Makefile.in'
make[2]: *** [Makefile:40: /__w/openwrt/openwrt/openwrt/build_dir/host/erofs-utils-1.8.9/.configured] Error 1
time: tools/erofs-utils/compile#5.81#3.34#11.04

need to retrigger the CI... @aparcar @Ansuel ...

Thanks for continuing the thing... I find it impressive that erofs now is actually smaller than squashfs

EROFS has landed advanced features like fragments and compressed data deduplication which makes the image size competitive.

But currently EROFS is still lack of metadata compression, and I'm working on it, hopefully it could be resolved this year so that the image sizes can be even smaller.

Also as for LZMA, it seems SquashFS supports to adjust -Xe -Xlc 0 -Xlp 2 -Xpb 2, which I need to support later too.

@hsiangkao i feel lzma option should be easy to implement and should be enough to make it on par with squashfs performance.

@hsiangkao i feel lzma option should be easy to implement and should be enough to make it on par with squashfs performance.

Yes, lzma options just need to add some command line option. Another one is the BCJ filter, XZ author @Larhzu already makes a generic interface in xz-utils 5.8.0 so that any compression algorithm in addition to lzma/xz can leverage that: https://github.com/tukaani-project/xz/releases/tag/v5.8.0
but I need to find extra time to support in EROFS. Anyway, those stuffs will make the image size smaller even further and I need more time to do step-by-step.

@Ansuel btw, is it possible to depend libuuid for erofs-utils?

logs/tools/erofs-utils/compile.txt-   39 |         for (;;)
logs/tools/erofs-utils/compile.txt-   40 |         {
logs/tools/erofs-utils/compile.txt-   41 |                 ssize_t r;
logs/tools/erofs-utils/compile.txt-   42 |                 int err;
logs/tools/erofs-utils/compile.txt-   43 | 
logs/tools/erofs-utils/compile.txt-   44 | #ifdef HAVE_SYS_RANDOM_H
logs/tools/erofs-utils/compile.txt-   45 |                 r = getrandom(out, size, flags);
logs/tools/erofs-utils/compile.txt-      |                     ~~~~~~~~~
logs/tools/erofs-utils/compile.txt-      |                     s_getrandom
logs/tools/erofs-utils/compile.txt-1 error generated.

I've seen a macos failure which seems macos doesn't have getrandom(). Otherwise I may need a oot patch to work around this..

Another failure seems trivial, I've reran FIXUP=1 to fix up this.

why libuuid?

For the getrandom it's not the first time I see that... I remember we have some downstream patch to address that (thank god it's only that on macos)

why libuuid?

For the getrandom it's not the first time I see that...

Random uuid generation needs that, although for openwrt use case, it's -Uclear.

I remember we have some downstream patch to address that (thank god it's only that on macos)

could you give me some pointer?

Random uuid generation needs that, although for openwrt use case, it's -Uclear.

ideally if possible it should be optional. But is it for host tool or for the target system? The erofs-utils package is optional right?

For getrandom I have to search let keep it that way currently. Maybe you can post here the oot patch

Random uuid generation needs that, although for openwrt use case, it's -Uclear.

ideally if possible it should be optional. But is it for host tool or for the target system?

I think it's a host tool.

The erofs-utils package is optional right?

Yes, I propose here as an optional one first.

For getrandom I have to search let keep it that way currently. Maybe you can post here the oot patch

I will try to mask off this with a oot patch, since I don't want to release a new erofs-utils version due to this.

I think it's a host tool.

if it's only host tool then we don't really care about dependency. Totally ok to depend on that

I think it's a host tool.

if it's only host tool then we don't really care about dependency. Totally ok to depend on that

But I know little about the openwrt Makefile style, how to add libuuid dependency?
Anyway, I already write a patch to disable getrandom() on MacOS, I will try this way first.

repushed (need another CI trigger), hopefully all CI issues are resolved.
@Ansuel @aparcar could you also help review?

EROFS per-cpu decompression kthread workers (EROFS_FS_PCPU_KTHREAD) [N/y/?] (NEW) 
EROFS high priority per-CPU kthread workers (EROFS_FS_PCPU_KTHREAD_HIPRI) [Y/n/?] (NEW) 

Kernel stills seems to ask some questions

Run . .github/workflows/scripts/ci_helpers.sh
tools/erofs-utils/Makefile
tools/erofs-utils/patches/0001-erofs-utils-fix-missing-getrandom-on-some-macOS-plat.patch
Some package Makefiles requires fix. (run 'make package/check FIXUP=1' and force push this pr)
You can also check the provided artifacts with the refreshed patch from this CI run.

What's wrong with that?
I ran both make tools/erofs-utils/check FIXUP=1 and make package/check FIXUP=1 but they change nothing.

EROFS per-cpu decompression kthread workers (EROFS_FS_PCPU_KTHREAD) [N/y/?] (NEW) 
EROFS high priority per-CPU kthread workers (EROFS_FS_PCPU_KTHREAD_HIPRI) [Y/n/?] (NEW) 

Kernel stills seems to ask some questions

Hi @aparcar! Oh, I forgot 6.6 has the kconfigs, will fix.

❯ git diff
diff --git i/tools/erofs-utils/Makefile w/tools/erofs-utils/Makefile
index 9014e208da4..4fa77944462 100644
--- i/tools/erofs-utils/Makefile
+++ w/tools/erofs-utils/Makefile
@@ -12,7 +12,7 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
-PKG_MIRROR_HASH:=b9f054afc4cbba76ce889df9e4108b2a3a8ad266c9bcd94e4ca36680939d9c02
+PKG_MIRROR_HASH:=feab7386de6faf11cb29af5bfa240ea119b14bfd66c14d80de0509c1ab16dcc6
 PKG_SOURCE_DATE:=2025-06-26
 PKG_SOURCE_VERSION:=81169bf3cfd26b8f2b3aa3b20da23971168a90a9

repushed with kconfig changes and PKG_MIRROR_HASH.

@hsiangkao @Ansuel what about the initramfs, can't we compress that via erofs, too?

@hsiangkao @Ansuel what about the initramfs, can't we compress that via erofs, too?

Do you mean erofs in the initramfs or the initrd one? I don't dig into how openwrt works on this so sorry about my limited knowledge. I suggest landing rootfs first since it takes too long and I found an extra slot these days.
As for the initrd one, that is quite a long story, see:
https://lore.kernel.org/all/20250320-initrd-erofs-v1-1-35bbb293468a@cyberus-technology.de/
https://lore.kernel.org/all/20250322-initrd-erofs-v2-0-d66ee4a2c756@cyberus-technology.de/
I think it needs more time to support initrd since hch doesn't allow a simple change.

@aparcar why it still fails? I've already replaced the patch and it makes me no way to debug this issue...

@hsiangkao please ignore it for no I will take care of fixing in free cycle :D

@hsiangkao please ignore it for no I will take care of fixing in free cycle :D

It seems other than the style failure, the other CIs are passed now.
Could you consider merging it now? @aparcar @Ansuel
Without that, users have no chance to try this filesystem.

Without that, users have no chance to try this filesystem.

What platforms are expected to boot with EROFS currently? I tried ramips (Xiaomi Router 3G), and encountered a boot failure.

Currently have no means of getting logs though, sorry. Lost my serial cable somewhere. I'm assuming it failed to mount the system and panicked.

Without that, users have no chance to try this filesystem.

What platforms are expected to boot with EROFS currently? I tried ramips (Xiaomi Router 3G), and encountered a boot failure.

Currently have no means of getting logs though, sorry. Lost my serial cable somewhere. I'm assuming it failed to mount the system and panicked.

I only tried the x86 platform and it can successfully boot.

and the mount result:

I don't have a real router to test this for now.

0001-libfstools-add-support-for-EroFS-based-images.patch

-       len = fread(&sb, sizeof(sb), 1, f);
+       len = fread(sb, sizeof(*sb), 1, f);

That will work then. @Ansuel , will you revise your patch?

ok stupid mistake! Thanks for bisecting it.

That will work then. @Ansuel , will you revise your patch?

ok stupid mistake! Thanks for bisecting it.

everything works now, will you merge this PR then? I guess no more stuff I need to work?

Final confirmation: Xiaomi Router 3G (v1) boots EROFS after a clean reclone and modifying config-6.12 to have erofs instead of squashfs as rootfs in cmdline.

Some more numbers from my second test device

mvebu/cortexa9 (arm/cortex-a9+vfpv3-d16)

8446306  root.squashfs
8794112  root.erofs    (+4.1%)

ath79/generic (mips/24kc)

4357596  root.squashfs
4349952  root.erofs    (-0.2%)

Both targets have quite a few config changes, but the difference between both sets is only the EROFS feature and command line. Booting and running just fine for a couple of minutes.

I come back to this PR - my Raspberry PI 4 (bcm27xx/bcm2711) does not boot from erosfs. Kernel starts but then ends with kernel panic when trying to mount root file system. Logs say that it supports ext4 and squashfs and root file system could not be identified. I've turned on erofs generation in menuconfig, that also selected kernel-support for erofs, but it does not work. Any ideas? I do not want to open an issue before knowing that it is really an OpenWrt issue.

Probably missing rootfstype in cmdline.txt which is not affected by any config flags

Did you try editing this line like this?

-console=tty1 console=serial0,115200 root=@ROOT@ rootfstype=squashfs,ext4 rootwait
+console=tty1 console=serial0,115200 root=@ROOT@ rootfstype=erofs,squashfs,ext4 rootwait

@stklcode Oh yes, i missed that. Works now. I think the erofs should be added to the default cmdline.txt for bcm27xx.