Lost in Translation

mach dir keinen Stress, aber es muss ja einen Grund haben warum der reboot geht wenn in einem schon gebooteten Image anderer Kernel gefunden wird und nicht wenn das beim auspacken beim booten passiert.

Aber das finden wir schon raus ...

EDIT: Ich glaube ich weis schon was fehlt - damit die fp.ko laden geht muss auch die stb-core.ko geladen sein. Und die habe ich vergessen reinzupacken. Na ja auf zur R10

OK & DANKE für heute.

Das waren eh sehr hilfreiche inputs zur Fehlerfindung. Ich habe jetzt den versprochenen RC10 kit auf die erste Seite gemacht, wo auch die stb-core.ko für die 7025 dabei ist und mitgeladen wird damit die fp.ko vieleicht jetzt funktioniert damit das /dev/dbox/fp0 device endlich auch wirklich für den reboot verwendet werden kann.

Mal sehen ob es damit auf der 7025 besser funktioniert ein nfi image beim booten zu extrahieren.

Wenn nicht bitte um das übliche bootlog, um zu sehen was diesmal schief geht.

Sonst gibst heute von mir aber auch nichts Neues mehr zum LowFAT. Ich warte mal auf morgen ob dann endlich ein neues experimental image von DMM gebacken wird, weil das vom 9.2 ist leider ausgefallen

Na ja wir sind ja geduldig....

LG
gutemine

Hi !

Immer noch keine neuen experimental Images auf der DMM Homepage.

Ich hoffe ich bin nicht schuld mit meinem cp437. Kann aber auch sein das bald eine 3.1 Release kommt und sie deswegen keine experimental images bauen wollen.

Egal, ich kann warten

Die Frage ist aber für mich wie wir jetzt das kernelhandling machen sollen:

So wie es jetzt ist:

