[solved] Eine einzige Option im rt-kernel ändern, wie?

[whiizy]

Nach mehreren dist-upgrades habe ich nun ein Bullseye mit dem Debian realtime kernel laufen (linux-image-5.10.0-10-rt-amd64).

Da ich eine einzige Kerneloption ändern möchte, will ich diesen Debian kernel wieder selbst kompilieren. Hatte ich schonmal unter Stretch hingekriegt, aber leider teilweise wieder vergessen.

Ich kann irgendwie keine Anleitung finden, auch https://kernel-team.pages.debian.net/ke ... tml#s4.2.5 lässt dieses wohl eher seltene Szenario aus.

Debian's linux-source-5.10 habe ich schon im home ausgepackt. Enthalten ist u.a. ein vielversprechender Patch /usr/src/linux-patch-5.10-rt.patch.xz

Muss ich den am Ende einfach nur ins home kopieren und dann die linux-source-5.10 damit patchen, in etwa so? ->

Code: Alles auswählen

cd ~/linux-source-5.10
xzcat ~/linux-patch-5.10-rt.patch.xz | patch -p1

Würdet ihr das so machen?

Daran anschließend käme ich wohl selbst weiter. Würde mir die .config des laufenden kernels holen (/boot/config-5.10.0-10-rt-amd64), dann mit make nconfig die einzelne Kerneloption ändern und schließlich das Debianpaket des gepatchten Kernels bauen und installieren.

Kann das so gehen oder hat jemand mal eine bessere Anleitung gesehen?

[KP97]

Zum Kompilieren habe ich einen Ordner Temp in meinem Home.
Darin entpacke ich die heruntergeladenen Sourcen, ich bevorzuge allerdings die Sourcen direkt von kernel.org.
Du kannst natürlich auch die Debian Sourcen verwenden.
Einen Patch kopiere ich ebenfalls ins Temp und führe dann

Code: Alles auswählen

patch -p1 < patchname.patch 

aus
Anschließend kannst Du den Kernel kompilieren mit

Code: Alles auswählen

make oldconfig
make nconfig  -> hier die Änderung vornehmen
make -j4 bindeb-pkg -> (-j4 für vier CPU Kerne, wenn Du mehr hast, entsprechend angeben)

Der Kernel wird als .deb erstellt und kann mit dpkg installiert werden.
Es werden auch Header erstellt und noch zwei kleinere Pakete, wenn Du die nicht willst, brauchst Du die nicht installieren.

[fischig]

Ich schöbe zwischen make oldconfig (das war der Spaß, den ich dir wünschte. ) und

Code: Alles auswählen

make j4 bindeb-pkg ...

make menuconfig ein.
make -nconfig kenne ich (noch) nicht.
Wenn du die Option kennst, die du ändern willst, kannst du mit make menuconfig danach suchen, dich dann durchs Menü hangeln und sie ändern. Theoretisch geht das auch direkt in der .config, aber da bewahrt dich menuconfig besser vor Fehlern.

[KP97]

nconfig ist das gleiche wie menuconfig, nur als ncurses, also etwas grafischer.

[whiizy]

Habe nach eurer Ermutigung die Debian sources gepatcht, wie geplant (lief sauber durch). Hatte ja zunächst damit gewartet, weil ich diesen zentralen Schritt irgendwie in keinem Debian README gefunden hatte.

In Stichworten zum Ablauf:

~/linux-source-5.10$ cp /boot/config-5.10.0-10-rt-amd64 .config

Wollte schon länger mal "make localmodconfig" ausprobieren, was basierend auf der .config und den geladenen Kernelmodulen auch nur die nötigsten Module konfiguriert ...

make localmodconfig

In Kapitel 4.5 hatte ich Verwirrendes zu Signaturen und Keys gelesen und hatte vor dem localmodconfig noch dafuer gesorgt, daß folgende Variablen so gesetzt waren:

#CONFIG_MODULE_SIG=y
CONFIG_SYSTEM_TRUSTED_KEYS=""

Ob das so nötig war, sei dahingestellt. Das Debugging brauche ich jedenfalls nicht:
~/linux-source-5.10$ scripts/config --disable DEBUG_INFO

make nconfig
(mit nconfig habe ich meine gewünschte Kerneloption ausgewählt)

make clean

Die Variablen in der .config waren direkt vorm Kompilieren wie folgt (MODULE_SIG war irgendwie wieder zurück auf y):
CONFIG_MODULE_SIG=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_DEBUG_INFO is not set

Dann habe ich mit den 4 cores kompiliert:

$ make -j4 bindeb-pkg

Der erste Anlauf brach gleich ab ...
dpkg-checkbuilddeps: error: Unmet build dependencies: libelf-dev:native libssl-dev:native

Habe dann libelf-dev und libssl-dev nachinstalliert und den letzten Befehl wiederholt. Lief dann sauber bis zum Ende:
[...]
HDRINST usr/include/asm/resource.h
HDRINST usr/include/asm/unistd_64.h
INSTALL debian/linux-libc-dev/usr/include
dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.10.84-rt58-1_amd64.deb'.
dpkg-deb: building package 'linux-image-5.10.84-rt58' in '../linux-image-5.10.84-rt58_5.10.84-rt58-1_amd64.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../linux-5.10.84-rt58_5.10.84-rt58-1_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)

Ich musste das neue Kernelpaket dann nur noch installieren:
# dpkg -i linux-image-5.10.84-rt58_5.10.84-rt58-1_amd64.deb

Grub hat diesen eigenen Kernel dann automatisch beim nächsten Boot gestartet.

Das Ziel dieses Threads eines angepassten rt-kernel mit PREEMPT_RT und 1000Hz-timer war an dieser Stelle schon erreicht.

WLAN geht, USB-Audio geht. Kleiner Wermutstropfen, ich bekomme keinen MIDI-Input von meinen Controllern. Habe aber schon gemerkt, woran es liegt. Das Modul snd_seq_midi wurde nicht gebaut. War während des make localmodconfig nicht geladen gewesen und wurde daher wohl nicht automatisch erfasst (obwohl das keyboard angeschlossen war). Ich kann den load von snd_seq_midi provozieren, indem ich meine Audiosoftware vorher starte. Eine zweite Möglichkeit wäre aber auch, es über make nconfig explizit zu setzen. Werde die Kompilation also nochmal wiederholen müssen. Ist aber kein Problem, weiß ja jetzt ungefähr, wie der Debian-way für einen speziellen rt-kernel aussieht. Die Kompilation hat auf dem lüfterlosen Mobilrechner auch weniger als eine halbe Stunde gebraucht.

Danke für eure Ermunterung!

[KP97]

Na prima, das lief ja ganz gut.
Beim nächsten Mal läßt Du aber das "make clean" weg, das ist kontraproduktiv. Das nutzt man nur, wenn man einen vorher eingestellten Wert wieder zurücknehmen will.
Das hast Du ja gemerkt, und zwar nicht "irgendwie" sondern durch den Parameter.

Noch was:
Das localmodconfig hat seine Tücken und sollte nur dann verwendet werden, wenn alles vorher mit gestartet ist.
Also Wlan, USB, Audio, sämtliche externen Geräte usw... Sicherer ist ein oldconfig, dann hat man keine fehlenden Einstellungen.
Kannst Du ja dann beim nächsten Mal machen...

[whiizy]

Na prima, das lief ja ganz gut.
Beim nächsten Mal läßt Du aber das "make clean" weg, das ist kontraproduktiv. Das nutzt man nur, wenn man einen vorher eingestellten Wert wieder zurücknehmen will.

Ja, danke. Wenn deine Gedanken zu "make clean" zutreffen, wäre das verlinkte kernel-handbook an der Stelle auch falsch. Empfohlenes Vorgehen dort:

$ make nconfig
[...]
After the configuration process is finished, the new or updated kernel configuration will be stored in .config file in the top-level directory. The build is started using the commands

$ make clean
$ make deb-pkg

Die Stärken von localmodconfig sind eben auch gleichzeitig seine Tücken. Man erhält sehr bequem einen hochspezialisierten, superschlanken Kernel, aber es kann passieren, daß man über das Ziel hinausschießt. Ich hatte in der Tat vorher dafür gesorgt, daß meine Zielgeräte angeschlossen und aktiv waren (USB-Audiointerface, USB-Midicontroller, WLAN). Was ich nur noch nicht bedacht hatte, daß manche MIDI-kernelmodules erst zur Laufzeit bestimmter Audiosoftwares nachgeladen werden. So waren zwar die meisten MIDI-Modules kompiliert worden, aber eben nur nicht das snd_seq_midi. Abhilfe habe ich ja schon beschrieben, muss ich aber noch testen.

Das "make oldconfig" war in meinem Szenario eigentlich nicht sinnvoll, da ich noch keine alte .config im System als Startpunkt hatte, sondern mein Referenzpunkt bewusst die Kernelconfig des normalen Debian rt-kernels sein sollte, eben /boot/config-5.10.0-10-rt-amd64.

Für gewöhnlichen Desktop-Betrieb habe ich ja noch weiterhin den Standard Debiankernel linux-image-amd64 im grub menue. Schwerpunkt ist aber Realtime Audio mit dem eigenen Kernel auf diesem Laptop.

Finde ich gut, daß du so mitdenkst!

Grüsse

[fischig]

da ich noch keine alte .config im System als Startpunkt hatte

Doch, hattest du und zwar die vom selbstgebauten 4.9er.

[whiizy]

Nein, hatte ich nicht
Das System hat nur eine kleine festverbaute MMC (und keine SSD) und ich hatte den ganzen Kernelkram vorher entfernt. Ich hätte eine alte config vom 4.9er Kernel aus oldoldstable (Stretch) auch nicht als Referenz genommen. Schon gar nicht, da meine alte .config kaum customized war bzw. nur minimale Abweichungen zum normalen Debian rt-kernel hatte.

[whiizy]

Im zweiten Anlauf macht mein Kernel nun alles, was er soll!
Hier der weiter eingedampfte Schnelldurchlauf. Ausgangspunkt ist wieder die gepatchte Debian source. Externe Geräte angeschlossen. MIDI-Anwendung in einem Fenster gestartet.

Code: Alles auswählen

cp /boot/config-5.10.0-10-rt-amd64 ~/linux-source-5.10/.config
~/linux-source-5.10$ make localmodconfig
~/linux-source-5.10$ scripts/config --disable DEBUG_INFO
$ make nconfig
$ make clean
$ make -j4 bindeb-pkg
# dpkg -i linux-image-5.10.84-rt58_5.10.84-rt58-1_amd64.deb
# reboot

Noch ein paar beiläufige Beobachtungen. Den zweiten Anlauf hatte ich zunächst begonnen, indem ich einfach erneut "make localmodconfig" nochmal ausgeführt habe. Die geänderten Rahmenbedingungen zu diesem Zeitpunkt waren nur, daß die bereits abgespeckte .config aus meinem letzten Post existierte und eine MIDI-Software im Hintergrund lief (welche das module snd_seq_midi verwendet).

Dieser blauäugige Ansatz brachte indirekt zutage, welche Module jetzt neu detektiert wurden und im ersten Anlauf fehlten:

Code: Alles auswählen

~/linux-source-5.10$ make localmodconfig
using config: '.config'
WARNING: SND_SEQ_MIDI_EVENT is required, but nothing in the
  current config selects it.
WARNING: SND_COMPRESS_OFFLOAD is required, but nothing in the
  current config selects it.
WARNING: SND_COMPRESS_OFFLOAD is required, but nothing in the
  current config selects it.
WARNING: SND_SEQ_MIDI_EVENT is required, but nothing in the
  current config selects it.
module snd_seq_dummy did not have configs CONFIG_SND_SEQ_DUMMY
module snd_compress did not have configs CONFIG_SND_COMPRESS_OFFLOAD
module snd_seq_midi_event did not have configs CONFIG_SND_SEQ_MIDI_EVENT
module snd_seq_midi did not have configs CONFIG_SND_SEQ_MIDI
module snd_seq_device did not have configs CONFIG_SND_SEQ_DEVICE
module snd_seq did not have configs CONFIG_SND_SEQUENCER
#
# configuration written to .config
#

Meine Lehre daraus ist, daß "make localmodconfig" zunächst eine vollständige .config braucht, welche diese Variablen noch enthält. Dies gewähleistet als Startbasis sehr gut die /boot/config-5.10.0-10-rt-amd64, die ich oben in meiner Kurzfassung schließlich dann wieder verwendet habe.

Bezüglich "make clean". Das wird dabei ausgegeben:

Code: Alles auswählen

~/linux-source-5.10$ make clean
  CLEAN   arch/x86/entry/vdso
  CLEAN   arch/x86/kernel/cpu
  CLEAN   arch/x86/kernel
  CLEAN   arch/x86/purgatory
  CLEAN   arch/x86/realmode/rm
  CLEAN   arch/x86/lib
  CLEAN   certs
  CLEAN   drivers/firmware/efi/libstub
  CLEAN   drivers/scsi
  CLEAN   drivers/tty/vt
  CLEAN   kernel
  CLEAN   lib
  CLEAN   net/wireless
  CLEAN   security/apparmor
  CLEAN   security/selinux
  CLEAN   security/tomoyo
  CLEAN   usr/include
  CLEAN   usr
  CLEAN   arch/x86/boot/compressed
  CLEAN   arch/x86/boot
  CLEAN   arch/x86/tools
  CLEAN   vmlinux.symvers modules-only.symvers modules.builtin modules.builtin.modinfo

Ich habe die .config vor und nach dem "make clean" mit vimdiff verglichen - die .config bleibt unverändert.

Grüsse