Windows-Krankheit unter Raspberry Pi OS bullseye 64-bit am Raspi400?

    Hi Leute,

    allmählich fällt es mir immer mehr auf, mein Raspi hat sich wohl mit einer Krankheit angesteckt, die ich bislang nur auf Windows-Systemen beobachtet habe: Alles dauert immer länger!

    Nach der kompletten Neuinstallation am Raspi brauchte es vom Einstecken des Netzteils bis zur Eingabe des Passworts etwa 4 bis maximal 5 Sekunden. Mittlerweile trödelt der Rechner schon deutlich über 10 Sekunden rum, bis ich das Passwort eintippen kann. Auch das Aufrufen vom Firefox dauert gefühlt länger, der Aufruf einer Website dauert ebenfalls gefühlt deutlich länger.

    Ist es auch unter Raspberry Pi OS angebracht, von Zeit zu Zeit den Rechner komplett neu aufzusetzen? Der Rechner ist ja sowieso nicht der Schnellste, aber wenn jetzt auch noch die Handbremse angezogen ist, wird es mühsam. Ganz zu schweigen, wie es ist, wenn das in dem Tempo so weitergeht. Ist ja erst gerade mal etwas über ein halbes Jahr her, dass ich den Rechner komplett neu aufgesetzt hatte.

    Oder gibt es Möglichkeiten, herauszufinden, was das System derart ausbremst?

  • Windows-Krankheit unter Raspberry Pi OS bullseye 64-bit am Raspi400?? Schau mal ob du hier fündig wirst!

    Hallo ralfi1988,

    die Informationslage ist äusserst bescheiden, um Dir auf die Sprünge zu helfen.

    Mehr als dmesg und df wird Dir erstmal nicht bleiben, um herauszufinden, womit sich der Raspberry Pi beim Hochfahren beschäftigt und was wie lange dauert. Letztlich ist auch der freie Speicher des Boot-Mediums entscheidend.

    Einen entscheidenden Einfluss auf die Geschwindigkeit hat auch der für GPU reservierte Speicher.


    Beste Grüsse

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Quote from ralfi1988

    Ist ja erst gerade mal etwas über ein halbes Jahr her, dass ich den Rechner komplett neu aufgesetzt hatte.

    Wenn ich deine Threads und Beiträge aus der Vergangenheit richtig im Kopf habe, hast du sehr viele Sachen ausprobiert. Manchmal erfolgreich und manchmal nicht erfolgreich.

    Da hier keiner nachvollziehen kann, was du alles ausprobiert, installiert, deinstalliert (ob vollständig oder unvollständig...) , ob nur Software aus offiziellen Repos, oder auch Software von Drittanbietern.... , welche Systemdateien verändert wurden.... ist eine Beantwortung deiner Frage schwer bis unmöglich.

    Da bleibt dir zunächst wirklich nur dmesg und df wie Andreas bereits angemerkt hat.

    Danke mal für die ersten Vorschläge.

    Franjo G

    Bin jetzt in mich gegangen, um mich zu erinnern, worauf Du jetzt anspielst. Software von Drittanbietern habe ich nie installiert. Wüsste auch nicht, welche. Ich hab immer wieder mal nach Programmen gefragt, um eine bestimmte Arbeit zu erledigen - aber meiner Erinnerung nach hatte ich dabei ausschließlich über Add/Remove Software installiert bzw deinstalliert.

    Einmal habe ich einen anderen Store installiert, aber den habe ich nach Anleitung hier im Forum wieder rausgeworfen. Und gelegentlich lösche ich diverse Dateien, die Stacer so findet. Das wars.

    dmesg gibt das hier aus (mir sagt das gar nix):

    df gibt das hier aus:

    Code
    Dateisystem    1K-Blöcke  Benutzt Verfügbar Verw% Eingehängt auf
