Externe Festplatte am Raspberry Pi 400 .... Problem

Hi,

ich wollte heute zum ersten Mal eine weitere externe Festplatte am Raspberry Pi 400 anschließen. Bislang hatte ich nur eine externe SSD angeschlossen, über den der Raspi bootet und das macht auch kein Problem. Jetzt hatte ich mir eine neue SSD zugelegt, um mir ein zweites System anzulegen und will diese SSD in einem externen Gehäuse am zweiten USB-3 Port anstecken. Der Rechner hat daraufhin nicht gemotzt - aber ich habe schnell festgestellt, dass beide Eingabegeräte (Tastatur + Maus) nicht mehr richtig funktionierten. Der Mauspfeil lässt sich noch bewegen, aber bei einem Klick tut sich ... nichts! Genauso reagiert der Rechner auch nicht auf eine Eingabe über die Tastatur.

Nach mehreren Versuchen (dazwischen immer den Rechner vom Strom nehmen - ja ich weiß, das soll man nicht, aber was tun, wenn der Rechner nicht auf Eingabegeräte reagiert?) habe ich dann interessehalber ein baugleiches externes Gehäuse verwendet wie von der Boot-Platte, um die neue SSD anzuschließen - mit genau den gleichen Effekten. Dann habe das Selbe mit einem simplen USB-Stick probiert und das funktioniert problemlos im laufenden Betrieb. Anstecken - der Dateimanager öffnet sich - Gerät auswerfen - ausstecken .... neuerlich einstecken und das Spiel wiederholt sich. Also hab ich mich gefragt, woran könnte es liegen, dass die externe Platte nicht genauso funktioniert.

Dann wollte ich es wissen und hab die Platte schon während des Bootens angesteckt gehabt - und schon funktioniert alles klaglos, egal mit welchem externen Gehäuse. Ich hab dann auch erfolgreich die neue SSD eingerichtet, also eine neue Partition angelegt und dann ein neues nfts-Laufwerk eingerichtet. Im Dateimanager kann ich dorthin Dateien kopieren, Verzeichnisse anlegen - alles kein Problem. Und ich kann die Platte auch auswerfen. Aber: will ich die Platte im selben Zustand jetzt wieder anschließen, passiert exakt das Selbe wie oben geschildert. Wenn ich schnell genug bin, kann ich noch den Dateimanager starten - aber sofort danach ist Schluss mit lustig. Der Mauspfeil lässt sich noch bewegen und weder auf eine Maustaste noch auf Eingaben über die Tastatur tut sich irgendwas.

Ist das Problem bekannt? Beziehungsweise gibt es eine Lösung für dieses Problem? Oder stehe ich alleine da mit diesem seltsamen Effekt?

Achja, zu meinem System - cat /etc/os-release gibt diese Ausgabe:

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

NAME="Raspbian GNU/Linux"

VERSION_ID="10"

VERSION="10 (buster)"

VERSION_CODENAME=buster

ID=raspbian

ID_LIKE=debian

HOME_URL="http://www.raspbian.org/"

SUPPORT_URL="http://www.raspbian.org/RaspbianForums"

BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

uname -r gibt diese Ausgabe:

5.10.63-v71+

Hi,

danke für den Tipp - das mit dem aktiven Hub werde ich demnächst testen, sobald ich mir einen leihen kann.

Aber wie erklärt man sich dann die Tatsache, dass es geht, sobald beim Booten beide SSDs angeschlossen sind? Das macht doch vom Strombedarf keinen Unterschied, oder? Und auch, dass der Rechner weiter läuft, sobald die zweite SSD im laufenden Betrieb angeschlossen wird. Wenn ich im Hintergrund ein YT-Video abspiele, läuft das problemlos weiter, ohne dass es mal hakt oder unterbrochen wird. Lediglich die Tastatur reagiert nicht und die Maustasten (die Positionierung der Maus funktioniert weiterhin).

Achja: BEIDE Tastaturen gehen nicht. Also die vom Gehäuse und die angeschlossene Funk-Tastatur (über die auch die Maus läuft). Wobei die Num-Lock Taste sehr wohl noch funktioniert. Ich weiß, das klingt ziemlich konfus.

Ich werde es mal mit einem 128 GB Stick probieren, denn irgendwie habe ich das Gefühl, dass es eher an der Kapazität des Datenträgers liegt. Ich berichte wieder, sobald ich den Hub bei mir habe.

So - irgendwie haben die letzten Aktionen dem System nicht wirklich gut getan. Habe den Raspe wie üblich gestartet - aber der Monitor blieb schwarz. Nach 2-maligem Trennen des Netzteils vom Netz und wieder anstecken kommt eine Startmeldung vom Raspi, wo er einige Infos anzeigt - und darunter dann dieser Text, der sich alle 20 Sekunden wiederholt:

