Hallo,
zuerst die System Infos:
BananaPi Pro mit Jessie, Boot von SD Karte, System auf SSD Platte.
Ich habe gestern einige Änderungen vorgenommen (komplettes Update plus Upgrade gemacht (auch in FHEM), IP Adressbereich wegen VPN Zugang geändert, Anpassungen an Smartvisu und in FHEM ein paar neue Devices eingefügt)
Lief danach alles prima, aber plötzlich wurden die UZSU Timer nicht mehr richtig angezeigt.
Ich ging dann mit putty ins System, das Login ging noch, aber die ZSH Shell spinnte herum. (user war l root, wobei l rot und root blau war, das waren Auswirkungen der defekten Shell ZSH)
Nach einigen hin und her habe ich dann die ZSH deinstalliert, das war es dann mit dem System. Die Banane ließ mich mit Putty nicht mehr rein :-\
Da ich noch parallel mit WinSCP im System war, hatte ich dann doch noch ein wenig Zugriff und kam dann auf die Idee das alte System auf der SD Karte zu mounten. Prima. ZSH rüberkopiert. Dann ging auch noch WinSCP hops und ich war ausgesperrt. Da mittlerweile die 2 Uhr Marke deutlich überschritten war habe ich das Problem dann vertagt. So ganz war die Banane dann doch nicht kaputt, nach einem Reset in der Konsole startet das System wieder und FHEM läuft. Smartvisu nicht, denn der Apache verweigert auch den Dienst.
Heute habe ich die uEnv.txt angepasst und bin das alte System auf der SD Karte gestartet. Die SSD Platte war auch noch da, ein e2fsck -f /dev/sda1 behob ein paar Fehler.
Das gesamte System scheint noch da zu sein (Ich habe dann natürlich FHEM und SmartVisu schnell gesichert 8) ), aber ich bekomme das System auf der Platte nicht mehr zum laufen.
Weiß jemand, wie man die Shell von Hand wieder zum laufen bringt? Ich habe schon den ganzen Tag gesucht, aber nichts richtiges dazu gefunden. Immer nur ..installieren, BananaConfig nutzen, aber nichts wo die entsprechende Datei liegt um die dann zu editieren. Da ich im Moment Zugriff auf beide System habe, könnte ich ich dann die entsprechenden Einträge aus dem laufendem System nehmen oder die entsprechenden Dateien kopieren.
Ich habe meine Banane jetzt neben mir stehen und kann beim kopieren ein pfeifen/summen aus dem BananaPi (wahrscheinlich vom Spannungsregler) hören.
Außerdem wird beim kopieren immer wieder die SATA speed umgestellt, mit einem Haufen Fehlermeldungen SError: {UnrecovData Persist PHYRdyChg} failed command: READ FPDMA QUEUED
Ich habe Testweise ein externes Netzteil und ein normales SATA Kabel genommen, aber das ging gar nicht. Kann das daran leigen das die Platte schon Saft hat und dann erst die Banane startet?
Zum nächste Test zerschneide ich das SATAT/Strom Kabel und benutze die Spannungsversorgung aus der Banane und ein am PC getestetes Sata Kabel.
Muss jetzt Einkaufen, ich hoffe Ihr könnt mir helfen und ich kann nach dem Einkauf das System wieder zum laufen bekommen ::)
Funsailor
Edit:
habe gerade gesehen, das der gesamte Ordner proc auf der Sata Platte leer ist, das wird es wohl sein....
Also doch nochmal frisch ans Werk und alles neu aufsetzen....
Oder ?
Hallo,
da fallen mir eine ganze Reihe Möglichkeiten ein, warum die Shell nicht laufen könnte: Defektes Binary, defekte Libraries oder auch fehlerhafte Einträge unter /dev.
Definitiv ist es nicht ein leeres proc - das wird auf der Platte immer leer sein, da dort ein virtuelles Filesystem gemounted wird.
Lässt sich denn die Shell per chroot starten?
chroot /mnt /bin/zsh
(Wenn unter /mnt Deine Platte mit dem defekten System gemounted ist).
Gruss,
Turo
wenn du die shell, die für root eingestellt(?) ist (s. /etc/passwd), löschst, schiesst du dir in's Knie.
diese windowsmentalität mit löschen, drüber installieren, neu installieren ist bei linux selten hilfreich. fehler lassen sich am besten mit dem lesen von logs und einer gehörigen portion erfahrung beheben.
schau dir die ausgabe von dmsg nach dem booten an.
wenn in proc gar nichts ist, hat das mounten nicht funktioniert...ggf ist / readonly gemountet worden? dann ist das ein folgefehler.
Gesendet von meinem SM-T813 mit Tapatalk
@turo
ja geht. Nachdem ich mir ein paar fehlende Dateien vom "altem" System geholt habe (zsh4)
@micky0867
naja, aber man kann ja komplette System kopieren, so bin ich mit dem System auch von der SD auf die SSD Platte umgezogen..
Ja, aber dann "läuft" die Shell ja! Dann muss das Problem woanders liegen.
Dann muss ich wild raten:
Eintrag von root in /mnt/etc/passwd korrekt?
In /mnt/etc/shadow?
Login als anderer User möglich?
Hilfreich wäre auch statt Putty von einem anderen Linux (oder Mac) System ein
"ssh -v -l root <dein_patient>" zu versuchen - das erzählt dann etwas mehr.
(Dazu muss es dann natürlich wieder von der SSD laufen.)
Gruss,
Turo
Hmm, jetzt kämpfe ich auch noch mit einer DSL Störung...
Die Bits tröpfeln nur noch durch das Netz und dann dann geht es pötzlich wieder mit Vollgas weiter.
Die von dir genannten Dateine sind fast fast gleich (Datum / Uhrzeit nicht)
jetzt sind Sie identisch.
In der die shell Datei fehlte zsh, das hatte ich aber schon heute Mittag Nachgetragen.
Mit einem anderem Linux kann ich nicht dienen, habe ich keins.
Login als anderer User ... habe bisher keinen anderen angelegt. :-[
Hast Du wirklich nur die zsh?
Kannst DU mal gucken, ob Du eventuell eine andere Shell noch "da" hast, z.B. bash?
An eubfachsten wird sein, auf eine andere Shell auszuweichen und dann erst zu "reparieren". Wobei ich eher das Gefühl habe, das Du Dir Dein Dateisystem zerschossen hast. Was hat den fsck repariert?
Hallo Werniemann,
hipp, hipp hurra. Es geht wieder. :) ;D 8)
Nach dem ich die von turo vorgeschlagenen Dateien von der SD auf die SSD kopiert habe und die uEnv.txt zurückgeändert habe, lief das System wieder. Außerdem habe ich noch"fsck.repair=yes" an die Zeile angehängt.
Ein vor dem Reboot gemachter e2fschk -f /dev/sda1 brachte keine Fehler mehr.
Das mit der anderen BASH war ja meine Absicht. Aber ich konnte heute morgen nirgends finden, in welcher Datei ich das ändern kann. Es ist echt zum Haareraufen was man da als Treffer angeboten bekommt. Immer wieder die super Tipps über die Bananaian-config. Super Tipps, dummerweise lies die Shell keine Eingaben zu >:(
In der shells Datei habe ich diese Infos gefunden:
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/bin/zsh
/usr/bin/zsh
/usr/bin/screen
aber erst nachdem ich wieder Zugriff aus das System hatte.
Naja, es läuft wieder.
Aber schön wäre es, wenn du mir sagen könntest wie ich mich aus der Affäre hätten retten können.
Dank an alle
Michael
Edit:
die ZSH merkt sich nichts, da muss noch irgendwo ein Fehler sein. Also nach einem Reboot sind alle alln Befehle weg (da steht nichts mehr!), innerhalb einer Session geht der ZSH schon.
Nochmal Edit:
Ich warte jetzt auf eine neue SSD Platte, scheinbar ist die eingebaute nichts mehr.... melde mich wieder wenn ich die Platte in Betrieb genommen habe. Jetzt muss erst mal die SD Karte herhalten, hoffentlich hält die noch solange durch.
Zur Info: Die aktuelle SSD Platte war schon ein paar Jahe in meinem Desktop PC im Einsatz, hatte nie gejammert oder Fehler gehabt, aber mal irgendwann ist halt doch Schluß. Jetzt warte ich auf das nächste Packet.
Das hört sich nach "Speicher-Problemen an". Weiß jetzt nicht, wo die zsh das ablegt...
Eine andere Shell kannst DUr elativ einfach für einen User einrichten.
https://wiki.ubuntuusers.de/chsh/ (https://wiki.ubuntuusers.de/chsh/)
Anleitung ist zwar für Ubuntu, sollte aber auch auf Dein Banana passen.
Alternativ könntest Du auch die Datei /etc/passwd händisch ändern (gefährlich!)
Hallo,
so, das war mal eine schnelle Lieferung. :) Die neu SSD Platte ist heute morgen angekommen und wurde auch gleich eingebaut.
Ich habe das funktionierende System von der SD Karte auf die neue SSD Platte übertragen, die letzte FHEM und SmartVISU Ablage aufgespielt und siehe da, jetzt brummt es wieder richtig gut. 8)
Auch der Zugriff auf FHEM und SmartVISU ist jetzt richtig flott, da hat die alte SSD Platte doch viel Performance geschluckt.
Jetzt muss ich nur noch die allerletzten Änderungen einpflegen, hmmm was war das wieder ??? muss nochmal in mich gehen.
Die alte SSD ist wirklich hin, das leichte Pfeifgeräusch kam beim zugriff auf die SSD aus dem Plattengehäuse. Ich denke mal da ist der Pegelwandler von 5V -> 3,3 und/oder 1,8V am Ende. Mal sehen ob ich da noch etwas retten kann ;D, aber das ist ein anderes Thema.
Danke an alle Helfer und ein schönes Wochenende
Michael