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
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
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
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... (-:
ZitatOriginal 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.
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
na des ist mist... dann gute n8
B
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
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....
...und da ist sie wieder die richtige IP
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
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
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
Zitatwas zeigt denn ein losetup -f
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
zur Zeit sind 39 Mitglieder (davon 5 unsichtbar) und 1.898 Gäste online - Rekord: 5.681 Benutzer ()