NomadBSD: Plötzlich kein USB mehr beim Anmelden an X-GUI (Openbox)

S

Schorse23

Member
[Sorry, erster post, und gleich mit einem Problem.]

NomadBSD 2022, ziemlich auf dem aktuellen Stand. Lief bisher so gut wie problemlos.

Heute: Mit dem mc zunächst 14GB vom System auf USB-Stick (NTFS) verschoben. Dann unmittelbar danach 5GB vom gleichen USB-Stick aufs System kopiert.

Später sehe ich aufs System: hängt. Null Reaktion. Maus auch nicht. Beide kabelgebunden.

Gut, hart ausgeschaltet (eventuell hätte ich mit kurzem Druck auf Power sanft herunterfahren können, habe ich aber nicht).

Neustart. Kennwort ZFS (geli) auf der Konsole, OK. ABER: keine Anmeldung bei Openbox möglich, keine Reaktion von Keyboard und Maus. Auch nicht nach umstecken von der Frontblende auf die Mainboard-Anschlüsse.
Auch nicht mit dem zweiten Satz Keyboard+Maus mit Logitech Funkdongle (funktionierte sonst immer, ist 2.4GHz/nicht Bluetooth).

Kurzer Druck auf Power, NomadBSD fährt herunter. Währenddessen sehe ich auf der Textkonsole, daß der Wechsel auf das Logitech Funkdongle registriert wurde. Mehrfacher reboot, gleiches Problem: Keine Reaktion (weder Maus noch Keyboard), sobald ich mich bei Openbox anmelden möchte. Weder Kabel, noch mit Funkdongle.

WAS kann da los sein? Irgendjemand eine Idee? Kurze Suche auf freebsd.org hat nichts irgendwie Ähnliches ergeben.

Gruß.

---
PS: Von den anderen schlechten Dingen heute erzähle ich lieber nichts, glaubt mir doch keiner.
 
Schorse23 schrieb:
auf USB-Stick (NTFS) verschoben. Dann unmittelbar
Zum Vergrößern anklicken....
Möglicherweise war 'unmittelbar' zu früh und der Kopiervorgang noch nicht durch. Schwer zu beurteilen, wenn der kein Blinklämpchen hat.

Schorse23 schrieb:
OK. ABER: keine Anmeldung bei Openbox möglich,
Zum Vergrößern anklicken....
Wenn ein autoscrub startete, weil nicht sauber runtergefahren wurde, ist I/O vom stick erstmal dicht.
Wenn kein scrub startete, solltest du manuell einen starten und hoffen, dass alles gefixt wird.
 
Schorse23 schrieb:
Heute: Mit dem mc zunächst 14GB vom System auf USB-Stick (NTFS) verschoben. Dann unmittelbar danach 5GB vom gleichen USB-Stick aufs System kopiert.
Zum Vergrößern anklicken....

Ich habe mir solche Aktionen übrigens weitestgehend abgewöhnt und nutze stattdessen lieber rsync, um Daten zu verschieben. MC hing bei mir öfters mal oder brauchte gefühlte Ewigkeiten.
 
Ich kenn ja nur FreeBSD Standard.
Kannst du direkt beim anbooten in die "Reparaturkonsole" wechseln? Achtung: Tastatur ist dann US. Evtl sieht man da einen Hinweis bei den Bootmeldungen und die Tastatur geht. Dort Filesystem mounten und /var/log/Messages anschauen.
Kann sein ( wie mr44er sagt) , daß das Filesystem repariert wird. Einfach Mal anstarten und warten.
 
@mr44er: Danke für das Wierdereröffnen.

Tnx für eure Antworten. Der Fehler muß in einem der 400 neuen Pakete stecken, die ich kürzlich per Konsole upgedated hatte (eigentlich dachte ich, ich hätte danach neu gebootet - egal.) Das wird auch hier beschrieben (hatte ich gestern noch nicht gelesen, so ist das bei unpassenden topics :eek:):
https://forum.nomadbsd.org/t/latest-upgrades-nomadbsd-131r-20221130/1249
Unklar ist mir aber, ob der Gute jetzt das neue image 13.2 installiert hat oder das alte 13.1 von 2022.