/dev/root       60253588 28152520  29595952   49% /
devtmpfs         1686604        0   1686604    0% /dev
tmpfs            1852332        0   1852332    0% /dev/shm
tmpfs             740936     9188    731748    2% /run
tmpfs               5120        4      5116    1% /run/lock
/dev/sda1         258095    30827    227268   12% /boot
tmpfs             370464       36    370428    1% /run/user/1000

    Demnach ist die SSD zu knapp 50% belegt und noch gut 28 GB sollten aktuell frei sein.

    Ich habe beim Booten auch den Verdacht, dass hier ein Boot-Vorgang beginnt und abgebrochen wird, denn nach etwa 7 oder 8 Sekunden sehe ich manchmal kurz das bunte Quadrad aufblitzen, das standardmäßig kommt, wenn der Raspi mit Strom versorgt wird. Meine Vermutung: Beim ersten Versuch zu booten erkennt das System meinen USB-Hub und bricht den Vorgang ab, scheint dann intern irgendwas zu ändern (aber nicht auf Dauer) und beginnt einen zweiten Boot-Vorgang mit geänderten Parametern. Auch gut zu sehen, weil LEDs für die beiden USB-Ports kurzzeitig ausgehen, an denen die Maus und die Tastatur angeschlossen ist. Ist sowas denkbar?

    Hallo ralfi1988,

    zu dmesg:

    Was verursacht die Fehlermeldungen von Sek. 12,9 bis 20,6? Das füllt immerhin 40% Deines Bootvorgangs.

    Bei mir kommen solche Fehlermeldungen nicht.

    Deine Ausgabe von df ist nicht weiter auffällig - ausser das 2 GB freier Speicher für mich grenzwertig wenig ist. Je nach dem, was Du sonst so eingestellt und konfiguriert hast. Und nicht vollständig beseitigt hast.

    Und mit dem Netzwerk stimmt was nicht. Aber das ist dann die nächste Baustelle.


    Beste Grüsse

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Edited once, last by Andreas (August 14, 2022 at 11:11 PM).

    Ausgabe von df -h:

    Code
    Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        58G     27G   29G   49% /
devtmpfs        1,7G       0  1,7G    0% /dev
tmpfs           1,8G       0  1,8G    0% /dev/shm
tmpfs           724M    9,0M  715M    2% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
/dev/sda1       253M     31M  222M   12% /boot
tmpfs           362M     32K  362M    1% /run/user/1000

    Ausgabe von free -m:

    Code
                  gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       3617        1290        1156         166        1170        2084
Swap:             99           0          99

    Welcher Art von Problemen sollte es mit meinem Netzwerk geben? Der Raspi ist via Kabel mit dem DSL-Modem/Router verbunden, WLAN ist ausgeschaltet.

    Hallo,

    die Ausgabe von systemd-analyze blame fehlt noch.

    Quote

    die ich bislang nur auf Windows-Systemen beobachtet habe: Alles dauert immer länger!

    Kann ich für meine fünf Rechner mit Windows 10 bzw. 11, Installation von Win liegt teilweise > 5 Jahre zurück, nicht bestätigen.

    Gruß, noisefloor

    Quote from noisefloor

    die Ausgabe von systemd-analyze blame fehlt noch.

    Sorry, hab ich wohl übersehen:

    Muss mich leider korrigieren - mir ist gerade eingefallen, dass ich ja das Tool Stressberry gemäß dieseer Anleitung installiert habe:

    https://bitreporter.de/raspberrypi/ra…mit_Stressberry

    Für jene, die dort nicht reingucken wollen - diese Anweisungen habe ich im Terminal eingegeben:

    Code
    sudo apt install stress
pip3 install stressberry --user
stressberry-run out.dat
stressberry-plot out.dat -o out.png

    Die letzte Zeile erzeugt nur eine Grafik über den Temperaturverlauf während des Tests.

    Hallo Ralfi,

    die Ausgabe von systemd-analyze blame ist für mich erst mal unauffällig, habe hier nur einen Pi 2 zum vergleichen, der läuft headless über Lan und darauf werkelt nur ein Pi-Hole, sonst dient er nur für verschiedene Experimente.

    Dort sehen die größten Zeitfresser so aus:

    Code
    # systemd-analyze blame
