3.2.1 Images bleiben bei Shutdown und Restart hängen

  • Hi !


    Eine der 'positiven' Auswirkungen des neuen Devicemanagers für das Einhängen der Festplatten ist jetzt dass bei einer Menge Boxen wenn man im enigma2 das Restart oder Herunterfahren auswählt enigma2 zwar sauber gestopped wird aber dann die box nichts mehr macht, weil sowohl das reboot also auch das halt im enigma2.sh script nicht den gewünschten Effekt haben.


    Man kann sich weiterhin mit telnet in die box einwählen und z.B. shutdown -r now eingeben und freudvoll feststellen das zwar der prompt verschwindet die box aber trotzdem nicht rebootet.


    Also workaround kann man im enigma2.sh sowohl das reboot als auch das halt mit -f -n als Option ergänzen, aber wenn man weiss das dadurch einfach die gemounteten devices nicht sauber ungemountet wird hätte ich das lieber ordentlich gefixed.


    Weil wenn ich in einem Release image die box sonst nur mehr mit dem Stromschalter stoppen kann ist das nicht so optimal - für die Box und die Festplatte.


    LG
    gutemine

  • Dann probier bitte aus ob es auch bei dir hilft die enigma2.sh mit dem reboot -n -f und halt -n -f zu patchen.


    Ist zwar kein echter workaround, aber besser als nichts.

  • Hallo,


    bei welchen Boxen soll das sein und wie kann man das reproduzieren.?


    Ich habe hier 2x DMM8000 - 2x DM500HD - 1x DM800PVR und Expeimental 3.2.1.


    Keine Probleme Hier.?

    DM900UHD SS - DM 500HD S - Diverses.

  • könnten bestimmte Boxen Rev. betroffen sein, warum keine Ahnung ...


    Ich selber habe die 1. dm8000 revision, und kann nach Neuaufsetzen des Images, bei Box Neustart kein Problem feststellen .

    DM8000 HD, (sata) HDD + (sata) SSD - DeLOCK + (usb) Stick, OoZooN OE2.0 (flash)
    QNAP TS-209 Pro, TS-409U, TS-219P
    40'' LCD Toshiba 40ZF355D
    AV : Logitech Z-5500 Digital

    Einmal editiert, zuletzt von SiennaRoot ()

  • Ich kann auch nur sagen das es besonders gerne auf 8000ern auftritt (weil die eben auch so viele devices hat die ungemountet gehören), und ja meine Box ist auch nicht betroffen, aber ich habe eine neue 8000 im Bekanntenkreis die das Problem seit dem Upgrade hat, also konnte ich das auch austesten, und wie gesagt sobald man die enigma2.sh entsprechend anpassed nicht auf das unmounten von devices beim runterfahren zu warten dann funktioniert es wieder wie vorher.


    Ihr könnt gerne wenn Ihr betroffen seit 3.2.1 Release Image flashen und die box an DMM schicken - wenn Sie Probleme haben das zu reproduzieren :smiling_face:


    Und ja nachdem scheinbar keine Rev 1 Boxen betroffen sind könnte es am DVD Laufwerk liegen das dort ja nicht direkt am SATA sondern am USB hängt, aber nachdem auch schon 800se Besitzer dieses neue 'Feature' berichtet haben glaube ich nicht das es daran liegt.


    LG


    gutemine

  • Ja gleiches Fehlerbild: das OLED ist nach dem shutdown über die GUI aus, aber die Box per Telnet noch erreichbar. Mit init 3 kann ich enigma wieder starten.
    Auch das "halt -f -n" in /sbin/enigma2.sh ändert leider daran leider bei meiner dm8000 nichts.
    Ein "halt" auf Kommandozeile schaltet sie aber aus...(?) - wie kann das sein?


    Box ist aus 2011, WD-Festplatte, Lüfter, Kein DVD...

    dm8000 (2xDVB-S2, DVB-C, DVB-T, 2 TB HDD, 4pin Fan) mit DMM - OE2.0+GP3.2

    Einmal editiert, zuletzt von tomde ()

  • Hab auch gleiches Fehlerbild:


    Wenn ich ausschalte, wird das Oled display dunkel, die box schaltet aber nicht komplett aus und läßt sich auch nicht über die Fernbedienung wieder einschalten.
    Nur ein aus und einschalten am hinteren Knopf bringt einen Neustart.


    Hab das hier auch schon im 3.2. thread geposted.


    Ghost hat geschrieben, dies hänge wahrscheinlich mit einem pluin zusammen.


    DM 8000 Release 3.2.1

  • da kommt eigentlich gar nichts, enigma2 stopped und linux läuft weiter wie wenn nichts passiert wäre, weil es scheinbar noch auf umounts wartet. Erst wenn man reboot -f -n eingibt gehts abwärts. Wie wenn nur ein init 4 passieren würde um enigma2 zu stoppen


    Macht man dann nur shutdown -h now (was dem normalen halt entspricht ohne die bösen parameter) kommt die systemmeldung das er runterfährt, was er aber dann nicht tut und das war es dann bis man den Netzschalter betätigt.


    Ich würde auf einen Fehler in den K* scripts tippen bei umounten, womit der init nicht weitekommt und hängenbleibt.


    LG


    gutemine

    2 Mal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Hi,


    da gabs aber überhaupt keine Änderung. Und nach wie vor finde ich das sehr eigenartig, dass das bei uns niemand nachvollziehen kann.


    Es ist dem umount -a auch total egal wer die hdd gemountet hat. Und wie. Das tut immer dasselbe.


    Ob nun e2 die hdd gemountet hat oder jemand anders .. das ist doch egal.


    Und wenn man e2 beendet, dann führ das enigma2.sh auch nur ein "halt" aus.


    Das ist alles sehr unlogisch.


    cya

  • Einen wunderschönen


    Meines Wissens wirkt ein umount -a nur auf Sachen, die in der fstab stehen - analog zu swapoff -a - das geht auch nur, wenn das Swap in der fstab steht
    Mounten und Answapen genauso - nur Einträge, die in der fstab stehen


    Andere Devices müssen direkt angesprochen werden - z.B. umount /media/hdd - swapoff /media/cf/swapfile

  • Hallo,


    ich habe zwar 0-Ahnung von mount/umount, aber schreibe trotzdem :D.


    Was passiert wenn ein umount nicht möglich ist, weil dann die Meldung kommt "device is busy". Zumindest konnte ich irgendwann mal (lange her) meine hdd nicht per Telnet umount-en. Kann sowas passieren?


    Jörg

  • Es muß sichergestellt sein, daß keine Schreib-, Lesezugriffe mehr stattfinden
    Das kann vom System selber sein - auch Swap - oder über Netzwerk (Samba, NFS oder sowas). Erst wenn sichergestellt ist, daß das der Fall ist, kann ein Laufwerk gelöst werden und dann das System sauber heruntergefahren werden.
    Ein Force jeglicher Art ist zu vermeiden, weil das Dateisystem sonst schaden nehmen kann - bis hin zum Totalverlust aller Daten.

    • Offizieller Beitrag

    Hi,


    also bei uns schaut das umount (in der busybox) nach /etc/mtab ... und /etc/mtab ist ein link auf /proc/mounts.


    Und in /proc/mounts steht alles drinn was gemountet wurde.


    Nunja.. egal.. daran wird es nicht liegen. Denn es soll ja sogar beim reinen e2 neustart hängen. Also nur GUI neustart. Dann kann es mit dem mounten beim besten willen nichts zu tun haben.


    cya

  • Ich kann mich ja auch irren, aber nachdem die -n und -f Flags nur das init und das umount umgehen muss es wohl aus dieser Ecke komme.


    Und das mit dem /proc/mounts ist zwar richtig aber es kann sein das ihn die uuid links statt den /dev/sd* verwirren.


    Alternativ könnten man noch auf den automount daemon tippen das der im /autofs nicht aufhören will, oder ähnliches.


    Aber das Einfachste wäre wohl wenn einer der betroffenen Ghost ssh Zugang auf die Box geben würde - nachdem das Netzwerk eh schön laufen bleibt ist es eigentlich kein Problem sich den seltsamen Zustand remote anzusehen.


    LG
    gutemine


    PS: Ich habe das übrigens auch zuerst nicht geglaubt bis ich auf einer betroffenen Box in meinem Bekanntenkreis mit telnet drinnen war und gesehen habe das die box NACH dem enigma2 shutdown mit gestopptem enigma2 weiterläuft und bei shutdown -r now hängenbleibt und man Netzschalter braucht und die box nur bei reboot -f -n wieder rebootet.

  • Ergänzend zur Info oben:


    1. Reboot über die FB oder über das WebIf stoppt e2 (OLED aus, man denkt die Kiste ist aus, wenn nicht der Lüfter noch rauschen würde...)
    2. Deepstandby über die FB oder das WebIf stoppt e2 (OLED aus, man denkt die Kiste ist aus, wenn nicht der Lüfter noch rauschen würde...)


    3. Die Befehle "reboot" und "halt" über ssh/telnet funktionieren (auch ohne Parameter) ohne wie gewünscht.


    Vielleicht hilfts ja...:


    Mit einem nfi-Backup vom Oktober dank dflash tut die Kiste endlich wieder was ihr befohlen.

    dm8000 (2xDVB-S2, DVB-C, DVB-T, 2 TB HDD, 4pin Fan) mit DMM - OE2.0+GP3.2

    2 Mal editiert, zuletzt von tomde ()