glad to know you tried and found fastboot enhance useful for your goals.
But, i m asking, where did you find/get recovery.img you reported as corrupted/unable to open ?
When you unpacked payload.bin via fastboot enhance, you clearly got some partitions.
The partition named boot.img is the recovery you will need to flash the rom, extract it.
The others partitions you need, dtbo.img and vendor_boot.img are the same available, just extract them as well.
Take a look please at this wiki, just as reference. https://wiki.lineageos.org/devices/renoir/install
E os is lineage os based.
Steps explained here to install lineage os 20/t will also work for e os s, based on lineage os 19.1
You will observe, is basically written, that the recovery.img is the boot.img
You don’ t need more than this, no need to unpack other files.
The next e os build, 1.16, will be shipped soon, read mid October.
This new release should fix the missing builds, recoveries and additional files as well.
Now It’ s all in your hands.
I am not a Windows user, but I think that Windows method is described in words as:
There is a tool called Payload-Windows-GO. Basically you just hover over the payload file over the EXE file of the tool and it extracts it.
quoted from the XDA forums link in Post #8 but this is relevant to extraction from the main ROM.zip only.
I think we have to look at this as an inadequacy in documentation as I also was not able to extract the required bits by following my reading of the /e/ install page quoted in Post #10. First I check my download was not corrupted.
$ cat recovery-e-1.14-s-20230819321663-dev-renoir.img.sha256sum
$ sha256sum recovery-e-1.14-s-20230819321663-dev-renoir.img
$ sudo mount -o loop /home/test/test/recovery-e-1.14-s-20230819321663-dev-renoir.img /media/two
mount: /media/two: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
agree with you about renoir’ s documentation stuff you pointed.
As we can observe in this page https://images.ecloud.global/dev/renoir/ the recovery always came as a single img file, not as described and expected, so a zip.
Additional partitions, dtbo and vendor_boot images, are missing.
Unpacking recoveries images won’ t produce missing files.
I think the only way to get them, as of now, is by unzipping rom’ s zip to get payload.bin and then use the mentioned methods to unpack it obtaining required partitions, as i suggested in my previous post.
I think there is some confusion of language going on here. We don’t want to be extracting anything from e-recovery.img; a file with that name is a complete recovery.img in itself.
eOS is intending to bundle the necessary .img files for booting recovery all together for downloading where the user can simply unzip them. Take a look for example at this download page for lemonade where for eOS-S the files are bundled together as “Recovery and boot img” (no .img).
The name of the bundle can be anything so long as it’s a zip.
For the time being users can extract the payload.bin from the OS download zip and extract the .img’s from that.
Indeed, I agree. The lemonade page demonstrates the intention well and I had not previously seen this provision of needed files, thanks.
I made an edit to the issue
The wording “First unzip the /e/OS Recovery file” does correctly apply when the files are published in the format used on this page. https://images.ecloud.global/dev/lemonade/. Perhaps users need to be aware to wait for the images to be published in the intended format.
I tried following @aibd 's instructions but running the payload thing gives an error, even when adjusting last argument to simply dtbo: $ ./payload-dumper-go -partitions -o dtbo,vbmeta 2023/10/16 06:19:37 File does not exist: dtbo,vbmeta
Any guidance, please?
I’m following the install instructions for hotdog which is affected by this issue (that I can’t fully understand).
In the wrong command payload.bin is missing, and the -o inbetween -partitions and dtbo,vbmeta breaks the -partitions parameter, letting payload-dumper-go either see dtbo,vbmeta as the file to work with (which doesn’t exist) or as the output folder specified after -o (which doesn’t exist) … I can’t test the specifics right now.
Perhaps better to say that it is a usable format! It did actually create a pretty expansive extraction of ¿all? .img files in the file, so I’m clearly getting it slightly wrong. I’ll link your answer on the gitlab workaround instructions.
I downloaded the Windows version just now, which gives the following usage info:
Usage: payload-dumper-go [options] [inputfile]
Number of multiple workers to extract (shorthand) (default 4)
Number of multiple workers to extract (default 4)
-l Show list of partitions in payload.bin (shorthand)
Show list of partitions in payload.bin
Set output directory (shorthand)
Set output directory
Dump only selected partitions (comma-separated) (shorthand)
Dump only selected partitions (comma-separated)
If I want to understand this in a strict sense, the input file (payload.bin) should be last after the options (-partitions dtbo,vbmeta), or even not given (I assume payload-dumper-go would work with payload.bin in the same directory then), so you could try whether ./payload-dumper-go -partitions dtbo,vbmeta payload.bin
or simply ./payload-dumper-go -partitions dtbo,vbmeta
would make a difference for you, extracting only the 2 given partitions.