setup erofs for tiny rootfs!

[adeebshihadeh]

Continuation of the compressed filesystem experiments from AGNOS (commaai/agnos-builder#438), which halted after experiencing SquashFS instabilities on our old kernel.

Should be stable given how prevalent it is in the Android ecosystem:

EROFS (Enhanced Read-Only File System) is used for system partitions on most modern Android devices running Android 13 or later, as it is mandated by Google to save space and improve performance. Key adopters include Huawei, Honor, OPPO, Xiaomi, Samsung, and Google (Pixel).

NOTE: this only works on mainline. I'll merge this such that it still outputs both an ext4 and erofs image.

---

Config	Size	vs ext4	Tradeoff
ext4 (sparse)	3400 MiB	—	Current baseline, read-write, no compression
none	3302 MiB	97%	No compression — just EROFS metadata savings
lz4, 4k	1811 MiB	53%	Fastest decompression, minimal read amplification
lz4, 16k	1679 MiB	49%	Fast decompression, small clusters
lz4, 64k	1635 MiB	48%	Fast decompression, moderate read amplification
lz4hc,9 4k	1658 MiB	49%	Better ratio than lz4, same decompression speed
lz4hc,9 16k	1485 MiB	44%	Good balance of ratio and read performance
lz4hc,9 64k	1391 MiB	41%	Good ratio, moderate read amplification
lz4hc,12 4k	1656 MiB	49%	Lvl 12 vs 9 barely helps at small clusters
lz4hc,12 16k	1481 MiB	44%	Lvl 12 vs 9 ~same — diminishing returns
lz4hc,12 64k	1386 MiB	41%	Our current pick — good sweet spot
lz4hc,12 256k	1361 MiB	40%	Marginal gain, reads amplified up to 256k
lz4hc,12 1m	1355 MiB	40%	Only 6 MiB smaller than 256k, not worth it
lzma, 4k	1132 MiB	33%	Best ratio, but ~10x slower decompression + very slow build

[greatgitsby]

is there a reason we want to keep both images? do we want vamOS to support the legacy kernel?

[github-actions]

vamOS System Profile

Changes vs master

Metric	Change
Used space	3442.3MB → 3458.4MB (+16.0MB)
Sparse image	3382.2MB → 3414.2MB (+32.0MB)
Package count	517 → 517

Directory size changes (>1MB)

Directory	Change

---

Metric	Value
Used space	3458.4MB / 5959.5MB
Files	55616
Directories	4418
Symlinks	3448
Packages	517

Top 10 Directories

Directory	Size

Category Breakdown

Category	Size	%
xbps packages	2477.7MB	71.6%
Python venv	655.3MB	18.9%
Firmware	1.2MB	0%
Other	324.0MB	9.3%

Top 10 Packages by Size

Package	Size
mit-krb5-libs-1.21.3_1	270.4MB
gawk-5.3.2_1	210.3MB
llvm-21_3	148.6MB
libldns-1.9.0_1	124.3MB
pcre2-devel-10.47_1	74MB
libclang21-21.1.7_1	70.2MB
glib-2.86.1_2	67.1MB
gcc-14.2.1+20250405_4	65.4MB
libcap-progs-2.77_1	56MB
cmake-4.2.2_1	53.2MB

Top 30 Files by Size

File	Size
/usr/lib/llvm/21/lib/libLLVM.so.21.1	124.3MB
/usr/lib/llvm/21/lib/libMLIR.so.21.1	89.7MB
/usr/lib/llvm/21/bin/mlir-transform-opt	82.9MB
/usr/lib/llvm/21/lib/libclang-cpp.so.21.1	56MB
/usr/lib/llvm/21/bin/mlir-translate	53.2MB
/usr/lib/llvm/21/bin/llvm-exegesis	52MB
/usr/lib/llvm/21/bin/llvm-bolt-binary-analysis	50.6MB
/usr/local/venv/lib/python3.12/site-packages/ffmpeg/install/lib/libavcodec.a	50.5MB
/usr/bin/uv	46.3MB
/usr/lib/gcc/aarch64-linux-gnu/14.2/gnat1	40.1MB
/usr/bin/gdb	38.1MB
/usr/lib/gcc/aarch64-linux-gnu/14.2/cc1plus	37.3MB
/usr/lib/libgallium-25.3.3.so	35.4MB
/usr/lib/libllvm-qcom.so	35.2MB
/usr/lib/gcc/aarch64-linux-gnu/14.2/cc1	35.2MB
/usr/lib/gcc/aarch64-linux-gnu/14.2/lto1	33.9MB
/usr/bin/lto-dump	33.9MB
/usr/lib/libRusticlOpenCL.so.1.0.0	32.5MB
/usr/local/venv/bin/ruff	31.8MB
/usr/share/icu/78.2/icudt78l.dat	31.5MB
/usr/lib/llvm/21/lib/libclang.so.21.1.7	30.2MB
/usr/lib/llvm/21/bin/c-index-test	28.6MB
/usr/local/venv/lib/python3.12/site-packages/gcc_arm_none_eabi/toolchain/libexec/gcc/arm-none-eabi/13.2.1/cc1	28.2MB
/usr/lib/libz3.so	27.9MB
/usr/bin/run	26.6MB
/usr/local/venv/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-71e1b124.so	23.6MB
/usr/comma/updater	23.5MB
/usr/comma/setup	23.5MB
/usr/comma/reset	23.5MB
/usr/local/uv/python/cpython-3.12.13-linux-aarch64-gnu/bin/python3.12	21.6MB

[adeebshihadeh]

is there a reason we want to keep both images? do we want vamOS to support the legacy kernel?

Unless it becomes a hassle, yes. Otherwise, it'll be difficult to disambiguate what's causing bugs when we eventually hit them. It's also unclear how we want to ship these changes (all at once or piecemeal).