(gelöst) bindeb-pkg

[guennid]

Wie verhindert man, das bindeb-pkg ein solches Namensmonstrum gebiert: linux-image-4.19.75t2.0_4.19.75t2.0-1_amd64.deb? t2.0 ist die von mir gewünschte lokale Version.

[ren22]

Indem man errät welche Befehle, welche Sourcen und welche patches Du anwendest ??

[JTH]

Ich könnt mir vorstellen, dass das nicht vorgesehen ist. Das folgt nunmal dem üblichen Schema NAME_VERSION_ARCHITEKTUR.deb (Name=linux-image-4.19.75t2.0, Version=4.19.75t2.0-1, Architektur=amd64). Die Kernelversion kommt halt per Konvention auch im Paketnamen vor.

Wenns dich nur einmalig stört: Einfach umbenennen. Der Name des .debs ist technisch irrelevant, guenther.deb geht auch.

Noch mehr anhängen ginge z.B. die -1 in der Version (durch mehr Zeichen) ersetzen.

[guennid]

@JTH Danke!

Ich könnt mir vorstellen, dass das nicht vorgesehen ist.

Das hatte ich befürchtet.

Einfach umbenennen.

So mach' ich's seit Jahr und Tag, aber ich mach's ungern! , insbeosndere weil in der config und vor allem im vmlinuz unter /boot ja nix mehr übrig bleibt von der lokalen Version. Ich hatte gehofft, das wenigstens das durch die Ablösung von kpkg durch bindeb-pkg ermöglicht worden wäre.

Mal abwarten. Vielleicht kommt noch jemand mit 'ner schlaueren Idee.

Grüße, Günther

[JTH]

[…] insbeosndere weil in der config und vor allem im vmlinuz unter /boot ja nix mehr übrig bleibt von der lokalen Version.

Wie meinst du denn das genau? Sieht es bei dir nicht in etwa so aus (konstruiert)?

Code: Alles auswählen

$ dpkg-deb -c linux-image-xyz.deb | grep ./boot
drwxr-xr-x root/root         0 2019-11-09 16:42 ./boot/
-rw-r--r-- root/root   3631874 2019-11-09 16:42 ./boot/System.map-5.3.0-2t2.0
-rw-r--r-- root/root    221867 2019-11-09 16:42 ./boot/config-5.3.0-2t2.0
-rw-r--r-- root/root   5549808 2019-11-09 16:42 ./boot/vmlinuz-5.3.0-2t2.0

Wenn nicht, wäre doch interessant zu wissen, wie genau baust.

[guennid]

„t2.0“
Sowas habe ich bei vmlinuz noch nie gesehen, weder mit:

Code: Alles auswählen

make-kpkg --revision=0.t2 linux-image

(die Option --revision verlangte bisher eine Zahl am Anfang) noch mit

Code: Alles auswählen

make bindeb-pkg LOCALVERSION=t2.0 KDEB_PKGVERSION=$(make kernelversion)-1

, noch mit:

Code: Alles auswählen

make bindeb-pkg LOCALVERSION=t2.0

Nichtsdestotrotz erstellen alle Kommandos fehlerfrei laufende Versionen von z.B. vmlinuz-4.19.75, die - soweit's bindeb-pkg - betrifft - allesamt aus dem Paket mit Namen 4.19.75t2.0_4.19.75t2.0-1_amd64.deb generiert werden

Grüße, Günther

[towo]

Code: Alles auswählen

make bindeb-pkg LOCALVERSION=-amdsystem-towo1 KDEB_PKGVERSION=$(make kernelversion) -j16

ergibt

Code: Alles auswählen

