Lost in Translation

sobald der cf kernel nicht genommen wird bootet der flash kernel und bei dem ist der bootlog ja disabelt.

Und ja nimmt einfach das vm-dm7025.gz aus dem R9, kann ja sein das mein FAT korrupt war und ich ihn dann korrupt in die RC10 gepackt habe.

Zitat

Original von Trekki80
Hallo gutemine

zu meinen Problem das das LowFat nach einer Aktualisierung des iCVS nicht mehr startet. Das Update hab ich per telnet mit deinen Befehlen angestoßen (Log im Anhang), danach wieder kein booten mehr möglich.
Einfaches löschen der lfboot.ini bringt nichts also hab ich weiter probiert. Ich muss noch die vm-8000.gz.ori die beim nfi extract gesichert wird wieder zurückbenennen in vm-8000.gz. Ich vermute das beim Update des Images der Kernel verändert wird, aber der Kernel zum booten in der vm-* nicht mit angepasst wird. Kann dies damit zu tun habe das ich mein System immer noch mit CF-Karte und angepasster autoexec betreibe? Alle versuche heute erfolgten noch mit RC8.
Eine Überprüfung des lfi Images über mein Flash Image ist nicht möglich da ich ja das DMM 3.0.3 einsetzte und momentan nicht gewillt bin neu zu flashen.

Gruß Rico

LowFAT unterstüzt nur immer eine Kernel Version, und in der RC8 ist das kernel kopieren noch nicht sauber drinnen. Entweder auf RC10 aktualisieren oder es lassen wie es ist ohne upgrade. In wenigen Tage wird das RC8 dann aber sowieso aufhören zu funktionieren, insofern bringt es wenig nicht zu aktualisieren.

Und dem LowFAT ist egal was du im Flash hast, zum Flashbooten wird dann derzeit der LowFAT Kernel verwendet.

LG
gutemine

Dann formatiere die CF mal so wie ich gesagt habe mit FAT32 und der größtmöglichen Blocksize die dir das FORMAT nimmt. Das bios hat scheinbar nur 16Bit, weswegen es manchmal mit der FAT (File Allocation Table) nicht zurecht kommt. Obwohl wie du richtig sagst FAT16 auch gehen müsste und sogar besser den Fähigkeiten des Bios entsprechen sollte. DMM macht auf dem NFI flash stick nicht umsonst egal wie groß er ist ein 512MB großes FAT16 drauf, weil das am stabilsten bootet.

Wenn ich so komische return 1 oder 2 Fehler hatte hat praktisch immer der alte Multiboot trick von thowi geholfen:

CF am PC, alle files mit Explorer in directory auf Hardddisk kopieren, CF formatieren und alle files zurückkopieren. Mir fällt nämlich gerade ein das ich diesmal zum packen mein Linux und nicht das Winrar genommen habe, womit evt. die Filereihenfolge anders ist im RAR und das vieleicht dem Bios dann das Leben schwer macht. Ich boote mal Windows und packe das RAR nochmals, vieleicht hilft es was.

LG
gutemine

Na ja wenn die CF richtig partitioniert ist bringt das HP Tool praktisch nichts mehr.

Das gute alte Format in der DOS box ist immer noch am flexibelsten, mit /A:32k kannst du dort die Blockgröße z.B. mit 32k angeben.

Aber ich war auch fleißig und habe das RAR nochmals wie bisher unter Windows mit WinRAR gepackt und die RC10 nochmals so hochgeladen, vieleicht hilft das ja.

LG
gutemine

Zitat

Original von Trekki80
So hab jetzt noch mal alles mit dem RC10 probiert gleiches Ergebnis. Installation von Plugins in das Image sind problemlos möglich eine tiefgreifende Image Aktualisierung nicht.
Wenn ich das weiß kann ich damit leben, mir geht es vorrangig darum mal ein fremdes Image anzusehen 1h damit rumzuspielen um dann festzustellen das ich mit meinem GP3 zufrieden bin.

Tolle Arbeit, mach weiter.

Gruß Rico

Doch das sollte schon gehen, aber eben nicht mir der alten Version die du verwendest. Die kann noch nicht richtig erkennen wenn ein neuer Kernel da ist und den zum booten nehmen, womit es dann eben nicht mehr bootet.

Wenn du also was beitragen willst verwende RC10 und berichte ob die nach Upgrade rebootet.

Zitat

Original von datbec
Du solltest beim nächsten Packen gleich von Windows gebootet haben.

Jetzt ist auch das Plugin wieder da.

MfG
datbec

Sch* Linux Packer - sorry

Na ja dann schauen wir mal ob das bootextract mit reboot jetzt mit dem bösen off code funktioniert - wenn nicht bootlog erstellen ob das fatty alles richtig macht.

Ich probeirt gerade einen 8GB stick mit 64k Blockgröße aus, da wanrt das Format schon so nett vor Kompatibilitätsproblemen - mal sehen wie das Dreambox Bios das sieht.

Ja sorry, aber ich glaube nicht das das einen Unterschied macht. Ein bootlog würde aber helfen rauszufinden warum das so ist.

Aber ich muss mir da noch was einfallen lassen weil in deinem Updatelog steht das:

mount: mounting /dev/loop/0 on /boot failed: Device or resource busy
postinst script returned status 255

Und ich dachte der bind mount in der /etc/fstab von /boot würde das verhindern Eigentlich mag ich aber nicht wieder den Trick mit dem /boot als tempfs so wie im LowFAT 2.0 reinmachen, das hat mir nie gefallen und dazu geführt das upgrades von kernel/bootlogo immer verloren gingen. Na ja, vieleicht fällt mir ja doch noch was dazu ein.

PS: Und mit 64k Blockgröße bootet es auch nicht mehr - format hatte also recht, aber 32k ist bei 8GB schluss - evt geht das ja wenn der stick noch größer ist, aber dazu habe ich wenig Lust zum testen - an 16GB formatiert die dosbox schon ewig.

LG
gutemine

die autoexec*.bat bringt schon alles für das Bootlog mit, du musst und darfst im Bios nichts mehr umstellen.

Doof, da ist schon wieder das:

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

Und dann bootet es halt nicht mehr :-/

Die Sch* ist halt das FAT ein uraltes Filesystem ist - wenn du ein file über eines gleichen Namens drüber kopierst wird das neu geschrieben und dann das alte gelöscht. Womit das neue dann evt wo liegt wo das bios es nicht mehr erreicht, und dann ist vorbei mit booten.

Das problem kann ich zwar mit großerer Blockgröße hinauszögern das es erst beim 3. oder 4. Image passiert, aber so kann man das nicht lassen.

Schlimmstenfalls müssten wir warten bis DMM den neuen Kernel als Standard released und dann davon ausgehen das aktuelel images alle damit booten - dann müsste ich das kernel copy aber wieder komplett rausmachen - hat eh nur 2 Tage gekostet das wenigstens so halbwegs hinzukriegen

LG
gutemine