staging.inyokaproject.org

Kennt wer das Paket linux-libc-dev? Das wird bei meiner Vorgehensweise aktualisiert und bei einer Kerneldeinstallation verbleibts auf dem Stand. Nun ist mir aufgefallen, dass das sowieso mit Kernelupdates durch Ubuntu selten aktualisiert wird (die Buntu Vm habe ich nicht mehr, dürfte aber dort ähnlich sein), denn:

apt-cache policy linux-libc-dev
linux-libc-dev:
  Installiert:           6.4.11-1
  Installationskandidat: 6.4.11-1
  Versionstabelle:
 *** 6.4.11-1 100
        100 /var/lib/dpkg/status
     5.15.0-79.86 500
        500 https://mirrors.tuxedocomputers.com/ubuntu/mirror/security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     5.15.0-78.85 500
        500 https://mirrors.tuxedocomputers.com/ubuntu/mirror/archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     5.15.0-25.25 500
        500 https://mirrors.tuxedocomputers.com/ubuntu/mirror/archive.ubuntu.com/ubuntu jammy/main amd64 Packages

Beschrieben wird das Paket so: These headers are used by the installed headers for GNU glibc and other system libraries.

Gnulibc und andere Systembibliotheken bleiben ja gleich, auch wenn man den selbst gebauten/installierten Kernel entfernt. Kann man das Paket also bei einer Kerneldeinstallation ruhigen Gewissens auf dem aktuellen Stand lassen?

Hallo verdooft,

vielen Dank für diese interessante Anleitung!

verdooft schrieb:

[...] Gnulibc und andere Systembibliotheken bleiben ja gleich, auch wenn man den selbst gebauten/installierten Kernel entfernt. Kann man das Paket also bei einer Kerneldeinstallation ruhigen Gewissens auf dem aktuellen Stand lassen?

Ich meine, dass das ja sowieso beim nächsten Kernelupdate bereinigt werden sollte, also wohl kein Problem darstellt. Eine (vielleicht nicht empfehlenswerte) Idee wäre auch die Nutzung von apt-mark hold oder anschließendem Downgrade unter Angabe der letzten Version.

Bitte noch den Artikel bezüglich Wiki/Textbausteine (Abschnitt „Paketinstallation“) überarbeiten. Außerdem könnten ein paar Links zu hilfreichen Wikiartikeln nicht schaden.

Danke für die Rückmeldung. Setze ich bald um. Theoretisch müsste man das Paket gar nicht installieren (im Rahmen des HowTos), dann hätte man das Problemchen nicht. Bei Buntu 22.04 wird vermutlich nie Kernel 6.4 als Update kommen, also würde linux-libc-dev, hier im Beispiel Version 6.4.11, ewig auf dem System bleiben. Mich wundert auch, dass es das in den Jammy-Paketquellen nur in Version 5.15.x gibt. Anscheinend bleibts dann auch auf dem Stand 5.15, wenn man z.B. den Kernel linux-image-5.19.0-50-generic aus den Quellen verwendet.

Hab vorher den Artikel gesehen: https://wiki.ubuntuusers.de/Archiv/Kernel/Kompilierung/

Allerdings habe ich im Rahmen eines anderen Threads: https://forum.ubuntuusers.de/topic/hp-envy-x360-kein-sound/

Jetzt die Vorgehensweise praktisch "erarbeitet". Zudem wären Hinweise auf aktuellere Compiler in richtigen Wikiartikel wohl nicht so gerne gesehen.

Das Rustkapitel habe ich rausgenommen, weil der Sprung von 1.66 auf 1.67 so groß nicht ist, also wird man praktisch kaum Vorteile dadurch haben. Dadurch ist auch die 2. PPA Warnbox weg. Hat einen Grund, warum die Vorlagen noch apt-get verwenden und nicht apt?

Hallo,

Das Rustkapitel habe ich rausgenommen, weil der Sprung von 1.66 auf 1.67 so groß nicht ist, also wird man praktisch kaum Vorteile dadurch haben.

Ja, aber denk' dran dass das HowTo in der aktuellen Form bis April 2027 im Wiki sein könnte - und dann wird die Versionsdifferenz zwischen den Jammy-Quellen und die aktuellen Version größer sein. Ob das dann relevant ist ist halt schwer vorherzusagen.

