020-10-05_smartpi_buster.img Grundinitialisierung führt zu korruptem Filesystem

[muennich]

Hallo liebe Leut,

bitte um Hilfe.
Ich hab nun zum 2. Mal von vorne angefangen.

• 2020-10-05_smartpi_buster.img auf neue SD
  
• Rein in einen neuen rpi 3B+ (zuvor erfolgreich getestet mit 2021-01-11-raspios-buster-armhf-lite.img) ... der 1. Versuch scheiterte mit einem älteren rpi3B ähnlich
  
• rpi angeschlossen an LAN - das smartpi2.0-Modul, Dieses an L und N - Maus, Tastatur, HDMI
  
• startet zuerst normal.
  
• dann bleibt für ca. 15min der Bildschirm dunkel.
  
• Dann erscheint "zeilenweise" die Desktop-GUI ... nur mit dem Papierkorb (wirklich auf Deutsch!)... sonst nix. 
  
• Ich habe noch mal 1/2h gewartet ... keine Änderung
  
• Mauszeiger bewegbar ... über rechte Maustaste Kontextmenü mit "New Folder", "New File" ...
  
• Wenn auf das Papierkorbsymbol links geklickt wurde, dann verschwindet es (=> nix mehr am Desktop! ... nur noch das Standard-Hintergrundbild). => neues Kontextmenü bei Rechtsklick: "Terminal emulator ... Web browser ... Applications ... ObConf ... Reconfigure ... Restart ... Exit"
  
• Bei Auswahl von "Reconfigure" verschwindet das Kontextmenü und es bleibt ein leeres Hintergrundbild mit bewegbarem Mauszeiger ohne Reaktion auf die Maustasten. 
  

• Über SSH und IP-Adresse (aus Router und MAC-Adresse des Vorversuches mit rpi-Standard-Image bekannt!) kommt keine Verbindung zustande ... auch nicht nach mehr als einer Stunde.
  
• "PuTTY Fatal Error - Network error: Software caused connection abort"
  

• Bei http:\<IP-Adresse> kommt zuerst, ganz träge, die Web-GUI mit aberwitzigen Werten (die angeschlossenen Messwandler sind leer, kein Stromdurchfluss!). Nach erfolglosen Navigationversuchen im WebGUI-Menü kommt dann nur noch Textmeldung "500 Internal Server Error".
  

• => Nach 2h ohne Veränderung Stromunterbrechung mit Neustart der aber nur zu Meldungs"flut", unter Anderm mit ext4-Fehlern bis zu "end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(172,2)" führt.
  
• keine Verbindung über SSH oder gar http möglich!
  

Das rpi-Board schein unbeschadet, da des Board (wieder "befreit" vom smartpi2.0-Modul und über die micro-USB-Buchse mit 5V-rpi-Standard-Netzteil versorgt) mit der SD aus dem Grundfunktionstest  einwandfrei startet und läuft!

Ist das smartpi2.0-Modul eventuell defekt?


Gern kann ich für tiefere Analysen Bildschirmphotos nachliefern.

Danke für Unterstützung.

Gruß
Andreas

[jens]

Da scheint die SSD wohl defekt zu sein.

[muennich]

Nein, die SD kann es leider nicht sein! Ich habe den Vorgang mit einer 2. (neuen) reproduziert!

[muennich]

Hallo Jens,

ich bitte um weitere Ideen, Vorschläge zur Analyse.
So kann ich das Modul nicht nutzen.
Alternativ möchte ich das Modul zurücksenden und das Geld wiederhaben.

Danke
Gruß
Andreas Münnich

[muennich]

Ich habe das jetzt zum 3. Mal reproduziert. Dieses Mal ohne das Modul zu verbinden. 5V-Speisung über micro-USB des Raspi. 
SD mit 2020-10-05_smartpi_buster.img startet und agiert danach total träge. Reaktionszeit 1/100 zu normal. 
Nach ca. 3h bricht eine Verbindung per ssh mit "systemd[1]: Freezing execution." ab. Über Maus, Tastatur, HDM direkt auf Desktopoberfläche ähnlich träge und zum Schluss keine Reaktion auf nix mehr.
grüne LED leuchtet durchgehend. erlischt erst 15 min vor "Freezing execution"

Alle SD´s darauffolgend mit RPI-Buster-Standard-Image geflash => läuft einwandfrei!

Wer hat denn bitte zuletzt 2020-10-05_smartpi_buster.img erfolgreich in Betrieb gebracht?

[frank]

Hallo Andreas,

bei mir läuft dieses Image seit Herbst ohne größere Komplikationen auf einem Raspi 2B.

Wenn das Verhalten ohne angeschlossene SmartPi Platine identisch ist, liegt für mich der Schluss nahe, dass die Kommunikation mit der Platine per I2C bei dir gar nicht funktioniert. Vielleicht kannst du das Betriebssystem mal ohne den SmartPi Service starten? Wenn das System dann normal läuft, kannst du mal i2cdetect starten um zu prüfen ob das Modul überhaupt erkannt wird. Stromversorgung braucht es dazu allerdings. Falls das klappt, würde ich mal smartpireadout per Konsole starten und die Ausgabe beobachten.

Grüße
Frank

[muennich]

Hallo Frank,


danke für Deinen Beitrag. 
Bitte gib mir Hinweise wie ich bereits vor dem Erststart den SmartPi Service verhindern kann.

