Angepinnt DM900UHD root write protect, Filesystem read only gemountet

    • kati910 schrieb:

      Der vixie-cron wird morgen über systemd gestartet war noch auf init script der sollte dann gehen.
      Danke für die Umstellung auf systemd! Jetzt klappt auch der @reboot string:

      Quellcode

      1. root@dm900:~# crontab -l|grep reboot
      2. @reboot /bin/touch /tmp/crontest.systemd.ok
      3. root@dm900:~# reboot
      4. root@dm900:~# ls /tmp/crontest.systemd.ok
      5. /tmp/crontest.systemd.ok
      6. root@dm900:~#
      @m0rphU
      das habe ich auch schon angesehen, läuft aber noch nicht so ich will
      wenn der @reboot über cron funktioniert, ist das ein wenig anwenderfreudlicher, aber danke für Tipp
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$
    • Hilfsbereit schrieb:

      systemctl stop engima2
      Systemctl stop engima2 wird nicht angenommen. Fstab lässt sich rauskopieren und ändern. Aber nach Neustart wieder alles wieder platt und Greenscreen. Würde nur ungern das zweite Gerät auch zurückschicken.
      "Chuck Norris haut sich morgens zum Frühstück zwei Pfannen in die Eier"

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

    • Ok es funktioniert. Man darf aber nicht den Fehler machen und die Festplatte erneut initialisieren oder eine weitere Platte mounten. Die Kiste macht sofort wieder read only.
      "Chuck Norris haut sich morgens zum Frühstück zwei Pfannen in die Eier"
    • Das war eigentlich auch nur als workaround gedacht

      Fred Bogus Trumper schrieb:

      Ist zwar nur eine Notlösung, weil beim boot das rootfs erstmal ro gemountet wird ...
      ... Aber ich schätze, dass das sowieso bald gefixt wird.
      Ich dachte, dass wurde längst reported.

      Auf meiner Box trat es genau einmal auf, danach nicht mehr. Und ich lasse das script sogar auf die sd loggen, damit man es zeitlich eingrenzen kann, wann das fs ro geht bzw. in der fstab der rootfs mount verschwindet.
      Gruß Fred

      Die Dreambox ist tot, es lebe die Dreambox

      ¯\_(ツ)_/¯

      Quellcode

      1. root@dm920:~$ mount | grep "/ "
      2. /dev/mmcblk1p1 on / type ext4 (rw,relatime,data=ordered)
      3. root@dm920:~$
    • Nein, soweit ich weis gibt es dazu noch keinen expliziten Thread im DMM board

      Im Prinzip muss man nur in der Harddisk.py wo das /etc/fstab gesichert wird vorher ein print reinmachen, dann siehst du schnell wann es was kaputt macht.

      Und mit einem simlplen find und join wäre das mit 2 zeilen an der Stelle gefixed, so das bei jedem Abspeichern der /etc/fstab auf einen vorhandenen Zeile für das mounten von / gechecked wird und bei Bedarf dieses halt wieder dazu gemacht wird.
    • Nein die Harddik.py verschluckt sich da immer noch ab und an - sehr beliebt sind die aufofs vs. Netzwerkbowser Basteleien die den Usern so eingeredet werden, weil dabei gestrandete Einträge in der fstab entstehen können.

      Die Meldung war nur eine Zeitlang beliebter weil bei einem Softwareupdate die fstab angepasst wurde (wo die Leute nicht wussten wie man im SW Manager ja nein mit der FB eingibt) um das /var/volatile anzupassen und damals ist es den Leuten halt reihenweise passiert ...

      Ich weis ja wie ich mir helfen kann (der Post mit dem remount Befehl um es überhaupt fixen zu können stammt ja von mir) , insofern habe ich wenig Lust das zu debuggen, schon weil es mir auch nur 1x passiert ist.

      Wie gesagt, das wären nur 2 Zeilen im python um einen check und ggf. einen fix zu machen damit die fstab nie kaputt gesaved werden kann.

      Ist zwar auch nicht optimal, weil es ein Codefehler sein müsste in der Harddisk.py der gefixed werden sollte, aber noch besser als shellscripte und crontabs ;)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Lost in Space ()

    • Ähm es hält Euch wenn Ihr bewiesen habt das es dann mit dem Spuk vorbei ist keiner davon ab beim DMM vorstellig zu werden und zu bitten die 2 Zeilen einzuchecken oder den bug zu fixen :)

      Womit wir wieder dabei sind das ich nicht glaube das DMM von dem Problem überhaupt weis.

      Ich mag das nicht auch noch machen ....

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Lost in Space ()

    • im nn image ist autofs vorinstalliert, im dmm original nicht.
      leider kann man autofs im nn auch nicht einfach deinstallieren, es hängen einige nn menus als abhänigkeit dran.
      autofs krallt sich dann vor dem speichergeräte-manager die hdd, die dann unter /autofs/sdx zu finden ist.
      das besagte fehlerbild ist dann die folge beim benutzen des speichergeräte-manager für meine ssd.
      beim usb stick gab es komischerweise keine probleme und wurde per autofs und parallel zum speichergeräte-manager gemounted.

      ich habe jetzt einfach hotplug in /etc/auto.master.d/enigma2.autofs deaktiviert.
      #/autofs /etc/auto.hotplug

      dann tut der speichergeräte-managerauch wie er soll.

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

    • moin moin,
      kam unter der Woche nicht dazu...deinen Befehlt gerade im telnet geschrieben, neu gestartet greenscrene,,
      sollte ich noch was anderes machen?

      edit:
      rw ist jetzt geblieben und Mediaportal wurde auch aktualisiert; nach dem letzten Neustart hat er trotzdem greens angezeigt. kommisch.
      Dateien

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