IMHO fehlt in der Einleitung auch noch die Abgrenzung, warum man selber kompilieren sollte, wenn man auch den Mainline-Kernel nehmen könnte.

Gruß, noisefloor

Ja, guter Punkt, ich kompiliere eigentlich nicht aus Notwendigkeit raus, sondern weil die Quelle für Mainlinekernels mal nicht aktuell war und ich bei einer Problemlösung im Forum unterstützen wollte. Hab was dazu geschrieben. Im Originalartikel steht noch was von Kernelentwicklern und -testern.

Das von mir verwendete PPA mit Rust hinkt sowieso hinterher, ich bin nicht sicher, ob da z.B. Rust 1.70, das in 23.10 schon ist, überhaupt landet. Werde das beobachten.

Hallo,

zwei weitere Punkte:

1. Kannst du abschätzen bzw. weißt du, wie weit die Kernel (also Systemkernel und neu zu kompilierender Kernel versionsmäßig auseinander liegen müssen, damit eine Übernahme der Konfiguration _nicht_ sinnvoll ist?

2. Es ist ewig her, dass ich selber mal eine Kernel kompiliert habe (das war ziemlich sicher, bevor ich Ubuntu benutzt habe, also vor Sommer 2005), aber damals gab es schon gefühlt 1 Millionen Konfigurationsmöglichkeiten. Heute werden es dann gefühlt vielleicht 1 Milliarden sein. Vielleicht sollte noch ein Hinweis in den Artikel, dass die manuelle Konfiguration extrem (zeit-) aufwendig sein kann. Ich vermutet auch mal, dass ein unkonfigurierter Vanilla-Kernel i.d.R. nach dem Kompilieren lauffähig ist?

Gruß, noisefloor

Zu 1.) Ich meine gelesen zu haben, dass alle hinzugefügten Optionen mit der im Artikel genannten Methode mit dem Defaultwert abgenickt werden, so als würde man ständig entern. Man wird zumindest nichts gefragt, bis auf das eine, wo ich nicht weiß, ob das mit gcc/g++-13 oder der -march=native Option zusammenhängt, einfach mit dem 11er gcc/g++ liefs ohne Rückfrage durch.

make defconfig

würde allle Optionen auf Default setzen, ohne eine alte Config zu verwenden.

make oldconfig

würde die alte Configdatei verwenden (auch kopieren?), aber alles neue abfragen.

Teste ich bald, kann ich dann gerne noch ergänzen.

Gibt noch viele andere Targets in der Richtung, dokumentiert z.B. hier:

https://www.kernel.org/doc/Documentation/admin-guide/README.rst

Das da wurde mir mal zum Verhängnis, weil CD-Rom Dateisystemunterstützung draussen war:

"make localmodconfig" Create a config based on current config and
                           loaded modules (lsmod). Disables any module
                           option that is not needed for the loaded modules.

Zu 2.) Ja, ich hatte 2012 unter Debian zuletzt Kernels kompiliert, schon damals waren es viele Optionen. Was mich auch wundert, ist die Abhängigkeit qtbase5-dev-tools, ich vermute, dass das nur für eine Qt Version zum Konfigurieren des Kernels benötigt wird, habs aber nicht getestet.

Ah, aus obigem Link:

"make xconfig" Qt based configuration tool.

Bei den Optionen muss man nicht alles durchgehen, meistens weiß man ja, was man anpassen möchte, z.B. wenn man möchte, dass der Kernel nur auf AMD CPU Systemen läuft, klickt man die anderen in dem Fenster weg, oder wenn man irgendeine Latenzzeit ändern möchte, geht man dahin, ändert den Wert. Zu vielen Optionen gibts noch Untermenüs, das würde wirklich ewig dauern, wenn man alles durchklicken würde, drum habe ich hier einfach die Config vom laufenden Kernel kopiert. Da ich auch menuconfig und xconfig erwähnt habe, ist dein Einwand berechtigt.

Theoretisch könnte man auch noch darauf hinweisen, dass Unterstützung von alter Hardware entfernt sein kann. Ich weiß nur nicht, wie relevant das praktisch ist.

Hallo,