Wenn ich deinen Ansatz richtig verstehe, dann könnte ja auch i2cdetect bei angeschlossenem smartpi2.0-Board bei laufendem Standard-Image aufschlussreich sein?
Hättest Du bitte einen Befehlszeilensatz für mich und auch das erwartete Ergebnis für mich?

noch etwas Anderes: Es wundert mich, dass die Imagedatei 15GB groß ist! Selbst ein RPI-Standard-Full-Image, mit einem großen SW-Umfang, hat nur 3GB!?


Danke
Gruß

Andreas

---

@Jens: kann denn das smartpi-Board erkannt werden, wenn es vom Raspi aus versorgt wird .... resp. kann der rpi das smartpi auf 5V versorgen?

[frank]

Um den automatischen Start zu verhindern, müsstest du die Speicherkarte vor dem ersten Start mit einem Betriebssystem öffnen, das das Dateisystem lesen kann (Windows geht nicht) und in /etc/systemd/system/multi-user.target.wants den Symlink smartpi.service löschen.

[muennich]

@Frank: Danke. Bin heute leider nicht mehr zum testen gekommen. Ich hoffe da morgen dazu zu kommen.

[muennich]

habe das Image angepasst = Symlink smartpi.service gelöscht. 
angeschlossen incl. smartpi2.0-Modul, LAN und HDMI.
soeben gestartet. gleich nach dem Regenbogen-Startbildschirm und den ersten service-Starts kommt schwarzer Bildschirm mit "outologin pi-user" ... dann "60 sec timeout" ... "retying Pi-user" ... dann leerer schwarzer Bildschirm und das mit aktiver roten und (nicht blinkenden)grüner Led ... das ca. 13min lang. 
Dann baut sich langsam der raspiOS-Desktop auf.
Im Netzwerk gab es, schon während des schwarzen Bildschirms Antwort auf ping, aber Verbindung per SSH erst 15 min nach dem Start. Erstes Login mit pi/smart4pi sehr träge.
2min. nach Erscheinen des Desktophintergrundbildes kam die raspberry-Menüleiste und Crome-Fenster mit "localhost" und rotem Ausrufezeichendreieck. Mauszeiger "bedienbar".
Auch nach nun 25 min. ist jedoch keine Reaktion auf Eingaben erkennbar.

---

über 40 min. nach dem Start: Ein "sudo apt-get update" auf der ssh-verbindung führt erst nach ca. 2 min zu einer Reaktion. Und diese auch sehr ungewöhnlich langsam .... erst nach einer gefühlten Ewigkeit (insg. ca. 20 min.) sind die Informationen downgeloaded und verarbeitet. incl.  "OK:3 https://repro.enerserve.eu/packages buster InRelease"

##################################################
login as: pi
pi@192.168.10.155's password:
Linux smartpi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Mar 20 14:45:41 2021
pi@smartpi:~ $ sudo apt-get update
Holen:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15,0 kB]
Holen:2 http://archive.raspberrypi.org/debian buster InRelease [32,9 kB]
OK:3 https://repro.enerserve.eu/packages buster InRelease
Holen:4 https://packages.grafana.com/oss/deb stable InRelease [12,1 kB]
Holen:5 https://repos.influxdata.com/debian buster InRelease [4.737 B]
Holen:6 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages [13,0 MB]
Holen:7 http://archive.raspberrypi.org/debian buster/main armhf Packages [372 kB]
Holen:8 https://packages.grafana.com/oss/deb stable/main armhf Packages [24,6 kB]
Holen:9 https://repos.influxdata.com/debian buster/stable armhf Packages [926 B]
Holen:10 http://raspbian.raspberrypi.org/raspbian buster/contrib armhf Packages [58,7 kB]
Holen:11 http://raspbian.raspberrypi.org/raspbian buster/non-free armhf Packages [104 kB]
Es wurden 13,6 MB in 8 min 15 s geholt (27,5 kB/s).
Paketlisten werden gelesen... Fertig
pi@smartpi:~ $
##########################################################

Da stimmt doch was nicht. Mit dem StandardRaspiOS-Image geht das "ratzfatz"!

---

Nach nun über 1,5h nach Startbeginn habe ich mich mit zähem Warten über raspi-config auf dem ssh-login zum Deaktivieren der I2C-Schnittstelle "durchgekämpft" => leider keine Gesamtveränderung.

---

"Spassehalber" erneut "sudo apt-get update" führt zu:

########################################
OK:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:2 http://archive.raspberrypi.org/debian buster InRelease
OK:3 https://repro.enerserve.eu/packages buster InRelease
OK:4 https://packages.grafana.com/oss/deb stable InRelease
OK:5 https://repos.influxdata.com/debian buster InRelease
Paketlisten werden gelesen... Fehler!
E: Problem parsing dependency 21
E: Fehler aufgetreten beim Verarbeiten von grafana (NewVersion2)
E: Problem with MergeList /var/lib/apt/lists/packages.grafana.com_oss_deb_dists_stable_main_binary-armhf_Packages
E: Die Paketliste oder die Statusdatei konnte nicht eingelesen oder geöffnet werden.
#####################################################

beginnt da bereits die filesystemkorruption?

---

Der Desktop bleibt weiter unbedienbar ...

---

Ein Updateversuch von "raspi-config" führt zu: " There was an error running option 8 Update"
Und die grüne Led leuchtet weiter dauerhaft!