Nicht erreichbare Mounts - Box kommt kaum noch hoch

  • Hallo *,


    Ich hatte gestern per Mount Manager die HDD der DM8000 eingebunden, um eine alte Aufnahme anzuschauen.
    Heute schalte ich die Box ein und sie braucht ewig zum Starten, kommt dann hoch, allerdings mit Dauer-Spinner und daher unbedienbar.


    So wie ich das sehe, hat der Mount Manager einen Eintrag in die fstab für die DM8000 erstellt.
    Dieser war heute nicht erreichbar, weil die DM8000 ausgeschaltet war.


    Per SSH habe ich den Eintrag in der fstab gelöscht und schon ist die Box wieder normal hochgefahren.


    Habe ich was falsch gemacht oder bringt ein nicht-erreichbarer Mount (in der fstab) die Box so zum Straucheln?


    Vielen Dank


    Grüße
    ...jp

    Grüße
    ...jp

  • das ist noch ein Problem im enigma2, ein simples umount auf den share im enigma2 startup script reicht um das Problem erstmal zu umgehen

  • du könnstes in der fstab die zusätzliche mount option bg versuchen, dann wird im Hintergrund versucht zu mounten, d.h. es wird gemountet, sobald die 8k hochkommt - theoretisch ...


    mit der option timeo=SEKUNDEN kannst du auch den timeout festlegen, wann der timeout erfolgen soll, wenn der share nicht erreichbar ist
    funktioniert aber glaube ich nur mit der option soft

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    2 Mal editiert, zuletzt von Fred Bogus Trumper ()

  • das bringt alles nichts (bg, timeout, retry parameter,...) weil das enigma2 ständig drauf zugreift wenn es den mount sieht beim Starten und dann das timeout immer wieder auf Neue losläuft.


    Macht was ich gesagt habe, das reicht das wenn e2 startet der mount kurz nicht da ist, damit wird er nicht zugregriffen und wenn der Server wieder das ist macht das autompunt vom systemd schon was es sollte ...

  • leider ist meine dm900 noch immer nicht eingetroffen, deshalb kann ich es nicht testen


    aber wie es aussieht, werde ich meinen automounter wieder aus der Versenkung holen müssen, den ich für OE1.6 geschrieben habe. Wenn E2 bei den mounts mitmischt, hat das noch nie zufriedenstellend funktioniert ...

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

  • das geht mit jeder box wo das neuen OE2.5 drauf ist. Sobald du den neuen systemd hast funktionieren die timeout, und retry parameter beim mount wie sie sollen, sprich du kannst duch einloggen und df -h wird dann nicht mehr hängenbleiben. Das hilft aber beim e2 eben nichts, das einzige was da problemlos funktioniert ist wenn der mount zu dem Zeitpunkt wo es startet gar nicht da ist - das simple umount -f reicht also damit e2 ohne spinner hochläuft.

  • das umount -f macht aber auch nur dann sinn, wenn der share nicht erreichbar ist - oder?


    also etwa


    if ! ping -c 1 -w 2 SHARE-IP >/dev/null;then umount -f /mount/point;fi


    ich werde das mal ausgiebig testen, wenn die Box morgen (hoffentlich) kommt

    Gruß Fred

    Die Dreambox ist tot, es lebe die Dreambox

    Einmal editiert, zuletzt von Fred Bogus Trumper ()

  • das ist egal, durch das automounten kommt es sobald du drauf zugreifst ja wieder zurück.


    Es geht nur darum das es die paar sekunden wo das e2 /media scanned nicht da ist dann ist ruhe und e2 startet weiter.


    Ist es dann schon im timeout dann wird es eben Zahnradig ... DMM könnte das ganz leicht im e2 code fixen aber nachdem das closed source ist musst du halt selber kreativ werden. Insofern kostet das ping zum checken nur unnötig Zeit.


    Und ich habe das mit OE2.5 zwischen 525 und 7080 rausgefunden, du musst nicht auf 900 warten.

    • Offizieller Beitrag

    Mit dem nächsten Update sollte sich die Situation ein ganzes Stück verbessern.
    Die Box sollte normal booten, selbst wenn Mounts nicht erreichbar sind (völlig ohne jegliche Verzögerung).
    Ich hab die Logik relativ stark vereinfacht und die ganzen Prüfungen beim Starten komplett entfernt (da sich die Verfügbarkeit von Shares jederzeit ändern kann gehen wir einfach immer davon aus dass es erreichbar sein könnten).

  • Ja das ist vom Ansatz gut so weil dann kann jeder selbst mit den timeout und retry parametern bestimmen wie das Verhalten der mounts sein soll. Vor allem bringt das auch wieder bootzeit und sollte auch einen gui restart beschleunigen. Nur sollte halt keiner auf die tolle Idee kommen die epg.db oder picons dann auf sowas abzulegen, weil dann geht die Jammerei erst wieder los :winking_face:

  • Vielen Dank.
    Das wird der Grund sein. Meine Box ging anfangs in 3 Sekunden an und braucht jetzt 1 Minute.
    Mal schaun, obs wieder normal ist.

    • Offizieller Beitrag

    Nein, das müssen sie nicht. Neue "wichtige Optionen" werden beim ersten Start nach dem update automatisch ergänzt und die Hänger haben im Prinzip mit den ergänzten Mountoptionen nicht viel zu tun.
    Obwohl diese grad bei NFS nochmal gut helfen sollten ewig lange Timeouts zu vermeiden.


    Der Fix für die eigentlich Hänger beim Booten ist völlig unabhängig davon.