Kernel kompilieren nach Thomas Hertweck
Hallo zusammen Ich wollt nach dem Kernel HowTo von Thomas Hertweck [1] mir einen neuen Kernel kompilieren. Ich habs auf das Folgende reduziert: $> 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 $> make O=/usr/src/linux-2.6.18-0.1-star-obj modules_prepare $> vi Makefile Geändert auf 'EXTRAVERSION = -0.1-star'. Ohne dashes in EXTRAVERSION sieht zwar der Kernelname besser aus, das Ganze endet aber gleich. $> cd ../linux-2.6.18-0.1-star-obj/ $> make binrpm-pkg Nachdem es eine ganze Weile kopiliert, endet es mit diesem Fehler: [...] CC sound/usb/usx2y/snd-usb-usx2y.mod.o LD [M] sound/usb/usx2y/snd-usb-usx2y.ko set -e; \ /bin/sh /usr/src/linux-2.6.18/scripts/mkversion > /usr/src/linux-2.6.18-0.1-star-obj/.tmp_version set -e; \ mv -f /usr/src/linux-2.6.18-0.1-star-obj/.tmp_version /usr/src/linux-2.6.18-0.1-star-obj/.version rpmbuild --define "_builddir /usr/src/linux-2.6.18" --target x86_64 -bb /usr/src/linux-2.6.18-0.1-star-obj/binkernel.spec Building target platforms: x86_64 Building for target x86_64 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.36475 + umask 022 + cd /usr/src/linux-2.6.18 + /bin/rm -rf /var/tmp/kernel-2.6.180.1starsmp-root ++ dirname /var/tmp/kernel-2.6.180.1starsmp-root + /bin/mkdir -p /var/tmp + /bin/mkdir /var/tmp/kernel-2.6.180.1starsmp-root + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.36475 + umask 022 + cd /usr/src/linux-2.6.18 + mkdir -p /var/tmp/kernel-2.6.180.1starsmp-root/boot /var/tmp/kernel-2.6.180.1starsmp-root/lib /var/tmp/kernel-2.6.180.1starsmp-root/lib/modules + INSTALL_MOD_PATH=/var/tmp/kernel-2.6.180.1starsmp-root + make -j2 modules_install HOSTCC scripts/basic/fixdep GEN /usr/src/linux-2.6.18/Makefile HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o HOSTCC scripts/kconfig/mconf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf 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 make[5]: *** [silentoldconfig] Fehler 2 make[4]: *** [include/config/auto.conf] Fehler 2 error: Bad exit status from /var/tmp/rpm-tmp.36475 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.36475 (%install) make[3]: *** [binrpm-pkg] Fehler 1 make[2]: *** [binrpm-pkg] Fehler 2 make[1]: *** [binrpm-pkg] Fehler 2 make: *** [binrpm-pkg] Fehler 2 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 make[860]: *** [mproper] Unterbrechung make[859]: *** [mproper] Unterbrechung make[858]: *** [mproper] Unterbrechung make[857]: *** [mproper] Unterbrechung make[856]: *** [mproper] Unterbrechung [...] make[1]: *** [mproper] Unterbrechung make: *** [mproper] Unterbrechung $> Wo hab ich den Fehler gemacht? Gruss Jürg [1]http://www.thomashertweck.de/kernel26.html
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.
Hi Thomas Thomas Hertweck schrieb:
Juerg Schneider wrote:
/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
Aeh, ja, sorry, ich hatte anfangs auch oldconfig. Zum weiteren Testen hab ichs automatisiert. Erzeugt oldconfig eigentlich nur die .config oder werden noch andere Files geaendert?
$> 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.
Ich hab Dein HowTo jetzt nochmals gelesen. Nach meinem Gefühl geht das nicht daraus hervor.
$> vi Makefile
Geändert auf 'EXTRAVERSION = -0.1-star'. Ohne dashes in EXTRAVERSION sieht zwar der Kernelname besser aus, das Ganze endet aber gleich.
Nicht der Kernelname sieht besser aus, nur temporaere Dateien in /tmp werden ohne die dashes geschrieben. Der Kernel hat sie wieder.
Das solltest vor einem "modules_prepare" ausgefuehrt werden und ist ebenfalls nur noetig, wenn man einen eigenen Kernel mit eindeutiger Release compilieren will.
Oh ja. Meine Kernel haben den Namen der Maschine drin. Sonst krieg ich ein 'puff'.
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.
Geht meiner Meinung nach auch nicht hervor.
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.
Hat es. UTS_RELEASE in utsrelease.h ist richtig.
Will man lediglich eine alte Konfig klonen, um z.B. weitere Kernelmodule zu uebersetzen, darf die EXTRAVERSION nicht geaendert werden.
Ich würde die eins hochzählen. Nur neue Module schaden wahrscheinlich nicht, aber einmal von Modul auf 'fest drin' vielleicht schon.
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...
Ok. Aber was meinst Du mit rudimentaer? Werden die SUSE Kernel nicht mit 'make rpm-pkg' gebaut?
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 hab ihn mal ganz normal ohne Build-Directory und ohne RPM gebaut. Debian Kernel mach schon lange als DEB, das wäre mein erster RPM Kernel geworden. Das mit den spec Files wird eine groessere Sache.
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.
Wenn ich helfen kann... Gruss Juerg
Juerg Schneider wrote:
[...] Aeh, ja, sorry, ich hatte anfangs auch oldconfig. Zum weiteren Testen hab ichs automatisiert. Erzeugt oldconfig eigentlich nur die .config oder werden noch andere Files geaendert?
Die .config wird nicht wirklich neu erzeugt, da Du vorher ja schon eine Datei an die korrekte Stelle kopiert hast (per zcat-Befehl). Durch oldconfig wird diese vorhandene .config Datei umbenannt und alle Symbole, die daraus fuer die Konfiguration des neuen Kernels uebernommen werden koennen, werden dann in die neue .config uebertragen, zu allen bisher nicht definierten Symbolen (vermutlich neue Features des Kernels) wirst Du gefragt, ob und ggf. wie Du sie implementiert haben moechtest (fest eincompiliert oder als Modul). In diesem Zusammenhang werden im Build-Directory dann noch weitere Dateien und Verzeichnisse angelegt.
[...]
Will man lediglich eine alte Konfig klonen, um z.B. weitere Kernelmodule zu uebersetzen, darf die EXTRAVERSION nicht geaendert werden.
Ich würde die eins hochzählen. Nur neue Module schaden wahrscheinlich nicht, aber einmal von Modul auf 'fest drin' vielleicht schon.
Nein. Wenn Du fuer einen bereits installierten Kernel weitere Module bauen willst, so musst Du genau die Versionsangabe des existierenden Kernels uebernehmen - es darf kein Zaehler hochgesetzt werden! Ansonsten baust Du ja dann externe Module mit einer falschen Release. Nur wenn Du einen kompletten Kernel neu compilieren willst, solltest Du auch dafuer sorgen, dass er eine eindeutige Release-Nummer bekommt.
[...] Ok. Aber was meinst Du mit rudimentaer? Werden die SUSE Kernel nicht mit 'make rpm-pkg' gebaut?
SUSE's .spec File ist ein wenig ausgereifter.
[...] Ich hab ihn mal ganz normal ohne Build-Directory und ohne RPM gebaut. Debian Kernel mach schon lange als DEB, das wäre mein erster RPM Kernel geworden. Das mit den spec Files wird eine groessere Sache.
Wenn Du kein Build-Directory verwendest, muesste auch der Bau eines RPMs funktionieren. Zum Howto nochmal allgemein: es ist praktisch unmoeglich, alle Eventualitaeten und Kleinigkeiten im Detail zu behandeln - insofern magst Du mit einem "das geht aber nicht explizit aus dem Howto hervor" durchaus recht haben. Es sollte aber hoffentlich implizit daraus hervorgehen, wenn man versteht, was die einzelnen Befehle bewirken. Wenn das Feedback (und davon gibt es einiges) immer wieder die gleichen Verbesserungsvorschlaege bringt, dann aendere ich das Howto gerne ab und fuehre im aufgefuehrten Punkt mehr Detail ein, aber ansonsten ist es eher schwierig und man muss einen Mittelweg finden, um den Rahmen nicht komplett zu sprengen. Niemand will am Ende einen 100-seitigen Text durchlesen, da gaebe es dann auch "Beschwerden" ;-) Im Prinzip hast Du nichts falsch gemacht, insofern hat das Howto ja sein Ziel nicht verfehlt. Du bist lediglich IMO ueber einen Bug im Kernel Build System gestolpert, der beim Bau von RPMs unter Einsatz eines Build Directories auftritt. Cheers, Th.
Am Mittwoch, 4. Oktober 2006 20:33 schrieb Thomas Hertweck:
Juerg Schneider wrote: [...] Nein. Wenn Du fuer einen bereits installierten Kernel weitere Module bauen willst, so musst Du genau die Versionsangabe des existierenden Kernels uebernehmen - es darf kein Zaehler hochgesetzt werden! Ansonsten baust Du ja dann externe Module mit einer falschen Release. Nur wenn Du einen kompletten Kernel neu compilieren willst, solltest Du auch dafuer sorgen, dass er eine eindeutige Release-Nummer bekommt.
Ok. Liegt wohl daran, dass ich das noch nie gemacht hab 'nur neue Module' kompilieren.
Ok. Aber was meinst Du mit rudimentaer? Werden die SUSE Kernel nicht mit 'make rpm-pkg' gebaut?
SUSE's .spec File ist ein wenig ausgereifter.
Das heisst: Die werden nicht mit 'make rpm-pkg' gebaut.
Niemand will am Ende einen 100-seitigen Text durchlesen, da gaebe es dann auch "Beschwerden" ;-)
*g* Ich werds nochmals versuchen. Zumindest meine Probleme mit der Uhr hab ich mit dem 2.6.18 Vanilla noch nicht beobachtet. Danke. Gruss Juerg
participants (2)
-
Juerg Schneider
-
Thomas Hertweck