Lost in Translation

Danke für die Crashlogs, da habe ich vergessen zu checken ob ein file überhuapt zum kopieren da ist.

Ich hänge Euch eine plugin.py an die das fixen sollte, bitte austauschen.

Und es gibt keine Fortschrittsanzeige mehr. Das LowFAT Logo bleibt einfach so lange bis er fertig ist und dann sollte er das image auch booten.

ABER eine Seite weiter oben steht aber das man das Bootextract im Moment nicht benutzen sollte sondern seine Images mit dem Plugin konvertieren, da es im Moment aus Stabilitätsgründen recht lange dauert.

Daher bitte nochmals mit dem Plugin das image konvertieren und berichten ob es dann ordentlich bootet.

Auf der 7025 sollte immer das LowFAT Logo beim einschalten angezeigt werden, und dann das imagelogo, bzw. das Flashlogo - je nachdem was man halt bootet.

LG
gutemine

Edit: Anhang entfernt, weiter unten ist bessere plugin.py

Zitat

Original von kko
mit der RC6 bootet meine 8000er nicht mehr.
Ich habe 10Min. gewartet und der Stick blinkt fröhlich vor sich hin. Dann mal auf den Stick gesehen und es ist dann ein .lfi und ein .nfi File da.

BITTE lest was ich zur RC6 geschrieben habe - Ihr sollt das RC6 nicht mit dem bootextract verwenden weil es zu lange dauert. Bitte konvertiert erstmals die Images mit dem Plugin (dauert 8-10 min statt der 2-3 wie vorher) und diese sollten dann hoffentlich booten.

Und solange der stick blinked arbeitet LowFAT noch

Es heisst ja nicht das das bootextract nicht funktioniert, aber je nach Imagegröße kann es so lange dauert das die Userv die Geduld verlieren. Und durch das Abdrehen beim auspacken ruiniert Ihr dann evt das Filesystem und dürft nochmals von vorne anfangen.

Wir müssen erstmals einen Weg haben das es stabil die images konvertiert (erstmal EGAL wie lange es dauert).

LG
gutemine

die 3.0 hat noch NIE wenn sie fertig war reboot gemacht, sondern bootet gleich das image weiter.

Was beim Bootlgo anzeigen schiefgeht kann ich dir nur mit einem Bootlog sagen - also bitte eines posten, sonst kann ich es nicht fixen.

LG
gutemine

Bitte konvertiere mal ein image mit dem Plugin dann weist du wie lange es jetzt im RC6 dauert.

Und nein 5h sind es nicht - ich habe gerade auf der 8000er ein image beim booten konvertiert - waren genau 9 min bis das Bootlogo verschwand und es weitergebootet hat (und die 7025 wäre dann wahrscheinlich wegen dem squashfs noch langsamer).

Und ja ich weis das das 3x so lange ist wie gewohnt - mehr als Euch vorher warnen kann ich aber nicht tun.

ABER wenn du nicht warten willst kannst du das nfidump im bin directory durch das aus dem Anhang ersetzten. Das solltle so schnell wie früher sein, ABER ob es auch beim Konvertieren keine Fehler macht müsst Ihr dann selbst rausfinden

LG
gutemine

Ja ich denke auch das das nfidump im rc6 besser funktioniert - nur ist es halt UR-langsam weil ich zur Sicherheit die Datenstrukturen immer lokal kopieren lasse (weil von dort kommt die corruption das sich die gegenseitig überschreiben).

Aber das ist wie Igel Sex haben - sehr vorsichtig

Wenn das nfidump aus dem RC6 besser funktioniert, dann könnt Ihr es ja mit dem das ich in der vorherigen Antwort ersetzt habe tauschen und schauen ob es immer noch stabil auspackt. Und ERST wenn das auch klappt rentiert es sich wieder den Bootextract auszuprobieren.

Und wenn das alles klappt dann mach ich noch einen letzten RC kit bei dem man nichts mehr tauschen muss und den testet Ihr bis Montag und dann wird released.

Und wenn nicht - dann leiden wir halt weiter ...

Bezüglich des iCVS - im Prinzip geht jedes aktuelle Image mit LoFAT, es geht darum ob es noch booten würde wenn du den vm-*.gz durch den vmlinux.gz aus dem /boot des Images ersetzt.

Also z.B. auf der 7025 wenn du das iCVS gebootet hast:

cp /boot/vmlinux.gz /tmp/lowfat/vm-dm7025.gz

Wenn es dann noch rebootet hat Schädel alles richtig gemacht

Ich habe im Moment aber das copy kernel Feature nicht im Plugin implementiert weil es noch zu wenig Images mit entsprechendem Kernel gibt das sich das rentiert. Wenn DMM den fix für das booten von FAT (ist eh nur eine fehlende codepage) einchecken würde und alle images so gebaut wären - DANN würde ich es auch wieder ins Plugin machen. Und von Hand geht es eben wie oben beschrieben

LG
gutemine

