Hi !

Nachdem ja jetzt dankenswerterweise eine Menge Verbesserungen in Bios und Kernel der Dreamboxen verwirklicht wurden um sie auch con CF/USB booten zu können, die ich mich auch bemühe im Dumbo und LowFAT als Bootwerkzeuge optimal auszunützen, bleibt nur mehr ein Problem bestehen das eigentlich auch lösbar sein sollte.

Sobald sich der devicename verschiebt weil man ein anderes USB device ansteckt, kann es passieren das der kernel Parameter root=/dev/xxx ein anderes xxx benötigen würde, womit man entweder das Bios umstellen oder die autoexec_*.bat editieren muss.

Wenn der secondstage loader der Dreambox in der Lage wäre device Label auszulesen und in device Namen zu übersetzen ähnlich wie es jetzt mit der /boot/ variable passsiert) so wie das z.B. grub unterstützt wäre auch dieses Problem elegant gelöst.

Wie man im bootlog erkennt wird ja eh schon versucht den Label des FAT auszulesen, daher kann das nicht so viel code sein diesen mit einer root=LABEL=XXXX:Y variable zu vergleichen und wenn der Label XXXX gefunden wird in den commandline argumenten für den Kernel das LABEL=XXXX durch das jeweilige /dev/ZZZY zu ersetzen.

Also aus root=LABEL=BOOTDEVICE:2 würde z.b. root=/dev/sdb2 weil das dann die ext3 Partition mit dem zum FAT mit dem label BOOTDEVICE passende root filesystem wäre.

Mir ist schon klar das dies nicht so einfach zu implementieren/testen wäre, aber es würde das Booten von externen devices unabhängig vom Flash noch weiter vereinfachen und flexibilisieren, und wünschen ist ja erlaubt - gerade vor Ostern

LG

gutemine

Optimist

Nachdem es nicht so aussieht als wenn wir das Feuture bekommen würden habe ich es halt als binary nachgebaut. Allerdings funktioniert es nicht das in einem initramfs laufen zu lassen.

Kann es sein das inird=/boot/meininitramfs.cpio.gz root=/dev/ram0 rootfstype=ramfs rw auf der Dreambox mit unserem Kernel 2.6.18 nicht funktioniert ?

Weil das initrd als Kernel Argument wird vom Kernel völlig ignoriert, Er mountet nur das ramfs und ist dann natürlich tot weil er dort kein init findet.

Bitte um Erleuchtung ...

PS: Kann es sein das das /boot/ nur beim kernel und bootlogo.elf funktioniert, aber /usb/ geht leider auch nicht ?

LG
gutemine

also ich war jetzt so frei den vmlinux-dm8000.gz Kernel den das NFIFlash Plugin benutzt ein bisschen auseinander zu nehmen und das verwendete initramfs.cpio.gz draus zu extrahieren um sicher zu gehen das es nicht an meinem initramfs.cpio.gz liegt.

Wenn ich diesem Kernel über ein initrd=/usb/initramfs.cpio.gz in der autoexec_dm8000.bat vom NFIFlash stick das extrahierte initramfs versuche aufzuzwingen bootet er weiterhin das im kernel reingelinkte, wenn in inird=/blabla schreibe bootet er auch ohne jeden Fehler genauso bei einem normalen vmlinux.gz aus einem aktuellen experimental. Scheinbar wird der initrd kernel parameter also wirklich vom derzeitigen Dreambox kernel aus dem OE 1.6 komplett ignoriert.

Kann es sein das ihr im kernel config file mit CONFIG_INITRAMFS_SOURCE fix ein leeres dummy initramfs enabelt habt und deswegen gar keine externen initramfs files mehr genommen werden ?

Wenn ja, könntet Ihr das bitte rausnehmen - wir sind hier ja in der Feature Request Sektion.

LG
gutemine

Nachdem dies hier ja sowieso ein Monolog zu sein scheint habe ich halt meine eigenen Spinnereien überprüft und mal aus einem aktuellen experimental vmlinux.gz das initramfs extrahiert:

cat initramfs.cpio | cpio -t
/dev
/dev/console
/root

Also habt Ihr in den standard images einen Dummy reingepackt, und im Kernel vom NFIFlash ein 'ordentliches' - womit id das initrd= scheinbar vergessen kann

Na gut, dann gehe ich halt mal den fertigen kernel patchen .... das wird lustig werden

Und ja, wenn ich mir das kernel builden im OE angeschaut hätte dann hätte ich das auch rausfinden können - aber dazu bin ich zu blöde.

PS: Ist aber nicht nett im NFIFlash noch den *.3 Kernel zu verwenden und nicht den aktuellen *.4, dann wäre das patchen einfacher gewesen ...

LG
gutemine

Das ist meine geringste Sorge, weil wenn wird von mir nur der aktuellste Kernel gepatched der auch nur mit den aktuellsten loadern und Treibern geht - und das die nicht auf Klonen laufen muss sich DMM wohl selbst drum kümmern (was bis jetzt ja weitestgehend funktioniert hat soweit ich weis).

Insofern stört mich auch nicht wirklich das der Kernel vom NFIFlash schon zu alt ist.

LG
gutemine

Danke für die Unterstützung.

Und wenn ich böse bin baue ich auch meine Clonerkennung ein, damit das Feature nur auf Originalboxen mit aktuellem und ungepatchtem Loader läuft

Und nein, den security Chip brauche ich da nicht dafür ...

LG
gutemine

Kurzer Zwischenbericht/Fortsetzung des Monologs:

root=LABEL=XXXX geht jetzt mit meinem initramfs.

Ich überlege jetzt auch nocht einen parameter rootpart=X für die Rootparttion zu machen auf der danach gesucht werden sollte (falls man mehrere Images auf einem device in unterschiedlichen partitionen hat), und theoretisch ginge jetzt sogar auch ein rootdir=/media/xxx für die Leute die mit chroot booten wollen und das auch gleich vom initramfs erledigt haben wollen.

Soll ich auch gleich einbauen das wenn ein device mit Label FLASH gefunden wird wo ein nfi file drauf ist das auch gleich geflast wird ?

PS: Und ja der check gegen gepatche Loader ist jetzt auch schon drinnen falls die Vorfreude an falscher Stelle überbordet.

LG
gutemine

Kurzer weiterer Zwischenbericht meiner initramfs Basteleien:

Label booten ... geht (FAT und ext3 als root=LABEL=)
Kernel bootparameter interpretieren .... geht (root= rootdelay= rootpart= rootfstype= ... wer braucht schon den Rest ?)
Aktueller Originalloder im Flash checken ... geht
gutemine's eigenes bootlogo.jpg auf dem Bootdevice checken ... geht

Und nein, da ist kein einziges shellscript im Einsatz ...

Und jetzt habe ich erstmals keine Lust mehr weitere Sachen einzubauen

Hatte wieder Lust dran zu basteln:

Flashen wenn ein USB stick oder eine CF mit Label FLASH beim booten gefunden wird wo ein nfi image drauf ist ... geht

Na ja, mir kommt das ein bisschen so wie 'Löcher in Socken stopfen' vor.

ABER es ist der perfekte Platz dafür und wenn jemandem die Farbe der Wolle nicht passt dann hat er halt Pech gehabt.

Wobei das kernel-initramfs ipk für die 8000er ist bei mir schon im Test.

Nur das kannst du dann überall verwenden, nicht nur bei Dumbo, sondern auch im Flash.

Wobei wir es mit Dumbo und LowFAT zuerst testen werden, wenn es gefällt schaue ich mal ob wir nicht images finden die das gleich fix als alternativen Kernel verbauen.

Nur das macht erst Sinn wenn es ausgiebig getestet ist.

Aber nicht hier, ich monologisiere nicht gerne

PS: Mein initramfs meldet sich jetzt übrigens als Jumpin'Jack Flash ... weil der Name so treffend ist.

LG
gutemine

Der Jumpin'Jack Flash initramfs Kernel ist jetzt als Testversion für die 8000er öffentlich verfügbar, sowie ein Dumbo kit um seine Funktionen auch zu benutzen.

Aber nicht hier, womit ich den Thread wohl nur mehr auf [selbst gelöst] setzen werde wenn wir fertig sind.

LG
gutemine

Na ja ein kleiner Zwischenbericht rentiert sich noch, schon weil wir noch mehr Tester benötigen würden da der Kit jetzt für alle enigma2 Dreamboxen als Testkit verfügbar ist.

Die geplanten bzw. von mir gewünschten Funktionen sind jetzt alle im Testkit verfügbar:

Checken des letzten SSL der jeweiligen Box

root mit label mounten

flashen eines nfi files von einem stick direkt beim booten

starten eines weiteren externen initramfs.cpio.gz mit initrd= in der autoexec*.bat

LG

gutemine