~
towo:Defiant> ls -al /boot
insgesamt 39161
drwxr-xr-x  4 root root     4096 Nov 11 19:24 .
drwxr-xr-x 21 root root     4096 Okt 31 14:41 ..
-rw-r--r--  1 root root   207887 Nov 11 16:46 config-5.4.0-rc7-amdsystem-towo1
drwxr-xr-x  3 root root     1024 Jan  1  1970 efi
drwxr-xr-x  6 root root     4096 Nov 11 19:24 grub
-rw-r--r--  1 root root 28957863 Nov 11 16:56 initrd.img-5.4.0-rc7-amdsystem-towo1
-rw-r--r--  1 root root  4142684 Nov 11 16:46 System.map-5.4.0-rc7-amdsystem-towo1
-rw-r--r--  1 root root  6772096 Nov 11 16:46 vmlinuz-5.4.0-rc7-amdsystem-towo1

Exakt wie es sein soll.

[guennid]

Wenn ich nichts übersehe, sehe ich zwei Unterschiede zu meinem 2. bindeb-pkg-Kommando: 1. das -j16 am Ende statt -1 2. das nirgendwo im Kommando erscheinende -rc7. Falls richtig gesehen: Kann mir das jemand erklären?

Zusatz: ich nutze ausschließlich die Quellen von kernel.org

Grüße, Günther

[towo]

-j16 sagt, mit 16 Threads kompilieren, das hat mit deinem -1 bei KDEB_PKGVERSION=$(make kernelversion)-1 nichts zu tun

rc7 steht im Makefile.

[guennid]

Mir erklärt das immer noch nicht, wieso bei dir die lokale Version auch in vmlinuz erscheint, bei mir aber nicht. Liegt es an den Einstellungen in menuconfig unter general setup/local version? Das habe ich immer weggelassen, weil ich bei früheren Kompilationen bemerkt zu haben glaubte, dass das noch monströsere Paketnamen produzierte.

Grüße, Günther

[towo]

Code: Alles auswählen

towo:Defiant> grep -i localversion /boot/config-5.4.0-rc7-amdsystem-towo1 
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

[JTH]

Liegt es an den Einstellungen in menuconfig unter general setup/local version?

Nein, mit dem Configeintrag kannst du anstelle LOCALVERSION beim make-Aufruf nen Suffix angeben. Damit das nicht bei jedem make-Aufruf passieren muss.

Man kann allerdings auch beide gleichzeitig setzen, das ist nicht das, was du suchst:
-foo in General setup/Local version plus LOCALVERSION=-bar ergibt den handlichen Namen linux-image-5.3.9-foo-bar_5.3.9-foo-bar-1_amd64.deb

[guennid]

Was vmlinuz angeht:
in meiner config stehen genau die gleichen beiden Einträge, die towo gepostet hat.

Ansonsten: im Paketnamen stört mich am meisten, das für mich sinnfreie Dopelt-Gemoppelt von Version und lokaler Version., also bei mir zuletzt 4.19.75t2.0_4.19.75t2.0 Was soll das?

Grüße, Günther

[JTH]

Ansonsten: im Paketnamen stört mich am meisten, das für mich sinnfreie Dopelt-Gemoppelt von Version und lokaler Version., also bei mir zuletzt 4.19.75t2.0_4.19.75t2.0 Was soll das?

Das ergibt sich, wie oben angerissen, aus Konventionen.

Der Dateiname setzt sich so zusammen: PAKETNAME_PAKETVERSION_PAKETARCHITEKTUR.deb.
Den Dateinamen legt ganz unten beim Bau von jeglichen Debianpaketen, das Werkzeug fest, das letztendlich alle Dateien zu einem Paket verpackt/archiviert: dpkg-deb. Ist wie gesagt für dpkg irrelevant, aber aus anderen Gründen sinnvoll.

Beim Kernel wird der PAKETNAME gebildet als linux-image-KERNELVERSION. Deshalb taucht die VERSION zweimal im Dateinamen auf. Wäre die KERNELVERSION hier nicht im PAKETNAMEN, könntest du auf deinem System nie ohne weiteres (per apt/dpkg) zwei verschiedene Kernelversionen installieren – du hättest nur ein linux-image in den dann verschiedenen Kernelversionen.

