Hallo! Juerg Schneider wrote:
[...] $> pwd /usr/src $> mkdir linux-2.6.18-0.1-star-obj/ $> tar -xf /home/jsc/NotBackuped/Kernel/linux-2.6.18.tar $> cd linux-2.6.18 $> zcat /proc/config.gz > /usr/src/linux-2.6.18-0.1-star-obj/.config $> make O=/usr/src/linux-2.6.18-0.1-star-obj allmodconfig
Das ist ein Widerspruch. Entweder kopierst Du eine alte Konfig mit Hilfe des zcat-Befehls und fuehrst danach zum Klonen ein $> make O=/usr/src/linux-2.6.18-0.1-star-obj oldconfig aus, oder Du generierst Dir direkt eine neue Standard-Konfig mit $> make O=/usr/src/linux-2.6.18-0.1-star-obj allmodconfig bei der dann alles moeglichst als Modul realisiert wird - in diesem Falle brauchst Du allerdings vorher den zcat-Befehl nicht! Die ueber "allmodconfig" erstellte Konfiguration ist aber nicht auf Dein System angepasst und sollte lediglich als Grundlage verwendet werden fuer eine eigene manuelle Konfiguration.
$> make O=/usr/src/linux-2.6.18-0.1-star-obj modules_prepare
Das kannst und solltest Du Dir sparen, wenn Du spaeter einen Kernel wirklich komplett compilieren willst. Es ist lediglich dazu da, benoetigte Header Files zu erstellen, die gebraucht werden, wenn man separat Kernelmodule uebersetzen will, aber keinen ganzen Kernel.
$> vi Makefile
Geändert auf 'EXTRAVERSION = -0.1-star'. Ohne dashes in EXTRAVERSION sieht zwar der Kernelname besser aus, das Ganze endet aber gleich.
Das solltest vor einem "modules_prepare" ausgefuehrt werden und ist ebenfalls nur noetig, wenn man einen eigenen Kernel mit eindeutiger Release compilieren will. In dem Falle, siehe oben, sollte dann aber eh kein "modules prepare" ausgefuehrt werden. Warum sollte es ggf. vor dem "modules_prepare" ausgefuehrt werden? Ganz einfach: durch den Befehl werden Header-Files erzeugt, z.B. utsrelease.h, in das auch die Variable EXTRAVERSION des Kernel-Makefiles eingeht. Wenn Du zuerst den Befehl ausfuehrst und dann das Makefile aenderst, wandert die Aenderung natuerlich zunaechst nicht in das entsprechende Header-File (leuchtet hoffentlich ein). Allerdings ist das Build-System AFAIK so schlau, dass es spaeter, wenn Du einen eigenen kompletten Kernel compiliert, Deine (nachtraegliche) Aenderung merkt und die entsprechenden Header-Files neu kreiert. Wenn Du das entsprechende Header File anschaust, sollte Deine EXTRAVERSION hoffentlich darin auftauchen. Will man lediglich eine alte Konfig klonen, um z.B. weitere Kernelmodule zu uebersetzen, darf die EXTRAVERSION nicht geaendert werden.
$> cd ../linux-2.6.18-0.1-star-obj/ $> make binrpm-pkg
Nachdem es eine ganze Weile kopiliert, endet es mit diesem Fehler:
[...] + cd /usr/src/linux-2.6.18 [...] scripts/kconfig/conf -s arch/x86_64/Kconfig *** *** You have not yet configured your kernel! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[6]: *** [silentoldconfig] Fehler 1
Das ist IMHO nicht Dein Fehler, sondern ein Bug des Kernel Build Systems!!! Der Kernel selbst kann mit Hilfe eines Build-Directories korrekt erstellt werden, aber der Bau eines RPMs durch ein "make binrpm-pkg" schlaegt bei Verwendung eines Build-Directories fehl! Normalerweise wird der Vanilla-Kernel nicht als RPM ausgeliefert, d.h. das Erstellen von rudimentaeren RPMs mit Hilfe des eingebauten Mechanismus ist wohl nicht besonders ausgereift und erprobt...
Ein anschliessendes Aufräumen lässt den Arbeitsspeicher in wenigen Sekunden vollaufen. Das folgende wurde nach einer Sekunde mit ^C abgebrochen:
$> make mproper [...] make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper make -C /usr/src/linux-2.6.18 O=/usr/src/linux-2.6.18 mproper
Das ist ein noch groesserer Bug in "make binrpm-pkg" bei Verwendung eines Build-Directories. Der Befehl hat das original Makefile im Verzeichnis mit den Kernel-Quellen durch das Makefile des Build-Directories ersetzt, was lediglich ein kurzes Wrapper-Makefile ist. Dadurch ruft sich durch jeden make-Befehl das Kernel-Makefile rekursiv selbst auf und forkt Prozesse, bis Dein Speicher ueberlaeuft. Das korrekte original Makefile des Source-Verzeichnisses ist uebrigens verloren. Empfehlung: bis auf die oben genannten kleineren Dinge hast Du nichts falsch gemacht. Loesche das Source-Verzeichnis des 2.6.18 sowie das Build-Verzeichnis - aufgrund oben genannten Problems musst Du die Quellen frisch entpacken. Wenn Du den Kernel als RPM bauen willst, dann hast Du nun zwei Moeglichkeiten: a) verzichte auf ein Build-Directory oder b) baue das RPM anhand z.B. eines SUSE Kernel-spec Files selbst. Oder verzichte eben auf den Bau eines RPMs und installiere den Kernel ganz normal, der neue zusaetzliche Kernel muss ja nicht unbedingt in der RPM Datenbank auftauchen. Ich hoffe, das hilft Dir weiter. Falls jemand meine Erklaerung hier nachvollziehen kann und evtl. die Zeit hat, das Problem noch weiter zu debuggen und herauszufinden, ob ich tatsaechlich richtig liege, muesste man ggf. einen Bug-Report einreichen, damit das Problem hoffentlich behoben wird. Cheers, Th.