2.788s dev-mmcblk0p2.device
1.892s log2ram.service
1.346s bluetooth.service
986ms user@1000.service
876ms dbus.service
830ms systemd-logind.service
697ms systemd-networkd.service
..........


    Der Pi2 ist eigentlich auch nicht der schnellste beim Starten, sieht bei mir so aus:

    Code
    # systemd-analyze time
Startup finished in 10.203s (kernel) + 9.113s (userspace) = 19.316s
multi-user.target reached after 8.835s in userspace.

    allerdings scheinen bei dir relativ viele Dienste gestartet zu werden (größer 50?), bei meinem Pi2 sind es 38:

    Code
    # systemd-analyze blame | wc -l
38

    und zum Vergleich auf einem Linux PC

    Code
    # systemd-analyze blame | wc -l
45

    Jeder gestartete Dienst braucht beim Boote natürlich extra Zeit und kann, wenn nicht notwendig auch abgeschaltet werden, z.B wpa_supplicant.service wenn du sowieso nur per Lan ins Netzwerk gehst.

    Vielleicht hat ja einer der anderen Foristen eine Kombination wie du (Pi400 mit Buster 64 bit) und kann bessere Vergleichswerte liefern.

    Ansonsten kann ich auch nicht sagen, was bei dir bremst, außer auf die Hinweise der Vorposter ( vielleicht Netzwerkproblem, auch Netzwerkkabel sollen schon mal kaputt gegangen sein ) zu verweisen.

    Gruß Martin

    Quote from Martin28

    allerdings scheinen bei dir relativ viele Dienste gestartet zu werden (größer 50?), bei meinem Pi2 sind es 38:

    Bei mir:

    Code
    # systemd-analyze blame | wc -l
