[gelöst] fakeroot Problem bei Kompilieren des ds-0.2.9_26-14.1 auf NFS mount?

zoolook · 4 Apr 2007

Hallo,

im ds-0.2.9_26-14 Thread las ich daß der Mod nun doch mit der FritzBox Fon WLAN 7050 geht, und habe es versucht, ihn zu bauen, mit der fritz.box_fon_wlan_7050.14.04.31.image und den beiden Patches die zum Anfang des Threads auch zum Download angeboten werden. Da ich den benötigten Platz auf keiner lokalen Linux-Partition habe, verwende ich einen NFS mount von meinem NAS. Ich erhalte leider nach

Code:

make menuconfig
make precompiled
make

ganze Bildschirme von

Code:

...
chown: changing ownership of `build/modified/filesystem/mod': Operation not permitted
chown: changing ownership of `build/modified/filesystem/var.tar': Operation not permitted
chown: changing ownership of `build/modified/filesystem': Operation not permitted

und am Ende dann

Code:

merging kernel image
ERROR: kernel image is 863232 bytes too big
make: *** [firmware] Error 1

kriegaex meinte, es könnte ein Problem mit fakeroot am NFS mount dafür verantwortlich sein, also bin ich seiner Bitte gefolgt, damit nun diesen neuen Thread zu öffnen:

kriegaex schrieb:
@zoolook: Mein DS-Mod benötigt mit selbst genauten Toolchains ca. 3,6 GB, aber ich baue nicht alle Pakete, das könnte also zwischen 3 und 4 GB schwanken.

Bevor Du die Umräumaktion startest, würde ich gern noch was probieren mit Fakeroot, damit wir alle was lernen. Mach mal bitte einen neuen Thread auf mit der Chown-Fehlermeldung, dann reden wir dort weiter. Ich sage Dir, was Du probieren kannst. Ursachen zu erkennen ist besser als nur Symptome zu beseitigen.

kriegaex · 4 Apr 2007

So, es hat ein Weilchen gedauert, es gab noch andere Anfragen. Versuch doch mal, manuell ein bißchen mit fakeroot auf Deinem NFS-Mount herumzuspielen, am besten im DS-Mod-Basisverzeichnis. Kriegst Du ähnliche Fehler, wenn Du das eingibst?

Edit: Sorry, da hat die Hälfte gefehlt:

Code:

cd <DS-Mod-Basisverzeichnis auf NFS-Mount>
tools/usr/bin/fakeroot

# Befehlszeilen-Prompt zeigt, daß Du jetzt (fake)root bist

# Herumspielen
mkdir _x
touch _x/abc
chown -R root:root _x

# Nicht vergessen, fakeroot wieder zu verlassen
exit

zoolook · 4 Apr 2007

kriegaex schrieb:
So, es hat ein Weilchen gedauert, es gab noch andere Anfragen.

Kein Problem, bin eh' auf Arbeit, voll beschäftigt. Nun, ich habe aber via ssh das auprobiert, und tatsächlich, die gleiche Fehlermeldung im fakeroot:

Code:

blues _ds-0.2.9_26-14.1 # chown -R root:root _x
chown: changing ownership of `_x/abc': Operation not permitted
chown: changing ownership of `_x': Operation not permitted

Merkwürdigerweise gehören aber sowohl das Verzeichnis _x als auch die Datei abc bereits vor dem Aufruf von chown root:root (ich meine, merkwürdig, daß dann überhaupt chown aufgerufen werden sollte). Nach Verlassen von fakeroot gehört alles wieder meinem User.

kriegaex · 4 Apr 2007

Ja, das beobachte ich bei mir auch, daß alles sowieso schon root:root gehört. Deswegen funktioniert der Build vermutlich auch, wenn man im Skript fwmod die Chroot-Zeile auskommentiert, aber trotzdem wäre es wichtig herauszufinden, wie man das Chroot innerhalb von Fakeroot, das ja bestimmt irgendeinen Zweck hat, auch auf NFS-Mounts zum Laufen bringen könnte. Vielleicht gibt es in Dokus oder Mailinglisten einen Hinweis darauf. Vorerst als Workaround kannst Du ja mal nach dieser Zeile suchen und durch Voranstellen eines #-Zeichens am Anfang deaktivieren:

Code:

echo "chown -R root:root $FILESYSTEM_MOD_DIR" >> _fakeroot

kriegaex · 4 Apr 2007

Bevor ich es vergesse und bevor wir es pauschal auf NFS schieben: Mach den gleichen Test mal auf einem lokalen Festplattenbereich (der Pfad zu Fakeroot muß korrekt sein, nimm das aus dem DS-Mod, wie zuvor).

zoolook · 4 Apr 2007

kriegaex schrieb:
...
Fakeroot, das ja bestimmt irgendeinen Zweck hat, auch auf NFS-Mounts zum Laufen bringen könnte. Vielleicht gibt es in Dokus oder Mailinglisten einen Hinweis darauf. Vorerst als Workaround kannst Du ja mal nach dieser Zeile suchen und durch Voranstellen eines #-Zeichens am Anfang deaktivieren:

Code:

echo "chown -R root:root $FILESYSTEM_MOD_DIR" >> _fakeroot

Vielleicht hat es den Zweck, daß man chown auf alles Dateien und Verzeichnisse aus dem zukünftigen firmware image überhaupt aufrufen kann, damit sie mit richtigem uid:gid auf die Fritzbox landen. Vielleicht ist es auch nicht ratsam zu probieren was pasiert, wenn man so ein image flasht, was wenn dann die box nicht mal mehr bootet?

kriegaex schrieb:
Bevor ich es vergesse und bevor wir es pauschal auf NFS schieben: Mach den gleichen Test mal auf einem lokalen Festplattenbereich (der Pfad zu Fakeroot muß korrekt sein, nimm das aus dem DS-Mod, wie zuvor).

Leider beobachte ich das gleiche Verhalten auch unter einem lokalen Verzeichnis. Kann's denn mit meinem chown zu tun haben? Ich benutze Gentoo, chown ist aus

Code:

sys-apps/coreutils-6.7-r1

kriegaex · 4 Apr 2007

Aha, also kein NFS-Problem. Das ist eine wertvolle Information. Aus der Man-Page von Fakeroot:

Code:

LIMITATIONS
    Library versions
        Every command executed within fakeroot needs to be
        linked to the same version of the C library as fakeroot itself.

    open()/create()
        fakeroot doesn't wrap open(), create(), etc.

Das sind zwei mögliche Gründe für Probleme. Möglicherweise ist Dein Chown ja gegen eine andere Version der glibc kompiliert worden als Fakeroot. Oder Dein Chroot verwendet open(). Ich tippe eher auf Ersteres, aber das ist natürlich spekulativ.

Ich denke im Übrigen nicht, daß Du Dir die Box zerschießt, denn Fakeroot nimmt ja standardmäßig sowieso an, daß alle Dateien root:root gehören, solange man nicht den Parameter -u angibt beim Start, und das tun wir ja nicht. Schlimmstenfalls wäre ein Recover fällig, was ja kein Problem wäre. Aber ich bin nach Lektüre der Man-Page inzwischen zu dem Schluß gelangt, daß dieser Chown-Befehl überflüssig ist, auch wenn es schade ist, daß er nicht überall funktionieren würde, wenn man ihn wirklich bräuchte. Kannst ja nochmal schauen, wie das mit den Libs ist, speziell mit der glibc.

kriegaex · 4 Apr 2007

Noch ein Vorschlag: Kannst ja mal versuchen, Fakeroot 1.6.5 statt 1.5.8 zu bauen und anstelle der älteren Version zu verwenden. Dann nochmal testen und sagen, ob das was ändert. Wenn das ginge, wüßten wir, daß es nicht an der glibc-Version liegt, sondern an der Fakeroot-Version.

Edit: http://packages.debian.org/unstable/utils/fakeroot, hätte ich fast vergessen.

zoolook · 4 Apr 2007

kriegaex schrieb:
Noch ein Vorschlag: Kannst ja mal versuchen, Fakeroot 1.6.5 statt 1.5.8 zu bauen und anstelle der älteren Version zu verwenden. Dann nochmal testen und sagen, ob das was ändert. Wenn das ginge, wüßten wir, daß es nicht an der glibc-Version liegt, sondern an der Fakeroot-Version.

Edit: http://packages.debian.org/unstable/utils/fakeroot, hätte ich fast vergessen.

Tja, ich habe beide fakeroot Versionen ausprobiert (waren beide auch in Gentoo als ebuild verfügbar, also kompilierte ich sie gegen die glibc meines systems, glibc-2.5), leider mit dem gleichen Ergebnis. Ist ja ganz verrückt, wird's denn wohl die glibc-Version sein?
Naja, jedenfalls, wenn ich die chown-Zeile auskommentiere, ist das Ergebnis dasselbe:

Code:

...
STEP 3: PACK
packing var.tar
creating filesystem image
merging kernel image
ERROR: kernel image is 863232 bytes too big

Möglicherweise kann es auch nicht anders sein, wird denn der Kernel, der da ge-merged wird nicht schon im make precompiled-Schritt erstellt?

kriegaex · 5 Apr 2007

Danke fürs Testen. Da würde als nächstes nur noch gdb als Prüfmöglichkeit bleiben, um zu sehen, was da passiert. Evtl. als Zwischenstufe vorher noch strace und/oder ltrace, möglicherweise sieht man dort auch was. Den Fehler mal in der Mailingliste von Fakeroot zu melden, wäre auch eine gute Idee.

Daß das eine nichts mit dem anderen Problem (zu großes Image) zu tun hat, hatte ich aber schon klargestellt, ich hoffe, Du hattest nicht damit gerechnet, daß es was bringen würde. :noidea:

zoolook · 5 Apr 2007

kriegaex schrieb:
Danke fürs Testen. Da würde als nächstes nur noch gdb als Prüfmöglichkeit bleiben, um zu sehen, was da passiert. Evtl. als Zwischenstufe vorher noch strace und/oder ltrace, möglicherweise sieht man dort auch was. Den Fehler mal in der Mailingliste von Fakeroot zu melden, wäre auch eine gute Idee.

Ja, werde bei Gelegenheit, wenn ich wieder mal ein bisschen mehr Zeit finde, es versuchen.

kriegaex schrieb:
Daß das eine nichts mit dem anderen Problem (zu großes Image) zu tun hat, hatte ich aber schon klargestellt, ich hoffe, Du hattest nicht damit gerechnet, daß es was bringen würde. :noidea:

Naja, so ganz habe ich nicht damit gerechnet, stimmt. Mich verwundert's dennoch, daß ich nichts Ähnliches im Forum gefunden habe, ich meine zu großen Kernel image, immer nur zu großes Firmware image

.

kriegaex · 5 Apr 2007

Hm, poste doch mal den Fehler mit dem zu großen Kernel extra mit sprechendem Titel, vielleicht liest es jemand, der Dir helfen kann. Hier vermutet man diesen Fehler nicht laut Überschrift. Am besten postest Du noch Deine .config als Anhang (nicht unbedingt als Zitat).

Das wäre mein einziger Tip, der mir dazu einfällt: Baust Du einen eigenen Kernel? Es sieht wohl so aus, denn der Original-Kernel der Firmware war ja vorher nicht zu groß, das wäre eine Erklärung dafür, daß er (der neue) es jetzt ist. Wozu baust Du überhaupt einen eigenen Kernel? Das ist für die allermeisten Anwendungen unnötig.

kriegaex · 5 Apr 2007

Mögliches Fakeroot-Problem mit glibc6 >=2.4 und coreutils >=6

Aha, es könnte sein, daß wir der Sache auf die Schliche kommen. Lies mal diesen Mailinglisten-Artikel: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-October/000891.html

Eine mögliche Erklärung dafür, daß ich das Problem nicht habe, ist, daß Ubuntu 6.10 die Paketversionen libc6-2.4 und coreutils-5.96-5 verwendet, also eine Kombination, die laut jenem Artikel gehen sollte.

Du hingegen verwendest libc6-2.5 und coreutils-6.7-r1, also eine Version, bei der es scheppern sollte (und auch tut), weil standardmäßig das neue, nicht von Fakeroot gewrappte *at() verwendet wird, u.a. auch durch chown.

Also entweder baust Du die Coreutils mit ./configure ac_cv_func_openat=no oder wartest auf einen Bugfix in einer neueren Fakeroot-Version. Ich hatte gehofft, die 1.6.5 würde es bringen, aber Du sagst ja, daß das nichts ändert.

Könntest Du mir den Gefallen tun, Coreutils mal mit o.g. Configure-Aufruf zu bauen und damit Fakeroot zu testen?

Update: Ich habe einen möglicherweise heilbringenden Patch für fakeroot-1.5.10 entdeckt. Ich werde mal sehen, ob ich die Version hier bauen kann und schicke Dir dann Makefile und Patch zum Testen. Drück mir die Daumen!

Update 2: Neue Version und Patch funktionieren bei mir, aber das ist ja nicht erstaunlich, es ging bei mir ja schon vorher. Du kriegst eine PM mit einem Download-Link zum Testen. Wenn das Dein Problem löst, checke ich es ein.

zoolook · 5 Apr 2007

Hi Alex, hast PM von mir, zum Fakeroot-Bug.

kriegaex schrieb:
Hm, poste doch mal den Fehler mit dem zu großen Kernel extra mit sprechendem Titel, vielleicht liest es jemand, der Dir helfen kann. Hier vermutet man diesen Fehler nicht laut Überschrift. Am besten postest Du noch Deine .config als Anhang (nicht unbedingt als Zitat).

Tja, werde ich wohl machen, wenn ich jetzt nicht selber herausfinde, wieso überhaupt es dazu kommen muß, denn wie ich im Folgenden sehe, ist es nicht nötig, den Kernel neu zu bauen...

kriegaex schrieb:
Das wäre mein einziger Tip, der mir dazu einfällt: Baust Du einen eigenen Kernel? Es sieht wohl so aus, denn der Original-Kernel der Firmware war ja vorher nicht zu groß, das wäre eine Erklärung dafür, daß er (der neue) es jetzt ist. Wozu baust Du überhaupt einen eigenen Kernel? Das ist für die allermeisten Anwendungen unnötig.

Wie gesagt, bewußt habe ich keinen neuen Kernel bauen wollen, für mich ist dieser -2.6-er Mod zum ds-mod neu, ich dachte einfach, das ist nunmal so, daß der Kernel neu gebaut wird. Wahrscheinlich hat das irgendeine Auswahl, die ich in make menuconfig getroffen habe, das als Folge, muß mal sehen, und eventuell dann einen neuen Thread öffnen.

kriegaex · 5 Apr 2007

Problem mit chown gelöst, Thema abgeschlossen

Okay, was ich Dir geschickt hatte, funktioniert ja bei Dir, also habe ich es eingecheckt. Kommt im nächsten Patch oder im Zwischenrelease 14.2. Außerdem werde ich mit olistudent diskutieren, ob wir die unnötige Chown-Zeile, obwohl sie gefixt ist durch den neuen Patch, vielleicht trotzdem mal raus nehmen, denn es ist ja laut Man-Page definitiv so, daß Fakeroot nach dem Start sowieso alles dem Benutzer root:root zuordnet, sofern nicht durch irgendwelche (von uns nicht benutzten) Parameter etwas anderes explizit gefordert wird.

Edit: Zoolook, würdest Du bitte den Titel des Threads durch erweitertes Editieren der ersten Nachricht vorne mit "[Gelöst] " ergänzen?

Languages

Suche

Languages

Suche

[gelöst] fakeroot Problem bei Kompilieren des ds-0.2.9_26-14.1 auf NFS mount?

zoolook

Neuer User

kriegaex

Aktives Mitglied

zoolook

Neuer User

kriegaex

Aktives Mitglied

kriegaex

Aktives Mitglied

zoolook

Neuer User

kriegaex

Aktives Mitglied

kriegaex

Aktives Mitglied

zoolook

Neuer User

kriegaex

Aktives Mitglied

zoolook

Neuer User

kriegaex

Aktives Mitglied

kriegaex

Aktives Mitglied

zoolook

Neuer User

kriegaex

Aktives Mitglied

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums