Bootprobleme bei Auslagerung von /usr auf ext3 oder ext4 formatierten usb-stick

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Bootprobleme bei Auslagerung von /usr auf ext3 oder ext4 formatierten usb-stick

      Hi,

      seitdem ich die installierte Software am Wochenende aktualisiert hatte, habe ich nun Probleme beim Booten, falls das /usr Verzeichnis auf einem ext3 oder ext4 formatierten USB Stick ausgelagert ist. D.h. genauer, die GIgablue SE freezt fast immer (Gigablue steht auf dem Display) beim Booten. Wenn ich den USB-Stick jedoch vorher abstecke, bootet er einwandfrei. Danach kann ich auch wieder den USB-Stick anstecken und gegebenenfalls Enigma2 neustarten, um das usr Verzeichnis des USB-Sticks zu verwenden.
      Das usr Verzeichnis habe ich übrigens mit dem Flashexpander ausgelagert, aber auch manuelles Auslagern, mounten und Anpassen der fstab hat dieselben Probleme beim Booten zur Folge. Mit der Build 103 ging das alles noch ohne Probleme. Aktuell hatte ich die Build 129 geflasht. Für die Verwendung des Receivers ist das zwar nicht wesentlich, da kaum zusätzliche Plugins verwendet werden, aber dennoch würde ich das Problem gerne lösen.
      Leider weiß ich nicht so recht, wo hier das Problem liegen könnte. Ich hoffe daher auf weitere Hilfe.

      Vielen Dank schon einmal Vorab für euere Hilfe und viele Grüße
    • Könnte meines Erachtens auch mit der Reihenfolge zusammenhängen, in der die Systemkomponenten gestartet werden. Die Image-Bauer mögen wissen, ob sich da was geändert hat. Wenn früh im Startprozess auf Komponenten auf /usr zugegriffen wir, das aber noch nicht richtig eingehängt ist ... Ähnliche Phänomene kann man sogar erleben, wenn sich an der Reihenfolge nichts ändert, sondern nur am Timing (weil vielleicht ein Modul jetzt schneller geladen ist als zuvor oder ein anderes langsamer). Früher sah man mal in Systemen (nicht offensichtlich verständliche) Synchronisationspunkte, wo gewartet wurde, bevor weitergemacht wird, um das zu vermeiden. Solche Punkte wurden leicht mal "wegoptimiert" ...
      Hast du das gesamte /usr-Verzeichnis auf den Stick verlinkt? Wundert mich, dass das funktioniert. Wird vor dem Mounten des USB-Sticks was gestartet, das eine Shared-lib aus /usr/lib benötigt, muss das schiefgehen. Auf meinem System ist das beispielsweise für den mount-Prozess (eigentlich busybox) der Fall -> d.h. Mounten des USB-Sticks mit mount-Kommando (über fstab) würde unmöglich. [Korrektur: Wenn ich das jetzt richtig sehe, sind alle von busybox genutzten shared libraries direkt in /lib, nicht in /usr/lib. Und nun erinnere ich mich auch daran, dass das kein Zufall ist. Klassisch kann in Unix-Systemen /usr spät eingehängt werden können, und früh benötigte Module müssen in /lib, /bin etc. sein. Das grundsätzlich Argument könnte dennoch helfen, das einzugrenzen.]

      (Wie der Flashexpander genau funktioniert, weiß ich nicht. Daher ist vielleicht die Argumentation nicht relevant.)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von buers ()

    • Vielen Dank euch schon mal für die Antworten.

      Es hängen sonst keine weiteren Festplatten oder USB-Sticks an der Box. Ich hatte nur einen Gigablue WLAN-USB-Stick dran hängen, aber das Problem trat vorher auch mit LAN Kabel auf. Ich verwalte mehrere Gigablue Receiver und bei allen anderen UE und UE+ Modellen funktioniert das Auslagern von /usr auf USB tadellos. Muss allerdings hinzufügen, dass die anderen Boxen nicht ganz uptodate sind, d.h. dasselbe Problem könnte dann prinzipiell auch bei den anderen eintreten. Auf meiner eigenen UE+ habe ich deutlich mehr Plugins installiert, so dass das Auslagern auf USB-Stick natürlich unumgänglich ist. Ich könnte die Box mal updaten und schauen was passiert, allerdings würde ich mich sehr ärgern, wenn das Problem auch dort auftreten sollte.

      Der Flashexpander kopiert im wesentlichen das usr Verezichnis auf die entsprechende Partition des USB-Sticks und ändert die fstab insofern, dass diese Partition in Abhängigkeit von ihrer UUID auf /usr gemountet wird. Falls kein USB-Stick dran hängt, sollte der Receiver trotzdem funktionieren, d.h. das usr Verzeichnis im Flash sollte dann trotzdem verwendet werden. Deswegen spiele ich nicht so gern mit symlinks rum (abgesehen davon, dass das wohl auch dieselben Probleme zeigen würde) Alternativ könnte ich natürlich statt des ganzen Verzeichnisses nur die lib und share Verzeichnisse aus /usr/... auslagern. Ich schätze aber, dass das Problem bestehen bleibt. Es ist komisch, dass das automatische mounten beim Systemstart manchmal (eher sehr selten) doch funktioniert. Natürlich könnte ich den Stick beim jedem Start vorher abziehen und dann wieder einstecken, sobald der Bootvorgang abgeschlossen ist. Ihr könnt euch aber sicherlich denken, dass das ziemlich nervig wäre.

      Nur nebenbei: interessanterweise musste ich zum Mounten der ext3 Partition noch kernel-module-ext3 nachinstallieren. Sonst kam immer der Fehler "NTFS signature is missing". Auf dem älteren image ging das ohne Probleme. Deswegen ist die Box vermutlich auch beim Versuch den Stick auf ext3 zu formatieren ständig eingefroren.
    • Die ext3 Module nachinstallieren ansonsten bekommst du einen NTFS Fehler? Schon komisch.
      Meine Bastelboxen: Mut@nt HD51 | GB Quad 4K | Mut@nt HD60 | OSMIO4K | HIS 4k Combo+

      ... Keinen Support per PN ... bitte stellt eure Fragen ins Forum!...

      ~ Benutzung OpenHDF Image ~ Benutzung der HDF-Toolbox ~ FAQ und Linksammlung ~ Build und Foren Server Spendenaktion ~
    • Ich fand es auch sehr komisch. Habe das auch mit einem anderen USB-Stick versucht und hatte dasselbe Problem. Es spielte auch keine Rolle, ob auf dem Stick noch andere Partitionen drauf waren, oder nicht. Der verwendete Port, d.h. ob hinten oder vorne, machte auch keinen Unterschied: Beim Booten bleibt das Bild in der Regel blau, auf dem Display bleibt Gigablue stehen und es tut sich nichts weiter, so dass ich das Stromkabel abziehen muss. Ich werde die Tage noch eine andere SE flashen. Mal sehen, ob ich da auf dasselbe Problem stoße, oder ob es da dann einfach und hoffentlich wie gewohnt läuft. Denn auf dieser SE würde ich gerne weitere Plugins installieren, für die der interne Speicher nicht ausreichen würde.
    • Eine pragmatische Lösung könnte sein, nur /usr/lib/enigma2/python/Plugins/Extensions auf den USB-Stick zu linken. Ich habe nur wenige Plugins, dennoch ist hier der weitaus größte Teil von /usr vergraben. Das Verzeichnis wir erst ganz spät während des Startens verwendet, nämlich wenn enigma2 gestartet wird. Wenn das auch nicht klappt, noch eine Idee unten, sonst keine Ahnung. Wenn das klappt, kann man noch versuchen, deine Beobachtungen einzugrenzen. (Weil ja eigentlich frühe Prozesse nicht auf /usr zugreifen sollten.

      Wenn du nur das Extensions-Verzeichnis auslagers, und das immer noch nicht geht: bei mir sieht /etc/init.d/rcS so aus - anzunehmen, dass das bei anderen images ähnlich ist:

      Quellcode

      1. ...
      2. #init rc.local
      3. /var/config/rc.local
      4. until false
      5. do
      6. python /usr/lib/enigma2/python/Plugins/Extensions/PKT/progress 60 MINI &
      7. echo "starting e2->"
      8. ...


      Vor der python Zeile kannst du noch

      /bin/sleep 10

      probieren.

      Wenn du das rcS Skript verstehst, kannst du auch versuchen früher ein Pause einzufügen. Bei mir beispielsweise wird schon früh auf /usr/sbin zugegriffen. Zugriffe auf /usr/lib sind nicht ganz einfach zu erkennen.
    • Ich habe mittlerweile auch die zweite SE Box neu geflasht und habe mit dieser ähnliche Probleme. Das Auslagern von /usr/lib/enigma2/python/Plugins/Extensions brachte leider auch keine nennenswerten Erfolge, auch wenn es mir so vorkam, dass der Receiver häufiger erfolgreich gebootet hatte. Mit den Startskripten kenne ich mich leider noch nicht sonderlich gut aus. Die /etc/init.d/rcS sieht auf der SE jedenfalls anders aus:

      Shell-Script

      1. #!/bin/sh
      2. #
      3. # rcS Call all S??* scripts in /etc/rcS.d in
      4. # numerical/alphabetical order.
      5. #
      6. # Version: @(#)/etc/init.d/rcS 2.76 19-Apr-1999 [email protected]
      7. #
      8. PATH=/sbin:/bin:/usr/sbin:/usr/bin
      9. runlevel=S
      10. prevlevel=N
      11. umask 022
      12. export PATH runlevel prevlevel
      13. # Make sure proc is mounted
      14. #
      15. [ -d "/proc/1" ] || mount /proc
      16. #
      17. # Source defaults.
      18. #
      19. . /etc/default/rcS
      20. #
      21. # Trap CTRL-C &c only in this shell so we can interrupt subprocesses.
      22. #
      23. trap ":" INT QUIT TSTP
      24. #
      25. # Call all parts in order.
      26. #
      27. exec /etc/init.d/rc S
      Alles anzeigen


      Eventuell kann ich dem genaueren Problem auf die Schliche kommen, wenn ich einzelne Ordner aus .../Extensions auf den USB-Stick verlinke und dann reboots versuche. Oder vielleicht finde ich etwas in einer log. Zur Not müsste ich mich wohl damit zufriedengeben, nur /usr/share/enigma2 wegen eines recht großen Skins auf USB-Stick auszulagern. Das funktioniert zumindest ohne Probleme. Denn rebooten sollte der Receiver ohne Probleme, da ich den per SSH und Openvpn aus der Ferne verwalte, wenn unter Umständen auch niemand vor Ort ist.

      Ich wünsche euch noch einen schönen Sonntag.

    Unsere Partnerboards

    ^
    Flag Counter