Jumpin'Jack Flash der initramfs Kernel ist jetzt als 1.8 verfügbar

Ja pack bitte neu aus und wenn das auch nicht will bitte bootlog machen. Aber heute freut es mich eh nicht drann zu basteln - Sinnkrise.

dem geht schon wieder das pal.png ab - Flashcopy statt imageauspacken ist angesagt

Soviel zur Sinnkrise ....

Kannst du dich mit telnet iemloggen und mir ein backup vom /usr/share/enigma2 machen damit ich mir das endlich mal anschauen kann ?

cd /tmp
tar -cvzf enigma2.tar.gz /usr/share/enigma2

Und dann das enigma2.tar.gz holen und hier posten.

von dem fehlerhaften Dumbo image - zur Not Flash booten und mount -t ext3 /dev/hdc2 /tmp/dumbo von hand machen um es zu erreichen. Aber theoretisch müsstest du wenn das enigma2 nicht startet es noch mit telnet betreten können und mit FTP wegkopieren.

Keinen Stress, wie gesagt ich mag heute eh nicht wirklich dran basteln.

Wenn ich ein 7025 image mit nfidump auspacke ist das pal.png immer dabei

Aber ich verwende auch schon nfidump 0.3.1

Ich habe daher eine 0.22h vom Dumbo gemacht wo die drinnen ist, probiert mal ob es damit besser auspacken geht.

Das mit dem kaputten nfidump im Dumbo tut mir leid, aber scheinbar funktioniert es jetzt ja wieder.

Das mit dem reboot ist halt so eine Sache. Fein wenn es funktioniert, aber wenn man nicht aufpasst flasht man doppelt. Aber das lernt Ihr schon

Fehlen nur mehr das Testen der anderen boxen und das Flashen auf der 7025.

LG
gutemine

Die Frage ist ob ich das Flashen nicht ganz disable. Es war zwar eine nette Spielerei zu sehen ob es funktioniert, aber wenn es auf der 7025 nicht stabil geht und auf den anderen Boxen das dFlash es genauso gut kann ist das relativ wenig Mehrwert für die zusätzliche Komplexität. Der Rest des initramfs binaries funktioniert scheinbar ja jetzt schon ziemlich stabil, von den Sonderfällen wie dem rootdir und dem rootpart abgesehen die wir einfach noch nicht ausgiebig getestet haben.

Ich denke wenn ich alles rausschmeisse was Ärger macht und wir die Sache erstmals releasen würden wäre es sinvoller, weil es dauert scheinbar sowieso bis sich die Leute an den Vorteil des initramfs gewöhnen und bis ich auch die anderen Multiboot Tools angepasst hätte. Und als zusätzliches initramfs.cpio.gz kann ich das Flashen immer noch leicht implementieren, weil dort kann ich auch das normale writenfi binary verwenden so wie im dFlash statt es mit Gewalt ins init binary im Kernel einwickeln zu müssen.

Testen wir einfach noch bis zum nächsten Wochenende ein bisschen die T0.8 und dann entscheiden wir ob sich eine T0.9 ohne die Ärger machenden Sachen rentiert oder wir gleich in einem Image weiter testen.

LG
gutemine

Na ja das ganze wird später sowieso anders gelöst sein. Man wird nicht mehr Flashkernel enablen und den Kernel mitkopieren sondern man wird Lable mount enabeln können und die autoexec*.bat wird dann entsprechend anders befüllt werden. Dann muss man selbst wissen ob sein image einen initramfs kernel hat. Oder ich baue eine Erkennnung der initramfs kernel ein das es automatisch geht.

Mal sehen ...

LG
gutemine

Von miraus ... Ich teste eh gerade eine T0.9 wo das Flashen erstmals disabelt ist.

Bei Sachen im Kernel der laufen MUSS ist Stabilität halt wichtig, insofern bin ich schon bereit es erstmals abzudrehen, genauso wie den USB support für die 7025.

Dafür habe ich mir jetzt in der Zwischenzeit ein kleines python script geschrieben das nachsehen kann ob mein initramfs im Kernel ist - damit die Klonehersteller es leichter haben

Ich denke das baue ich ins Dumbo ein mit folgender Logik:

Wenn nach dem auspacken im FAT ein kernel mit initramfs ist, wird automatisch root=LABEL verwendet, sonst nur wenn Flashkernel an ist das besagt das dieser kopiert werden soll (was dann auch nur enablen geht wenn ein initramfs Kernel installiert ist)

Weil das entspricht dann schon eher der Logik im Dumbo wie es letztendlich sein sollte.

EDIT: die initramfs Kernel Erkennung ist jetzt im Dumbo 0.23a Kit zum Testen verfügbar, der Rest steht im Dumbo Thread.

LG
gutemine