Nach ein paar Tagen keine Verbindung mehr zum Router

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Nach ein paar Tagen keine Verbindung mehr zum Router

      Vielleicht hat jemand von euch dasselbe Problem schon mal gehabt:

      Ich installiere OMV ganz normal auf dem Raspberry Pi, mache die üblichen Updates und initialisiere die angeschlossenen Datenträger. So weit, so gut. Wenn ich jetzt aber mal ein paar Tage Pause mache, gibt es bei nächsten Einschalten auf einmal keine Verbindung mehr zum Router. Ich benutze den Speedport W921V. Zwar ist der Raspberry Pi in der Liste der verfügbaren Geräte mit IP- und MAC-Adresse gelistet, aber blass, also inaktiv. Aktualisierung bringt nichts. Nach dem Einschalten blinkt die Kontrolllampe, auch die beiden Lämpchen am LAN-Anschluss zeigen einige Regung, aber das war's denn auch.

      Spiele ich OMV neu auf, habe ich sofort wieder Verbindung zum Router. Das ist aber auf Dauer keine Lösung.

      Gibt's da einen Trick?
    • NiroStahl wrote:

      Gibt's da einen Trick?
      Geht es nach einem Reboot des PIs nicht auch wieder? Immer gleich neu installieren, ist auf Dauer nicht die Lösung und daran liegt es wahrscheinlich auch nicht.

      Vielleicht mal eine längere Netzwerkleitung zwischen Router und PI verwenden. Kein Scherz. Die ganzen 'Green IT'-Ports reduzieren die Leistung, wenn eine kurze Leitung verwendet wird. Manche Gegenstellen meinen dann, dass drüben keiner mehr da ist. Also vielleicht mal in den Einstellungen aller beteiligter Geräte schauen, ob man das Energiemanagement der Lan-Ports abschalten kann. Wenn nicht, dann tatsächlich mal ein längeres LAN-Kabel ausprobieren.
      OMV 3.0.78 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • Danke für die rasche Reaktion. Reboot? Du meist Aus- und wieder Einschalten? Nein, keine Reaktion. Außerdem habe ich den Raspberry sowieso nie permanent am Netz. Von wegen Erpressersoftware und so. Netzwerkkabellänge beträgt 1,50 m. Das müsste eigentlich reichen. Ich habe es auch mit anderen Kabeln versucht. Keine Reaktion.

      Übrigens: Ich habe auf einer anderen Speicherkarte Raspbian installiert. Boote ich statt mit OMV mit Raspbian, ist die Verbindung zum Router kein Problem. Auch nach einem Monat Pause. Am Router kann es also eigentlich nicht liegen.
    • NiroStahl wrote:

      Nach dem Einschalten blinkt die Kontrolllampe, auch die beiden Lämpchen am LAN-Anschluss zeigen einige Regung, aber das war's denn auch.
      Hast Du 'ne serielle Konsole und kannst nachgucken, was auf dem Ding passiert?

      NiroStahl wrote:

      Gibt's da einen Trick?
      Wenn Du eh dauernd am neu installieren bist, würde ich erstmal H2testw an die SD-Karte ranlassen. Das ist eh immer das erste, was man mit Flash-Medien wie USB-Sticks oder SD-Karten macht.

      Wenn Dir das zu viel Arbeit ist, kann man Dir zwar eh fast schon nicht mehr helfen aber dann wäre es empfehlenswert, wenn Du das nächste mal vorm Runterfahren vorher mal die Logs von der Kiste ziehst.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • NiroStahl wrote:

      Außerdem habe ich den Raspberry sowieso nie permanent am Netz. Von wegen Erpressersoftware und so.
      Ahm .. Ok eine gesunde Portion Vorsicht ist nicht verkehrt aber das ist ein Wenig zu Viel des guten :)


      Ist natürlich Doof wenn du zB. eine feste IP vergeben hast an der Raspi... der aber wiederum Eine zeit lang nicht am Netz ist und in der Zwischenzeit ein anderes Gerät sich die IP geschnappt hat. (das soll Zwar der Router vermeind Können ... Aber es gibt auch noch Speedports und co. und denen traue ich das zu das sie es nicht es Können)

      Anderseits würde ich erst zu eine Raspbian oder auch Armbian Installieren und OMV Drüberbügeln (hat bis jetzt immer gut funktioniert)
    • The Master wrote:

      Anderseits würde ich erst zu eine Raspbian oder auch Armbian Installieren und OMV Drüberbügeln (hat bis jetzt immer gut funktioniert)
      Das würde ich niemals tun. Immer schön direkt die offiziellen ARM OMV images nehmen (basierend auf Armbian aber haben einige zusätzliche Performance-Verbesserungen unter der Haube) und für Rasperries würde ich persönlich natürlich das neueste Image, das nicht mehr auf Raspbian sondern zu 99% auf Armbian besteht, nehmen: New approach for Raspberry Pi OMV images (aus genau dem selben Grund: weil performanter)

      Zum Problem an sich: Es ist völlig albern, auf SD-Karten zu vertrauen. Die Dinger sind teils fake, teils schon beim Kauf hinüber oder gehen mit der Zeit kaputt. Die Symptome, die @NiroStahl schildert, passen ziemlich exakt zu 'SD-Karte Schrott'. Frische Installation auf Karte funktioniert, der Installer erweitert beim ersten Booten die Partitionen und alles funktioniert erstmal. Nach Runterfahren und erneut Tage/Wochen später wieder hochfahren, holt sich OMV dann noch per DHCP Request wieder eine DHCP Lease und fliegt dann auf die Fresse wegen Dateisystem kaputt, Rettungskonsole und Pipapo (wirklich was dazu sagen kann man nur mit 'ner seriellen Konsole. Aber solange man nicht die SD-Karten gecheckt hat, ist das alles eh nur totale Zeitverschwendung).
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Ich habe den Router so eingestellt, dass der die IP-Adresse über Wochen hält. Der Raspberry hat z.B. 192.xxx.x.101, und die hat der praktisch, seit ich den Raspberry besitze. Da hat sich also kein anderes Gerät die IP-Adresse "geschnappt". Bei meinen Tabletts mit Android, da sieht das zuweilen schon mal anders aus.

      Was ist mit "Drüberbügeln" gemeint? Ich kenne OMV eigentlich nur als Stand-alone-Software. Wenn ich OMV installiere, ist der Rest auf der SD-Karte jedenfalls futsch.
    • tkaiser wrote:

      The Master wrote:

      Anderseits würde ich erst zu eine Raspbian oder auch Armbian Installieren und OMV Drüberbügeln (hat bis jetzt immer gut funktioniert)
      Das würde ich niemals tun. Immer schön direkt die offiziellen ARM OMV images nehmen (basierend auf Armbian aber haben einige zusätzliche Performance-Verbesserungen unter der Haube) und für Rasperries würde ich persönlich natürlich das neueste Image, das nicht mehr auf Raspbian sondern zu 99% auf Armbian besteht, nehmen: New approach for Raspberry Pi OMV images (aus genau dem selben Grund: weil performanter)
      Zum Problem an sich: Es ist völlig albern, auf SD-Karten zu vertrauen. Die Dinger sind teils fake, teils schon beim Kauf hinüber oder gehen mit der Zeit kaputt. Die Symptome, die @NiroStahl schildert, passen ziemlich exakt zu 'SD-Karte Schrott'. Frische Installation auf Karte funktioniert, der Installer erweitert beim ersten Booten die Partitionen und alles funktioniert erstmal. Nach Runterfahren und erneut Tage/Wochen später wieder hochfahren, holt sich OMV dann noch per DHCP Request wieder eine DHCP Lease und fliegt dann auf die Fresse wegen Dateisystem kaputt, Rettungskonsole und Pipapo (wirklich was dazu sagen kann man nur mit 'ner seriellen Konsole. Aber solange man nicht die SD-Karten gecheckt hat, ist das alles eh nur totale Zeitverschwendung).

      tkaiser wrote:

      der Installer erweitert beim ersten Booten die Partitionen und alles funktioniert erstmal.
      Beim ersten Booten "erweitert" der Installer zumindest bei mir erst mal gar nichts. Im Gegenteil, der Arbeitsbereich auf der Karte ist mehr als dürftig. Ich habe sogar mal mit einigem Erfolg die Partitionen verändert (vergrößert/verkleinert), aber irgendwann hatte ich erneut denselben Effekt.
    • Ich möchte jetzt hier kein Feuer entfachen und und es darf jeder seine Meinung frei äußern.

      Aber trotzdem, möchte ich festhalten dass auch wenn es eine sehr gute Lösung Bietet, ist Armbian (zumiendest für mich) nicht das maß aller Dinge.

      Auch das Thema Defekte oder Gefakete SD Karten kann ich nicht nachvollziehen (außer evtl. man kauft die Karten auf dem Basar)
      Ich benütze SanDisc Karten 8-32GB die ich schon etliche mal Überschrieben habe ... Zuletzt auch mit dem F3 Toll Getestet und Alles OK
      Das bedeutet nicht das es ausschließt das auch mal welche Kaputt gehen oder defekt sind .. nur nicht in dem Ausmaß wie es dargestellt wird.
    • The Master wrote:

      Armbian (zumiendest für mich) nicht das maß aller Dinge.
      Ach? Für mich auch nicht. Armbian ist für mich einfach der Versuch, nicht jeden Tag das Rad neu zu erfinden. All die Erfahrungen, Erkenntnisse und Verbesserungen, die hier und da gesammelt werden, nicht wegzuschmeißen sondern in ein Build-System zu integrieren. Das voll automatisch OS-Images ausspuckt (die ganzen neuen OMV-Images für ARM-Boards muß man deshalb auch nicht jedes mal einzeln akribisch durchtesten, weil sie vollautomatisch/geskripted erstellt werden).

      Und so war's halt auch mit den OMV-Optimierungen. Die stecken halt drin, wenn man ein fertiges OMV-Image nimmt, und nicht, wenn man selber rumfrickelt. Kann man simpel testen. Aber egal.

      Dito mit SD-Karten. Soll doch jeder sinnlos Zeit verschwenden, womit er mag. Es ist einfach nur dumm, SD-Karten nicht immer sofort zu testen und nicht ausschließlich mit Etcher zu beschreiben (das einen Verify!!! durchführt). 90% aller SBC-Probleme haben mit SD-Karten-Geschissel oder Stromversorgungsproblemen zu tun. Kann man gerne ignorieren, was übrigens auch das ist, was ich ab jetzt machen werde: Ignoranten ignorieren -- weil's zu sehr nervt :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Sorry .. Ich wurde erst jetzt aufmerksam ..


      NiroStahl wrote:

      Was ist mit "Drüberbügeln" gemeint? Ich kenne OMV eigentlich nur als Stand-alone-Software
      Damit meinte ich .. Ein Betriebssystem auf Debian Basis ... und OMV nachträglich Installieren.
      (habe gerade die Info erhalten das es bei der Raspberry nicht möglich sei)
      bin davon ausgegangen das es genau so easy ist wie bei der Banana PI ) bitte diesbezüglich noch weitere Informationen einholen bevor dich ans Werk machst falls Ambitionen ...
    • Ich ziehe mal folgendes Fazit:

      Auch an der Karte kann es nicht liegen. Habe drei Karten (von 8 - 32 GByte Speichergröße) ausprobiert. Ergebnis: immer dasselbe. Mit Raspbian oder Debian+Pixel keine Probleme.

      OMV selbst habe ich stets mit dd direkt auf die Karte aufgespielt. Ohne irgendwelche Windows-Programme. Immer direkt auf Linux-Ebene. Auch deshalb, weil es einfach so am bequemsten ist.

      Ich sehe keinen einzigen Lösungsansatz. Das soll kein Vorwurf sein, eher die traurige Erkenntnis, dass das Problem offenbar niemandem von euch geläufig ist. Glückwunsch. Ich jedenfalls sehe inzwischen keinen Sinn mehr darin, OMV weiterhin zu verwenden. Jede Woche eine neue Installation des OS. So sad!
    • NiroStahl wrote:

      OMV selbst habe ich stets mit dd direkt auf die Karte aufgespielt. Ohne irgendwelche Windows-Programme. Immer direkt auf Linux-Ebene. Auch deshalb, weil es einfach so am bequemsten ist.
      Klar, bequem. Nur eben nicht zuverlässig. dd meldet viele Fehler nicht und in den meisten modernen Linux-Distros braucht's auch noch 'nen sync hinterher, weil der inzwischen auch auf Block-Device-Ebene wirkt. Egal, wer sich nicht dazu bequemt, auf Etcher zu setzen, manövriert sich in eine unsupportbare Situation, weil nicht sichergestellt ist, dass das, was auf Karte soll, auch das ist, was dort ankommt (das ist der Punkt: Etcher macht 'nen Verify!!!).

      Und serielle Konsole willst/hast Du nicht, also wie soll irgendwer hier 'ne Aussage dazu treffen können, was eigentlich geschieht?

      NiroStahl wrote:

      Ich sehe keinen einzigen Lösungsansatz.
      Mei, wenn's mit Raspbian klappt und Du mehrere Karten durchprobiert hast, ist evtl. was beim Download schiefgegangen (ja, klingt doof, passiert aber extrem oft. Ich hab mit solchen Problemchen laufend zu tun, hab also 'ne statistische Datenbasis, die eine gewisse Relevanz hat). Aus mir unerfindlichen Gründen bieten die OMV-Admins keine Hashes auf ihrer Download-Seite. Warum auch immer...

      Jedenfalls wenn Du Dich an die folgende Liste halten würdest, dann wird es auch klappen:
      • Download von OMV_3_0_79_RaspberryPi_2_3_4.9.35.7z
      • Prüfsumme per md5sum bilden (muß a10085da373a90c586c78842df088313 sein)
      • SD-Karte mittels F3 testen
      • Dann mit Etcher (GUI oder CLI Version, siehe unten) auf Karte bügeln
      • Dann booten, warten, werkeln
      • Sofort rebooten und testen (denn wenn ich Dich richtig verstehe ist das Symptom bei Dir, dass OMV einmal bootet aber danach nie wieder?)


      PS: Etcher CLI siehe hier und Etcher auf Debian/Ubuntu geht so

      Source Code

      1. sudo echo "deb https://dl.bintray.com/resin-io/debian stable etcher" | sudo tee /etc/apt/sources.list.d/etcher.list
      2. sudo apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 379CE192D401AB61
      3. sudo apt update
      4. sudo apt install etcher-electron
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • Danke für die Nachricht und den Tipp. Ich versuch's jetzt mal mit der Version 3_0_79. Was mir auffällt:
      1.) Version 3_0_79 unterscheidet sich von der ursprünglichen Version durch ein wesentlich größeres Schriftbild.
      2.) Die Dateien für das Upgrade sind bereits vorgemerkt.
      3.) Und ich bin da, glaube ich, dem Problem auf die Spur gekommen. Ich werde den Verdacht nicht los, dass OMV zwischendurch die Uhrzeit "vergisst". Jedenfalls ist mir bei der Kontrolle der Uhrzeit zweimal aufgefallen, dass OMV die völlig falsche Zeit - zuweilen auch das gestrige Datum - vermerkt hat. Ob das mit meinem ursprünglichen Problem zu tun hat, wird man sehen.

      Ich werde Version 3_0_79 jetzt erst mal laufen und mich überraschen lassen.
    • NiroStahl wrote:

      Version 3_0_79 unterscheidet sich von der ursprünglichen Version durch ein wesentlich größeres Schriftbild.
      Siehe dafür und andere Infos zu dem neuen Release, das inzwischen das offizielle ist, hier bitte: New approach for Raspberry Pi OMV images

      Generell wäre es geschickt, vor dem Runterfahren wenigstens einmal in 'nem Terminal 'sudo armbianmonitor -u' auszuführen und die Support-URL zu notieren. Sollten dann wieder Probleme auftreten oder das Image nicht mehr booten, dann her mit der Support-URL :)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • NiroStahl wrote:

      3.) Und ich bin da, glaube ich, dem Problem auf die Spur gekommen. Ich werde den Verdacht nicht los, dass OMV zwischendurch die Uhrzeit "vergisst". Jedenfalls ist mir bei der Kontrolle der Uhrzeit zweimal aufgefallen, dass OMV die völlig falsche Zeit - zuweilen auch das gestrige Datum - vermerkt hat. Ob das mit meinem ursprünglichen Problem zu tun hat, wird man sehen.

      NiroStahl wrote:

      Außerdem habe ich den Raspberry sowieso nie permanent am Netz. Von wegen Erpressersoftware und so.
      Ahm ... ja wenn Stromlos ist .. ist natürlich die Zeit auch Futsch außer du bastelst dir irgendwie ein RTC modul zusammen
      Es gibt noch den berühmt berüchtigten Fake HWClock ich habe damit keine (gute) Erfahrungen ... wenn die zeit über NTP aktualisiert werden soll ... wird es auch geschehen (früher oder später)