[ pixel 8 ] request features : repack system_dlkm

[Aarqw12]

hi,

its possible to add features for allow to repack system_dlkm ?

12:17:47.228 [main] WARN cfig.packable.PackableLauncher - 'unpack' sequence completed
[lcockx@lcockx-asustufgamingf15fx506lhtuf506lh boot_editor_v13r3]$ ./gradlew pack system_dlkm.img
12:18:03.701 [main] WARN cfig.packable.PackableLauncher - [system_dlkm.img] will be handled by [SparseImgParser]
12:18:03.776 [main] WARN cfig.packable.PackableLauncher - 'pack' sequence initialized
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at kotlin.reflect.jvm.internal.calls.CallerImpl$Method.callMethod(CallerImpl.kt:97)
at kotlin.reflect.jvm.internal.calls.CallerImpl$Method$Instance.call(CallerImpl.kt:113)
at kotlin.reflect.jvm.internal.KCallableImpl.call(KCallableImpl.kt:108)
at cfig.packable.PackableLauncherKt.main(PackableLauncher.kt:110)
Caused by: kotlin.NotImplementedError: An operation is not implemented: not implemented
at cfig.utils.SparseImgParser.pack(SparseImgParser.kt:88)
... 8 more

[cfig]

1. filesystem types

1.1 ext4: Pixel 8 system_dlkm.img is still readonly ext4 image:

Linux rev 1.0 ext2 filesystem data, UUID=1d99b11c-1e79-5d0a-ad56-ff5d389d8221, 
volume name "system_dlkm" (extents) (large files) (huge files)

1.2 erofs: Google recommends to change to erofs for readonly images, something like this:

system_dlkm.img: EROFS filesystem, compat: SB_CHKSUM MTIME, blocksize=12, 
exslots=0, uuid=A7F0F0DB-EA70-6142-9859-630288E2492F, incompat: LZ4_0PADDING

So I really can not fully understand why Google's latest flagship didn't adopt erofs.

2. image packing flow

2.1 About ext4 system_dlkm:

TBD

2.2 About erofs system_dlkm:

• Android specific dependencies

avbtool
fec
mkfs.erofs
libc++.so

• common dependencies

du

• data dependencies

file_contexts.bin

The image is generated as below flow

Hi @Aarqw12 ,
What's your working flow with system_dlkm.img? Do you have full AOSP code base?
It should be convenient to work under AOSP code base for platform developers/hackers.

[Aarqw12]

1. filesystem types

1.1 ext4: Pixel 8 system_dlkm.img is still readonly ext4 image:

Linux rev 1.0 ext2 filesystem data, UUID=1d99b11c-1e79-5d0a-ad56-ff5d389d8221, 
volume name "system_dlkm" (extents) (large files) (huge files)

1.2 erofs: Google recommends to change to erofs for readonly images, something like this:

system_dlkm.img: EROFS filesystem, compat: SB_CHKSUM MTIME, blocksize=12, 
exslots=0, uuid=A7F0F0DB-EA70-6142-9859-630288E2492F, incompat: LZ4_0PADDING

So I really can not fully understand why Google's latest flagship didn't adopt erofs.

2. image packing flow

2.1 About ext4 system_dlkm:

TBD

2.2 About erofs system_dlkm:

* Android specific dependencies

avbtool
fec
mkfs.erofs
libc++.so

* common dependencies

du

* data dependencies

file_contexts.bin

The image is generated as below flow

Hi @Aarqw12 , What's your working flow with system_dlkm.img? Do you have full AOSP code base? It should be convenient to work under AOSP code base for platform developers/hackers.

Hi,

I generate system_dlkm.img from kernel google manifest

https://android.googlesource.com/kernel/manifest/+/refs/heads/android-gs-shusky-5.15-android14-d1

Effectively in fstab.zuma I see it's ext ro.

So for test I replaced all new .ko I compiled & repack for see.

[cfig]

ext4 is supported .
Usage:

cp <your_system_dlkm.img> system_dlkm.img
cp <your_vbmeta_image> vbmeta.img
./gradlew unpack
# replace your .ko
./gradlew pack

Then flash vbmeta.img.signed and system_dlkm.img.signed to the device.