Muss ich Dir jetzt ein 3. mal schreiben das du KEIN nfi drauf kopierne sollst und es beim Booten konvertieren, sondern es erstmals mit dem Plugin konvertieren wenn das Flashimage gebootet ist, damit ich halbwegs sicher sein kann es es KEIN Konvertierfehler ist ?

Und ja ich glaube dir ja das es nicht bootet, aber du willst ja das wir rausfinden warum, also muss ich versuchen rauszufinden was das Problem verursacht ?

Wenn du die box abgedreht hast weil es dir zu lange wurde kann auch einfach dein Filesystem hops gegangen sein, dann suche ich völlig umsonst.

Und laut deinem bootlog hat das image schon gebootet nur enigma2 startet nicht weil kein Framebuffer da ist (weil er vorher beim laden eines Treibers einen crash hatte) - und woher soll ich jetzt wissen warum das so ist wenn du es nicht so konvertiert hast wie ich dir gesagt habe?

Wenn du also das FAT nochmals formatierst und das image nochmals mit dem Plugin konvertierst (und brav wartest bis das Work in progress verschwindet) und dann bootest und es dann immer noch diese Macken macht, dann bitte nochmals mit bootlog posten.

Ich versuche ja auch nur mit Eurer Hilfe die Probleme einzugrenzen und zu lösen.

LG
gutemine

Ich mag aber das bootextract nicht debuggen solange ich nicht sicher weis das das nfidump auch auf der dm7025 endlich seinen Job macht

Also bitte erstmals alle nfi images die euch so einfallen auf /hdd/MB_Images und mit dem letzen Plugin (und vonr mir aus auch mit dem letzten nfidump das wieder schneller ist und nicht mit dem aus dem RC6 kit) auf lfi konvertieren und dann schauen ob alle (!) anstandslos booten.

Wenn das der Fall ist dann wenden wir uns gerne freudvoll dem Extrahieren der nfis beim booten zu

Vorher macht das einfach wenig Sinn, weil es eben der schlimmste Fall ist, wo zusätzliche Fehlerquellen bestehen und ich absolut sicher sein muss dass es nicht am nfidump liegt.

Nicht böse sein, aber wir haben mit diversen Codefehlern im nfidump jetzt schon Tage vertan, und solange ich dem nicht trauen kann macht es wenig Sinn Bootprobleme (die vieleicht dadurch verursacht sind) zu debuggen.

Fehlersuche funktioniert wie die Mördersuche beim Tatort - man eliminiert alle die es NICHT sein können (Alibi, ...) - der der überbleibt ist der Mörder.

LG
gutemine

OK, trotzdem ist da auch noch ein Bug in der plugin.py den Ihr dabei hättet finden müssen

Oder habt Ihr die crashes ignoriert ?

Und Flashen kann LowFAT eh schon lange (Images als Flash.nfi auf das LwoFAT device machen - steht doch alles im readme.txt). Aber nicht das aktuelle/gebootetet Image sondern eben nur ein nfi image.

Das Kernel tausch Feature hat nur damit zu tun das dann beim booten eines LowFAT images auch sein eigener Kernel verwendet wird (und nicht der den LowFAT mibringt damit man überhaupt von FAT booten kann).

In der angehängten plugin.py habe ich das Feature halt temporär aufgedreht (Kernel swap und restore auf grün), aber ausser in aktuellem OoZooN und iCVS image wird LowFAT dann nachher nicht mehr booten und ihr müsst die *.ori kernel dann trotzdem wieder von Hand zurück kopieren. Das Feature ist also nur zum Testen da, und wird wahrscheinlich wieder disabelt.

Also bitte noch ausgiebig testen ob auch das letzte nfidump stabil images mit dem Plugin auspackt. Das bootextract kann ich mir wenn dann eh erst am Abend anschauen. Aber wenn wir stabil auf allen Boxen den Flash clonen, nfi images flashen und images auspacken können ist das eh schon eine ganze Menge

LG
gutemine

PS: Backup der lfi images in ein nfi mache ich auch irgendwann, aber sicher nicht in der 3.0. Weil wenn man ich dann gleich so wie beim nfidump ein all-in-1 nfibuild binary das die images backupen kann egal wo sie sind (also nicht nur reines Flash backup das beim LowFAT ja ziemlich nutzlos ist) - also auch nur als directory irgendwo ausgepackt, oder gerade gebootet, etc.

EDIT: Anhang entfernt, besseres plugin.py ist weiter unten.

Danke, da geht ihm scheinbar beim root.jffs2 auspacken was schief, womit es dann natürlich nicht mehr bootet.

Aber wie schon gesagt im Detail schaue ich mit das bootextract erst am Abend an. Jetzt muss erstmals das normale Image extrahieren wasserdicht funktionieren, genauso wie das clonen und das Flashen eines Flash.nfi

Insiofern habt Ihr genug zum testen bis zum Abend

Und mit der letzten plugin.py könnt ihr auch mit gebootetem OoZooN und iCVS das swap kernel testen, bei allen anderen images wird es sonst nicht mehr booten und dan bringt das restore Kernel im Plugjn nichts mehr weil man nicht mehr soweit kommt

LG
gutemine