(aufgegeben) brauche hilfe zum kernelbau nach anleitung zwecks bugreport patch test

[michaa7]

Nach bugreport wurde ich vom entsprechenden Debian maintainer gebeten einen patch zu testen.

Dies Anleitung hat er verlinkt:
https://kernel-team.pages.debian.net/ke ... mmon-tasks

Habe nach Anleitung installiert, wobei mir die Punkte
4.1
# apt-get install linux-source-4.3

und

4.2.1.
$ apt-get source linux

redundant vorkommen. 4.1 habe ich gemacht, 4.2.1 nicht.

Definitiv hänge ich hier 4.2.2. Die devscripts habe ich zwar installiert, aber mit
$ bash debian/bin/test-patches ../fix-bug123456.patch ../add-foo-driver.patch kann ich nichts anfangen

Ich befinde mich in meinem home in ~/linux-source-5.17$ . Hier gibt es natürlich kein debian verzeichnis.
Was mache ich falsch?

[JTH]

Ohne sonst weiter drauf einzugehen: Wenn du apt-get source benutzt, bekommst du die Quellen, aus denen du direkt ein Paket bauen kannst – inklusive des wichtigen debian/-Ordners.

[michaa7]

Ok, ich habe, was ich vorher vergessen hatte, in der sources.list... deb-src aktiviert und dann die linux sourcen installiert (als user) Habe jetzt das linux-<version> verzeichnis und darin einen debian ordner.

Jetzt muß ich noch schauen wie ich den patch aus der e-mail wohin auch immer kopiere ... das mache ich morgen.

Danke soweit.

[michaa7]

Die gesamte sektion "4.2.3. Applying patches or configuration changes" verstehe ich nicht.

Das ist der patch:

>From 8c0dbed07b388e7d97cecc184099caf80067a7bc Mon Sep 17 00:00:00 2001
From: Piotr Chmura <chmooreck@gmail.com>
Date: Thu, 31 Mar 2022 17:55:50 +0200
Subject: [PATCH] media: si2157: unknown chip version Si2147-A30 ROM 0x50

commit 3ae87d2f25c0e998da2721ce332e2b80d3d53c39 upstream.

Fix firmware file names assignment in si2157 tuner, allow for running
devices without firmware files needed.

modprobe gives error: unknown chip version Si2147-A30 ROM 0x50
Device initialization is interrupted.

Caused by:
1. table si2157_tuners has swapped fields rom_id and required vs struct
si2157_tuner_info.
2. both firmware file names can be null for devices with
required == false - device uses build-in firmware in this case

Tested on this device:
m07ca:1871 AVerMedia Technologies, Inc. TD310 DVB-T/T2/C dongle

[mchehab: fix mangled patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215726
Link: https://lore.kernel.org/lkml/5f660108-8 ... huis.info/
Link: https://lore.kernel.org/linux-media/c4b ... @gmail.com
Fixes: 1c35ba3bf972 ("media: si2157: use a different namespace for firmware")
Cc: stable@vger.kernel.org # 5.17.x
Signed-off-by: Piotr Chmura <chmooreck@gmail.com>
Tested-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/tuners/si2157.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 47029746b89e..0de587b412d4 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -77,16 +77,16 @@ static int si2157_cmd_execute(struct i2c_client *client, struct si2157_cmd *cmd)
}

