Na ja mir würde im ersten run schon reichen wenn die Module mitgebaut würden und am Softwarefeed sind damit man sich beim Kernel Updaten keinen Probleme einhandeln kann.
Im Kernel wäre aber natürlich die schönere Lösung, weil wie gesagt dann könnte man es perfekt lösen und alles in den Kernel tun also auch die deviceerkennung und das ummounten.
Klar würde es als Modul reichen. 
Ich hab da eine Frage.
Ist es nicht sinnvoller so viel wie möglich fest in den Kernel einzubinden und nur Fs, die Closed Source Treiber und Tuner als Modul zu machen?
Linus sieht das anders und zum debuggen ist es auch einfacher wenn du nicht ständig neuen kernel bauen musst.
Wobei als Kloneschutz ist etwas das fix im kernel verbaut ist schon ganz brauchbar, mein initramfs oder rambo prüft ja auch brav ob ein aktueller Originalloader verwendert wird und nicht was gepanschtes. Ich bin da auch eher der Meinung das man in den kernel nur packen sollte was man zum booten braucht und sonst nichts - wobei diese definition dann auf den block2mtd zutreffen würde wenn man größeren Flash braucht. Einer der Gründe das wir kein ubifs gekriegt haben ist ja auch dass der Freiplatz noch weiter runter gehen würde und dann ist es bei 64MB Flashboxen schon fast zu knapp.
Sachen die man sehr früh im booten braucht könnte man ja auch als module in ein initramfs packen - ich habe mir nicht umsonst in meinem kinit binary den support für externe initramfs.cpio.gz reingemacht.
Nur wird dafür der Platz in /boot AUCH schon recht knapp, aber das ist eine andere Geschichte.
LG
gutemine
Naja, bei der 7020hd ist im /boot noch recht viel platz. 
Was kann denn UbiFS denn so besonderes?
LG
http://www.linux-mtd.infradead.org/doc/ubifs.html
Da gibts reichlich Lesestoff dazu.
Im Prinzip hat jffs2 bei größerem Flash ein Problem performant zu bleiben, ubifs nicht.
Mit ein bisschen Handarbeit kann man es im OE 2.0 sogar für das root filesystem ausprobieren (/boot geht nicht weil unser bios derzeit kein ubifs kann, wobei dort stört jffs2 auf Grund der geringen Größe auch nicht wirklich)
Evtl. sollte DMM zweigleisig fahren.
UbiFS für die Boxen mit großen Flash und Jff2 für den Rest.
Ghost hat gesagt wir werden ubifs schon kriegen aber nicht gleich zum Anfang der OE 2.0
Alle nötigen Treiber und tools sind aber vorhanden, nur das bios kann halt (noch) nicht damit umgehen.
ich könnte ein kleines root2ubifs Plugin schreiben, aber dann werde ich wieder gesteinigt.
Mit dem neuen dFlash das auch naddump und nandwrite beherrscht könnte man solche ubifs images aber auch flashen, mit DreamUP und Bios halt nicht.
Insofern war das eher eine Spielerei um zu sehen ob es geht und wie rasch es damit bootet.
Block2mtd ist jetzt fest im Kernel.
ich könnte ein kleines root2ubifs Plugin schreiben, aber dann werde ich wieder gesteinigt.
Wieso steinigen?
Weil dann die Leute schon wieder Sachen benutzen die sie nicht verstehen
Und ja das mit dem block2mtd habe ich gesehen, ist nett von Ihnen. Ich muss aber erst das initramfs wieder 100% zum laufen bringen, aus irgendeinem Grund will das Labelmounten schon wieder nicht funktionieren. Ich habe gestern ja das Dumbo fürs OE 2.0 als Testkit fertig gemacht (bei OoZoon im Board zu finden) und da geht eigentlich schon wieder alles wie im OE 1.6 eben bis auf das Labelmounten.
Sobald ich rausgefunden habe warum das initramfs nicht per Label mounten will schaue ich mir wie versproochen mal an ob ich den Rambo code da drinnen zum Laufen kriege.
Dann ist das Thema ja gelöst.
Kann man Rambo nicht im Zusammenhang mit dem root2ubifs Plugin missbrauchen? 
Na ja sagen wir mal so um ubifs zu simulieren wäre das nandsim sinvoller, aber wenn schon dann macht man es auf den echten Flash:
Wenn du die ubifs Beschreibung die ich dir gepostet habe ordenlich durchliest, mit Dumbo von einem stick bootest damit du /dev/mtdblock3 mit den mtd-utils formatieren und ubifs drauf machen kannst ist es eigentlich eh nur eine Handvoll Befehle abtippen, in den mtd utils findest du ja alles nötige und ubifs Treiber ist im Kernel schon drinnen.
Dann kopierst du vom Dumbo device die root wieder in den unifizierten Flash zurück (oder packst mit nfidump eine neue aus einem nfi drauf) passt die autoexec*.bat an und schon ist das Flashimage 'ubifiziert'
In Summe keine 10 min Arbeit, du kannst es ja ausprobieren und HowTo schreiben - dann fliegen die Steine mal in eine andere Richtung.
Wobei das jffs2 auf einem block2mtd device eh viele Nachteile des echten jffs2 auf NAND Flash nicht hat, schließlich brauchst du kein ECC und Weearlevel handling weil ja keine echten Flashbausteine drunter sind.
Auf jeden Fall habe ich den thread jetzt auf gelöst gesetzt und muss schnell neue rambo version bauen die die Treiber nicht mehr nachlädt (aber noch als standalone binary).
LG
gutemine
Kleiner update noch, das rambo 0.9.2 kommt jetzt auch mit dem neuen Kernel mit block2mtd Treiber im kernel zurecht, mal sehen ob es den Leuten gefällt.
Cool.
Kennst Du dich im OE aus?
Ich hab zum Spaß mir einen Kernel für die DM7020 kompiliert mit allen Modulen, die in /lib/modules sind fest in den Kernel.
Das Problem ist, dass manche Abhängigkeiten nicht mehr stimmen.
| Collected errors:
| * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-boot:
| * kernel-module-stv0299 *
| * opkg_install_cmd: Cannot install package task-core-boot.
| * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-opendreambox-enigma2:
| * kernel-module-ppp-deflate * kernel-module-ppp-generic * kernel-module-ppp-async * kernel-module-isofs * kernel-module-zd1211rw * kernel-module-rt2800usb * kernel-module-r8712u * kernel-module-rt73usb * kernel-module-carl9170 *
| * opkg_install_cmd: Cannot install package task-opendreambox-enigma2.
NOTE: package dreambox-image-1.0-r0: task do_rootfs: FailedIn der task-core-boot kann ich diese nicht finden. 
wirklich gescheit ist das aber nicht, weil abgesehen von der Kernelgröße die auf der 7020HD nicht so das Problem ist wäre so ein genvminux mit allen devices auch entsprechend träge bis er das alles initialisiert hat. Da wäre ein Kenrel der auf allen Dreamboxen läuft schon eine lustigere Herausforderung
Und nein, ich bin bekennender im Debian auf der Box compilierer, insofern bin ich fürs OE der denkbar schlechteste Ansprechpartner, ich war schon froh mir einen kernel mit meinem initramfs Patch selber bauen zu können.
Wenn dir fade ist dann mach lieber in den kernel auch die mtd devices für den restlichen Flash rein, weil über das /dev/mtd0 kann man den zwar benutzen, aber das bringt wenig wenn man jedesmal nachher den loader wieder flashen muss
LG
gutemine
Thx.
Im Moment ist bei mir alles nur Spielwiese.
Mtd für den restlichen Flash, oh je. hoffentlich überschreitet das nicht meine Kenntnisse. Blutiger C-Anfänger mit Grundkenntnissen.
Mein obiges Problem hab ich mittlerweile gelöst.
Mann muss sich einzeln durch die Task hangeln und die Abhängigkeiten löschen.
das mtdlayout ist in irgendeinem config file hinterlegt, das muss man nur finden und anpassen. Such mal nach maxvar für die enigma1 images da war das schön erklärt auch wenn es jetzt wahrscheinlich ganz anders funktioniert.
Und nur mit dem Tasklöschen wird es nicht getan sein, da baut dann zwar der kernel aber ob das alles funktioniert ist eine andere Frage
Wobei wenn man nicht spielt lernt man nichts, insofern bist du schon auf dem richtigen Weg.
Die Module, die jetzt fest im Kernel sind aus den tasks entfernen hat geklappt.
Image boote in ca. 88 Sekunden hoch. Von Power-On bis zum Bild.
root@dm7020hd:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 248.0M 85.9M 162.1M 35% /
devtmpfs 154.2M 0 154.2M 0% /dev
none 154.3M 380.0K 153.9M 0% /var/volatile
/dev/mtdblock2 7.0M 4.5M 2.5M 65% /boot
/dev/disk/by-uuid/1ecf0a8f-6944-45f8-8fb7-b63316f658f0
1.8T 875.1G 987.4G 47% /media/hdd
Im /boot sind noch ganze 2.5 MB frei.
na ja schau mal ins bootlog/dmesg was davon auch wirklich alles geladen wurde und devices anlegt, Vieles wie die Berge von Tunermodulen macht ja nur was wenn auch so ein device angesteckt ist.
Was mich daran erinnert das ich da auch einiges an USB devices herumliegen hätte was ich bis zum OE 2.0 beiseite gelegt hatte
So radikal war ich auch nicht.
Es ist nur im Kernel, was unter /modules/lib vorhanden ist, außer das extra Verzeichnis und ntfs und reiserfs.
Den Sound bekomm ich irgendwie nicht rein, obwohl es in der defconfig angegeben ist.
sound ist auch nur in den closed source broadcom Treibern drinnen glaube ich
Erst wenn die laufen kannst du die ganzen anderen devices wie alsa pulseaudio & co starten.