Failed to open device 'sdcard' (cmd 371a0010 status 1fff0001)
USB2[1} 400202e1 connected
USB2 root HUB port 1 init
HUB [01:00] 2.16 000000:01 init port 3 speed 1
HUB [01:00] 2.16 000000:01 init port 4 speed 2
USB MSD timed out after 20 seconds

Sieht wohl so aus, als ob da irgendwann irgendeine wichtige Datei auf der SSD zerstört wurde durch das ungestüme stromlos Schalten des Raspi. Das Jahr fängt ja super an ......

Gibt es eine Möglichkeit, das System auf einfache Weise zu retten? Unter Windows lässt sich die boot-Partition der SSD auslesen und vermutlich auch ändern - auf die zweite Partition habe ich ja unter Windows keinen Zugriff, scheint wohl irgendeine ext? Partition zu sein. Dummerweise finde ich gerade meine SD-Karte nicht, die beim Raspberry Pi 400 dabei war ....

Nachtrag:

Da ich jetzt am Desktop-Rechner sitze, habe ich mal mein Messgerät rausgeholt und mir anzeigen lassen, mit wie viel Strom der USB-Port belastet wird, wenn ich eine SSD im externen Gehäuse anhänge. Demnach sieht es so aus: Die alte SSD braucht etwa 160 mA, die neue begnügt sich mit etwa 160 mA im Leerlauf, beim Schreiben komme ich auf etwa 240 mA. Ist das wirklich schon zu viel?

Seltsamerweise funktioniert es im Moment wieder - hab den Rechner einfach mal eine Stunde laufen lassen mit dem dunklen Monitor - danach (weil immer noch nichts zu sehen war) hab ich den Rechner wieder stromlos gemacht und neu gestartet - und plötzlich lief er wieder.

Im Moment läuft eine Sicherung ....

Wo genau kann ich nach 'under-voltage' suchen?

In dem Verzeichnis /var/log gibt es keine Dateien mit sys.log* ... nur syslog*

Also eine syslog, in der kommt kein 'under-voltage' vor.

In syslog.1 kann ich nicht sagen, die Datei scheint zerstört zu sein. Er will sie wohl in den Editor laden, aber das klappt nicht - der Rechner scheint da nicht weiter zu kommen und Linux ist offensichtlich nicht intelligent genug, den Vorgang selber abzubrechen, versucht es also permanent und am laufenden Band, die Datei zu lesen. Selbst nachdem ich den Dateimanager abgeschossen habe, sehe ich am Blinken der LED am externen Gehäuse, dass er immer wieder darauf zugreift.

Wenn ich in der Console einen cat auf diese Datei absetze, lese ich auch nichts über ein 'under-voltage' .... wobei ich sagen muss: der letzte Eintrag in der Datei ist von heute um 09:17:44 Uhr.

Scheint uns also auch nicht viel zu helfen?

Ohne Ergebnis ....

Je länger ich da jetzt versuche, irgendwas zu tun, umso mehr stelle ich fest: irgendwas läuft nicht ganz rund im Moment.

Wenn ich im Dateimanager die Datei /var/log/syslog.1 aufrufen will, hat er vorhin ewig gebraucht und ist zu keinem Ergebnis gekommen. Nach einem Neustart des Rechners bekomme ich jetzt ein Fenster mit der Meldung 'Dieses Dokument ist kein gültiges UTF-8 - bitte unten eine Zeichencodierung auswählen'.

Ich kann jetzt wählen zwischen Standard (UTF-8) oder System (UTF-8) oder Andere ... aber was immer ich bei 'Andere' dann einstelle, der OK-Button bleibt ausgegraut, lässt sich somit nicht auswählen. Ich kann nur auf Abbrechen klicken, bekomme darauf aber einen leeren Editor.

Aber lassen wir es mal dabei bewenden. Ich denke, da sind jetzt einige Dateien korrupt. Und nachdem ich eh vor habe, auf die Version 11 umzusteigen, wird es wohl nicht viel Sinn machen, da noch allzu viel Aufwand reinzustecken. Es wäre halt schön gewesen, wenn sich das irgendwie geklärt hätte. Jetzt schaue ich mal, was morgen passiert, weil da sollte ja eine neue syslog.1 erzeugt werden, oder?

Gute Nacht .... und danke für die Unterstützung.

RTFM

Hmm .... Strg+C funktioniert aber nicht in der grafischen Oberfläche .... komisch.

Noch eine Frage: im syslog von gestern fand sich dieser Fehler:

 Jan  6 22:06:39 raspberrypi systemd[683]: Starting Virtual filesystem service - Media Transfer Protocol monitor...
