fsck-Problem mit OpenBSD arm64

berni51

berni51

Open-Net-FreeBSD user
Mal wieder ein Problem, diesmal ist es OpenBSd 7.4 (arm64) auf einem BananaPi M5. Davon sind mittlerweile 4 Stück im Einsatz, und einer davon hat folgendes Problem:

Bei fast jedem Systemstart (schätze so 98%) hängt das System mit folgenden Meldungen:
Code: 
Can't open /dev/rsd1f:
Device not configured.
Can't check file system /dev/rsd1f: unexpected inconsitency;run fsck_ffs manually.

Diese Meldungen kommen dann für alle Partitionen von /dev/sd1.

Dann lande ich im single user mode. Hier rufe ich nun fsck /dev/sd1f usw. auf, und bei allen Partitionen kommt die Antwort:

Code: 
File system clean, not checking.

Ich verlasse dann den single user mode und das System bootet einwandfrei hoch und ist danach zu 100% in Ordnung, alles funktioniert, auch stunden- oder tagelang.
Nur beim nächsten Reboot dann wieder das gleiche Spiel.

Alle 4 BananaPi Systeme sind nach dem gleichen Schema aufgebaut: Die / -Partition liegt auf sd0, der internen emmc mit 16GB. Die weiteren Partitionen e, f, g, h und j sind auf einer externen SSD sd1, die via USB angeklemmt ist. Diese externen SSD sind bei den 4 Bananas aber unterschiedlich, was Hersteller und Größe betrifft.

Versucht habe ich bisher:
1. Neuinstallation des gesamten Systems.
2. Einsatz einer anderen externen SSD. Ursprünglich war eine nvme (via USB) an diesem Problem-BananaPi, die dann gegen eine ngff ausgetauscht wurde.
3. Kabel und Adapter der externen SSD gewechselt.
4. Stärkeres Netzteil verwendet.
5. Die fstab-Einträge nicht mehr über die UUID der Partitionen definiert, sondern die Device Namen benutzt.

Hat aber alles nichts genutzt.
Mittlerweile rufe ich im single user mode nur noch ein kleines Script namens f auf, das ein fsck über die Partitionen laufen lässt. Dabei ist eigentlich nicht mal das nötig, denn auch ohne fsck und einfach durch Verlassen des single user mode läuft das System wieder ordentlich hoch.

Irgendeine Idee, was hier im Argen liegt? Mir fällt gerad nix mehr ein.

Berni
 
hi

mal ganz bloed gedacht:

kann es sein das die ssd etwas mehr zeit benötigt um zu initalisieren ?
oder der usb port .

so das die paar sekunden den unterschied machen zwischen fsck und
normal boot.

Holger
 
Das laesst sich hacken.. schau mal in /etc/rc, wo er die mounts macht. da noch einen sleep 3 o.ae. davor.
Das "device not configured" geht schon in die Ecke, die mark beschreibt.

(rc.local duerfte zu spaet sein, daher der direkte hack)
 
mark05 schrieb:
oder der usb port
Zum Vergrößern anklicken....
Jep, riecht danach. USB3 muss irgendwie vorglühen. :)

Bei einer VM mit ähnlicher Konstellation brauche ich entgegen aller Vernunft 10sec delay, damit das klappt.

Als Gegentest: Wenn es da USB2-Ports gibt, versuche die mal oder falls das BIOS es hergibt USB3-Ports fest auf USB2 degradieren.
 
Habs gerade mit einem "sleep 5" in der /etc/rc probiert - und es funktioniert!!!
Ihr hattet Recht, das Banana-USB an diesem Board braucht offensichtlich etwas länger zur Initialiserung der SSD.

USB2 hat der BananaPi M5 nicht mehr. Aber jetzt kommts mir wieder: Auch der Raspberry4 hat manchmal Probleme mit SSDs an USB3-Ports.
Jedenfalls hat das sleep jetzt 5 einwandfreie Bootvorgänge ermöglicht - vorher undenkbar.
Ich danke euch für die schnelle Hilfe.

Berni
 
Zuletzt bearbeitet:
Präzise und analytisch bis in die Haarspitzen - aber Du hast natürlich Recht. Die SSDs selber waren nie schuld daran.
 
Habt ihr auch vielleicht hierfür einen Tipp:
Bei der seriellen Verbindung werden ständig "yyyyy" auf den Schirm geschrieben. Ich bau die Verbindung mit cu über einen seriell/USB-Converter auf, Parameter sind 115200-8N1.
Verbindung steht einwandfrei, aber dese yyyyy! Passiert nur bei den Bananas (bei allen), die Rasperries geben einen sauberen Bildschirm.
Bei minicom exakt das gleiche Bild.
 

Anhänge

  • 2024-02-22-17-30_1280x1024.png
    2024-02-22-17-30_1280x1024.png
    243,4 KB · Aufrufe: 37
Hab ich versucht, aber die Gegenstelle, also der Banana, macht nur und ausschliesslich 115200. Bei 9600 z.B. kommt gar nichts mehr.
Mittlerweile habe ich so ziemlich alle Parameter in minicom durch, keine Besserung.
 
Die ÿÿÿÿ kommen bei Tastendruck, etwa 10 nach jedem eingetippten Zeichen.
Die Flows sind beide deaktiviert, mit HW flow erhöht sich die Anzahl der ÿÿÿÿ, mit SW flow geht gar nichts mehr.
Die Ausgaben, egal was, kommen alle sauber zurück - OK, manchmal werden ganz am Ende ein paar ÿÿÿÿ eingefügt.
 
Rennt die Banane eventuell nicht auf UTF8 und der normale Pi schon?

Ist das falsche ÿ dann nicht der break im falschen Zeichensatz?
 
Also im normalen Betrieb läuft auch der Banana auf UTF-8, aber was da hinter dem debug-uart werkelt, scheint mir doch ein Stück Firmware zu sein. Und was da läuft - ich weiss es nicht.
Es gibt ja einen recht umfangreichen Befehlssatz in der Firmware, da versuch ich gerade heraus zu bekommen, was da alles geht. Ist leider sehr schwach dokumentiert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben