ubuntuusers.de

Ist kein Tippfehler:

     "make oldconfig"   Default all questions based on the contents of
                        your existing ./.config file and asking about
                        new config symbols.

     "make olddefconfig"
                        Like above, but sets new symbols to their default
                        values without prompting.

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

Wegen keiner Rückfragen bezogen auf neue "config symbols" habe ich das Ziel gewählt. Ist so, als würde man bei den neuen Optionen alle Standardwerte per Enter abnicken. Ich habe oldconfig aber doch mal hinzugefügt - für Leute, die gerne Anpassungen vornehmen. Hab das meine ich 2012 bei Debian auch verwendet und nach fast jeder gefragten Option im Web recherchiert, um mich für einen Wert zu entscheiden.

mrproper macht anscheinend mehr als clean, habe ich irgendwo gelesen.

gpg2 → gpg ist erledigt, verwendet laut Versionsangabe eh dasselbe. Hab erst überlegt, bezogen aufs Überprüfen der Signatur nur auf den gpg Artikel zu verlinken, aber die Schlüssel anhand der Mailadressen hinzuzufügen und das mit dem Trust Model scheinen mir sinnvoll zu sein. Vielleicht ist eine gewisse Redundanz (Überschneidungen mit Inhalten aus anderen Wikiartikeln) bei HowTos eher ok.

Laut Kernelsignaturseite muss man --trust-model nur einmal angeben, in meinem Test gings aber beim 2. Mal auch nicht ohne, drum habe ich das einfach allgemein dringelassen. Vielleicht kann man irgendwie das Trust Model in einer Konfigurationsdatei setzen, ich hab mich mit gpg noch nicht weiter beschäftigt.

Vielleicht füge ich noch was zur Dauer des Kompilierens inklusive Paketebau ein, wenn ich das auf meinen betagten Core 2 Duos getestet habe. Rein rechnerisch würde das da mehrere Stunden dauern, weils auf meinem 8 Kerne System auch schon eine halbe Stunde dauert. Immerhin verwenden manche noch ältere Systeme, die könnte die Dauer dann überraschen.

Hallo,

Vielleicht füge ich noch was zur Dauer des Kompilierens inklusive Paketebau ein,

Ist denke ich eine gute Idee. Beim Kernel kompilieren ist Geduld ja nicht verkehrt ☺

Gruß, noisefloor

Ist ergänzt:

Core 2 Duo P9500, 2,53 GHz, 8 GB Ram, altmodische Platte, externer Monitor per VGA, 1920x1200, internes Display abgeschaltet.

time make CC=/usr/bin/gcc-13 CXX=/usr/bin/g++-13 KCFLAGS="-march=native" -j 2 bindeb-pkg LOCALVERSION=-"custombuild-001"
[...]
real    237m4,830s
user    415m48,134s
sys     47m58,827s

Baugleiches System, mit dem Unterschied, dass nur das interne Display läuft.

real    246m45,187s
user    416m46,990s
sys     48m32,458s

Das deute ich als 4 Stunden, dachte das Pakete bauen am Ende dauert länger, das ging recht fix.

Zum Vergleich: Ryzen 5700u, 8 Kerne:

time make CC=/usr/bin/gcc-13 CXX=/usr/bin/g++-13 KCFLAGS="-march=native" -j 16 bindeb-pkg LOCALVERSION=-"custombuild-001"
[...]
real    28m38,021s
user    330m39,115s
sys     65m15,892s

Vielen Dank für die Anleitung, verdooft! Der Artikel ist jetzt freigeschaltet.

Danke auch für deine Korrekturen.

Ich hab KCFLAGS="-march=native" rausgenommen, weil ich nicht sicher bin, ob das wirklich den gewünschten Effekt hat. Im Arch Wiki wird zwar erklärt, wie das richtig geht, ist mir aber zu kompliziert. Außerdem bringts wohl nicht soviel, hier wurde allerdings auch mit -O3 getestet: https://www.phoronix.com/news/Linux-5.19-O3-March-Native

Auf meinem Server hat bc gefehlt, dachte eigentlich, das ist bei einer Standardinstallation (Ubuntu Server) dabei, habs mal zu den Abhängigkeiten hinzugefügt. Es ist nicht ausgeschlossen, dass der Installationsumfang vom Hoster angepasst wurde.

verdooft schrieb:

Ich hab KCFLAGS="-march=native" rausgenommen, weil ich nicht sicher bin, ob das wirklich den gewünschten Effekt hat. Im Arch Wiki wird zwar erklärt, wie das richtig geht, ist mir aber zu kompliziert. Außerdem bringts wohl nicht soviel, hier wurde allerdings auch mit -O3 getestet: https://www.phoronix.com/news/Linux-5.19-O3-March-Native