Jan  6 22:06:39 raspberrypi dbus-daemon[702]: [session uid=1000 pid=702] Successfully activated service 'org.gtk.vfs.MTPVolumeMonitor'
Jan  6 22:06:39 raspberrypi systemd[683]: Started Virtual filesystem service - Media Transfer Protocol monitor.
Jan  6 22:06:39 raspberrypi dbus-daemon[702]: [session uid=1000 pid=702] Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor' unit='gvfs-afc-volume-monitor.service' requested by ':1.8' (uid=1000 pid=763 comm="lxpanel --profile LXDE-pi ")
Jan  6 22:06:39 raspberrypi systemd[683]: Starting Virtual filesystem service - Apple File Conduit monitor...
Jan  6 22:06:39 raspberrypi gvfs-afc-volume-monitor[853]: Volume monitor alive
Jan  6 22:06:39 raspberrypi dbus-daemon[702]: [session uid=1000 pid=702] Successfully activated service 'org.gtk.vfs.AfcVolumeMonitor'
Jan  6 22:06:39 raspberrypi systemd[683]: Started Virtual filesystem service - Apple File Conduit monitor.
Jan  6 22:06:39 raspberrypi pulseaudio[814]: E: [alsa-sink-bcm2835 HDMI 1] alsa-sink.c: ALSA weckte uns auf, um neue Daten auf das Gerät zu schreiben, doch es gab nichts zum Schreiben!
Jan  6 22:06:39 raspberrypi pulseaudio[814]: E: [alsa-sink-bcm2835 HDMI 1] alsa-sink.c: Dies ist höchstwahrscheinlich ein Fehler im ALSA-Treiber »snd_bcm2835«. Bitte melden Sie diesen Fehler den ALSA-Entwicklern.
Jan  6 22:06:39 raspberrypi pulseaudio[814]: E: [alsa-sink-bcm2835 HDMI 1] alsa-sink.c: Wir wurden durch das POLLOUT-Set geweckt, allerdings lieferte ein anschließender snd_pcm_avail() den Wert 0 oder einen anderen Wert < min_avail.

Es geht um die 3 letzten Zeilen, da steht ja, dass man diesen Fehler den ALSA-Entwicklern melden sollte. Wie/wo genau kann ich das tun?

Hi,

ich hab jetzt eine Vermutung, was tatsächlich passiert (ist):

Kurz nach dem Kauf des RPi hatte ich das Image, was beim RPi dabei war, auf eine bis dahin nicht mehr benötigte SSD übertragen wollen. Nur hatte ich damals keinen Adapter für die SSD, also hab ich kurzerhand eine externe Festplatte geöffnet und die SSD dort reingetan. Und dieses Gehäuse scheint perfekt mit dem RPi zu funktionieren.

Jetzt hatte ich eine zweite SSD geordert und auch gleich zwei externe Festplattengehäuse. Die neue hatte ich in eines der neuen Gehäusen eingebaut und dort habe ich versucht, diese anzuschließen. Was mit den geschilderten Problemen quittiert wurde. Und bis gestern hatte ich meine Boot-SSD noch im 'ausgeborgten' Gehäuse verwendet, das hat zuletzt wieder problemfrei getan (bis auf die Tatsache, dass wohl die eine oder andere Log-Datei defekt ist, weil ich einfach den RPi vom Strom getrennt hatte). Gestern am Abend hatte ich dann noch die Boot-SSD in das neue Gehäuse eingebaut und angeschlossen, den Rechner aber nicht mehr gestartet. Heute in der Früh gab es noch Probleme damit, manchmal hat das Booten funktioniert, dann wieder nicht - also hab ich kurzerhand die SSD wieder in das ursprüngliche Gehäuse reingegeben und seitdem läuft wieder alles problemfrei.

Sieht also eher so aus, als ob der im Gehäuse verbaute USB-Adapter nicht mit dem RPi so tut, wie es soll.

Wieder mal so eine Erkenntnis, dass es mit Linux immer noch nicht so problemfrei läuft wie unter Windows. Weil am Windows-Rechner hat der neue Adapter überhaupt keine Probleme gezeigt, und den hatte ich gestern einige mal aus- und wieder angesteckt. Angeblich gibt es ja auch eine Liste von solchen Adaptern, die nachweislich funktionieren.

Tja ....

Quote from simonz

Du vergleichst beim Anschluss von externen Geräten eine kleine Bastelplatine mit einem ausgewachsenen PC und schließt dann, dass es am Betriebssystem liegt.

Faszinierend...

Faszinierend ist, wie Deine Glaskugel funktioniert ...

Im Vertrauen: ich habe schon ähnliche Probleme unter Linux Mint gehabt.