Hallo, On Tue, 17 Sep 2002, Peter Meyer wrote:
Hae? Wie "ohne SCSI Controller"? Ausgebaut? oder nur Treiber weggelassen oder...?
Nein, neue Maschine (Notebook [mit IDE]) konfiguriert! ;-))
Achso.
Ich bin also wie folgt vorgegangen (Sorry, was folgt ist eine Art Protokoll für die spätere Doku und in Englisch, ich hoffe es ist auch verständlich):
copied the linux-2.4.19.tar.gz to /usr/src extracted linux-2.4.19.tar.gz in /usr/src mv /usr/src/linux-2.4.19 to /usr/src/linux-2.4.19a created link in /usr/src/linux to /usr/src/linux-2.4.19a
Hm. Da hast du evtl. was flasch gemacht, denn mind. bis incl. 2.4.18 sind die Kernel so getart, das sie nach 'linux' entpacken. Du hast also evtl. deinen alten Kernel ueberschrieben. Richtig waere:
Mit stellt sich das etwas anders dar: Laut SuSE Handbuch 7.3 "Die Referenz" (Seite 254) sei die Konfiguration des Kernels der Datei .config im Verzeichnis /usr/src/linux zu entnehmen. Nach meiner "Minimalen Installation mit Grafik" (7.3) gab es weder die Datei .config noch das Verzeichnis /usr/src/linux. Es gab lediglich /usr/src/, und dieses war -wenn ich mich recht entsinne- auch leer.
Das heisst (nur), dass du bisher keine Kernelquellen installiert hattest.
Wenn ich die Kernel-Quelle in einem beliebigen Verzeichnis entpacke, dann wird immer in ein Unterverzeichnis mit dem Namen linux-2.4.19 entpackt und nicht nach /usr/src.
Du solltest dich mal mit 'man tar' beschaeftigen ;) Tar arbeitet grundsaetzlich mit relativen Dateinamen.
Aus irgendeiner Quelle (auf die ich jetzt nicht mehr komme) wird geraten, nach entpacken der Kernel-Quelle einen Link /usr/src/linux auf /usr/src/linux-2.4.19 zu machen, in meinem Fall jedoch mit der zusätzlichen EXTRAVERSION "a". Daher die obige Vorgehensweise.
Die war in dem Fall auch korrekt. Haettest du aber schon die 2.4.10er Quellen in /usr/src/linux gehabt, dann gilt mein Kommentar dazu, denn in dem Fall haettest du die "alten" Kernelquellen ueberschrieben...
Ob ich den alten Kernel überschrieben habe, kann ich nicht ganz beurteilen.
Wenn das Verzeichnis /usr/src/linux leer war (oder nicht existierte), dann ist alles in Ordnung.
Was ich jedoch mit Gewissheit behaupten kann, ist, dass der alte Kernel über lilo.conf wie u.a. noch einwandfrei startet.
Gut. Das ist ja u.a. der Sinn der ganzen Aktion mit der Extraversion ;)
cd /usr/src test -d linux && mv linux linux-`uname -r` ## a) bisheriges Kernel-dir ## umbenennen
Das wäre bei mir also fehlgeschlagen!!!
test -L linux && rm linux ## b) symlink loeschen
es gab hier auch keinen Link, also wäre dieser Befehl fehlgeschlagen
Jep. Obiges geht davon aus, dass a) ein Verzeichnis oder ein symlink auf schon installierte Kernelquellen vorhanden ist, die zuerst mal "weg" sollen ;) In deinem Fall, war das also ueberfluessig. Das wird aber wohl dann fuer die naechsten Kernel gelten, die du wohl irgendwann bald backen wollen wirst, dann gilt's den symlink umzusetzen ;)
tar xzf PFAD/linux-<neue-version> ## tar auspacken
gut, das wäre eine Vereinfachung gewesen
s.o. man tar (*scnr*)
mv linux linux-<neue-version> ## umbenennen
Unnötig, da das entpackte Verzeichnis bereits linux-2.4.19 heisst
Das ist ungewoehnlich, mindestens bis inklusive 2.4.18 wurde der (ungepatchte) Kernel (also der von kernel.org) immer so eingepackt, dass er nach 'linux' entpackt wird, daher obiges Vorgehen. Wenn das Verzeichnis in das entpackt wird 'linux-<version>' heisst ist das natuerlich nicht noetig. Apropos: woher hast du die Kernelquellen?
ln -s linux-<neue-version> linux ## verlinken
hatte ich ja gemacht, halt nur mir der EXTRAVERSION "a", also ln -s linux-2.4.19a linux
Ok.
discommented line "export INSTALL_PATH=/boot" in Makefile
Wieso das? Solange man nicht 'make lilo' oder 'make bzlio' verwendet stoert die Definition der Variablen...
Sorry, wusste ich nicht. Ich bin nur dem Tipp des SuSE Handbuchs 7.3 "Die Referenz" (Seite 256) gefolgt, da ist keine Rede von 'make lilo' oder 'make bzlio' in diesem Zusammenhang.
Nicht? Hm. Find ich sogar gut ;) Denn wenn das zweimal mit einem nicht bootbaren Kernel gemacht wird... Das laeuft aber eh dem von mir beschriebenen Schema der Kernel-benennung zuwieder...
let run make oldconfig in case of no .config is available
Ist das ein Kommentar?
Durch den Befehl 'make oldconfig' konnte ich endlich über .config verfügen, die ja ursprünglich nicht da war.
Klar. IIRC bring das make (wie unten) erst nach dem 'zcat /proc/config.gz' etwas... Ich meinte ob das ein Kommentar von dir zum folgenden Vorgehen war...
zcat /proc/config.gz .config make oldconfig
[..]
mv /boot/vmlinuz /boot/vmlinz-2.4.10-4GB (altes Image gesichert)
Ist dann evtl. ein 'mk_initrd' fuer diesen Kernel noetig?
Das weiss ich eben auch nicht!!!
Nach dem unten von dir geschriebenem kann ich schonmal sagen: "ja, ist es".
Ich denke 'mk_initrd' bezieht sich irgendwie auch auf SCSI Controller und ReiserFS.
Nein, mk_initrd ist ein script, dass es bequemer macht, eine initrd zu erzeugen. Die "initrd" ist die "Initial Ramdisk", die es ermoeglicht, Kernelmodule die zum booten benoetigt werden zu laden, welche aber als Modul kompiliert wurden. Die Module der initrd werden also beim booten, noch bevor die Festplatte ansprechbar ist zum Kernel dazugeladen. Somit ist es moeglich z.B. den Festplattentreiber als Modul zu kompilieren. Ich muss aber deutlich sagen, dass ich das bei einem fuer einen bestimmten Rechner (selbst)kompilierten Kernel fuer ziemlichen Unfug halte. Fuer einen Distributionskernel, der auf moeglichst _vielen_ Rechnern laufen soll ist die initrd hingegen die Rettung vor dem kompilieren von Kernels fuer dutzende Rechner.
Hab jetzt nochmal die Doku durchgeschaut. Hier muss der Fehler liegen. Siehe unten.
Ja.
Ja, ich sollte wohl mal mehr zur initrd schreiben...
Ja bitte! ;-))
Das Problem: ich kenne mk_initrd / initrd praktisch nicht. Ich weiss praktisch nur obiges, naemlich dass ich die initrd nicht brauche. :)
Wie erstelle ich denn eine initrd? Ich dachte ich könnte für mein vmlinuz-2.4.19a auch /boot/initrd nehmen und hab mit 'mk_inird -k "vmlinuz-2.4.19a" -i "initrd"' versucht. Leider erfolglos. Jetzt konnte ich weder "vmlinuz-2.4.19a" noch "vmlinuz-2.4.10-4GB" starten. Über "failsafe" bin ich wieder rein gekommen und konnte mit 'mk_inird -k "vmlinuz-2.4.10-4GB" -i "initrd"' die ganze Sache rückgängig machen und nun läuft das Original Linux "vmlinuz-2.4.10-4GB" wieder.
Dazu hat Christoph ja schon geschrieben. Du brauchst fuer jeden Kernel eine eigene initrd, da die darin enthaltenen Module ja Kernelspezifisch sind. Verwende also fuer den neuen Kernel mk_initrd -k "vmlinuz-2.4.19a" -i "initrd-2.4.19a" oder besser noch: mk_initrd -k "vmlinuz-2.4.19a" -i "initrd-2.4.19a" \ -m "<die Module die du zum booten brauchst>"
Ich habe doch ursprünglich die alte Konfiguration übernommen (zcat /proc/config.gz .config und make oldconfig), d.h. doch auch die gleichen Module und festeingebundenen Treiber wie im Original Kernel. Warum kommt der neue Kernel dann nicht mit der "/boot/initrd" zurecht?
Weil die in dieser initrd enthaltenen Module nicht zum neuen Kernel passen (und andersrum).
Auch die initrd musst du fuer jeden Kernel erstellen -- besser aber, du laesst die initrd fuer den neuen Kernel ganz weg, d.h. alles zum booten noetige fest in den Kernel und den Rest dann als Modul.
Wei ermittele ich, was alles "noetig" ist für den Kernel?
Das was du zum booten brauchst, kurz: alle Module die bisher in der initrd sind (also u.a. Festplattentreiber usw. und Dateisysteme). Die bisherverwendeten Module sollten sich in der /etc/rc.config bzw. /etc/sysconfig/kernel in der Variablen 'INITRD_MODULES' finden (sind aber evtl. zu viele ;) Diese Module werden verwendet, wenn du mk_initrd nicht via -m direkt welche angibst, fallst du mehr/andere/weniger als diese brauchst, dann gibt die benoetigten direkt via -m "modul ..." dem mk_initrd-script mit (s.o.). -dnh -- Sehr gehrter Damen und Herren, ich bitte, auf weitere Zusendungen bez. "newsgroups" zu verzichten [Ernst-Ludwig Becker in dnq]