So.
In die Konsole gebootet; dank 'zfs history' konnte ich auch das verschlüsselte /home mounten.
Manueller scrub lief durch, kein Fehler.
Dabei fiel mir auf, daß sich gelegentlich Maus und Tastur abmeldeten, sowohl per Kabel als auch mit dem Funkdongle.

Jedenfalls ist jetzt ein älteres BE vom Mai aktiv; /home ist voll OK (der alte Firefox des BE meckert über die neueren Profileinstellungen in /home).
Deshalb immer wieder zfs! Keine Ahnung, ob ufs das auch kann.

Erstmal ist das also gelöst.
Derzeitige Vermutung: Ich habe nach dem Einspielen der vielen updates nicht neu gebootet. Es KÖNNTE sein, daß mc beim Kopieren der 5GB Datei gecrasht ist und NomadBSD mitgerissen hat... glauben kann ich das aber nicht wirklich.

NB: rsync mag ja gut und schön sein, aber mc ist halt komfortabler: F5 und gut. Die filemanager in der GUI zeigen bei so großen Dateien keinen Fortschritt.
Das vorausgegangene Verschieben der 14GB auf USB war definitiv beendet; vorher hätte ich das Kopieren nicht starten können. Der USB-Stick hat tatsächlich keine LED.

Gruß!
Schorse.
 
Eine kurze Nachfrage (und hoffentlich blamiere ich mich dabei nicht): NTFS "kassiert" beim Kopieren aber keine Dateirechte, oder?

VLG
Stephan
 
Dumme Fragen gibt's doch nicht...

Beim Kopieren auf NTFS werden alle Rechte gesetzt, außer 'Special'. Besitzer ist dann 'Everyone'.
Beim Kopieren von NTFS auf zfs hat die Datei dann 100777, User {username}, Gruppe 'wheeel' (unter NomadBSD).

---

Ich kann die Abstürze jetzt reproduzieren.
5.4GB Datei mit Thunar auf NTFS (USB-Stick) verschoben. Beim verify (so ist Thunar eingestellt, 'Comparing checksums') crasht mindestens Thunar wegen Speichermangel. Bei einem Versuch fiel Openbox auf die Anmeldung (GUI) zurück. Kurzer Druck auf Power-Taste fährt das System aber wohl ziemlich sicher nach einigen Minuten herunter. Eventuell melden sich dabei noch noch NACH 'all buffers synced' die USB-Geräte ab.
Jetzt gehen zwar im BE vom Mai (s. oben) Maus und Tastatur noch, aber jetzt mit diesem BE geht kein NETZ mehr (LAN). Ich habe KEINE Ahnung, wie Speichermangel das SYSTEM so dermaßen zerschießen kann, daß USB oder Netz nicht mehr funktionieren!

Thunar crashte einmal mit
#dmesg
pid 1821 (thunar), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1831 (tumblerd), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1660 (plank), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1700 (ibus-ui-gtk3), jid 0, uid 1001, was killed: failed to reclaim memory

top sagt vor dem crash (letzter Versuch):
PRI 20/NICE -20 (sic!!, alle anderen Prozesse 0)/SIZE 7314M/RES 5261M/STATE STOP/WCPU 0.00% (sonst beim ersten Schritt [Kopieren] 5-20%, wie auch ntfs-3g)

Der scheduler dreht also wohl voll am Rad, wenn nicht mehr genug RAM zur Verfügung steht. Der PC hat 8GB, bare metal.

Der Vollständigkeit halber: Der USB-Stick ist ein sehr schneller Stick, 512GB von AXE Memory, an USB3 angeschlossen:
USB-DISK 3.2, class 0/0rev 3.20/1.10
SCSI over Bulk-Only; quirks=0x8100
< USB DISK 3.2 PMAP> Fixed Direct Access SPC-4 SCSI device
400MB/s transfers
quirks=0x2(NO_6_BYTE)

Ich habe ein paar Fotos gemacht.

Pfffff.
 
Ich kenn jetzt nomadBSD nicht wirklich, aber das ist ja eigentlich ein Livesystem oder? Hast du also einen USB Stick mit dem System, und einen zweiten, wohin du kopierst? Oder hast du nomad auf einer internen SSD installiert?

