sorry, ich bin blöd :((
die patches und so sind nicht ausgeführrt worden, weil ich einen Befehlt vergessen hatte :((
Geh mal ins Verzeichnis /bash treble_build_los und öffen buildbot_treble.sh
Zeile 101 kannst du auf ‘false’ setzen, wenn du kein root haben willst
Zeile 112 bis 117 sind die build Variationen. Einfach die, die du NICHT haben willst mit # zum Kommentar machen.
Dann kannst du mit
bash treble_build_los/buildbot_treble.sh
nochmal starten. Dann sollte das buidl auch wirklich starten
Das script war mit ‘der heißen Nadel gestrickt’ ich mach nochmal eine neues funktionierendes fertig, wenn dein Build auch läuft
leider, leider, auch nicht geklappt…
Hatte zwischenzeitlich nochmals neu gestartet, da Bildschirmschoner an ging, und gar nichts mehr reagierte.
Nach einem rabiaten Neustart, Bildschirmschoner deaktiviert, ca. 75min gelaufen und dann nichts mehr…
BUILD_ID=QQ3A.200805.001
OUT_DIR=out
WITH_SU=false
============================================
[ 38% 252/658] including packages/apps/Backgrounds/Android.mk ...
/bin/bash: Zeile 0: test: -gt: Einstelliger (unärer) Operator erwartet.
[ 61% 402/658] including system/sepolicy/Android.mk ...
system/sepolicy/Android.mk:89: warning: Be careful when using the SELINUX_IGNORE
_NEVERALLOWS flag. It does not work in user builds and using it will not stop yo
u from failing CTS.
[ 97% 639/658] including vendor/lineage/bootanimation/Android.mk ...
vendor/lineage/bootanimation/Android.mk:19: warning: TARGET_SCREEN_WIDTH is not
set, using default value: 1080
vendor/lineage/bootanimation/Android.mk:23: warning: TARGET_SCREEN_HEIGHT is not
set, using default value: 1920
[ 99% 657/658] finishing build rules ...
platform_testing/build/tasks/tests/platform_test_list.mk: warning: platform_test
s: Unknown installed file for module 'CalendarTests'
[100% 662/662] build vndk-test-sepolicy
FAILED: vndk-test-sepolicy
/bin/bash -c "bash \"vendor/vndk-tests/run.sh\" \"vendor/vndk-tests\" \"out/targ
et/product/phhgsi_arm64_ab\""
+ sext=
+ '[' -f out/target/product/phhgsi_arm64_ab/system/system_ext/etc/selinux/system
_ext_sepolicy.cil ']'
++ uname -s
+ HOST_OS=Linux
+ TARGET_INCLUDE=linux
+ '[' Linux == Darwin ']'
++ mktemp
+ t=/home/user/srv/e/out/soong/.temp/tmp.XXXXy2cr8R
+ for vndk in 26 27
++ find vendor/vndk-tests/sepolicies/26/ -name '*.cil'
+ for src in $(find "$1"/sepolicies/$vndk/ -name \*.cil)
+ ./out/host/linux-x86/bin/secilc out/target/product/phhgsi_arm64_ab/system/etc/
selinux/plat_sepolicy.cil -o /home/user/srv/e/out/soong/.temp/tmp.XXXXy2cr8R -M
true -G -N -c 30 out/target/product/phhgsi_arm64_ab/system/etc/selinux/mapping/2
6.0.cil vendor/vndk-tests/sepolicies/26/G960F.cil
vendor/vndk-tests/run.sh: Zeile 19: ./out/host/linux-x86/bin/secilc: Datei oder
Verzeichnis nicht gefunden
19:33:00 ninja failed with: exit status 1
#### failed to build some targets (33:10 (mm:ss)) ####
mv: Aufruf von stat für '/home/user/srv/e/out/target/product/phhgsi_arm64_ab/system.img' nicht möglich: Datei oder Verzeichnis nicht gefunden
Buildbot completed in 75 minutes and 49 seconds
Ok, das kenn ich. Im treble-build-los.sh script ist im unteren Bereich eine Zeile mit ‘vdnk-test’
lösche sie und starte neu.
Am besten auch weiter oben dir Zeile mit ‘repi sync’ zum kommentar machen, damit kein unnötiger sync gemacht wird
Kurzer Zwischenstand, nach dem Neustart des Scripts, wo es geändert wurde, kamen wieder Fehlermeldungen, u.a. was, das die Ordner oder Dateien schon vorhanden sind.
Da ich nicht wußte, welche Dateien ich genau löschen muß, habe ich wieder eine VM geklont und von vorne angefangen.
Nach dem Standardfehler mit dem GSI-Q.sh, habe ich dann das buildbot_treble.sh wieder umgeändert. Dabei hattest Du mich wieder auf die Probe gestellt:-), vndk-test, heißt es und repo sync:-)
Egal, nachdem ich es gestartet hatte, kamen Fehler das im Ordner device der Ordner phhh fehlt usw…
Ich habe das repo sync wieder zugelassen, und siehe da, das Verzeichnis phhh im Ordner devices wurde erstellt. Jetzt momentan läuft es und ich gehe mal ins Bett:-)
Monitor angeschalten, in Windows angemeldet, in Linux angemeldet, leerer Bildschirm… Im Ordner “build output” ist nichts.
Terminal war geschlossen, keine Ahnung was da passiert war.
Ich habe einfach das Script eben nochmals gestartet, nachdem ich alles mögliche an Energiesparen, auch in Windows, ausgeschalten habe…
Er hängt jetzt bestimmt schon eine halbe Stunde an dieser Stelle, also die Zeit läuft da nicht weiter, bleibt auf 23.52 stehen.
VM reagiert auch nicht… Allerdings arbeitet scheinbar noch die Festplatte, also die blinkt in der VM immer schön rot/grün.
Kann das damit zusammenhängen das die Sachen quasi schon begonnen wurden, gestern Nacht?
Welches System nutzt Du? LM19.3?
Ich habe LM20 installiert. Oder welches System wäre für diesen Zweck am besten geeignet?
Mint 19 is OK, aber 8 GB RAM ist wohl zu wenig. Unter 12 gibt es nur Probleme.
Kein Platz für Dual boot direct in Mint ? Mint 20 is gut, 19 is besser, das viele Scripts in Python2 sind und in Mint 20 is python3 standard. das bringt auch ab und an Probleme
achja, wenn du das script neu startest, dann vergiss die Meldungen wegen bereits vorhandener Verzeichnisse oder patches. Das kommt vom ersten Durchlauf.
wenn einmal das build gestartet war, dann würde ich immer mit dem restart.sh script weitermachen
Ansonsten war das jetzt, mal wieder, mit Fehlern beendet worden.
[100% 12400/12400] out/soong/.bootstrap/bin/soong_build out/soong/build.ninja
FAILED: out/soong/build.ninja
out/soong/.bootstrap/bin/soong_build -t -l out/.module_paths/Android.bp.list -b
out/soong -n out -d out/soong/build.ninja.d -globFile out/soong/.bootstrap/build
-globs.ninja -o out/soong/build.ninja Android.bp
Killed
11:53:49 soong bootstrap failed with: exit status 1
FAILED: ninja fifo didn't finish after 5s
ninja: build stopped: subcommand failed.
#### failed to build some targets (02:11:31 (hh:mm:ss)) ####
mv: Aufruf von stat für '/home/andy/srv/e/out/target/product/phhgsi_arm64_ab/system.img' nicht möglich: Datei oder Verzeichnis nicht gefunden
Buildbot completed in 138 minutes and 51 seconds
Auf dem Laptop bringt das dann wohl nichts, da habe ich Xubuntu 20.04, und es ist halt “nur” ein Laptop, zwar i5 und 16GB RAM, aber halt “nur” Laptop.
Ich habe mir eine 500GB ssd bestellt, dann installiere ich nächste Woche da mal ein System drauf für den Spiele PC, aber Dualboot, hmmmm, früher, vor ca. 20 Jahren gab es mal einen sauguten Bootmanager, da konnte man Systeme untereinander verstecken und Partitonen nur für bestimmte Systeme freigeben, der war geil, aber so was gibt es ja wahrscheinlich nicht mehr. Und mit dem “normalen” Linux Bootmanager kann man ja keine Partitionen verstecken… Ach, ich muß es mir mal überlegen…
Vorher installiere ich dann mal Mint 19.3 in einer VM…
Also ccache sollltest du installieren. Gerade bei wenig RAM macht das Sinn.
Mein 2011 iMac mit Mint19 dauf hatte auch nicht viel power. Das build dauerte halt länger. Aber es ist immer noch besser als in ner VM.
Ich dachte, du hast die VM auf nem Windoofs PC. Deshalb der Hinweis auf Dualboot. Die Linux Distro’s bauen ja Problemlos nen Bootmanager ein, sodass das heute ja kein Problem mehr ist.
Ich hoffe, ich komme heute dazu, das Script so fertig zu machen, dass es auf Anhieb läuft.
SSD’s sind natürlich super. Ich hatte mir vor kurzem ein Barebone mit 24 GB RAM, 250 GG interner SSD und ner 1 TB externen SSD angeschafft. Damit dauern die Builds nur noch halb so lange
Korrekt, das ist mein Spiele PC, da lief jetzt die ganze Zeit die LM 20 VM drauf.
Zudem habe ich einen Laptop mit verschlüsseltem Xubuntu 20.04.
Daher habe ich mir extra eine SSD bestellt, 500GB dürften ja reichen, nur für GSI Builds zu erstellen, auf Dich kommt also noch Arbeit zu
Ich muss ja komplett von vorne anfangen, habe ja gar keine Ahnung was da läuft, von daher ist es eigentlich ganz gut das nicht immer alles direkt läuft, denn dann kann man auch wieder was lernen .
Dienstag kommt die SSD, dann wird gesichert und installiert.
Das ist ja das andere Problem, das läuft gar nicht bei mir auf dem Note 9pro. Das kann ich über fastbootd installieren, nach einem Neustart kommt aber immer nur fastboot Modus.
Das ist noch das Problem mit dem TWRP, das läuft nicht mit fastbootd, daher muß ich ja auch öfters wieder auf original recovery zurück um z.B. Dein eOS Update zu installieren.
