Dreamboard

Nochmals Danke, aber irgend ein weiterer kernel patch oder ein weiterer CONFIG Parameter geht Ihm da noch ab weil das module bringt beim Laden noch einen Fehler:

modprobe unionfs
modprobe: can't load module unionfs (kernel/fs/unionfs/unionfs.ko): unknown symbol in module, or unknown parameter

dmesg
[ 492.161000] unionfs: Unknown symbol vfs_splice_from (err 0)
[ 492.161000] unionfs: Unknown symbol lookup_one_len_nd (err 0)
[ 492.162000] unionfs: Unknown symbol vfs_splice_to (err 0)
[ 492.163000] unionfs: Unknown symbol release_open_intent (err 0)

Aber das finden wir erst morgen raus ... Und das Problem hat der beim X-Compilieren fürs Android von obigem Link auch.

Gerne, aber erst am Nachmittag, weil ich bin gerade erst wieder aufgestanden und muss auch noch was arbeiten :-)

PS: Danke für die Nachtschicht !

So jetzt habe ich das modul ausprobiert (vor und nach dem Softwareupdate von heute). Leider immer noch die selben Fehler wie mit der allerersten Version.

Das release_open_intent kommt aber aus dem namei.c:

diff --git a/fs/namei.c b/fs/namei.c index 2826db3..38628ef 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -490,6 +490,7 @@ void release_open_intent(struct nameidata *nd) fput(file);

Wobei das normal nur eine blöde funktion um ein file zu öffnen ist so in der Art:

* release_open_intent - free up open intent resources
* @nd: pointer to nameidata
*/
void release_open_intent(struct nameidata *nd)
{
if (nd->intent.open.file->f_dentry == NULL)
put_filp(nd->intent.open.file);
else
fput(nd->intent.open.file);
}

Und im Prinzip macht das diff auch nichts anderes als die routine auf fput umbiegen. Und die anderen 2 fehlenden routinen sind auch nur eine halbe codeseite.

Schau dir mal das diff an von dem Burschen aus dem Android Forum den ich weiter oben gepostet habe, der hat einfach die 3 fehlenden routinen wo geklaut und mit einem weiteren diff dazu gemacht damit es läuft - nicht schön, aber effizient.

Wenn man die entsprechenden halbe codeseite einfach mal schmutzing in das originale diff reineditiert (oder daraus 2. Patch macht) müsste es eigentlich gehen das die symbole alle vorhanden sind und das zeug sich lädt.

LG
gutemine

Und da ist noch die Änderung der splice routinen im splice.c die uns das Problem mit den 2 anderen unknown symbols macht:

http://osdir.com/ml/file-systems.unionfs…5/msg00640.html

Ist aber nur ein umbenennen, also müsste man theoretisch auch einfach den alten Namen verwenden können. Wobei der Change scheinbar schon bei 2.6.29 war, also im 3.2 müsste beides schon drinnen sein so wie das diff vom unionfs es haben will.

Ich muss aber gerade mein OE neu aufbauen (wie befürchtet), mit dem neuen patch fürs initramfs in den Kernel habe ich mir zu viel kaputt gemacht.

Ich werde da wohl erstmals nur ein How To machen wie man es von Hand einbaut und mich dann erst wieder daran wagen einen patch zu diffen. Aber Hauptsache man kann mal Kernel mit initramfs bauen, jetzt fehlt mir wirklich nur mehr das unionfs dann könnte das ein sehr produktives Muttertagswochenende werden.

Kein Problem, ich bin ja schon froh wenn mir überhaupt jemand hilft, weil meine Talente (sofern überhaupt vorhanden) liegen woanders.

Und so viel fehlt da ja auch nicht mehr, es baut ja schon und wir wissen wo ca. das Problem herkommt - nur mehr lösen muss man es :-)

Meinst du das böse um die routinen kurz zu schließen ?

Das ist die 2. Reply in dem Thread

http://www.android-hilfe.de/android-os-e…er-versuch.html

Oder meinst du das da:

diff --git a/fs/namei.c b/fs/namei.c index 2826db3..38628ef 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -490,6 +490,7 @@ void release_open_intent(struct nameidata *nd) fput(file);

Das stammt aus dem unionfs patch, und beinhaltet ja die ganze routine (die eh nur das file aufmacht). Nur macht es das scheinbar ins namei.c rein und das wird wohl nicht in den kernel gelinked oder kommt in ein anderes modul.

Im Text steht da das:

We are
+ currently introducing VFS changes to fs/namei.c's do_path_lookup() to
+ allow proper file lookup and opening in stackable file systems.

Und dannweiter unten eben der codeschnipsel:

diff --git a/fs/namei.c b/fs/namei.c
index 5008f01..411dbaa 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -492,6 +492,7 @@ void release_open_intent(struct nameidata *nd)
fput(file);
}
}

Nur wird das namei.c scheinbar nicht dazugelinked sonst wäre die routine ja nicht unknown.

ODER er linked sie in den Kernel den du in deinem OE baust und ich lade es dann gegen den standard kernel wo es eben nicht drinnen ist und dadurch kommen die symbol Fehler