static const struct si2157_tuner_info si2157_tuners[] = {
- { SI2141, false, 0x60, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
- { SI2141, false, 0x61, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
- { SI2146, false, 0x11, SI2146_11_FIRMWARE, NULL },
- { SI2147, false, 0x50, SI2147_50_FIRMWARE, NULL },
- { SI2148, true, 0x32, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2148, true, 0x33, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2157, false, 0x50, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
- { SI2158, false, 0x50, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2158, false, 0x51, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
- { SI2177, false, 0x50, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
+ { SI2141, 0x60, false, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
+ { SI2141, 0x61, false, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
+ { SI2146, 0x11, false, SI2146_11_FIRMWARE, NULL },
+ { SI2147, 0x50, false, SI2147_50_FIRMWARE, NULL },
+ { SI2148, 0x32, true, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2148, 0x33, true, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2157, 0x50, false, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
+ { SI2158, 0x50, false, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2158, 0x51, false, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
+ { SI2177, 0x50, false, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
};

static int si2157_load_firmware(struct dvb_frontend *fe,
@@ -178,7 +178,7 @@ static int si2157_find_and_load_firmware(struct dvb_frontend *fe)
}
}

- if (!fw_name && !fw_alt_name) {
+ if (required && !fw_name && !fw_alt_name) {
dev_err(&client->dev,
"unknown chip version Si21%d-%c%c%c ROM 0x%02x\n",
part_id, cmd.args[1], cmd.args[3], cmd.args[4], rom_id);
--
2.36.0

Wohin gehört der kopiert?

[Tintom]

Laut Changelog ist der Patch im aktuellen Kernel 5.17.4 eingespielt. Entweder wartest du noch ein wenig bis der Kernel in sid eintrudelt oder du baust ihn selbst aus den Quellen von kernel.org

[michaa7]

Laut Changelog ist der Patch im aktuellen Kernel 5.17.4 eingespielt.

Ich weiß, das hat mir der maintainer auch schon mitgeteilt. Es geht jetzt eigentlich nur darum das einmal zu ende durchzukauen ... für das nächste mal. #Im siduction kernel ist das sowieso schon gepatcht.

... oder du baust ihn selbst aus den Quellen von kernel.org

Wie gesagt, es geht nicht darum dass ich einen gepatchten kernel brauche, den habe ich ja längst. Es geht darum den Prozess wie von maintainern angefragt zu kapieren ... für zukünftige Fälle.

[Tintom]

Gut, verstehe.

Erstmal grundsätzlich: git ist das Tool der Wahl für Kernelentwickler, d.h. du solltest zumindest das rudimentär verstehen. Der Patch wurde damit erzeugt, zum einspielen kannst Du git apply /pfad/zum/patch verwenden.

Patches werden immer für bzw. gegen eine bestimmte Kernelversion gebaut/angewendet. Hier ist es Kernel 5.17.3. Möchtest du den Patch nachvollziehen benötigst du möglichst exakt die selbe Version der Quellen für die der Patch gebaut wurde. Ist die Versionsnummer unterschiedlich besteht die Möglichkeit, dass die Anwendung des Patches scheitert.

Grundsätzlich wichtig, hier aber weniger relevant: Der Patch kommt von upstream, d.h. er sollte auf ungepatchte Quellen aus upstream angewendet werden. Debian selbst patcht seine Kernel jedoch, d.h. schlägt die Anwendung des Patches fehl weil du den Patch auf gepatchte Debian-Quellen ausführst bekommst du von upstream keine Unterstützung für dein Problem.

Die Datei /pfad/zum/patch enthält die Anweisungen was git genau machen soll (Hier wird die Syntax des Patches erläutert).

Vereinfacht gesagt sucht git apply anhand der Angaben des Patches in der Quelldatei (hier: drivers/media/tuners/si2157.c) in einer bestimmten Zeile (@@) einen bestimmten String (-) und ersetzt ihn durch einen anderen String (+). Deshalb ist die zugrunde liegende Kernelversion auch wichtig: Sofern eine andere Kernelversion verwendet wird, steht an besagter Stelle der Quelldatei mitunter eben nicht der definierte String und die Anwendung des Patches scheitert.

Um diesen Patch nachzuvollziehen besorgst du dir also die Quellen von Kernel 5.17.3 entweder von Kernel.org oder debian, entpackst den Kernel, wechselst in das entpackte Verzeichnis, führst ein git --init aus und wendest mit git apply /pfad/zum/patch den Patch an. Die Datei /pfad/zum/patch enthält den Text deines Postings beginnend mit diff --git a/drivers...

[michaa7]

Um diesen Patch nachzuvollziehen besorgst du dir also die Quellen von Kernel 5.17.3 entweder von Kernel.org oder debian, entpackst den Kernel, wechselst in das entpackte Verzeichnis, führst ein git --init aus und wendest mit git apply /pfad/zum/patch den Patch an. Die Datei /pfad/zum/patch enthält den Text deines Postings beginnend mit diff --git a/drivers...

Soweit es die Vorbereitungen betrifft habe ich alles *nach Anleitung des maintainers* gemacht:
https://kernel-team.pages.debian.net/ke ... tasks.html
Ich möchte bei dieser Anleitung bleiben.

Aber ich denke es ist egal ob ich mittels git oder quilt patche. Nur in welches Verzeichnis gehe ich, "linux-source-5.17" oder "linux-5.17.3"? (Nach Befolgen der Anleitung habe ich ja diese beiden Verzeichnisse, was ich schon nicht versteh wozu?)

Und wenn ich dich richtig verstehe muß ich aus dem geposteten patch alles *vor* "diff" löschen, das wird nicht automatisch ignoriert?

[Tintom]

Aber ich denke es ist egal ob ich mittels git oder quilt patche.

Mit quilt habe ich noch nicht gearbeitet, da kann evtl. jemand anderes etwas dazu sagen.

Nur in welches Verzeichnis gehe ich, "linux-source-5.17" oder "linux-5.17.3"? (Nach Befolgen der Anleitung habe ich ja diese beiden Verzeichnisse, was ich schon nicht versteh wozu?)

linux-5.17.3 ist vermutlich das entpackte Verzeichnis des Vanilla-Kerns, linux-source-5.17 sind die Quellen von Debian

Und wenn ich dich richtig verstehe muß ich aus dem geposteten patch alles *vor* "diff" löschen, das wird nicht automatisch ignoriert?

Das sollte die Sache vereinfachen. Du kannst natürlich auch die gesamte Email einlesen, siehe dazu man git-am

[michaa7]

...
linux-5.17.3 ist vermutlich das entpackte Verzeichnis des Vanilla-Kerns, linux-source-5.17 sind die Quellen von Debian

Das wiederspricht der Anleitung, und ein debian verzeichnis gibt es nur in linux-5.17.3 . Hier habe ich git apply /pfad/zu/patch ohne Fehler ausgeführt. Ein "git --init" wurde jedoch mit einem "Unbekannte Option: --init" beantwortet. (Edit://) es muss "git init" heißen(EDIT:) Ein anschließendes "git apply /pfad/zu/patch" lief jedoch ohne Fehler durch. Schaut für mich (??? ) so aus als wären die sourcen nun gepatcht.

Ich habe jetzt den buildprozess so angestoßen, ich hoffe das war richtig:

fakeroot make -f debian/rules.gen setup_amd64

?

[michaa7]

Ich habe mich jetzt durch die Anleitung durchgeraten so gut ich es vielleicht verstanden habe und der built prozess starte dann tatsächlich ( fakeroot make -f debian/rules.gen binary-arch_amd64) , brach aber schnell ab mit einem Fehler:

/home/<user>/linux-5.17.3/scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: Datei oder Verzeichnis nicht gefunden
25 | #include <openssl/opensslv.h>

Ich vermute, dass hier ein signierter Kernel gebaut werden soll und die Beschwerde auf mein *nicht vorhandenes* Zertifikat verweist?

A: Ist diese Vermutung richtig?
B: an welcher Stelle kann ich für einen nicht signierten Kernel sorgen?



EDIT://
Alles Quark, es fehlte nur "libssl-dev"

[michaa7]

So, nach 3-4 std. ist da nun irgendetwas herausgekommen, vielleicht. Zumindest sind 2 Fehler herausgekommen, ob es auch ein kernel gibt und ob der läuft weiß ich nicht.

...
...
+ make -f /home/mh/linux-5.17.3/scripts/Makefile.modpost MODPOST_VMLINUX=1
scripts/mod/modpost -m -o vmlinux.symvers vmlinux.o
+ info MODINFO modules.builtin.modinfo
+ printf %-7s %s\n MODINFO modules.builtin.modinfo
MODINFO modules.builtin.modinfo
+ objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
+ info GEN modules.builtin
+ printf %-7s %s\n GEN modules.builtin
GEN modules.builtin
+ tr \0 \n
+ sed -n+ uniq
+ s/^[[:alnum:]:_]*\.file=//p
+ trsed -e s:^:kernel/: -e s/$/.ko/
\n
+ btf_vmlinux_bin_o=
+ is_enabled CONFIG_DEBUG_INFO_BTF
+ grep -q ^CONFIG_DEBUG_INFO_BTF=y include/config/auto.conf
+ btf_vmlinux_bin_o=.btf.vmlinux.bin.o
+ gen_btf .tmp_vmlinux.btf .btf.vmlinux.bin.o
+ local pahole_ver
+ command -v pahole
+ [ -x ]
+ echo BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
+ return 1
+ echo Failed to generate BTF for vmlinux
Failed to generate BTF for vmlinux
+ echo Try to disable CONFIG_DEBUG_INFO_BTF
Try to disable CONFIG_DEBUG_INFO_BTF
+ exit 1
make[2]: *** [/home/mh/linux-5.17.3/Makefile vmlinux] Error 1
make[2]: Leaving directory '/home/mh/linux-5.17.3/debian/build/build_amd64_none_amd64'
make[1]: *** [debian/rules.real:214: debian/stamps/build_amd64_none_amd64] Fehler 2
make[1]: Verzeichnis „/home/mh/linux-5.17.3“ wird verlassen
make: *** [debian/rules.gen:27: binary-arch_amd64_none_amd64_real] Fehler 2

War alles umsonst?
Wo fände ich den kernel, falls es einen gibt?
Wo liegt der Fehler?

[JTH]

[…] ob es auch ein kernel gibt und ob der läuft weiß ich nicht.

Evtl. schon irgendwo in debian/build/build_amd64_none_amd64 oder anderswo. Aber nach dem Fehler sicher noch nicht als fertiges Paket.

Wo liegt der Fehler?

Steht doch dort :

Code: Alles auswählen

BTF: .tmp_vmlinux.btf: pahole (pahole) is not available

Ein apt search BEGRIFF führt nicht selten zum Ziel. Hier liefert es für „pahole“ ein (oder mit Backports zwei) naheliegende, fehlende Pakete. Oder du schaltest CONFIG_DEBUG_INFO_BTF ab, wie ein paar Zeilen weiter unten vorgeschlagen:

Code: Alles auswählen

Try to disable CONFIG_DEBUG_INFO_BTF

[michaa7]

Eigentlioch hatte ich aufgegeben und dies auch dem maintainer mitgeteilt. Das problem ist anscheinen eh schon im kommenden kernel 5.17.4 gelöst. Ich wollte dies eben gerne für die zukunft durchgespielt haben, erfolgreich ....

Brauche ich pahole (ich=gcc z.B. beim compilieren des nvidiamoduls?)

.... und das Fehlen eines paketes fällt dem build system nach ca 3,5 std auf?

Die build time war vermutlich auch deswegen so lange weil ich die config unverändert übernommen habe. D.h. da wird viel mehr gebaut als ich brauche.
Gibt es irgend eine ruck zuck art - ohne jetzt alles bis ins detail zu optimieren - die config irgendwie sinnvoll einzuschränken?