Theoretisch könnte man auch noch darauf hinweisen, dass Unterstützung von alter Hardware entfernt sein kann. Ich weiß nur nicht, wie relevant das praktisch ist.

Ja, guter Punkt. In der aktuellen Einleitung wird ja schon erklärt, warum man einen neuen Kernel bauen möchte. Da könntest du noch einen Satz dran hängen wie "Verwendet man sehr alte Hardware, könnte es sein, dass der neue Kernel diese nicht mehr unterstützt."

Das Problem ist vermutlich in 99% der Fälle zumindest hypothetisch, weil Treiber AFAIK ziemlich lange im Kernel bleiben. Aber ein Hinweis kann IMHO nicht schaden.

Gruß, noisefloor

Erledigt. Ich überlege noch, ob andere make-Ziele (etwa gtk-Oberfläche zum konfigurieren, irgendwas um kleinere Kernel zu bauen, etc.) erklärt werden. Auch ists vielleicht nicht optimal, wenn ich direkt die Version 6.4.11 verwende, vielleicht besser <version>, damit Leute in 10 Jahren nicht mit der Anleitung Kernel 6.4.11 nehmen.

Außerdem vermute ich stark, dass das so nur ohne Secure Boot funktioniert.

Hallo,

kleiner Kernel bauen macht IMHO nur Sinn, wenn man weiß, was man tut. Also wenn man sehr genau weiß, welche Teile / Treiber / Subsysteme man weg lassen kann. Was IMHO ein eigener Artikel wäre. Die Intention des Howto ist doch, sich einen neueren Kernel zu bauen, um ggf Hardwtreiberprobleme o.ä. zu beheben. Dann tut man i.d.R. gut dran, erstmal alles im Kernel drin zu lassen.

Gruß, noisefloor

Ok, sehe ich genauso. Wenn man nur die aktuell geladenen Module übernimmt, fehlt schnell mal die Unterstützung für ein Dateisystem, oder eine Hardware, die man später anstöpselt. Wer anderes umsetzen möchte, kann das in der verlinkten Textdatei nachlesen.

Habs jetzt mehrfach für den jeweils aktuellen Kernel getestet, von mir aus ist der Artikel fertig.

Solange ich Kernel selbst baue, werd ich den Artikel aktuell halten, ansonsten stelle ich den auf Platzhalter wie <kernelversion> um. Weil da nix mit Signieren vorkommt, gehe ich davon aus, dass der Kernel so nur für Systeme mit ausgeschaltetem Secure Boot verwendet werden kann? Falls das jemand bestätigt, kann ich das noch reinschreiben.

Eventuell füge ich noch die Überprüfung per gpg hinzu.

Überprüfung der Signatur hinzugefügt.

Ich hab gemerkt, dass eckige Klammer auf Zahl Eckige Klammer zu auf die Verweise oben zeigen. Wie referenziert man denn die unten angegegeben Websites?

make mrproper habe ich nie ausgeführt, habs aber mal aufgrund dieses Eintrages im Archwiki übernommen: "do not rely on the source tree being clean after unpacking" https://wiki.archlinux.org/title/Kernel/Traditional_compilation

Irgendwann füge ich noch paar Verweise auf die oberen Einträge ein.

verdooft schrieb:

Überprüfung der Signatur hinzugefügt.

Die mangelhafte Übersetzung der GPG-Ausgabe ist Dir wohl auch aufgefallen 😉

Ich finde Du solltest gpg2 denn doch auf gpg umstellen. Ich werde anregen, das im Hauptartikel ebenfalls anzupassen.

Ich hab gemerkt, dass eckige Klammer auf Zahl Eckige Klammer zu auf die Verweise oben zeigen. Wie referenziert man denn die unten angegegeben Websites?

Ich fürchte das ist derzeit nicht möglich.

make mrproper habe ich nie ausgeführt, habs aber mal aufgrund dieses Eintrages im Archwiki übernommen: "do not rely on the source tree being clean after unpacking" https://wiki.archlinux.org/title/Kernel/Traditional_compilation [...]

Ja, finde ich sinnvoll. make clean scheint übrigens eine Alternative zu sein.

make olddefconfig  

Ist das ein Tippfehler? Laut Ubuntu-Dokumentation heißt das Ziel oldconfig.