Noch ein Vorschlag, wenn du deine „lokale“ Version nur einmal haben willst:

Code: Alles auswählen

$ make bindeb-pkg KDEB_PKGVERSION=$(make kernelversion)t2.0

Damit tauch t2.0 nur einmal im Dateinamen auf. 4.x.y bleibt aber doppelt. vmlinux-x.y.z enthält damit aber nicht deine „lokale“ Version.

Anderer Vorschlag: Wenn du deine Pakete partout anders benennen willst: Ersetz in der Kernelquellen in der Datei scripts/package/mkdebian die Zeile (~64)

Code: Alles auswählen

packagename=linux-image-$version

durch

Code: Alles auswählen

packagename=guenthers-linux-image

o.ä. – ungetestet.

[guennid]

wenn du deine „lokale“ Version nur einmal haben willst:

Ich will keine Dopplung, nicht eine nur teilweise Dopplung (Kernel-Version.) Ich kann keinen Sinn erkennen in 2x(Version+lokaler Version). Das ist schlicht redundant.
Konventionen können auch schlecht sein. Und hier sind sie's - meiner Meinng nach. Aber lassen wir das. Es ist mir nicht so wichtig. Ich find' mich damit ab, dass ein übersichtlicherer Paketname, der trotzdem alle Information enthält, z.Z. kaum möglich ist.
Das Ergebniss von

packagename=guenthers-linux-image

werde ich mir vielleicht mal anschauen, obwohl ich beim ersten Lesen skeptisch ist, ob das in die Richtung geht, die mir vorschwebt. Ich will ja keinesfalls die Bezeichnung der Kernel-Version im Paketnamen verlieren.


Viel interessanter ist, warum towo die lokale Version im vmlinuz-Namen hat und ich nicht.

Grüße, Günther

[KP97]

Nur mal so zum Vergleich mein /boot, wobei ich den Kernel ohne zusätzliche lokale Version kompiliere:

-rw-r--r-- 1 root root 144619 Nov 10 13:29 config-5.3.10
drwxr-xr-x 3 root root 4096 Sep 8 2018 efi
drwxr-xr-x 6 root root 4096 Nov 10 13:59 grub
-rw-r--r-- 1 root root 5329176 Nov 11 12:36 initrd.img-5.3.10
-rw-r--r-- 1 root root 3777403 Nov 10 13:29 System.map-5.3.10
-rw-r--r-- 1 root root 6747520 Nov 10 13:29 vmlinuz-5.3.10

Mein fertiges Paket heißt auch genau so, nämlich linux-image-5.3.10
Ich nehme an, daß Du immer nur einen Kernel installiert hast und die Pakete an anderer Stelle aufbewahrst, falls Du mehrere hast. Da könntest Du ja dann die fertigen Pakete entsprechend umbenennen, falls Du doch mal eine andere Version installieren willst.

[guennid]

Meine vmlinuze sehen zunächst genauso aus wie deine. Und das entsprechende Verzeichnis unter /lib/modules hat dann auch nur diese Kernel-Versions-Bezeichnung. Ich habe mich deswegen bisher noch nie getraut, zwei Kernel der gleichen Kernel-Version aber mit eigener unterschiedlicher lokaler Version zu installieren.

Grüße, Günther

[JTH]

wenn du deine „lokale“ Version nur einmal haben willst:

Ich will keine Dopplung, nicht eine nur teilweise Dopplung (Kernel-Version.) Ich kann keinen Sinn erkennen in 2x(Version+lokaler Version). Das ist schlicht redundant.
Konventionen können auch schlecht sein. Und hier sind sie's - meiner Meinng nach.