Das bei Speichermangel die verrücktesten Dinge passieren ist jetzt mal nicht ungewöhnlich, hast du denn Swap und wie ist der ausgelastet? 8GB ist halt auch nicht viel für ein System mit ZFS und wenn dann noch fuse hinzu kommt und vielleicht sonst noch das eine oder andere..
 
@medV2:
Fast.
Bei NomadBSD lässt sich /home live auf dem USB-Stick mit geli verschlüsseln. Aus dem Live-System (von USB) heraus kann es auf eine feste Platte/SSD installiert werden. Da dabei aber aus *°%$ Gründen keine geli-Verschlüsselung möglich ist (wurde ausgebaut, ging in früheren Versionen), habe ich die USB-Partition per dd auf die SSD gepackt. Klar, die Partition ist dann nur so groß wie der USB-Stick. Das ist aktuell etwas knapp, für swap bleibt da nicht viel, oder ist sogar aus.

Daß zfs ein Speicherfresser ist, gilt höchstens, wenn dedup aktiv ist, sonst nicht. Das ist eine weit verbreitete urban legend, denke ich. Da zfs so gut integriert ist, gibt es kooperativ RAM ans System zurück, wenn er gebraucht wird. Aber Ende ist nunmal Ende, wenn es kein swap gibt.
#top sagte:
1132K Active, 164K Inact, 1279M Wired, 705M Buf, 38M free, ARC 228M total, 1890K Header, 7166K Other (während Thunar 7314M belegt und im STATE STOP ist).

Ich kann NomadBSD nur empfehlen, probierts aus. So einfach kam ein *BSD mMn noch nie daher.

@morromett : Ja. Damit ist Nomad auch für ganz alte Gurken geeignet. Und bringt schon alles mit, was man so brauchen könnte. Was nicht da ist, wird mit pkg nachinstalliert.
 
Ich weiß ja nicht was du sonst mit dem System machst, nur weil etwas funktioniert, heißt nicht, dass es in jedem Anwendungsfall klug ist. ZFS cached deutlich aggressiver als UFS und auch wenn es deutlich besser geworden ist, dauert es immer noch länger bis der ARC wieder freigegeben wird. Aber du hast ja wohl schon den Schuldigen gefunden, wenn der Thunar deinen speicher frisst eventuell einen anderen Dateimanger probieren, oder diese verify Option mal deaktivieren, vielleicht ist das ja das Problem.
Wenn deine SSD sowieso nich voll von deiner Partition genutzt wird, kannst du ja eine swap Partition erstellen.

Und dein erster Absatz widerspricht der Aussage "So einfach kam ein *BSD mMn noch nie daher." :D
 
Von allem Speichergeprügel mal abgesehen und sofern ich mich korrekt erinnere, war ein pkg upgrade (für nomadBSD) generell nicht empfohlen und man sollte dann einfach die nächste Version nutzen. Ich hab es nicht ausprobiert, kann mittlerweile auch anders sein.
 
mr44er schrieb:
... war ein pkg upgrade (für nomadBSD) generell nicht empfohlen und man sollte dann einfach die nächste Version nutzen. Ich hab es nicht ausprobiert, kann mittlerweile auch anders sein.
Zum Vergrößern anklicken....
"pkg upgrade" funktioniert und "freebsd-update fetch install" funktioniert auch mit NomadBSD.
Was bei mir nicht funktioniert hat mit NomadBSD, ist, release-upgrade mit "freebsd-update -r newrelease".
 
mir geht das mal wieder etwas zu schnell.
Also, zunächst werden Maus und Tastatur nach dem Einschalten nicht erkennt? oder erst mit X?
Wenn die nach dem Einschalten noch funktionieren, solltest du vielleicht erst mal auf Konsole nachsehen und auch von dort Ausschalten, wenn du das nicht auch über Netzwerk kannst.
Über Netzwerk wäre dann auch die Alternative zu einer gar nicht mehr erkannten Tastatur/Maus.

Hier kann zur Fehlersuche der berühmte cat /var/run/devd.pipe vielleicht weiter helfen, weil man da die System-Reaktion nach Anschließen einer HW recht gut und ausführlich sehen kann. Die HW muss erst mal hier erkannt und im System registriert werden. Sonst haben alle weiteren Fehlersuchen ja nicht viel Sinn.