Imagekernel wird überprüft ob cp437 drinnen ist und wenn ja wird er ins FAT kopiert und rebootet damit er auch aktiv ist (ausser der selbe kernel ist schon im FAT (weil z.B: mit Plugin entpackt), dann wird gleich weitergebootet. Das kostet aber 3-5 sec bootzeit für checken und kopieren und fast 1 Minute wenn man rebooten muss. Kann der kernel nicht vom FAT booten wird der vm*.ori kernel vom LowFAT genommen und auch kopiert & rebootet falls nötig.

Wenn dann eh alle images entsprechenden kernel haben ist das aber unnötiger Overhead. Ich würde dann einfach annehmen das der kernel passt und diesen ohne Prüfung verwenden. Evt mach ich dann ins Plugin auf Gelb noch den Menupunkt Kernel check rein damit man wenn es nicht bootet oder man sich nicht sicher ist es nach dem Auspacken und vor dem reboot noch checken kann (und wenn der keinen FAT enableten Kernel findet kopiert er einem halt wieder den vom LowFAT - nur eben nicht beim booten damit das flott bleibt).

Das wäre eigentlich die Variante die für die Releaste Version am meisten Sinn machen würde, wobei ich es aber auch so lassen kann wie es jetzt ist.

Wobei dann halt auch keine 'alten' images aus der Zeit bevor die cp437 in den Kernel gewandert ist ohne manuelles check & fix des kernels gehen würden (ausser OoZooN und iCVS die es ja jetzt schon haben). Nachdem die Images aber eh bald nachziehen werden wenn es wirklich ein entsprechendes Release Image gibt sollte das eigentlich nur temporär zur Anwendung kommen, und in einer 3.1 könnte ich den Kernel Check dann schon ganz rausschmeissen.

Wie seht Ihr das - so wie es jetzt ist oder vereinfacht?

Was übrigens auch noch getestet gehört ist die Geschichte mit der Blockgröße beiom FAT formatieren. Bei 32K kann ich auf meinem 8GB stick 3 Images auspacken und kernel hin und her kommentieren, beim 4. Image ist dann Schluss, das bios kann dann den kernel nicht mehr sauber auspacken weil er jenseits von 1GB liegt und dann bootet mir wieder der Flash. Ich muss noch testen ob da die großen Blöckgrößen (64128/256) noch eine Verbesserung bringen, weil mehr als 3 images hat man bald.

Ja und letztendlich müsstet Ihr sagen ob das Plugin jetzt so OK ist, oder gibt es noch Wünsche dazu ?

Weil wenn die 7025 endlich auch sauber funktioniert würde ich schön langsam mal über ein Release Datum nachdenken wollen.

LG
gutemine

Zitat

Original von Freaknet
Hab ich ja bereits gemacht:

Im Falle der DM800 bedeutet dies:

primary boot source: usb [/ autoexec_dm800.bat]
secondary boot source: flash

aber wie mach ich das? Wollte die aus der *.rar enthaltene autoexec_DM800.bat in das /boot Verzeichniss kopieren, jedoch kommt dann die Fehlermeldung "Kritischer Dateiübertragungsfehler

Wie bring ich die *.bat auf meine Dreambox?

Edit: habs hinbekommen mit der autoexec.bat, jedoch startet meine Box immer vom Flash aus, obwohl auf Primary der usb [/ autoexec_dm800.bat] steht.
Kann es sein das mein USB-Gerät nicht erkannt wird beim booten der Box?

Alles anzeigen

Die autoexec_*.bat bleibt auf dem LowFAT device, die hat auf /boot nichts zu suchen. Du sagst der box nur im Bios wo sie ist und wie sie heisst damit sie auch von dort ausgelesen wird.

Scheinbar hast du das ja jetzt geschafft. Wenn du es richtig gemacht hast muss aber im OLED der box /usb/bl-dmXXX.elf und dann /usb/vm-dmXXX.gz beim Einschalten erscheinen.

Wenn nicht dann hast du es noch nicht richtig gemacht, oder das Filesystem des LowFAT devices ist nicht richtig als FAT(32) formatiert wie es im liesmich.txt steht. Wenn es dann trotzdem nicht weiterbootet und/oder hängenbleibt nachdenken ob du anderes USB device noch an der box hast (das muss erstmals weg) oder anderen stick verwenden wenn er zu langsam ist.

Und wenn das und/oder ein USB hub auch nichts hilft muss man ein bootlog machen, um zu sehen ob und als welches device der stick erkannt wird und erst dann ggf. die autpoexec*.bat editieren. Manchmal ist der stick einfach zu langsam, dann hilft evt. das rootdelay in der autoexec*.bat auf 15 drehen, mehr ist aber nutzlos.

LG
gutemine

schau mal ins bootlog, wahrscheinlich wird da der Kernel zwar entpackt, aber dann kommt ein Returncode 1 oder 2 zurück und es wird vom Bios wieder der Flash gebootet womit dann natürlich das fatty binary nicht seine Arbeit tun kann um das Plugin und den Flash zu mounten?

Wenn ja, dann kann es sein das du die CF nochmals formatieren müsstestmit anderer Blocksize und nur das RAR drauf packen (mehr steht im liesmich.txt). Ich habe weiter oben schon geschrieben das es Probleme geben kann den Kernel zu laden wenn die Files an der falschen Stelle im FAT landen. und das kann auch beim ersten Booten beim kopieren des Flashkernels passieren. Dann wäre eben eine größere Blocksize beim FAT einen Versuch wert - bei mir hilft das aber auch nur begrenzt wie weiter oben erklärt.

LG
gutemine

Zitat

Original von datbec
Die CF war frisch formatiert, bevor ich die RC10 dahin entpackt habe.

MfG
datbec

Mit Standardgröße formatiert , oder mit 32k so wie empfohlen ?

Dann mach mal ein bootlog, sonst ist das nur Raterei was da schon wieder schiefgeht. Kann auch sein das ich einen Fehler im fatty eigebaut habe beim dazugeben des ladens der stb-core.ko, das müsste das bootlog aber schnell zeigen.

Freaknet - zeigt die box das LowFAT Logo beim booten und das /usb/* im oled ?

dann sind wahrscheinlich deine Bios Einstellungen falsch. Nochmals genau lesen.

Wahrscheinlich kernel command line enablet, oder usb disabelt, oder prerun,... schau halt mal ein paar Seiten zurück, da steht genau was funktioniert mit screenshots

Zitat

Original von datbec
Bootlog.
Ich formatiere das Teil noch einmal.

Jetzt ist Log auch dabei.

MfG
datbec

executing '/cf/vm-dm7025.gz' returned: -2

Wie ich geschrieben habe, der Kernel auf der CF hat etwas und will nicht starten.

Kannst du versuchen den kernel für die 7025 aus einem älteren RAR drüber zu kopieren, vieleicht hilft es was.

Und Filesystem wird als FAT16 erkannt - ist deine CF wirklich so klein ?