Trotzdem noch als Ergänzung: Der ganze Debian-Werkzeugkasten – den letztendlich auch die kernel.org-Quellen benutzen – zielt halt darauf, dass dein Paket potentiell irgendwann auch im Debian-/in einem Repository landet. Dort liegen dann mitunter viele gleichnamige Pakete gleicher und unterschiedlicher Versionen und Architekturen in einem Ordner, z.B. hier http://ftp.debian.org/debian/pool/main/l/linux-latest/. Da funktioniert es nicht, wenn du nur ein linux-image.deb oder auch linux-image_3.14.15-42.deb gebaut hast, es geht ohne eine Konvention wie NAME_VERSION_ARCHITEKTUR.deb nicht.

[KP97]

Günther, ich habe jetzt extra nochmal einen weiteren 5.3.10 kompiliert (geht bei mir schnell). Dabei habe ich im entpackten Verzeichnis in der Datei Makefile
die Zeile EXTRAVERSION geändert:

# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 3
SUBLEVEL = 10
EXTRAVERSION = kern2
NAME = Bobtail Squid

Nach Installation des Paketes sieht es in /boot so aus:

root@MB:/boot# ll
insgesamt 31280
-rw-r--r-- 1 root root 144619 Nov 10 13:29 config-5.3.10
-rw-r--r-- 1 root root 144624 Nov 12 17:19 config-5.3.10kern2
drwxr-xr-x 3 root root 4096 Sep 8 2018 efi
drwxr-xr-x 6 root root 4096 Nov 12 17:35 grub
-rw-r--r-- 1 root root 5329176 Nov 11 12:36 initrd.img-5.3.10
-rw-r--r-- 1 root root 5330152 Nov 12 17:35 initrd.img-5.3.10kern2
-rw-r--r-- 1 root root 3777403 Nov 10 13:29 System.map-5.3.10
-rw-r--r-- 1 root root 3777403 Nov 12 17:19 System.map-5.3.10kern2
-rw-r--r-- 1 root root 6747520 Nov 10 13:29 vmlinuz-5.3.10
-rw-r--r-- 1 root root 6747520 Nov 12 17:19 vmlinuz-5.3.10kern2

Der Kernel ist also mit einem neuen Namen zusätzlich vorhanden, auch in /lib/modules ist ein zweites Verzeichnis mit dem kern2 im Namen vorhanden.
Jetzt kommt sich nichts ins Gehege, und ist auch simpel durch das Ändern im Makefile zu erstellen.

[towo]

Also ich ändere am Makefile nichts

Code: Alles auswählen

~
towo:Defiant> grep EXTRAVERS /usr/src/linux-headers-5.4.0-rc7-amdsystem-towo1/Makefile 
EXTRAVERSION = -rc7
KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

gebaut habe ich mit

Code: Alles auswählen

make bindeb-pkg LOCALVERSION=-amdsystem-towo1 KDEB_PKGVERSION=$(make kernelversion) -j16

Und da kommen die normalen debs raus:

Code: Alles auswählen

linux-headers-5.4.0-rc7-amdsystem-towo1_5.4.0-rc7_amd64.deb
linux-image-5.4.0-rc7-amdsystem-towo1_5.4.0-rc7_amd64.deb

und dann das:

Code: Alles auswählen

~/daten2/kernel
towo:Defiant> ls -al /boot/
insgesamt 39289
drwxr-xr-x  4 root root     4096 Nov 11 20:57 .
drwxr-xr-x 21 root root     4096 Okt 31 14:41 ..
-rw-r--r--  1 root root   207887 Nov 11 16:46 config-5.4.0-rc7-amdsystem-towo1
drwxr-xr-x  3 root root     1024 Jan  1  1970 efi
drwxr-xr-x  6 root root     4096 Nov 11 19:24 grub
-rw-r--r--  1 root root 29086224 Nov 11 20:57 initrd.img-5.4.0-rc7-amdsystem-towo1
-rw-r--r--  1 root root  4142684 Nov 11 16:46 System.map-5.4.0-rc7-amdsystem-towo1
-rw-r--r--  1 root root  6772096 Nov 11 16:46 vmlinuz-5.4.0-rc7-amdsystem-towo1

