Nachdem die Leute sich eine einfache Möglichkeit wünsche den Flash der 800se und 500hd zu erweitern muss ich wohl Freeze & Co wieder zum Leben erwecken.

Dafür müsste man aber auch im OE 2.0 die unionfs-modules zur Verfügung haben und evt. auch die unionfs-utils, weil so lässt sich am einfachsten der Flash erweitern wenn man einfach ein USB device oder ähnliches dazu mountet.

Auf der Unionfs Homepage gibt es eigentlich auch ein aktuelles diff für den 3.2 Kernel:

http://download.filesystems.org/unionfs/unionfs-2.x-latest/

Also sollte es eigentlich relativ einfach möglich sein beides auch ins OE 2.0 einzubinden, damit man sich das kernel modul und die utils für alle boxe bauen lassen kann.

Es wäre sehr nett wenn Ihr das auch noch machen könntet!

Weil dann sollte es eigentlich nur einen Tag dauern die entsprechende Tools auch im 2.0 zum Laufen zu bringen, und das Jammern wegen dem Platzmangel im Flash würde sich reduzieren.

Und ja ich habe gesehen das squashfs und cramfs im Kernel bereits mitgebaut wird (squashfs sogar mit LZMA !), aber ich würde das gerne vermeiden nachdem Ihr Euch auch dagegen entschieden habt.

LG
gutemine

Das müsste doch mit einem bitbake file so wie da gehen:

http://git.openembedded.org/op…dded/tree/recipes/unionfs

Vor allem wenn ich das richtig lese müsste es ja im Openembedded auch ein entsprechendes Bitbake geben fürs unionfs:

http://git.openembedded.org/op…inux/linux-omap_2.6.39.bb

Und wenn sogar das patch file eingebunden wird dann sollte es doch ganz leicht sein das auf unsere Version des Kernels anzupasssen, weil die alten Versionen machen wenig Sinn zu verwenden ?

Vieleicht kann es ja auch wer anderer soweit an die aktuellen Versionen für den 3.2 Kernel anpassen, weil ich bin noch beschäftigt das initramfs in den Kernel reinzukriegen.

Jetzt habe ich zwischendurch mal selbst probiert einfach das alte bb file im neuen OE zu benutzen um zu verstehe wie es geht, bzw. das ein bitbake unionfs-modules wenigstens was (versucht) zu tun.

Die Sourcen des aktuellen 2.* vom unionfs sind aber nicht mehr als tar.gz so wie beim 1.1* zum runterladen, sondern nur mehr übers git auscheckbar. Also muss das bb file auch anders aussehen, bzw. auf den git link umgestellt werden wenn man die aktuellen sourcen auschecken will.

Hat irgendwer damit mehr Erfahrung als ich (was nicht schwer ist, weil ich davon kaum Ahnung habe), weil sonst wird das ziemlich mühsam wenn ich erst rausfinden muss wie das geht?

PS: wenigstens mein initramfs landet schon im 3.2 kernel

PPS: Und ich liebe Monolog Threads, aber das initramfs hat auch so angefangen ...

Davon habe ich aber nichts wenn mich alle hier dumm sterben lassen ...

Als bekennender git/OE Verweigerer bin ich der denkbar schlechteste Kandidat für sowas - ich habe gestern 4h gebraucht bis endlich das initramfs wieder im Kernel gelandet ist. Jemand der sich auskennt hätte das wahrscheinlich in 10min hingebracht.

Und beim unionfs wird es wahrscheinlich ähnlich sein

Apropos blamieren ...

Jetzt habe ich mir mal das diff vom unions für den Kernel 3.2 angesehen. So wie ich das verstehe steckt da eh alles drinnen, sprich wenn man den patch anwendet werden alle zusätzlichen configs, sourcen,... in den jeweiligen Kernel source Tree reingepatched, wenn du dann den Kernel neu baust müsste man nur mehr in die defconfig ein CONFIG_UNION_FS=m reinmachen und ein bitbake linux-dreambox-3.2 würde dann das unionfs.ko ausspucken ???

Dann hätte ich unnötig kompliziert gedacht.

Ist das jetzt richtig so ?

Womit wir bei der Frage sind wie/wo man weitere kernel patches einbindet - muss ich jetzt recipes lesen gehen ?