Wenn das der Fall ist müsstest du auch das vmlinux als vmlinux.gz zippen und hier posten das bei dir mitgebaut wird und ich dann auf der box auch den kernel tauschen um zu sehen ob es dann nicht vieleicht eh auch geht zu dem kernel das module zu laden.

So habe ich ja auch immer gechecked ob das initramfs im Kernel auch funktioniert.

PS: du kannst aber vorher mit strings vmlinux | grep release_open_intent auch selber nachsehen ob die symbole in deinem kernel drinnen sind.

Jetzt habe ich einfach die commits abgesucht, der einzige wo das andere symbol vorkommt ist der commit:

http://osdir.com/ml/file-systems.unionfs…5/msg00602.html

Das müssten dann die 2 commits sein die uns das Leben schwer machen weil sich das unionfs drauf bezieht.

EDIT: mein OE ist erst bei der Hälfte der Buildsteps, ich denke das dauert noch bis morgen bevor ich wieder mitspielen kann.

Ja so mit kernel und module zusammen aus einem Build funktioniert das modprobe Prima.

Ich bedanke mich nochmals sehr !

Letztendlich hätte ich sowieso gerne das DMM uns den Patch fix ins OE einbindet, das alles Images gleich damit gebaut werden. Selbst wenn wir das nicht gleich bekommen werde ich jetzt mal OoZooN bitten uns den Patch fix in seine Images rein zu machen, genauso wie den initramfs patch (mein OE läuft auch wieder, also denke ich schaffe ich es auch den Patch heute noch fertig zu machen).

Und wenn das dann alles klaglos bei den Benutzern läuft dann denke ich nicht das DMM sich verschließen wird das unionfs als module in der defconfig fix vorzusehen. Sobald das der Fall wäre sollte auch kein anderes modul under dem Patch leiden denke ich mal, weil die dann alle entsprechend mitgebaut würden. Und da wir jetzt scheinbar eh mit dem Standard Patch auskommen sollte das eigentlich keine Probleme machen.

Die noch fehlenden unions-utils für 2.5.11 schaue ich das ich mir am Wochenende auch noch bauen kann, aber das schaffe ich leichter weil ich nicht die ganzen Kernel dependencies habe wo ich mich halt nicht wirklich auskenne.

Du darfst ja nicht vergessen das statt dem uralt 1.1* unionfs das wir im OE 1.6 verwenden mussten, indem wir das bitbake der 7025 vergewaltigt haben wir jetzt endlich den aktuellen patch für den aktuellen Kernel verwenden, womit das eigentlich sobald man Ihn richtig einbindet auch problemlos weiterhin funktionieren sollte.

Genau deswegeen hat DMM sich ja die Arbeit mit dem aktuellen Kernel gemacht um nicht immer mühsam backporten oder alte versionen verwenden zu müssen,also gilt das in diesem fall auch würde ich sagen.

Also erstmal nochmals Danke für die Unterstützung, mal sehen was ich draus am Wochenende so zaubern kann.

Kurzes Feedback noch - ich habe jetzt völlig problemlos so wie von Dr. Chaos gepostet das unionfs mit dem kernel mitgebaut, geht prima.

Evt. müsste einer noch ausprobieren ob das mit dem alten kernel 2.6.18 der alten 800er nicht auch bauen geht.

Weil ein diff für diese Kernelversion vom aktuellen 2.5.11 vom unionfs gibt es auch hier:

http://download.filesystems.org/unionfs/….6.18.8.diff.gz

Wenn wer ein OE für die alte 800er am Laufen hat bitte ausprobieren und berichten, dann steigt die Chance das die das auch bekommt und Freeze & Co wieder zu haben um den Flashspeicher erweitern zu können.

PS: Und mein initramfs zusammen mit dem unionfs baut jetzt auch schon im 2.0er OE, wenn auch noch ohne initramfs patch.

OH, da warst du aber fleissig :-)

Danke schön, weil dann können am Wochenende mehr Leute mitbasteln beim Flasherweitern mit ???.

Dann gehe ich schnell die aktuellen unionfs utils 2.1 compilieren, wenn ich glück habe ist das nur ein configure und make im squeeze auf der Dreambox selber.

Das war leicht, wir brauchen ja nur das unionctl binary, alles andere kann man ja mit dem mount machen :-)

So schlecht ist bei solchen Sachen der Ansatz auf der box gleich in mipsel zu compilieren nämlich nicht wenn man nur ein standalone binary braucht, und die nötigen libs sind im Debian mipsel squeeze meistens alle dabei.

Damit kann ich schon mal Mr. Freeze wieder zum laufen bringen im OE 2.0, weil der Rest des Plugins ist nur ein dummes Shellscript das sich alles beim booten zusammenmountet.

Wobei das unionctls sich seit 2007 nicht mehr geändert hat, es gäbe nur ein pre0.3 bei den sourcen aber ich gleube nicht dass das irgendwas kann was ich benötige.

PS: Und vor alle kenne ich beim compilieren auf der box schon fast alle Tricks wenn es mal doch nicht will.

PPS: Soll ich den Thread jetzt auf [gelöst] setzen oder machen wir das erst wenn uns DMM das unionfs auch gleich ins OE fix einbindet ?

LG
gutemine