Seit der Version e-1.7-r habe ich - bei gleich gebliebener Software-Situation - immer wieder das Problem, dass mein Fairphone 3 für einen Neustart statt 20-30 Sekunden leider 2 oder mehr Minuten braucht. Dies geschieht mehr oder weniger gelegentlich und unregelmäßig, ist manchmal aber recht ärgerlich. Die Ursache konnte ich bislang nicht herausfinden.
Der Akku scheint mir noch recht gut zu arbeiten.
Versuche mit dem abgesicherten Modus brachten keine sicheren Erkenntnisse, vielleicht die Vermutung, dass hier der Launcher Trébuchet im Hintergrund eine Rolle spielen könnte . . . ?
adb logcat kann ab dem “bouncing e” Screen schon mitschreiben, wenn der langsame Teil nach dem “native init” passiert. Beim reboot nach einem System-Update werden preload klassen von Java neu geschrieben um spätere Starts schneller zu machen, “zygote preload classes”… das könnte es sein. Dass es immer mal wieder passiert ausserhalb eines Updates wundert mich auch.
Wenn Du es visualisieren willst, Bootchart kann das.
1 Like
Vielen Dank für deine Hilfe.
Anbei eine Darstellung meines gescheiteren Versuches, den Bootvorgang darzustellen mit Hilfe von Bootchart, worin man sehen kann, dass ich in Sachen ADB usw. Anfänger bin.
marc@Perotin:~$ sudo -i
[sudo] Passwort für marc:
root@Perotin:~# cd /
root@Perotin:/# ls -a
. boot etc lib32 lost+found opt run srv tmp
… cdrom home lib64 media proc sbin swapfile usr
bin dev lib libx32 mnt root snap sys var
root@Perotin:/# cd media/marc/Software
root@Perotin:/media/marc/Software# cd ‘ADB-Platform-Tools Linux’/platform-tools
root@Perotin:/media/marc/Software/ADB-Platform-Tools Linux/platform-tools# ./adb devices
adb server version (39) doesn’t match this client (41); killing…
- daemon started successfully
List of devices attached
A209L8RY0202 device
root@Perotin:/media/marc/Software/ADB-Platform-Tools Linux/platform-tools# ./adb shell ‘touch /data/bootchart/enabled’
root@Perotin:/media/marc/Software/ADB-Platform-Tools Linux/platform-tools# ./adb reboot
root@Perotin:/media/marc/Software/ADB-Platform-Tools Linux/platform-tools# ./ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh
Vermutlich habe ich hier schon den ersten Fehler gemacht.
-bash: ./ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh: Datei oder Verzeichnis nicht gefunden
Weiter bin ich erst einmal nicht gekommen
Für den Fall, dass ich evtl. bei einem weiteren Versuch erfolgreicher sein sollte, habe ich noch die Frage zu folgender Anweisung:
“Wenn Sie fertig sind, löschen /data… , um zu verhindern, dass die Daten jedes Mal erfasst werden.”
Wie man hier das Löschen durchführt, habe ich nicht verstanden.
je nach Distro (debian,arch,ubuntu etc) ist adb paketiert, du könntest es darüber beziehen. Benötigt hostseitig kein sudo. Ein “adb root” muss funktionieren bevor Du das “enabled” file touch’est, sonst dürfte es gar nicht geschrieben werden im Kontext des Smartphones.
“ANDROID_BUILD_TOP” ist eine Variable, kein Pfadbestandteil, deshalb kann es nicht gefunden werden. Es geht von der Präsenz eines Buildenvironments aus für Android bzw zumindest dem android_system_core Repo - sorry habe ich nicht gesehen. Es will das shellscript grab-bootchart.sh. Das will nochmal editiert werden um auf deinen clone des bootchart pythons zu zeigen.
Wenn Du es nicht selber machen willst / kannst, führe nach dem boot mit dem enabled flag das nach einem “adb root” aus und schick mir die Logs dann schaue ich es mir an und vergleiche auch mal mit meinem eigenen FP3.
Folgendes ist eine vereinfachte Variante von grab-bootchart.sh:
mkdir -p /tmp/android-bootchart;
for f in header proc_stat.log proc_ps.log proc_diskstats.log; do
adb pull /data/bootchart/$f /tmp/android-bootchart/$f 2>&1 > /dev/null
done
(cd /tmp/android-bootchart && tar -czf bootchart.tgz header proc_stat.log proc_ps.log proc_diskstats.log)
und schicke mir bootchart.tgz
vom Hostsystem aus nach “adb root”:
adb shell rm /data/bootchart/enabled
1 Like
Vielen Dank für deine Zeilen!
Ich habe mein System (Ubuntu LTS 20.04) heute erst einmal auf den Zustand VOR meinen letzten Versuchen mit Bootchart zurückgesetzt, das uralte ADB (v. 1.8) deinstalliert und von der Download-Seite des Projekts „Platform Tools“ die neueste Version „platform-tools_r34.0.0-linux.zip“ geholt und nach /usr/local/bin/ entpackt und dort installiert.
Das scheint bis dahin gut gelaufen zu sein, den das Fairphone 3 wurde erkannt:
marc@Perotin:~$ adb devices
List of devices attached
A209L8RY0202 device
marc@Perotin:~$ sudo udevadm control --reload-rules
(Die entsprechende Nachhilfe habe ich mir u.a. bei „ubuntuusers“ geholt.)
Ein weiterer Schritt klappte auch:
marc@Perotin:~$ adb shell ‘touch /data/bootchart/enabled’
marc@Perotin:~$ adb reboot
Das FP3 startete wieder von neuem.
Dann kam ich aber leider nicht weiter:
marc@Perotin:~$ adb root
ADB Root access is disabled by system setting - enable in Settings → System → Developer options
Bei den Entwickleroptionen fand ich keine mir dafür sinnvoll erscheinende Einstellung.
Und so habe ich wieder nur Fragen:
Was meinst du mit „führe nach dem boot mit dem enabled flag das (was?) nach einem “adb root ” aus“ ?
Welcher „flag“ soll „enabled“ werden?
Und soll ich beim Ausführen der vereinfachten Variante von „grab-bootchart.sh“ jeweils
zeilenweise die Befehle in das Terminal setzen?
-
mkdir -p ….
-
for f ….
-
adb pull …
(- done kommt bei erfolgreichem Ablauf vermutlich von selber)
Und wie soll ich mit der Anweisung in Klammer verfahren?
(cd /tmp/android-bootchart && tar -czf bootchart.tgz header proc_stat.log proc_ps.log proc_diskstats.log)
Oh weh, du bist wahrscheinlich über meine dummen Fragen entsetzt, aber ich kann z.B. nicht programmieren und bin in Sachen Computer samt Software nur ein mäßig voran gekommener Autodidakt.
Und bin deshalb für Hilfe sehr, sehr dankbar.
Und wenn ich dich zu viel Zeit und Geduld koste, habe ich dafür volles Verständnis, wenn du abwinkst.
wenn Du ein FP3 aus dem stable zweig hast fehlt die adb root debug option (“Rooted debugging”) leider. Die ist sonst eins unter “USB debugging” im Smartphone.
Würde das nicht klappen würde aber eigentlich der adb shell ‘touch /data/bootchart/enabled’ mit Fehler zurückkommen. Hast Du ggf doch aktiviert?
Ist von mir missverständlich, es ist nur eine Datei die ein “flip switch” ist, aus oder an, ein boolean… ich müsste mal https://stackoverflow.com/questions/32810229/why-are-bools-are-sometimes-referred-to-as-flags oder https://en.wikipedia.org/wiki/Boolean_flag lesen weil ich es selber auch nicht wusste und das Gewohnheit war weils mal jemand anders gesagt hat
Die Schlaufe “for” bis "done müsstest Du in einem Stück einfügen - bzw wartet die Shell darauf dass Du das “done” tippst / einfügst. Bei den anderen ist es egal. Klammer nur da um das logische und (&&) noch deutlicher zu machen, funktional gleich zu ohne. Es ist das Quellskript runtergedampft ohne Variablen.
1 Like
Inzwischen fehlt die Option im Zweifelsfall wegen R, offenbar nicht mehr wegen stable … Feedback for v1.6 - #163 by jobal.
Dank deiner Infos habe ich jetzt ganz flott „bootchart.tgz“ erstellen können, was ich hier anfüge. Ich bin sehr gespannt, was du aus dem Gewimmel von 1 und 0 herauslesen wirst.
(Attachment bootchart.tgz is missing)
Dank deiner Infos habe ich jetzt ganz flott „bootchart.tgz“ erstellen können, was ich hier anfüge. Ich bin sehr gespannt, was du aus dem Gewimmel von 1 und 0 herauslesen wirst.
Wie kann ich denn hier “bootchart.tgz” anfügen?
Das System bellt folgendermaßen: “Entschuldige, die Datei, die du hochladen möchtest, ist nicht erlaubt (erlaubte Dateiendungen sind: jpg, jpeg, png, gif, heic, heif, webp).”
Dann benenn’ die Datei doch um bootchart.jpg.
Dann kann sich die Forumsoftware wenigstens nicht mehr über die Endung beschweren und muss sich mehr Mühe geben, wenn sie meckern will 
.
1 Like
@AnotherElk: Danke, habe wahrscheinlich zu viel “Ehrfurcht” vor diversen Instanzen . . . .
Leider ist der System-Cerberos unbestechlich. Ich habe alle Formate (jpg, jpeg, png, gif, heic, heif, webp) beim Umbenennen ausprobiert. Es kommen folgende Nachrichten:
- Sorry, but we couldn’t determine the size of the image. Maybe your image is corrupted?
- lib/discourse.rb:126:in `exec’: An error happened when converting from PNG to JPG.
Ohne Extension-Benennung geht es auch nicht.
Was tun?
die Auswertung ist ziemlich einfach, kannst Du bestimmt auch selber !
git clone https://github.com/xrmx/bootchart.git
cd bootchart/
mv pybootchartgui/main.py.in pybootchartgui/main.py
./pybootchartgui.py /tmp/android-bootchart/bootchart.tgz
ansonsten, bin Fan von https://transfer.sh/ und https://oshi.at/
anbei meine eigene FP3 bootchart.png mit ~23s Bootzeit. Interessant sind die zygote64 / zygote (untergeordneten) Zeilen die sowohl viel I/O als auch CPU möchten. Zygote ist wie gesagt der Java Init, startet das meiste was der User sieht und mit interagiert. Vermutlich wird die Sichtbarkeit in Zygote gar nicht ausreichen und man muss zu Systrace wechseln um weiter auseinander zu klamüsern.
Du müsstest das enabled file solange liegen lassen bis ein Boot mal langsam war. Wenn es gut läuft ist e eine andere Komponente die dauert und sich nicht in Zygote versteckt
1 Like
Danke, auch für die tollen Tips bzgl. filesharing.
Da kannst du die bislang nicht übermittelte Datei dir holen. Wegen des bellenden System-Cerberos teile ich dir den Zugang etwas umständlich mit: Teil 1 ist oshi.at und Teil 2 HuXq.
Ich kann leider nichts damit anfangen, da fehlen mir einfach die Kenntnisse.
@AnotherElk: Vielen Dank für den sehr interessanten Hinweis: file-xx
Nur: warum gibt es bei deinem Beitrag keinen Ärger mit dem System?
Ich habe bei entsprechenden Angaben als diesbezüglicher Anfänger große Aufregung erzeugt und meine Texte (auch uralte!) wurden mehrfach gesperrt und dann huldvoll doch wieder zugelassen, z.B:
Hallo,dies ist eine automatische Nachricht von /e/OS community, um dich zu informieren, dass dein Beitrag wiederhergestellt worden ist.
Dieser Beitrag wurde von der Community gemeldet und ein Team-Mitglied hat entschieden, ihn wiederherzustellen.
The app VRN eTarif, version 1.9.25 (com.sevenre.linear_v3145753.apk) is listed in /e/ Application Checker, but in version 1.4.0. I downloaded and installed it via APPS (foundation.e.apps / cleanapk.org).
Unfortunately, I am now unable to purchase a ticket. The "location" setting is enabled, everything works fine. The database has been updated: 7965 stops. ONLY: the stop where you are standing is not found, although you can see the current time in the Android settings (location - VRN etarif - last access).
With other apps (DB Navigator, stadtmobil, OsmAnd, Magic Earth) the display of the location works without problems.
What to do ?
das ist dein bootchart - ~23sek. genau wie bei mir. Nun müsstest Du das anlassen bis Du mal einen gefühlt langsamen Boot erfährst. Die zwei Charts sehen sich halbwegs ähnlich, Zygote hat in deinem Android 12 eher durchgehend was zu tun, in dem Android 13 bei mir ist da Atempause für paar Sekunden - Bootzeit aber gleich. Bin gespannt auf einen langsamen Boot.
1 Like
Ich vermute mal einen Zusammenhang mit den Trust Levels der hier eingesetzten Forumsoftware Discourse …
https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/
Für deine Geduld und Hilfsbereitschaft kann ich mich immer wieder nur bedanken.
Leider habe ich wieder einige, hoffentlich nicht zu unangemessenen Fragen:
- Du schreibst: „Nun müsstest Du DAS anlassen, bis Du mal einen gefühlt langsamen Boot erfährst.“
WAS genau soll ich anlassen?
Nach Einsatz von ADB deaktiviere ich OEM-Entsperrung, USB-Debugging und Entwickleroptionen.
Soll ich alle diese Einstellungen aktiviert lassen, bis sich ein „langsamer Boot“ ereignet?
- Welches „enabled file soll ich solange liegen lassen, bis ein Boot mal langsam war?“
Bisheriger Vorgang:
marc@Perotin:~$ mkdir -p /tmp/android-bootchart;
marc@Perotin:~$ for f in header proc_stat.log proc_ps.log proc_diskstats.log; do
adb pull /data/bootchart/$f /tmp/android-bootchart/$f 2>&1 > /dev/null
done
marc@Perotin:~$ cd /tmp/android-bootchart && tar -czf bootchart.tgz header proc_stat.log
In /tmp ist darauf hin entstanden das Verzeichnis „android-bootchart“ mit dem Archiv „bootchart.tgz“ sowie den Dateien „header“, „proc_diskstats.log“, „proc_ps.log“ und „proc_stat.log“
Soll ich das alles so belassen, bis ein Boot mal langsam war.
- Und was soll ich dann nach einem langsamen Boot tun?
muss nicht, aber spricht nichts dagegen adb immer laufen zu lassen - die OEM-Entsperrung deaktivieren nachdem es einmal “offen” war solltest Du lassen, glaube ich. Mit “DAS” bezog ich mich auf den flag / die Datei in /data/bootchart/enabled - die sollte bleiben. Die Dateien die in dem .tgz Archiv zusammengefasst werden, werden in jedem Boot neu geschrieben.
diese 4 Zeilen mit dem mkdir, for-loop und tar wieder ausführen und selbst dem Python Skript zuführen oder hier wieder posten. Erst da klärt sich ob das Tool überhaupt zur Aufklärung beitragen kann oder ob man Systrace bemüht.
Wenn ich dich richtig verstanden habe, lasse ich die Entwickleroptionen angeschaltet, die Bootloader/OEM-Entsperrung aktiviert und das USB-Debugging ebenfalls aktiviert?
Mein FP3 hat mit /e/OS-Version 1.8.1-r -->Android 11.
Es ist nicht gerootet und somit habe ich auch keinen Zugang auf den internen Speicher mit Android/data.
Nach einem langsamen Boot werde ich die vier Zeilen mit dem mkdir, for-loop und tar wieder ausführen und dir dann das aktualisierte Archiv „bootchart.tgz“ zusenden.
Bis dahin verbleibe ich mit herzlichen Dankesgrüßen!