Ja so verstehe ich das 2.5.11 diff für den 3.2 Kernel auch. Schließlich sind da alle sourcen als new files geadded und auch die anpassungen für Kconfig,....

NUR ich baue normal keine Kernel von Hand, und schon gar nicht im OE, sprich ich müsste erst mühsam rausfinden wie man das diff beim bauen anwendet, weil wenn ich Ihm das diff von Hand reinwürge kann ich mir mein OE morden so das der Kernel für das initramfs nicht mehr baut - und nochmals 40h lade ich das nicht runter

PS: Kann das nicht mal wer anderer ausprobieren, wenn wir uns schon unsere Wünsche selbst erfüllen müssen?

PPS: Weil sonst mache ich erstmals das initramfs fertig, und dann sichere ich das OE bevor ich alles kaputt machen gehe ... nur müsst Ihr dann auf diverse Sachen wie das freeze die ein unionfs brauchen noch einige Zeit warten.

PS: So ungefähr wie da müsste man den unionfs Patch wohl auch von Hand anwenden können ohne das er ins OE eingbunden ist:

http://www.android-hilfe.de/an…ieren-erster-versuch.html

Schließlich will ich nur 1x das blöde unionfs modul für alle boxen haben, im Moment wäre es erstmals egal das man wenn der Patch nicht eingebunden ist beim Updaten ein Problem kriegt.

Habe es gerade mal von Hand reingewürgt:

cd /mein_pfad_zun_oe/opendreambox/tmp/work/dmXXXXX-oe-linux/linux-dreambox/linux-dreambox-3.2-r7.11-bsp1/linux-3.2

zcat unionfs-2.5.11_for_3.2.2.diff.gz | patch -p1 --dry-run

Läuft alles durch mit patching file ...

Die frage ist jetzt ob ich das --dry_run weglassen soll

Habs einfach gemacht, und die ganzen sourcen werden angelegt, jetzt mal schnell ins defconfig das CONFIG_UNION_FS=m rein und ein

bitbake -f -c compile linux-dreambox-3.2

Mal sehen ... mehr als das alles kaputt ist kann wohl nicht passieren und ich ein bitbake -c clean linux-dreambox-3.2 machen muss

@Dr.Chaos - danke für die Pfade, wenn ich es dort reinmache sollte es dann automatisch im do_patch Schritt erledigt werden ???

Ja bitte, weil mit dem bitbake -f -c compile gehts nicht das er das blöde modul baut, und für heute ist es zu spät, ich muss morgen früh aufstehen.

Aber nachdem der unionfs 2.5.11 patch für den 3.2.2 Kernel sich ohne Fehler von Hand anwenden lässt wie oben beschrieben müsste es auch automatisch gehen denke ich mal.

Wie schon gesagt im Moment brauch ich die unionfs utils eh (noch) nicht, es reicht schon wenn ich das unionfs.ko für die 8000 oder 7020hd oder von miraus auch die 500hd habe, dann kann ich eine Menge Sachen wieder im OE 2.0 zum laufen brigen.

Und die utils kann ich Zur Not mir auch später im Debian auf der Box compilieren, dafür ist kein X-compile nötig, nur bei den Treibern geht das halt nicht.

Na ja wenn du ein unionfs-modules ipk für die genannten Boxen (oder alle wenn du sehr motiviert bis) bauen könntest wäre das fein, weil wie schon gesagt, letztendlich hätte ich gerne das alle Imagebauer das unionfs module mitbauen können, damit man damit dem Flash der 800se/500hd entsprechend erweitern kann.

Aber zuerst muss es erstmals funktionieren

gutenacht
gutemine

wenns mit einer box geht dann gehts eh mit allen (nur bei der alten 800er müsste man wegen 2.6.18 Kernel anderes diff verwenden)

Aber wie schon gesagt ich muss heute schon ins Bett ...

Danke auf jeden Fall für die Hilfe !

DANKE ...

Kannst du auch kurz schreiben was zu tun ist, weil ich hätte eben letztendlich gerne das der zusätzliche unionfs Patch fix ins OE eingebunden wird.

PS: Und jetzt schlafe ich sicher besonders gut wenn ich für morgen neues Spielzeug habe