All das hat nun wieder gar nichts mit ZFS und wenig RAM zu tun.
Als ich zuletzt nomad ausprobierte, nutze es nicht ZFS. Wie es das bei einer festen Installation nun macht?
Angenommen, es kann da auf ZFS gelegt werden, dann ist aber deine verschlüsselte /home auf dem Stick UFS? die du dann mittels dd rüber kopierst? Das scheint mir irgendwie merkwürdig. Deshalb frage ich mich natürlich, wo ich da was falsch verstanden habe.

Meiner Erfahrung nach macht es immer noch Sinn, dem ZFS seinen ARC zu begrenzen. Gerade bei Systemen, die lange laufen oder auch mit Anwendungen, die mal viel Hunger nach Speicher haben, erlebte ich hier schon mal Engpässe.

Doch nochmal: so wirklich verstehe ich nicht, wie das nun mit Maus und Tastatur zusammen hängen kann.

Was den thunar angeht, benutze ich den zu Gunsten von pcmanfm schon länger nicht mehr. Meiner damaligen Erfahrung nach lief pcmanfm mit weniger Problemen und integrierte auch gut den dsbmc, den nomad ja benutzt.
 
Er hat doch schon geschrieben, dass es ein RAM Problem gibt.

Thunar crashte einmal mit
#dmesg
pid 1821 (thunar), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1831 (tumblerd), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1660 (plank), jid 0, uid 1001, was killed: failed to reclaim memory
pid 1700 (ibus-ui-gtk3), jid 0, uid 1001, was killed: failed to reclaim memory
Zum Vergrößern anklicken....
 
So wie ich das verstanden habe, tritt das auf, wenn er eben im Thunar herumkopiert, und da tritt auch der Speichermangel auf. Aber vielleicht hab ich das auch falsch verstanden.
 
Das Problem trat zunächst beim Kopieren mit mc auf (USB/NTFS->zfs).
Danach funktionierte zumindest das Keyboard definitiv auf der Konsole (vor dem Start von X) noch, aber beim Anmelden mit Openbox nicht mehr.

Auf das BE vom Mai gewechselt, weil Maus und Keyboard mit diesem BE noch funktionieren, auch in Openbox..
Hier trat das Problem dann mit Thunar beim Verschieben auf (null Reaktion von Maus und Keyboard, oder die beiden haben sich sporadisch beim Herunterfahren abgemeldet, gesehen auf der Konsole). Mit diesem BE vom Mai hatte ich dann nach dem reboot in Openbox kein Netz mehr, ist aber wieder da...

mc habe ich noch nicht wieder versucht: pcmanfm kann nicht verifzieren, aber konnte heute 2 mal >5GB auf USB (NTFS) verschieben..

Aktuell weiß ich aber nicht, was mit dem Rechner los ist. Sieht aus wie ein komischer Hardware-Defekt. Mainboard ist ein ASUS A68HM-Plus und war bisher problemlos. Lief auch 24/7 für einige Zeit. Grrrrr.

---

@pit234a : NomadBSD kam zunächst nur mit zfs, ufs kam später dazu (13.1, 2022-12-04). Das sind verschiedene images. Verschlüsselung geht seit 1.0 (2018-02-28). Ich habe nur zfs. Und da ich /home mit geli verschlüsselt haben wollte, ist derzeit der Umweg über dd nötig. Das ist so nicht vorgesehen; meine Aussage 'war nie einfacher' bezog sich auf NomadBSD per se.

PS:
NomadBSD soll meine Windows-Büchsen ablösen. Dazu gibt es aber noch ein anderes großes Problem zu lösen. Alles reines Hobby.
 
Staub rauspusten, ggf. Kriechströme.

Kann natürlich auch ein RAM-Defekt sein.
memtest.org

Memtest86+ | The Open-Source Memory Testing Tool

Memtest86+ is an advanced, free, open-source, stand-alone memory tester for 32- and 64-bit computers (UEFI & BIOS supported)
memtest.org memtest.org
www.memtest86.com

MemTest86 - Official Site of the x86 Memory Testing Tool

MemTest86 is the original self booting memory testing software for x86 and ARM computers. Supporting both BIOS and UEFI, with options to boot from USB.
www.memtest86.com

Auch immer schön sind standby/powerdown/green world/stromspar ...irgendwas Dinge bei USB. -> im BIOS mal alles durchgehen und deaktivieren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben