[gelöst] Kernel bauen im Jahr 2020
[gelöst] Kernel bauen im Jahr 2020
Hallo zusammen,
ich befasse mich derzeit wieder mit dem Thema Kernelbau. Ich habe ein Kernelmodul, das nicht so arbeitet wie es soll und will das upstream melden. Das habe ich vor ~10 Jahren schon einmal gemacht, damals habe ich den entwickelten Patch eingespielt und den kompletten Kernel neu gebaut. Allerdings war damals der Kernel nicht so umfangreich wie heute, ich war noch thematisch im Thema Kernelbau „drin“ und ich hatte auch zeitgemäße Hardware.
Um es kurz zu machen: Ich möchte wegen einem Modul nicht den kompletten Kernel neu bauen, weil meine antike Hardware das gar nicht hergibt.
Hat sich in der Zwischenzeit etwas in Sachen Patching getan? Ich habe in dem Zusammenhang von „Live-Patching“ gelesen, allerdings bin ich mir unsicher, ob das in meinem Fall anwendbar ist.
Wenn ich um den Neubau des Kernels nicht herumkomme: Ich spiele mit dem Gedanken mir dafür stunden-/tageweise einen potenten vServer zu mieten. Welche Empfehlungen/Erfahrungen könnt ihr mir dafür geben?
ich befasse mich derzeit wieder mit dem Thema Kernelbau. Ich habe ein Kernelmodul, das nicht so arbeitet wie es soll und will das upstream melden. Das habe ich vor ~10 Jahren schon einmal gemacht, damals habe ich den entwickelten Patch eingespielt und den kompletten Kernel neu gebaut. Allerdings war damals der Kernel nicht so umfangreich wie heute, ich war noch thematisch im Thema Kernelbau „drin“ und ich hatte auch zeitgemäße Hardware.
Um es kurz zu machen: Ich möchte wegen einem Modul nicht den kompletten Kernel neu bauen, weil meine antike Hardware das gar nicht hergibt.
Hat sich in der Zwischenzeit etwas in Sachen Patching getan? Ich habe in dem Zusammenhang von „Live-Patching“ gelesen, allerdings bin ich mir unsicher, ob das in meinem Fall anwendbar ist.
Wenn ich um den Neubau des Kernels nicht herumkomme: Ich spiele mit dem Gedanken mir dafür stunden-/tageweise einen potenten vServer zu mieten. Welche Empfehlungen/Erfahrungen könnt ihr mir dafür geben?
Zuletzt geändert von Tintom am 18.08.2020 18:58:37, insgesamt 2-mal geändert.
Re: Kernel bauen im Jahr 2020
Heutzutage gibt’s DKMS, mit dem man ’n Modul von Dritten recht problemlos für den vorliegenden Kernel bauen kann. Dazu ist’s notwendig, dass der Code des Moduls in passender Form vorliegt.Ich möchte wegen einem Modul nicht den kompletten Kernel neu bauen, weil meine antike Hardware das gar nicht hergibt.
- schorsch_76
- Beiträge: 2544
- Registriert: 06.11.2007 16:00:42
- Lizenz eigener Beiträge: MIT Lizenz
Re: Kernel bauen im Jahr 2020
Kernel bauen ist nicht schlimm. Auf einem Pi4 dauert der ganze Kernel 2h. Deine Hardware wird sicher schneller sein als ein Pi4
- Livingston
- Beiträge: 1454
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Kernel bauen im Jahr 2020
Ich habe ein ähnliches Problem, komme aber gerade nicht dazu, mich damit zu befassen. Das hier https://stackoverflow.com/questions/874 ... 2#44204152 sieht jedenfalls vielversprechnd aus.
- Livingston
- Beiträge: 1454
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Kernel bauen im Jahr 2020
So, endlich vollbracht. Ich liefer hier mal ein Beispiel für das Modul rtc_rs5c372.ko, dass auf meiner ARM-Plattform verbaut werden möchte. Es befindet sich zwar in der kernel source, liegt aber nicht im fertigen Image-Paket vor.
Die ursprüngliche Buster-Installation läuft mit folgendem Kernel:
Zu installieren:
Vielleicht müssen auch noch manuell gcc, make, build-essential, libncurses-dev, libssl-dev oder anderer Krempel dazukommen, aber den hat man ja eh schon drauf, wenn man sich mit Kernel-Compilieren befasst.
Ich baue gerne ohne root-Rechte, deshalb wird erst mal die source im Home-Verzeichnis entpackt und rein-cdt:
Da sich das zu bauende Modul auf den konkreten, laufenden Kernel bezieht, müssen die oberen Zeilen von Makefile
angepasst werden und gemäß uname -r (s.o.) nach dem Editieren so aussehen:
Als nächstes wird das config-File des laufenden Kernels in die source gepackt
und das entsprechende Modul mit make menuconfig - oder was auch immer beliebt - ausgewählt. Um das Ganze zu scripten wäre hier ein Eingriff mit sed oder awk sinnvoll. make menuconfig hat den Vorteil, dass man bei der Modul-Auswahl über help bequem an weitere Infos kommt, vor allem Modulname und Verzeichnis innerhalb der source:
Nach dem Speichern noch mal checken:
Die Symboltabelle des aktuellen Kernels muss auch noch rüber:
den "." am Ende für das aktuelle Arbeitsverzeichnis beachten!
Die folgenden Schritte erfolgen in einem normalen make automatisch, müssen aber für die hier beschriebene Methode manuell ausgeführt werden:
Kleine Falle: Sollte zwischendurch eine Fehlermeldung bei dem Schritt HOSTCC scripts/extract-cert auftauchen, muss noch libssl-dev nachinstalliert werden.
Danach kann man sich endlich an das eigentliche Modul heranmachen. Die notwendigen Infos haben wir bereits in make menuconfig / help gefunden:
Ich denke, hier hätte man noch vorausgewählte Module abwählen können.
Am Ende Rüberkopieren, Modulabhängigkeiten klären, Modul laden, checken und u.U. initramfs updaten. Das macht man natürlich als root:
Da ich su statt su - benutzt habe, um im source-Verzeichnis zu bleiben, befindet sich /sbin nicht in $PATH.
Mit su - kann man sich das klemmen, muss aber erst mal wieder ins Verzeichnis rein oder gleich die absoluten Pfade beim Kopieren verwenden.
Das war's auch schon.
TODO: Ich werde diesen Beitrag demnächst wikifizieren und schauen, wie sich das Ganze scripten lässt (uname aufbröseln, Pfade extrahieren, Pakete nachinstallieren).
EDIT: Nachtrag zu su / su -
EDIT: Typos rausgeholt und TODO ergänzt.
Die ursprüngliche Buster-Installation läuft mit folgendem Kernel:
Code: Alles auswählen
#uname -r
4.19.0-9-armmp
Code: Alles auswählen
#aptitude / #apt-get install linux-source-4.19 linux-headers-4.19
Ich baue gerne ohne root-Rechte, deshalb wird erst mal die source im Home-Verzeichnis entpackt und rein-cdt:
Code: Alles auswählen
$cd ~
$tar xvJf /usr/src/linux-source-4.19.tar.xz
$cd linux-source-4.19
Code: Alles auswählen
$head -n5 Makefile
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
SUBLEVEL = 118
EXTRAVERSION =
Code: Alles auswählen
$head -n5 Makefile
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
SUBLEVEL = 0
EXTRAVERSION = -9-armmp
Code: Alles auswählen
$cp /boot/config-4.19.0-9-armmp .config
Code: Alles auswählen
CONFIG_RTC_DRV_RS5C372:
If you say yes here you get support for the
Ricoh R2025S/D, RS5C372A, RS5C372B, RV5C386, and RV5C387A RTC chips.
This driver can also be built as a module. If so, the module
will be called rtc-rs5c372.
Symbol: RTC_DRV_RS5C372 [=m]
Type : tristate
Prompt: Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A
Location:
-> Device Drivers
-> Real Time Clock (RTC_CLASS [=y])
Defined at drivers/rtc/Kconfig:375
Depends on: RTC_CLASS [=y] && I2C [=y]
Code: Alles auswählen
$grep RS5C372 .config
CONFIG_RTC_DRV_RS5C372=m
Code: Alles auswählen
$cp /usr/src/linux-headers-4.19.0-9-armmp/Module.symvers .
Die folgenden Schritte erfolgen in einem normalen make automatisch, müssen aber für die hier beschriebene Methode manuell ausgeführt werden:
Code: Alles auswählen
$make scripts
$make prepare
$make modules_prepare
Danach kann man sich endlich an das eigentliche Modul heranmachen. Die notwendigen Infos haben wir bereits in make menuconfig / help gefunden:
Code: Alles auswählen
$make -C . M=drivers/rtc modules
make: Verzeichnis „/home/lstone/linux-source-4.19“ wird betreten
CC [M] drivers/rtc/rtc-cmos.o
CC [M] drivers/rtc/rtc-mc13xxx.o
CC [M] drivers/rtc/rtc-rs5c372.o
Building modules, stage 2.
MODPOST 3 modules
CC drivers/rtc/rtc-cmos.mod.o
LD [M] drivers/rtc/rtc-cmos.ko
CC drivers/rtc/rtc-mc13xxx.mod.o
LD [M] drivers/rtc/rtc-mc13xxx.ko
CC drivers/rtc/rtc-rs5c372.mod.o
LD [M] drivers/rtc/rtc-rs5c372.ko
make: Verzeichnis „/home/lstone/linux-source-4.19“ wird verlassen
Am Ende Rüberkopieren, Modulabhängigkeiten klären, Modul laden, checken und u.U. initramfs updaten. Das macht man natürlich als root:
Code: Alles auswählen
$su
#cp drivers/rtc/rtc-rs5c372.ko /lib/modules/4.19.0-9-armmp/kernel/drivers/rtc/
#/sbin/depmod -a
#/sbin/modprobe rtc-rs5c372
#/sbin/lsmod|grep rtc
rtc_rs5c372 16384 0
#/sbin/update-initramfs -u
Mit su - kann man sich das klemmen, muss aber erst mal wieder ins Verzeichnis rein oder gleich die absoluten Pfade beim Kopieren verwenden.
Das war's auch schon.
TODO: Ich werde diesen Beitrag demnächst wikifizieren und schauen, wie sich das Ganze scripten lässt (uname aufbröseln, Pfade extrahieren, Pakete nachinstallieren).
EDIT: Nachtrag zu su / su -
EDIT: Typos rausgeholt und TODO ergänzt.
Re: Kernel bauen im Jahr 2020
Wenn das Modul in den Sources enthalten ist, kannst Du das auch einfacher haben.
Die benötigten Pakete zum Kompilieren und die passenden Headers hast Du bereits, dann im Verzeichnis ein:
make oldconfig
make menuconfig
das gewünschte Modul aktivieren mit *
speichern und das Verzeichnis verlassen
dann als root
make bindeb-pkg
Nun werden die Pakete gebaut und können anschließend mit dpkg -i installiert werden.
Die Hardware ist mir nicht vertraut, aber wenn Du mehrere Kerne hast, kannst Du die verwenden mit
make -j4 bindeb-pkg (für z.B. vier Kerne)
So baue ich in 2020 (und auch schon früher) meine Kernel...;-)
Die benötigten Pakete zum Kompilieren und die passenden Headers hast Du bereits, dann im Verzeichnis ein:
make oldconfig
make menuconfig
das gewünschte Modul aktivieren mit *
speichern und das Verzeichnis verlassen
dann als root
make bindeb-pkg
Nun werden die Pakete gebaut und können anschließend mit dpkg -i installiert werden.
Die Hardware ist mir nicht vertraut, aber wenn Du mehrere Kerne hast, kannst Du die verwenden mit
make -j4 bindeb-pkg (für z.B. vier Kerne)
So baue ich in 2020 (und auch schon früher) meine Kernel...;-)
- Livingston
- Beiträge: 1454
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Kernel bauen im Jahr 2020
Ich will ja eben keinen kompletten Kernel bauen sondern nur genau ein Modul. Das war ja auch die Fragestellung von Tintom.
Kannst ja mal versuchen, auf einem altersschwachen SoC einen Kernel zu bauen. U.U. geht das gar nicht, weil gar kein Platz vorhanden ist, ganz zu schweigen von der benötigten Zeit. Ok, ok, man kann natürlich nostalgisch werden und sagen, früher - Anfang 90'er - da nach hatten wir noch keine Module. Da haben wir immer den kompletten Kernel selbst gebacken (was auch zutrifft: So ein 386'er konnte ganz schön heißlaufen) - Zeit spielt keine Rolle.
Kannst ja mal versuchen, auf einem altersschwachen SoC einen Kernel zu bauen. U.U. geht das gar nicht, weil gar kein Platz vorhanden ist, ganz zu schweigen von der benötigten Zeit. Ok, ok, man kann natürlich nostalgisch werden und sagen, früher - Anfang 90'er - da nach hatten wir noch keine Module. Da haben wir immer den kompletten Kernel selbst gebacken (was auch zutrifft: So ein 386'er konnte ganz schön heißlaufen) - Zeit spielt keine Rolle.
Re: Kernel bauen im Jahr 2020
Na gut, dann war meine Idee nix... wie gesagt, ich kenne solche Hardware nicht, aber Du hast es ja bereits gelöst.
Vergiß meinen Hinweis...
Vergiß meinen Hinweis...