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