Lange Startzeit seit e-1.7-r

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 :slight_smile: .

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?

https://www.file.io/ ?

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:

  1. 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?

  1. 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.

  1. 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!

aus dem 1.8 feedback thread - die adb logs in FP3 boots slow (~1 min boot time) (#6501) · Issues · e / Backlog · GitLab zeigen einen 5 minütigen restorecon, die Ursache beheben dass sich der init veranlasst sieht den auszuführen sollte wohl die Bootzeit wieder drücken

Ich habe es bislang mit dem Befehl “adb logcat” nur geschafft, die Ereignisse in Echtzeit darzustellen, das erfolgte aber in einem kaum noch lesbaren Tempo.
Eine Speicherung war mir nicht möglich.
Dann entdeckte ich den Befehl mit Zusatz “adb logcat -d”, die Hälfte der Darstellung findest du hier:
https://oshi.at/oiGM
Viel interessanter scheint mir aber der Sachverhalt zu sein, dass VOR meinem Posting im Forum am 17.02.23 der lang sich ausdehnende Bootvorgang (gitlab: FP3 boots slow) ziemlich häufig auftrat, seit Anwendung deiner Ratschläge bis zum jetzigen Zeitpunkt ÜBERHAUPT NICHT MEHR.

verwendest Du magisk oder ähnliches auf deinem FP3?

Nein, nichts Derartiges!