
Linux-Kernel-Version 4.x http://kernel.org/
Dies sind die Versionshinweise für Linux-Version 4. Lesen Sie sie sorgfältig, denn sie erklären, worum es sich handelt, wie Sie den Kernel installieren und was Sie tun sollten, wenn etwas schiefgeht.
WAS IST LINUX?
Linux ist ein Klon des Betriebssystems Unix, der von Grund auf geschrieben wurde von Linus Torvalds mit Unterstützung eines locker verbundenen Teams von Hackern im Internet. Es zielt auf die Einhaltung von POSIX und der Single UNIX Specification ab.
Es verfügt über alle Funktionen, die man von einem modernen vollwertigen Unix erwartet, einschließlich echtem Multitasking, virtuellem Speicher, gemeinsamen Bibliotheken, Demand Loading, gemeinsam genutzten Copy-on-Write-Executables, ordentlicher Speicherverwaltung und Multistack-Netzwerkunterstützung einschließlich IPv4 und IPv6.
Es wird unter der GNU General Public License vertrieben – siehe die beiliegende Datei COPYING für weitere Details.
AUF WELCHER HARDWARE LÄUFT ES?
Obwohl es ursprünglich zuerst für 32-Bit-x86-PCs (386 oder höher) entwickelt wurde, läuft Linux heute auch auf (mindestens) den Architekturen Compaq Alpha AXP, Sun SPARC und UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, Xtensa, Tilera TILE, AVR32 und Renesas M32R.
Linux ist leicht auf die meisten Allzweck-32- oder 64-Bit-Architekturen portierbar, sofern sie über eine Paged Memory Management Unit (PMMU) und einen Port des GNU-C-Compilers (gcc) (Teil der GNU Compiler Collection, GCC) verfügen. Linux wurde auch auf eine Reihe von Architekturen ohne PMMU portiert, obwohl die Funktionalität dann offensichtlich etwas eingeschränkt ist. Linux wurde auch auf sich selbst portiert. Sie können den Kernel jetzt als Userspace-Anwendung ausführen – dies wird UserMode Linux (UML) genannt.
DOKUMENTATION:
Es gibt eine große Menge an Dokumentation, sowohl in elektronischer Form im Internet als auch in Büchern, sowohl Linux-spezifisch als auch zu allgemeinen UNIX-Fragen. Ich empfehle, in den Dokumentations-Unterverzeichnissen auf einer beliebigen Linux-FTP-Site nach den LDP-Büchern (Linux Documentation Project) zu suchen. Dieses README ist nicht als Dokumentation über das System gedacht: Es sind viel bessere Quellen verfügbar.
Im Unterverzeichnis Documentation/ gibt es verschiedene README-Dateien: Diese enthalten normalerweise kernel-spezifische Installationshinweise für einige Treiber, zum Beispiel. Siehe Documentation/00-INDEX für eine Liste dessen, was in jeder Datei enthalten ist. Bitte lesen Sie die Datei Changes, da sie Informationen über die Probleme enthält, die durch ein Upgrade Ihres Kernels entstehen können.
Das Unterverzeichnis Documentation/DocBook/ enthält mehrere Anleitungen für Kernel-Entwickler und -Benutzer. Diese Anleitungen können in verschiedenen Formaten ausgegeben werden: PostScript (.ps), PDF, HTML und man-pages, unter anderem. Nach der Installation rendern "make psdocs", "make pdfdocs", "make htmldocs" oder "make mandocs" die Dokumentation im gewünschten Format.
INSTALLATION DES KERNEL-QUELLCODES:
Wenn Sie den vollständigen Quellcode installieren, legen Sie das Kernel-Tarball in ein Verzeichnis, in dem Sie Schreibrechte haben (z.B. Ihr Home-Verzeichnis), und entpacken Sie es:
xz -cd linux-4.X.tar.xz | tar xvf -
Ersetzen Sie "X" durch die Versionsnummer des neuesten Kernels.
Verwenden Sie NICHT den Bereich /usr/src/linux! Dieser Bereich enthält einen (normalerweise unvollständigen) Satz von Kernel-Headern, die von den Library-Header-Dateien verwendet werden. Sie sollten zur Bibliothek passen und nicht durch den jeweiligen Kernel-des-Tages durcheinandergebracht werden.
Sie können auch zwischen 4.x-Versionen durch Patchen aktualisieren. Patches werden im xz-Format verteilt. Um per Patchen zu installieren, besorgen Sie sich alle neueren Patch-Dateien, wechseln Sie in das oberste Verzeichnis des Kernel-Quellcodes (linux-4.X) und führen Sie aus:
xz -cd ../patch-4.x.xz | patch -p1
Ersetzen Sie "x" für alle Versionen, die größer sind als die Version "X" Ihres aktuellen Quellcode-Baums, der Reihe nach, und alles sollte in Ordnung sein. Möglicherweise möchten Sie die Sicherungsdateien (some-file-name~ oder some-file-name.orig) entfernen und sicherstellen, dass keine fehlgeschlagenen Patches vorhanden sind (some-file-name# oder some-file-name.rej). Falls welche vorhanden sind, haben entweder Sie oder ich einen Fehler gemacht.
Im Gegensatz zu Patches für die 4.x-Kernel sind Patches für die 4.x.y-Kernel (auch als -stable-Kernel bekannt) nicht inkrementell, sondern werden direkt auf den Basis-4.x-Kernel angewendet. Wenn Ihr Basiskernel beispielsweise 4.0 ist und Sie den 4.0.3-Patch anwenden möchten, dürfen Sie nicht zuerst die 4.0.1- und 4.0.2-Patches anwenden. Wenn Sie Kernel-Version 4.0.2 ausführen und auf 4.0.3 wechseln möchten, müssen Sie zuerst den 4.0.2-Patch zurücknehmen (d.h. patch -R) bevor Sie den 4.0.3-Patch anwenden. Weitere Informationen dazu finden Sie in Documentation/applying-patches.txt
Alternativ kann das Skript patch-kernel verwendet werden, um diesen Prozess zu automatisieren. Es ermittelt die aktuelle Kernel-Version und wendet alle gefundenen Patches an.
linux/scripts/patch-kernel linux
Das erste Argument im obigen Befehl ist der Speicherort des Kernel-Quellcodes. Patches werden aus dem aktuellen Verzeichnis angewendet, aber ein alternatives Verzeichnis kann als zweites Argument angegeben werden.
Stellen Sie sicher, dass keine veralteten .o-Dateien und Abhängigkeiten herumliegen:
cd linux make mrproper
Sie sollten nun die Quellen korrekt installiert haben.
SOFTWARE-ANFORDERUNGEN
Das Kompilieren und Ausführen der 4.x-Kernel erfordert aktuelle Versionen verschiedener Softwarepakete. Konsultieren Sie Documentation/Changes für die erforderlichen Mindestversionsnummern und wie Sie Updates für diese Pakete erhalten. Seien Sie sich bewusst, dass die Verwendung übermäßig alter Versionen dieser Pakete indirekte Fehler verursachen kann, die nur sehr schwer aufzuspüren sind. Gehen Sie also nicht davon aus, dass Sie Pakete einfach aktualisieren können, wenn während des Builds oder des Betriebs offensichtliche Probleme auftreten.
BUILD-VERZEICHNIS für den Kernel:
Beim Kompilieren des Kernels werden standardmäßig alle Ausgabedateien zusammen mit dem Kernel-Quellcode gespeichert. Mit der Option "make O=output/dir" können Sie einen alternativen Ort für die Ausgabedateien (einschließlich .config) angeben. Beispiel:
Kernel-Quellcode: /usr/src/linux-4.X
Build-Verzeichnis: /home/name/build/kernel
Um den Kernel zu konfigurieren und zu bauen, verwenden Sie:
cd /usr/src/linux-4.X
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Bitte beachten Sie: Wenn die Option 'O=output/dir' verwendet wird, muss sie für alle Aufrufe von make verwendet werden.
KONFIGURATION DES KERNELS:
Überspringen Sie diesen Schritt nicht, auch wenn Sie nur eine Nebenversion aktualisieren. In jeder Version werden neue Konfigurationsoptionen hinzugefügt, und seltsame Probleme treten auf, wenn die Konfigurationsdateien nicht wie erwartet eingerichtet sind. Wenn Sie Ihre bestehende Konfiguration mit minimalem Aufwand auf eine neue Version übertragen möchten, verwenden Sie "make oldconfig", das Ihnen nur die Antworten auf neue Fragen abverlangt.
Alternative Konfigurationsbefehle sind:
"make config" Textbasierte Oberfläche.
"make menuconfig" Textbasierte Farbmenüs, Radiolisten und Dialoge.
"make nconfig" Erweiterte textbasierte Farbmenüs.
"make xconfig" Auf X-Windows (Qt) basierendes Konfigurationswerkzeug.
"make gconfig" Auf X-Windows (Gtk) basierendes Konfigurationswerkzeug.
"make oldconfig" Beantwortet alle Fragen standardmäßig anhand des Inhalts Ihrer bestehenden ./.config-Datei und fragt nach neuen Konfigurationssymbolen.
"make silentoldconfig" Wie oben, vermeidet jedoch, den Bildschirm mit bereits beantworteten Fragen zu überladen. Aktualisiert zusätzlich die Abhängigkeiten.
"make olddefconfig" Wie oben, setzt jedoch neue Symbole ohne Rückfrage auf ihre Standardwerte.
"make defconfig" Erstellt eine ./.config-Datei mithilfe der Standard- Symbolwerte entweder aus arch/$ARCH/defconfig oder arch/$ARCH/configs/${PLATFORM}_defconfig, abhängig von der Architektur.
"make ${PLATFORM}_defconfig" Erstellt eine ./.config-Datei mithilfe der Standard- Symbolwerte aus arch/$ARCH/configs/${PLATFORM}_defconfig. Verwenden Sie "make help", um eine Liste aller verfügbaren Plattformen Ihrer Architektur zu erhalten.
"make allyesconfig" Erstellt eine ./.config-Datei, indem die Symbol- Werte nach Möglichkeit auf 'y' gesetzt werden.
"make allmodconfig" Erstellt eine ./.config-Datei, indem die Symbol- Werte nach Möglichkeit auf 'm' gesetzt werden.
"make allnoconfig" Erstellt eine ./.config-Datei, indem die Symbol- Werte nach Möglichkeit auf 'n' gesetzt werden.
"make randconfig" Erstellt eine ./.config-Datei, indem die Symbol- Werte auf zufällige Werte gesetzt werden.
"make localmodconfig" Erstellt eine Konfiguration basierend auf der aktuellen Konfiguration und den geladenen Modulen (lsmod). Deaktiviert jede Modul- Option, die für die geladenen Module nicht benötigt wird.
Um eine localmodconfig für einen anderen Rechner zu erstellen,
speichern Sie das lsmod dieses Rechners in einer Datei
und übergeben Sie es als LSMOD-Parameter.
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod localmodconfig
Das Obige funktioniert auch beim Cross-Kompilieren.
KOMPILIEREN DES KERNELS:
Stellen Sie sicher, dass mindestens gcc 3.2 verfügbar ist. Weitere Informationen finden Sie in Documentation/Changes.
Bitte beachten Sie, dass Sie mit diesem Kernel weiterhin a.out-Benutzerprogramme ausführen können.
Führen Sie "make" aus, um ein komprimiertes Kernel-Abbild zu erstellen. Es ist auch möglich, "make install" auszuführen, wenn Sie lilo passend zu den Kernel-Makefiles installiert haben, aber Sie sollten zuerst Ihre spezielle lilo-Konfiguration überprüfen.
Für die eigentliche Installation müssen Sie root sein, aber keiner der normalen Build-Schritte sollte das erfordern. Nehmen Sie den Namen root nicht vergeblich in den Mund.
Wenn Sie Teile des Kernels als `modules' konfiguriert haben, müssen Sie auch "make modules_install" ausführen.
Ausführliche Kernel-Kompilierungs-/Build-Ausgabe:
Normalerweise läuft das Kernel-Build-System in einem relativ ruhigen Modus (aber nicht völlig still). Manchmal müssen Sie oder andere Kernel-Entwickler jedoch die Kompilier-, Link- oder anderen Befehle genau so sehen, wie sie ausgeführt werden. Verwenden Sie dazu den "verbose"-Build-Modus. Dies geschieht durch Einfügen von "V=1" in den "make"-Befehl. Z.B.:
make V=1 all
Damit das Build-System auch den Grund für den Neubau jedes Ziels angibt, verwenden Sie "V=2". Der Standard ist "V=0".
Halten Sie einen Backup-Kernel bereit, falls etwas schiefgeht. Dies gilt besonders für Entwicklungsversionen, da jede neue Version neuen Code enthält, der nicht debuggt wurde. Stellen Sie sicher, dass Sie auch ein Backup der zu diesem Kernel gehörenden Module aufbewahren. Wenn Sie einen neuen Kernel mit derselben Versionsnummer wie Ihren funktionierenden Kernel installieren, erstellen Sie ein Backup Ihres Module-Verzeichnisses, bevor Sie "make modules_install" ausführen.
Alternativ können Sie vor dem Kompilieren die Kernel-Konfigurationsoption "LOCALVERSION" verwenden, um dem regulären Kernel-Versionsstring ein eindeutiges Suffix anzuhängen. LOCALVERSION kann im Menü "General Setup" gesetzt werden.
Um Ihren neuen Kernel zu booten, müssen Sie das Kernel-Abbild (z.B. .../linux/arch/i386/boot/bzImage nach der Kompilierung) an den Ort kopieren, an dem sich Ihr regulärer bootbarer Kernel befindet.
Das Booten eines Kernels direkt von einer Diskette ohne die Unterstützung eines Bootloaders wie LILO wird nicht mehr unterstützt.
Wenn Sie Linux von der Festplatte booten, verwenden Sie wahrscheinlich LILO, das das Kernel-Abbild verwendet, das in der Datei /etc/lilo.conf angegeben ist. Die Kernel-Abbilddatei ist normalerweise /vmlinuz, /boot/vmlinuz, /bzImage oder /boot/bzImage. Um den neuen Kernel zu verwenden, speichern Sie eine Kopie des alten Abbilds und kopieren Sie das neue Abbild über das alte. Dann MÜSSEN Sie LILO erneut ausführen, um die Lademap zu aktualisieren!! Wenn Sie das nicht tun, können Sie das neue Kernel-Abbild nicht booten.
WENN ETWAS SCHIEFGEHT:
Wenn Sie Probleme haben, die auf Kernel-Fehler zurückzuführen zu sein scheinen, sehen Sie bitte in der Datei MAINTAINERS nach, ob es eine bestimmte Person gibt, die mit dem Teil des Kernels in Verbindung steht, mit dem Sie Probleme haben. Wenn dort niemand aufgeführt ist, ist die zweitbeste Möglichkeit, sie an mich ([email protected]) und möglicherweise an eine andere relevante Mailing-Liste oder die Newsgroup zu senden.
Geben Sie in allen Fehlerberichten bitte an, um welchen Kernel es sich handelt, wie das Problem reproduziert werden kann und wie Ihre Konfiguration aussieht (benutzen Sie Ihren gesunden Menschenverstand). Wenn das Problem neu ist, teilen Sie mir das mit, und wenn es alt ist, versuchen Sie bitte, mir mitzuteilen, wann Sie es zuerst bemerkt haben.
Wenn der Fehler zu einer Meldung wie der folgenden führt:
unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx
oder ähnliche Kernel-Debug-Informationen auf Ihrem Bildschirm oder in Ihrem Systemprotokoll, bitte übermitteln Sie es exakt. Der Dump mag Ihnen unverständlich erscheinen, aber er enthält Informationen, die beim Debuggen des Problems helfen können. Der Text über dem Dump ist ebenfalls wichtig: Er sagt etwas darüber aus, warum der Kernel Code ausgegeben hat (im obigen Beispiel ist es ein ungültiger Kernel-Zeiger). Weitere Informationen zur Interpretation des Dumps finden Sie in Documentation/oops-tracing.txt
Wenn Sie den Kernel mit CONFIG_KALLSYMS kompiliert haben, können Sie den Dump unverändert senden, andernfalls müssen Sie das Programm "ksymoops" verwenden, um den Dump zu interpretieren (aber das Kompilieren mit CONFIG_KALLSYMS ist normalerweise vorzuziehen). Dieses Dienstprogramm kann von ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ heruntergeladen werden. Alternativ können Sie die Dump-Suche von Hand durchführen:
Bei Debug-Dumps wie dem obigen hilft es enorm, wenn Sie nachschlagen können, was der EIP-Wert bedeutet. Der Hex-Wert als solcher hilft mir oder sonst jemandem nicht sehr viel: Er hängt von Ihrer speziellen Kernel-Konfiguration ab. Sie sollten den Hex-Wert aus der EIP- Zeile nehmen (ignorieren Sie "0010:"), und ihn in der Kernel-Namensliste nachschlagen, um zu sehen, welche Kernel-Funktion die betreffende Adresse enthält.
Um den Namen der Kernel-Funktion herauszufinden, müssen Sie das System- Binary finden, das zu dem Kernel gehört, der das Symptom zeigte. Das ist die Datei 'linux/vmlinux'. Um die Namensliste zu extrahieren und sie gegen die EIP aus dem Kernel-Absturz abzugleichen, führen Sie Folgendes aus:
nm vmlinux | sort | less
"make localyesconfig" Ähnlich wie localmodconfig, außer dass es alle Moduloptionen in eingebaute (=y) Optionen umwandelt.
Weitere Informationen zur Verwendung der Linux-Kernel-Konfigurationswerkzeuge finden Sie in Documentation/kbuild/kconfig.txt.
HINWEISE zu "make config":
Überflüssige Treiber machen den Kernel größer und können unter bestimmten Umständen zu Problemen führen: Das Abtasten einer nicht vorhandenen Controllerkarte kann andere Controller verwirren.
Wird der Kernel mit einem "Processor type" über 386 kompiliert, entsteht ein Kernel, der NICHT auf einem 386 funktioniert. Der Kernel erkennt dies beim Booten und gibt auf.
Ein Kernel mit eingebauter Math-Emulation verwendet weiterhin den Koprozessor, falls einer vorhanden ist: Die Math-Emulation wird in diesem Fall einfach nie genutzt. Der Kernel wird etwas größer, funktioniert aber auf verschiedenen Rechnern, unabhängig davon, ob sie einen Math-Koprozessor haben oder nicht.
Die Konfigurationsdetails unter "kernel hacking" führen normalerweise zu einem größeren oder langsameren Kernel (oder beidem) und können den Kernel sogar instabiler machen, indem einige Routinen so konfiguriert werden, dass sie aktiv schlechten Code zu brechen versuchen, um Kernel-Probleme zu finden (kmalloc()). Daher sollten Sie die Fragen zu "development", "experimental" oder "debugging" wahrscheinlich mit 'n' beantworten.
Die Neuinstallation von LILO ist normalerweise eine Sache von /sbin/lilo. Möglicherweise möchten Sie /etc/lilo.conf bearbeiten, um einen Eintrag für Ihr altes Kernel-Abbild (z.B. /vmlinux.old) anzugeben, falls das neue nicht funktioniert. Weitere Informationen finden Sie in der LILO-Dokumentation.
Nach der Neuinstallation von LILO sollte alles bereit sein. Fahren Sie das System herunter, starten Sie neu und genießen Sie es!
Falls Sie jemals das Standard-Root-Gerät, den Videomodus, die Ramdisk-Größe usw. im Kernel-Abbild ändern müssen, verwenden Sie das Programm 'rdev' (oder gegebenenfalls die LILO-Boot-Optionen). Sie müssen den Kernel nicht neu kompilieren, um diese Parameter zu ändern.
Starten Sie mit dem neuen Kernel neu und freuen Sie sich.
Dies liefert Ihnen eine Liste der Kernel-Adressen in aufsteigender Reihenfolge, aus der es einfach ist, die Funktion zu finden, die die betreffende Adresse enthält. Beachten Sie, dass die von den Kernel- Debug-Meldungen angegebene Adresse nicht unbedingt exakt mit den Funktionsadressen übereinstimmt (tatsächlich ist das sehr unwahrscheinlich), sodass Sie die Liste nicht einfach 'grep'en können: Die Liste gibt Ihnen jedoch den Startpunkt jeder Kernel-Funktion, sodass Sie, wenn Sie nach der Funktion suchen, die eine Startadresse niedriger als die gesuchte hat, aber von einer Funktion mit höherer Adresse gefolgt wird, die gewünschte finden. Tatsächlich ist es eine gute Idee, ein wenig "Kontext" in Ihren Problembericht aufzunehmen, indem Sie ein paar Zeilen um die interessante Stelle angeben.
Wenn Sie das aus irgendeinem Grund nicht können (Sie haben ein vorkompiliertes Kernel-Abbild oder ähnliches), hilft es, mir so viel wie möglich über Ihre Konfiguration mitzuteilen. Bitte lesen Sie das Dokument REPORTING-BUGS für Details.
Alternativ können Sie gdb auf einem laufenden Kernel verwenden. (schreibgeschützt; d.h. Sie können keine Werte ändern oder Haltepunkte setzen.) Dazu kompilieren Sie zuerst den Kernel mit -g; bearbeiten Sie arch/i386/Makefile entsprechend, und führen Sie dann "make clean" aus. Sie müssen außerdem CONFIG_PROC_FS aktivieren (über "make config").
Nachdem Sie mit dem neuen Kernel neu gestartet haben, führen Sie "gdb vmlinux /proc/kcore" aus. Sie können nun alle üblichen gdb-Befehle verwenden. Der Befehl, um den Punkt nachzuschlagen, an dem Ihr System abgestürzt ist, lautet "l *0xXXXXXXXX". (Ersetzen Sie die XXXes durch den EIP-Wert.)
Das Debuggen eines nicht laufenden Kernels mit gdb schlägt derzeit fehl, weil gdb (fälschlicherweise) den Start-Offset ignoriert, für den der Kernel kompiliert wurde.