Ich kann mir Leistungsverluste mit Compiler Flag -march=native eigentlich nur erklären, dass die ARM ähnliche big.LITTLE hybride Architektur mit den P-Kernen und E-Kernen ab Alder-Lake in den neueren Intel-CPUs diesen nachteiligen Effekt auf CPUs mit Alder-Lake Architektur haben.

Hauptgrund warum ichs rausgenommen habe, ist, dass ich nicht sicher bin, ob KCFLAGS=... überhaupt reicht, im Arch Wiki steht eine andere Vorgehensweise. Richtig flott wirds vielleicht erst, wenn man auch libc und so derart optimiert baut. Vielleicht teste ich das (Gentoo) irgendwann in einer virtuellen Maschine, da hat man ja fast Host-Speed und auch den originalen Prozessor.

noisefloor schrieb:

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?

Ich hab eben einen neuen VPS eingerichtet und mal die Übernahme der Konfiguration von 5.15.0-25 mit 6.5.6 getestet, da kam es zum ersten Mal zu Meldungen:

# using defaults found in /boot/config-5.15.0-25-generic
#
.config:436:warning: symbol value 'm' invalid for I8K
.config:1988:warning: symbol value 'm' invalid for MCTP
.config:7684:warning: symbol value 'm' invalid for USB_FOTG210_HCD
.config:7917:warning: symbol value 'm' invalid for USB_FOTG210_UDC
.config:8803:warning: symbol value 'm' invalid for VIDEO_ZORAN_DC30
.config:8804:warning: symbol value 'm' invalid for VIDEO_ZORAN_ZR36060
.config:8805:warning: symbol value 'm' invalid for VIDEO_ZORAN_BUZ
.config:8806:warning: symbol value 'm' invalid for VIDEO_ZORAN_DC10
.config:8807:warning: symbol value 'm' invalid for VIDEO_ZORAN_LML33
.config:8808:warning: symbol value 'm' invalid for VIDEO_ZORAN_LML33R10
.config:8809:warning: symbol value 'm' invalid for VIDEO_ZORAN_AVS6EYES
.config:9900:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC
.config:9901:warning: symbol value 'm' invalid for ANDROID_BINDERFS
.config:10644:warning: symbol value 'm' invalid for CRYPTO_BLAKE2S_X86
.config:10737:warning: symbol value 'm' invalid for CRYPTO_ARCH_HAVE_LIB_BLAKE2S
.config:10738:warning: symbol value 'm' invalid for CRYPTO_LIB_BLAKE2S_GENERIC
#
# configuration written to .config

Hat aber trotzdem geklappt, vermutlich wurden für die Optionen/Symbole einfach die Defaultwerte verwendet.

Ich hab noch 2 Änderungen vorgenommen:

• Entfernen eines nicht leeren modules Verzeichnisses nach dem Purgen des Kernels

• Empfehlung für Screen/Tmux, damits beim Verbindungsabbruch nicht unterbrochen wird

Hab erst überlegt, die konkreten Schritte für Screen (nur das verwende ich) aufzuführen, dann aber zurückgerudert, weil Leute ruhig auch in anderen Wiki Artikel nachlesen sollen.

Fun Fact am Rande: Suche ich nach "ubuntu kernel kompilieren" ohne ", ist der Artikel bei mir auf Platz 1.

Kernel 6.6.5 lasse ich mal ausfallen, weil ich einen amdgpu-Reset hatte, wo auch was mit DRM vorkam. Laut Changelog wurde da was geändert.

Ich poste noch die Ausgabe von dmesg, vielleicht stoßen Leute mit dem Problem dann eher auf den Thread:

[ 4451.808349] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=8878, emitted seq=8880
[ 4451.808710] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process RDD Process pid 6362 thread firefox-bi:cs0 pid 20016
[ 4451.809002] amdgpu 0000:05:00.0: amdgpu: GPU reset begin!
[ 4452.025361] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002n
[ 4452.215173] [drm] Register(0) [mmUVD_RBC_RB_RPTR] failed to reach value 0x000001c0 != 0x000001a0n
[ 4452.399241] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002n
[ 4452.438677] amdgpu 0000:05:00.0: amdgpu: MODE2 reset
[ 4452.438878] amdgpu 0000:05:00.0: amdgpu: GPU reset succeeded, trying to resume
[ 4452.439273] [drm] PCIE GART of 1024M enabled.
[ 4452.439280] [drm] PTB located at 0x000000F47FC00000
[ 4452.439584] [drm] PSP is resuming...
[ 4453.137031] [drm] reserve 0x400000 from 0xf47f800000 for PSP TMR
[ 4453.402320] amdgpu 0000:05:00.0: amdgpu: RAS: optional ras ta ucode is not available
[ 4453.412558] amdgpu 0000:05:00.0: amdgpu: RAP: optional rap ta ucode is not available
[ 4453.412566] amdgpu 0000:05:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[ 4453.412572] amdgpu 0000:05:00.0: amdgpu: SMU is resuming...
[ 4453.414670] amdgpu 0000:05:00.0: amdgpu: SMU is resumed successfully!
[ 4453.415333] [drm] DMUB hardware initialized: version=0x0101001F
[ 4453.830201] [drm] kiq ring mec 2 pipe 1 q 0
[ 4453.834424] [drm] VCN decode and encode initialized successfully(under DPG Mode).
[ 4453.834492] [drm] JPEG decode initialized successfully.
[ 4453.834496] amdgpu 0000:05:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[ 4453.834499] amdgpu 0000:05:00.0: amdgpu: ring gfx_low uses VM inv eng 1 on hub 0
[ 4453.834501] amdgpu 0000:05:00.0: amdgpu: ring gfx_high uses VM inv eng 4 on hub 0
[ 4453.834503] amdgpu 0000:05:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 5 on hub 0
[ 4453.834504] amdgpu 0000:05:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 6 on hub 0
[ 4453.834506] amdgpu 0000:05:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 7 on hub 0
[ 4453.834508] amdgpu 0000:05:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 8 on hub 0
[ 4453.834510] amdgpu 0000:05:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 9 on hub 0
[ 4453.834511] amdgpu 0000:05:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 10 on hub 0
[ 4453.834513] amdgpu 0000:05:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 11 on hub 0
[ 4453.834515] amdgpu 0000:05:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 12 on hub 0
[ 4453.834517] amdgpu 0000:05:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 13 on hub 0
[ 4453.834519] amdgpu 0000:05:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8
[ 4453.834521] amdgpu 0000:05:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8
[ 4453.834522] amdgpu 0000:05:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8
[ 4453.834524] amdgpu 0000:05:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8
[ 4453.834526] amdgpu 0000:05:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8
[ 4453.837589] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow start
[ 4453.837595] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow done
[ 4453.837678] amdgpu 0000:05:00.0: amdgpu: GPU reset(1) succeeded!
[ 4453.839923] [drm] Skip scheduling IBs!
[ 4453.839956] [drm] Skip scheduling IBs!
[ 4453.842077] [drm] Skip scheduling IBs!
[ 4453.842093] [drm] Skip scheduling IBs!
[ 4453.842790] [drm] Skip scheduling IBs!
[ 4453.846236] amdgpu_cs_ioctl: 21 callbacks suppressed
[ 4453.846239] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!

Das System ist nicht stillgestanden, alles bis aufs KDE-Startmenü scheint weiter zu funktionieren.

Habs mal für den Kernel 6.12.1 angepasst. Allerdings verwende ich jetzt was 24.04 basiertes, da gibt es libncurses5-dev nicht mehr, zudem sind gcc/g++ Version 14 in den Paketquellen, ich lasse das erstmal auf für 22.04 getestet und passe das mal an, wenn ich eine frische 24.04er VM habe.

Geht so mit aktuellen Kerneln nicht mehr, hab aktuell auch nicht die Zeit/Motivation, rauszufinden, wie man das ändern kann.

Gibts für den Fall irgendeinen Status, in den man den Artikel versetzen kann? Möglich dass nur irgendein Paket fehlt.

verdooft schrieb:

Geht so mit aktuellen Kerneln nicht mehr

Das ist ziemlich unspezifisch. Was genau funktioniert denn nicht mehr und wie lautet die Fehlermeldung?

[…] Gibts für den Fall irgendeinen Status

Einen fehlerhaften Artikel sollte man mit dem dafür vorgesehenen Textbaustein als eben Fehlerhaft kennzeichnen:
Wiki/Textbausteine (Abschnitt „Fehlerhaft-Markierung“)

Make Fehler, den ich nicht zuordnen kann. Da ich kein Ubuntu mehr nutze, ists auch sinnlos, wenn ich das in meiner Distribution zum Laufen bekomme, fällt keinem Ubuntuuser eine Lösung ein, kann man den Artikel löschen.