[guennid]

So, ich habe towos Beispielkommando mal so abgeändert durchgezogen:

Code: Alles auswählen

make bindeb-pkg LOCALVERSION=-x61.0 KDEB_PKGVERSION=$(make kernelversion) -j16

Nach wie vor keine Ahnung was -j16 bedeutet und ob ich das weglassen kann. Das Kommando liefert zwar immer noch diesen unsäglichen Paketnamen linux-image-4.19.84-x61.0_4.19.84_amd64.deb aber immerhin, im vmliuz erscheint jetzt die lokale Version. Für mich ist das eine Verbesserung. Den Overhead im Vergleich zu make-kpkg muss man halt händiusch löschen. Ach ja: Wie „säubert“ man mit bindeb-pkg im Nachtrag die Umgebung? make-kpkg clean tut's anscheinend nicht mehr.

zu JTH

Da funktioniert es nicht, wenn du nur ein linux-image.deb oder auch linux-image_3.14.15-42.deb

Ich halte das für untaugliche Beispiele: Warum geht 3.14.15-x61.0-amd64.deb nicht? Warum muss die Kernel-Version 2x erscheinen?

[towo]

Ach ja: Wie „säubert“ man mit bindeb-pkg im Nachtrag die Umgebung? make-kpkg clean tut's anscheinend nicht mehr.

Code: Alles auswählen

make clean

oder

Code: Alles auswählen

make distclean

Nach wie vor keine Ahnung was -j16 bedeutet und ob ich das weglassen kann.

Hab ich doch schonmal geschrieben! Das gibt die Anzahl der zu verwendenden Threads für's Kompilieren an.

[guennid]

Hab ich doch schon mal geschrieben!

Ja, ich weiß, wollt' ich gerade noch nachgucken. Warst aber schneller! 'Tschuldigung! Was weiß ich, was in dem Zusammenhang „Threads“ sind?

[JTH]

Da funktioniert es nicht, wenn du nur ein linux-image.deb oder auch linux-image_3.14.15-42.deb

Ich halte das für untaugliche Beispiele: Warum geht 3.14.15-x61.0-amd64.deb nicht? Warum muss die Kernel-Version 2x erscheinen?

Du meinst damit ein linux-image_3.14.15-x61.0_amd64.deb? Das Paket hieße damit „linux-image“ und hätte die Version 3.14.15-x61.0, für die Architektur amd64. Du könntest damit per apt/dpkg den Kernel (das imaginäre Paket linux-image) nur in einer einzigen Version installiert haben. Das ist aus vielen Gründen unpraktisch und riskant.

Deshalb gibt es Pakete mit dem Namen linux-image-4.19.0-5-amd64, linux-image-5.3.0-1-amd64, linux-image-5.3.0-2-amd64 etc., die kann man wegen der unterschiedlichen Namen nebeneinander installieren.

Das die Architektur in den Namen oben auch nochmal redundant auftaucht, ist vermutlich Multiarch und anderem geschuldet. (linux-image-5.3.0-2-amd64 steckt in einem linux-image-5.3.0-2-amd64_5.3.9-2_amd64.deb – Name_Version_Architektur.deb.)

Ein Paket lässt sich im Dateinamen im Repository halt nur mit Name, Version & Architektur eindeutig benennen.

[guennid]

Das die Architektur in den Namen oben auch nochmal redundant auftaucht, ist vermutlich Multiarch und anderem geschuldet.

Ich halt mich mal ans „vermutlich“. Als „notwendig“ einzusehen vermag ich's nicht, denn dass

Ein Paket sich im Dateinamen im Repository halt nur mit Name, Version & Architektur eindeutig benennen (lässt)

, ist ja in meinem letzten Beispiel (ohne Redundanz) berücksichtigt.

Grüße, Günther

und danke für die ausführlichen Erläuterungen!