Xiaomi Mi A1 (tissot) for /e/OS-T v2.1

[pswiatki]

I am trying to recreate the official build after following this thread (pointer to the OP’s closing message):

[UNOFFICIAL BUILD] Pi/e/ test ROM for the MiA1 tissot

Closing this thread and removing the unofficial builds as the Xiaomi MiA1 tissot is now officially supported. Thanks to all those who helped with the testing of the unofficial build.

@Manoj said I should ask questions at the forum, so here I go:

the build (inside the provided docker container) is invoked like this:

docker run \
-v "./src:/srv/src" \
-v "./zips:/srv/zips" \
-v "./logs:/srv/logs" \
-v "./ccache:/srv/ccache" \
-e "BRANCH_NAME=v2.1-t" \
-e "DEVICE_LIST=tissot" \
-e "REPO=https://gitlab.e.foundation/e/os/releases.git" \
registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community

It cannot proceed unless the manifest is corrected - one of the commit hashes is not found in the respective repository, specifically for android_vendor_lineage:
https://gitlab.e.foundation/e/os/releases/-/blame/v2.1-t/default.xml?ref_type=tags#L342
Commit 6417edcc961ce81cd7a71825082c789cb354812e could not be found.
When corrected (I used bdc7bd4e262a7d426cd845c12a220feb71a71d2a - the current (at time of writing) HEAD of v2.1-t branch (see: https://gitlab.e.foundation/e/os/android_vendor_lineage/-/tree/v2.1-t?ref_type=heads) the build did progress until the very end. However, at image creation, it FAILED with the following:

2024-06-17 02:30:40 - common.py - WARNING : Failed to read build.prop for partition system_dlkm
2024-06-17 02:30:40 - common.py - WARNING : Failed to read IMAGES/init_boot.img
2024-06-17 02:30:41 - ota_from_target_files.py - WARNING : Source build doesn't support lz4diff, or source/target don't have compatible lz4diff versions. Disabling lz4diff.
Traceback (most recent call last):
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 196, in _run_module_as_main
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 86, in _run_code
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/__main__.py", line 12, in <module>
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 196, in _run_module_as_main
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/internal/stdlib/runpy.py", line 86, in _run_code
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 1656, in <module>
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 1627, in main
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 1257, in GenerateAbOtaPackage
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 458, in Generate
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/ota_from_target_files.py", line 432, in _Run
  File "/srv/src/T/out/host/linux-x86/bin/ota_from_target_files/common.py", line 313, in RunAndCheckOutput
common.ExternalError: Failed to run command '['brillo_update_payload', 'generate', '--payload', '/tmp/payload-enewsgor.bin', '--target_image', '/srv/src/T/out/target/product/tissot/lineage_-target_files-20240617.zip', '--enable_zucchini', 'false', '--enable_lz4diff', 'false', '--max_timestamp', '1718586493', '--partition_timestamps', 'boot:1718586493,system:1718586493']' (exit code 1):
Extracting images for full update.
/srv/src/T/out/host/linux-x86/bin/brillo_update_payload: line 402: xxd: command not found
ERROR: Media size (2562809711) is not a multiple of sector size(512)
brillo_update_payload: error: Couldn't detect the image format of /srv/src/T/out/target/product/tissot/lineage_-target_files-20240617.zip

>> [Mon Jun 17 02:30:42 UTC 2024] Moving build artifacts for tissot to '/srv/zips/tissot'
sha256sum: 'e-*.zip': No such file or directory
>> [Mon Jun 17 02:30:42 UTC 2024] Finishing build for tissot
>> [Mon Jun 17 02:30:42 UTC 2024] Cleaning source dir for device tissot
>> [Mon Jun 17 02:31:19 UTC 2024] Switch back to Python3

real	97m42.150s
user	0m8.211s
sys	0m10.033s

The questions are:

1. Why did the build fail with the above message? Wasn’t it supposed to be self-contained build environment to compile /e/OS all the way to get the final ZIP (with flashfiles, I presume)?
   To be clear: after correcting the commit hash in the manifest I cleared the work area (except .repo/ directory, naturally).

2. Why does the manifest contain some hash that the build tools cannot find?

[aibd]

Forgive me but I won’t address your questions … however (and I cannot see the environment) you just have to track up the errors … starting say

/srv/src/T/out/host/linux-x86/bin/brillo_update_payload: line 402

What is it trying to do? I don’t fully know your motivation for adjusting the manifest, but brillo cannot do its job.

Why ? I have no idea, but sometimes as you search the errors it becomes clear !

I must put a plug in for working like this https://gitlab.e.foundation/steadfasterX/android_vendor_e/-/blob/main/README.md rather than in docker!

[pswiatki]

@aibd

I don’t fully know your motivation for adjusting the manifest, but brillo cannot do its job.

There is no other motivation than to make the build proceed. It craps out saying this particular hash present in the manifest cannot be found. Indeed, when I checked on GitLab, I could not locate it. So I took the [current] HEAD of branch v2.1-t. If not for the error, I would not touch the manifest (why would I need to do that?).

By the way: the README you mentioned states:

Especially for new users who never build Android before it is THE method
which will simply just work.

Interestingly, I immediately ran into issues with the container-based approach.
In general, as we were able to discuss on Telegram before further discussions on that matter were banned on Telegram by the admin, repo sync is a particularly fragile operation that may make the work area dirty in so many different ways, it is a major PITA.

To be clear, I used to port the component my radio group was working on to several releases of AOSP (and for several projects for each Android version), so I am familiar with the AOSP building process.

[tcecyk]

@pswiatki

line 402: xxd: command not found

tl;dr: current docker image hasn’t got the hex util xxd (but should).

The reason the shell script (called within the python script - thus the py stacktrace) exits is it can’t locate xxd on its PATH (for some zip magic). The tag got pushed onto 3 days ago, probably not from that Dockerfile or it is erroring somewhere in the apt-get and nobody noticed.

You can run the image interactively and see for yourself. What to do? build the Dockerimage in the linked repo give it a :local tag and change that in your invocation.

missing git ref: I prefered the v1-t branches, not the build tags. Just taking whatever is at that moment in the tip

If you built AOSP before, I’d forgo the docker method, much more flexible

[pswiatki]

@tcecyk

l;dr: current docker image hasn’t got the hex util xxd (but should).
The reason the shell script (called within the python script - thus the py stacktrace) exits is it can’t locate xxd on its PATH (for some zip magic).

Yes, I realized that immediately, when it failed me the first time. I could not comprehend though why this could be, if the docker image supposedly contains everything (!!) needed to build the whole thing.
Since you pointed to a particular line containing xxd in the Docerfile, I could quickly deduce the rest of the problem. You see, my commando line contains this:

 -e "REPO=https://gitlab.e.foundation/e/os/releases.git" registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community

So, the image tag is :community, thus the presumption Dockerfile.community is used for that image. As one can see, no xxd package is present in that Dockerfile’s RUN apt-get install clause.

@tcecyk

The tag got pushed onto 3 days ago, probably not from that Dockerfile or it is erroring somewhere in the apt-get and nobody noticed.

Which tag are you referring to here? I pulled the image from docker-lineage-cicd using:

 docker pull registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community

but I believe the image in the Docker registry on GitLab is composed off of the master branch in docker-lineage-cicd project on GitLab.

@tcecyk

You can run the image interactively and see for yourself. What to do? build the Dockerimage in the linked repo give it a :local tag and change that in your invocation.

How would building the image locally allow me to run it interactively? Do you mean adding a means of getting the shell access to the system running in the container? If this is what you meant - yeah, I was contemplating that, sure. In fact:

@tcecyk

If you built AOSP before, I’d forgo the docker method, much more flexible

Docker images I used were prepared (at least those for developer use) with some flavour of shell program in the ENTRYPOINT clause in the Dockerfile. That allowed for the interactive use of anything provided inside the image.

@tcecyk

missing git ref: I prefered the v1-t branches, not the build tags. Just taking whatever is at that moment in the tip.

Do you mean I should go to v1-t when fixing the problem with missing git hash? If so, it just so happens (if I remember correctly) v1-t and v2.1-t pointed to the same commit at that time I looked for a sane commit to point to. By the way: is v1-t somehow special (like e.g. “main development” branch)?

[tcecyk]

yep v1-{r,s,t,u} are “main branches”. When I used them I could always finish the build, ymmv - as the lineage deps are stable for a few weeks, it’s only some downstream deps that update.

I left a MR for repo owners to notice - https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/merge_requests/93

The entrypoint of that Dockerfile is the buildscript. But you can override the EP easily for interactive use, normal aosp/lineage make targets - it’s 4-5 important lines in the buildscript that you’d issue on the cli.

If you build the Dockerfile first locally and docker-tag it to anything to reference it later on the ‘run’ invocation you can stick to the normal script EP, that is what I was suggesting.

[pswiatki]

Yes, this is all great. I just researched and found out -it --entrypoint /bin/bash is all that’s needed in this case. Just to be sure I shall pull the Dockerfile from GitLab, modify it (fix the issues), build the image locally and use it for my local builds.

Thank you much for your suggestions, @tcecyk.

[tcecyk]

to let you know, the community image has xxd now included, so this shouldn’t crop up again