65

    Nachdem ich versuche, den Boot-Vorgang genauer zu beobachten, komme ich immer mehr zu dem Schluss, der eigentliche Boot-Vorgang dauert gar nicht sooo lange. Ich bin überzeugt davon, dass der Rechner zumindest 1x zwischendurch neu bootet. Leider ist der Monitor zu langsam bei der Anzeige, sodass ich nicht alles sehe, was der Rechner tatsächlich über HDMI ausgibt.

    RTFM

    Ich kenn mich da zu wenig aus in den Logfiles. Was da drin steht, ist für mich unverständliches Kauderwelsch. Schon auch deswegen, weil ich ja gar keine Vorstellung davon habe, was beim Booten genau passiert (bzw passieren soll). Ich sehe beispielsweise bei jedem 5.Bootvorgang gerade noch das bunte Quadrat aufblitzen. Wo sehe ich im Logfile, dass dieses Quadrat am HDMI-Port ausgegeben wird? Oder: hie und da sehe ich einen Raspberry OS Startbildschirm. Wo sehe ich im Logfile, dass dieser Startbildschirm angezeigt wird?

    Dass es mindestens 2 Bootvorgänge sind, erkenne ich daran, dass ich einen USB-Hub am Raspi angeschlossen ist. Die rote Power-LED leuchtet innerhalb von 2 Sekunden auf, nachdem der Raspi unter Spannung gesetzt wurde. Daraus schließe ich, dass zu diesem Zeitpunkt die USB-Ports aktiviert wurden und dort Spannung anliegt, die der Hub abgreift. Ein paar Sekunden später gehen die beiden blauen LEDs an für die beiden Ports, wo die Tastatur und die Maus am Hub angeschlossen sind. Und dann gehen die beiden blauen LEDs plötzlich wieder aus, woraus ich schließe, dass der USB-Port am Raspi wieder deaktiviert wurde. Und daraus schließe ich, dass während des ersten Boot-Vorgangs eine USB-Hardware erkannt wurde, für den erstmal ein Treiber für Raspberry Pi OS geladen werden muss. Also wird irgendwo irgendwas eingetragen, sodass beim Reboot der Treiber automatisch geladen wird. Dass ein Reboot erfolgt, schließe ich daraus, dass JETZT das bunte Quadrat sichtbar wird (wenn es sichtbar wird). Und dann sehe ich (falls der Monitor schnell genug reagiert) den Willkommensbildschirm von Raspberry Pi OS. Und danach gehen die beiden blauen LEDs am USB-Hub wieder an. Und etwa 5 bis 6 Sekunden später kann ich mein Passwort eingeben.

    Das ist grob gesagt der Ablauf, wenn ich den Raspi einschalte.

    Ich werde beim nächsten Booten testen, wie sich der Rechner verhält, wenn ich den USB-Hub abstecke und die Maus alleine am Raspi direkt anschließe. Wenns dann deutlich schneller bootet, dann scheint der USB-Hub den Bootvorgang zu beeinflussen.

    Du solltest einmal in der Documentation von https://www.raspberrypi.org/help/ schmökern, v.A. was die HDMI und Audio Einstellungen betrifft. Die Bremse fängt mMn spätestens in Zeile 409 von #5 an, setzt sich über Zeile 496 bis 507 und 509 bis 520 fort, bis die Einrichtung des hdmi-audio-codec abgebrochen wird. Der Hinweis in Zeile 324 könnte auch durch ein aktuelles Update beseitigbar sein.

    Linux verwendet im Bootprozess zwei Tastatur und Pointer Devices. Einmal für die Textkonsole und einmal für die Grafik(konsole). Es ist durchaus möglich, dass beim Umschalten in den Grafikmodus die Eingabegeräte kurzfristig vom USB Bus getrennt werden.

    Servus !

    RTFM = Read The Factory Manual, oder so

    RTFM

    Danke für den Link - nur leider ist das in einer falsche Sprache verfasst ...

    Der Hinweis in Zeile 324 könnte daher resultieren: Raspberry OS Bullseye 64-bit fährt nicht ordnungsgemäß runter ...

    Damals hatte ich immer wieder das Problem, dass der Raspi beim Runterfahren hängen geblieben ist und dabei ständig Meldungen ins Log geschrieben hat. Es hat sich herausgestellt, dass der Dämon, der für die Zeitsynchronisation, permanent einen Fehler gemeldet hat. Das scheint dazu geführt zu haben, dass der Dämon im Zuge des Shutdowns wieder gestartet wurde, obwohl kurz davor der Dämon beendet wurde - und das wurde kurz vor dem stromlos Schalten erkannt, weswegen der Rechner nicht abgeschaltet wurde. Es hat sich herausgestellt, dass bei meinem Router wohl die Synchronisation nicht klappt, wenn IPv6 eingeschaltet ist. Seit ich IPv6 ausgeschaltet habe, ist das Problem nicht mehr aufgetaucht.

    Das eigentliche Problem von damals wurde, meiner Meinung nach, auch nie wirklich geklärt. Kann es sein, dass der Router nicht dem Standard entspricht?

    Auf jeden Fall installiere ich immer alle anstehenden Updates sofort, meist unmittelbar nach dem Booten des Raspi.

    Was den HDMI-Audio-Codec betrifft, da weiß ich auch nicht, woher das kommt. Und noch weniger, was ich dagegen tun können sollte. Wie gesagt, da ich so gut wie keine Englisch-Kenntnisse habe, überfordert mich die verlinkte Dokumentation komplett. Und irgendeine automatisierte Übersetzung bringt auch nicht viel, weil bei solchen Dokumentationen in der Regel mit zu vielen Fachbegriffen herumgeworfen wird, die dann der Algorithmus falsch übersetzt.

    Was genau sagt diese Zeile aus?

    Code
    [    6.552236] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login