Lost in Translation

  • dann ist das losetup -d noch falsch :-(


    Kann ja nicht sein das es von Hand mit der /dev/loop/1 geht und dann die plugin.py nicht das selbe zusammen bringt.


    LG
    gutemine

    Edited 3 times, last by gutemine ().

  • nö, leider keine Besserung...


    wie lange hätte das vorhin denn dauern müssen? ging relativ flott im telnet..

  • das mounten geht schnell, weist du ja jetzt. selbst das auspacken des lowfat.lfi.gz containers ist flott. Nur wenn das plugin den nicht mounten kann dann kann nicht gekloned werden :-(


    Na ja muss ich halt nochmals den code durchsehen, aber eigentlich macht der auch nur das gzip, das losetup und dann das mount ...


    LG
    gutemine

    Edited once, last by gutemine ().

  • habs gerade noch mal durchgespiel mit loop/1
    zip ca 2,5 minuten,


    die beiden anderne so 1-2 sec...


    und es ging wieder..


    kann ja mal versuchen das xxx zu booten... aber dann mach ich morgen weiter... zuviele boot sind schlecht fürn WAF


    B

  • übrigends umbenennen und mounten das xxx aus dem Plugin kommt mit gleicher fehlermeldung war aber wohl klar... (-:

  • Quote

    Original von Boardman
    übrigends umbenennen und mounten das xxx aus dem Plugin kommt mit gleicher fehlermeldung war aber wohl klar... (-:


    das xx.lfi ist auch ein leeres ext3 filesystem das kann nicht booten. Das wird eben erst von der plugin.py befüllt - nur der code kommt erst nach dem mounten :-(


    Für Heute reicht das eh, code kontrollierne geht nicht so schnell wie einfach ändern.

    Edited once, last by gutemine ().

  • Aber ich bin jetzt deprimiert und gehe ins Bett.


    Jetzt habe ich extra einen mac checker ins fatty rein gemacht der noch VOR der pivot root die mac ausliest - und wisst Ihr was da ausgegeben wird: 00:00:00...


    Also liegt es gar nicht an der pivot_root :-(

  • Nur um das Problem einzugrenzen - auf der 7025 wenn man mit dem LowFAT device vom Flash bootet ist die Mac adresse noch OK (mit ifconfig im telnet nachsehen) und nicht 00:00:00... ?

  • hier

    Files

    • Unbenannt.png

      (27.62 kB, downloaded 220 times, last: )

    Gruß ##Ray


    -------------------------------------------
    ...schade :scheisse:


    Macht’s gut, und danke für den Fisch

  • Na ja dir Mac adresse stimmt dort, dafür hat das zeroconf dir wieder die 169* adresse spendiert weil ich die config Änderung nur in den LowFAT images mache :-(


    Probier bitte mal aus ob wenn du das FALLBACK=yes ins /etc/default/zeroconf machst DHCP im Flash image wieder ordentlich funktioniert und du richtige IP kriegst.


    Wenn ja, dann mach ich halt erstmals ins Plugin das dies auch im Flash image erfolgt....

    Edited 3 times, last by gutemine ().

  • ...und da ist sie wieder die richtige IP :)

    Files

    • Unbenannt.png

      (25.32 kB, downloaded 202 times, last: )

    Gruß ##Ray


    -------------------------------------------
    ...schade :scheisse:


    Macht’s gut, und danke für den Fisch

  • OK, dann baue ich halt mal das zeroconf für den Flash und einen Manuellen Workaround zum Mac anpassen und die Möglichkeit mit ifconfig nachzusehen ins LowFAT Plugin ein, wobei das eigentlich nicht schön ist, aber sonst kommen wir nicht weiter :-(

    Edited once, last by gutemine ().

  • Na gut, tauscht bitte die plugin.py gegen die aus dem Anhang.


    Da kann man im LowFAT Plugin jetzt auf Gelb mit Check Network das ifconfig ausführen um zu sehen ob man das 00:00:00 ... Mac adressen Probelm hat, und wenn ja dann kann man mit Network fix dieses auch fixen. Dabei wird beim ersten mal die Mac adresse abgefragt (wenn man sie nicht weis im Flashimage ohne LowFAT device mit ifconfig in telnet nachsehen, oder gleich wenn man mit telnet im Bios ist). Die Mac adresse wird dann als mac.ini auf dem LoFAT device abgelegt und in Zukunft verwendet (bis man es evt löscht, dann muss man neu eingeben)


    Bitte testen ob das ordentlich funktioniert.


    Ausserdem wird jetzt in jedem Image (auch im Flash) das zeroconfig fallback enabled, weil mir das zu blöde ist mich damit weiter zu ärgern !


    Ich hoffe damit können wir jetzt endlich ordentlich weitertesten !


    Und ich kann jetzt am Nachmittag wieder an dem doofen losetup Problem auf der 7025 arbeiten ...


    PS: wenn man auf der 7025 mit LowFAT vom Flash gebootet ist - was zeigt denn ein losetup -f
    EIGENTLICH müsste das /dev/loop/1 anzeigen, weil 0 vom unionfs mount verwendt wird, es kann aber sein das es durch das pivot_root verwirrt ist,


    LG
    gutemine

    Edited 6 times, last by gutemine ().

  • GuteMine


    Habe nun entlich den Stick zum laufen bekommen, habe nochmal alles Resetet und Formatiert. Nun gehts :-) auch mit gesteckter CF und SD (/dev/sdc1) rootdelay auf 10.


    Netzwerk geht auch mit der plugin.py


    Was mir fehlt, deine Bankverbindung oder kommt das erst im nächsten RC?

  • Die Spendeninfos kommen erst wenn es released ist in die Logos. Vorher macht das keinen Sinn.


    Und released wird erst wenn auch die 7025 funktioniert :-)

    Edited 2 times, last by gutemine ().

  • Quote

    was zeigt denn ein losetup -f

    Files

    • Unbenannt.png

      (5.08 kB, downloaded 130 times, last: )

    Gruß ##Ray


    -------------------------------------------
    ...schade :scheisse:


    Macht’s gut, und danke für den Fisch

  • und hier der test...


    root@dm7025:~# losetup -f
    /dev/loop0



    zu blöd dasß ich so gar keine Ahnung habe wa sdu da machst...


    B

  • hab noch mal die Tests von gestern mit loop0 versucht - geht aber nicht


    root@dm7025:~# cd /tmp/lowfat
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# gunzip -c lowfat
    lfi.gz > xxx.lfi
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# losetup /dev/loo
    0 xxx.lfi
    losetup: /dev/loop0: No such file or directory
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# losetup /dev/loo
    /0 xxx.lfi
    losetup: /dev/loop/0
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# mount -t ext3 /d
    v/loop/0 lowfat
    mount: mounting /dev/loop/0 on lowfat failed: Device or resource busy
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# mount -t ext3 /d
    v/loop/1 lowfat
    mount: mounting /dev/loop/1 on lowfat failed: Invalid argument
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# losetup /dev/loo
    /0 xxx.lfi
    losetup: /dev/loop/0
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# losetup /dev/loo
    /1 xxx.lfi
    root@dm7025:/usr/lib/enigma2/python/Plugins/Extensions/LowFAT# mount -t ext3 /d
    v/loop/1 lowfat

  • Ja, genau das ist ja dir Wurzel des ganzen Übels auf der 7025 das die pivot_root das /dev/loop/0 versteckt und damit mount und losetup immer das 0 nehmen wollen das aber schon benutzt ist.


    Die anderen Boxen haben das problem nicht, weil die eben nicht bereits beim booten ein loopdevice für das unionfs aufbrauchen.


    Wenn man ihm beim losetup das /dev/loop/1 aufzwingt funktioniert es ja.


    Insofern muss ich jetzt nur noch eine schleife proggen die einfach alle durchprobiert, bis eines geht. Was prinzipiell ja nicht so schwer ist :-)


    LG