[Huawei P30 Pro Guides, News, & Discussion] newbit:
No, not at all. That is why I could need a working autorun.iso from an Android 10 Device and its corresponding firmware.

If your EMUI9.1 autorun.iso is in a ??? form in your extracted Firmware as well, then I could use them as well to compare it.

If I can't be 100% sure the unpacking is working correct, I don't need to repack it. But thanks.

Cheers NewBit

Update 18.05.2020:

Successfully extracted and mounted a super.img from Android 10

I've build a Kernel 5.5.9 in Linux mint with enabled EROFS features.

After that I was able to extract with HuaweiFirmwareExtracter the SUPER.IMG

and with the otatools like simg2img and lpunpack its partitions.

After mounting the system.img and hw_product.img I could list its contents without the ???.

In fact, with no ??? at all.

I tried it on three firmware images and extracted the autorun.iso from LYA, LIO CHN and LIO OVS.

View attachment LYA-autorun.iso.zip

View attachment LIO-CHN-autorun.iso.zip

View attachment LIO-OVS-autorun.iso.zip

The text file shows a ls -l from the mounted system.img in a root folder.

View attachment system.img.LYA.txt

Update 22.05.2020:

SuperR Kitchen and splituapp.py on github are updated thanks to [MENTION=10137977]superr[/MENTION]

In case of the Firmware VOG-LPRP2-OVS-10.0.0.209 (EMUI 10.0), it contains two super.img files in it.

View attachment 5024463

And splituapp.py was overwriting the first extracted larger super.img with the second smaller super.img. It was possible to

unsparse it, but you can't lpunpack it. So SuperR changed the script to keep both files. After some investigation,

it seems that both super.img files will be merged as unsparsed files. The second super.img has the exact same size as the larger one.

But only contains data where the larger one doesn't and vice versa. After inserting this data, and then extracting it,

the odm.img contains data, otherwise it was just filled with zeros. Not sure why this second super.img is in the UPDATE.APP,

but I guess it was added afterwards with lpadd.

Regarding the FF blocks, EROFS has a the capability of an inplace compression and decompression. Which would explain

why the data of the ISO looked so different by accessing it directly in memory, but is fine after copying it out over

the mounted filesystem.

Update 26.05.2020:

[MENTION=10137977]superr[/MENTION] again updated his SuperR Kitchen.

After it extracted the UPDATE.APP with two super.img files, it asks you If you want to merge these two super.img files. The result will be

an unsparsed super.img that can be lpunpacked to all its containing partitions. I tested it with a couple of Android 10 Firmware files,

and I could mount and access all its partitions like: hw_product.img, odm.img, vendor.img, cust.img and system.img

I've mounted system.img to a root folder and all others to its corresponding folders in it.

mount | grep erofs ->

/home/newbit/android/superrs-kitchen3/superr_temp/system.img on /home/newbit/android/superrs-kitchen3/superr_temp/root type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)
/home/newbit/android/superrs-kitchen3/superr_temp/cust.img on /home/newbit/android/superrs-kitchen3/superr_temp/root/cust type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)
/home/newbit/android/superrs-kitchen3/superr_temp/hw_product.img on /home/newbit/android/superrs-kitchen3/superr_temp/root/hw_product type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)
/home/newbit/android/superrs-kitchen3/superr_temp/odm.img on /home/newbit/android/superrs-kitchen3/superr_temp/root/odm type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)
/home/newbit/android/superrs-kitchen3/superr_temp/vendor.img on /home/newbit/android/superrs-kitchen3/superr_temp/root/vendor type erofs (ro,relatime,user_xattr,acl,cache_strategy=readaround)

View attachment LIO-AN00-CUST_10.0.0.167_C735.pdf.zip of the ls -lR result

Please note they are ZERO ???

Now I think it is time to repack or rather lpmake.

Anyone has any experience in that Arena?

lpdump?!