(gelöst) apt(-get) dist-upgrade und Eigenbau-Kernels

[guennid]

Hmm, ich meine, sowas noch nicht gesehen zu haben:

Bei einem jessie dist-upgrade will mir apt meine Vanilla-Eigenbau-Kerne aktualisieren Was soll das?

[schwedenmann]

Hallo

Bei einem jessie dist-upgrade will mir apt meine Eigenbau-Kerne aktualisieren Was soll das?

Wenn du mal den Befehl und die Ausgabe posten würdest, incl. des gerade benutzen Kernels, können dir bestimmt Andere was erzählen.

mfg
schwedenmann

[Teddybear]

Meine Kristallkugel ist leider defekt..

[guennid]

Hmmm, also inwiefern ich hier ein Kristallkugelproblem erzeugt habe, erschließt sich mir derzeit nicht wirklich.

Code: Alles auswählen

# apt-get -s dist-upgrade | grep image-3.18.
  linux-image-3.16.0-4-amd64 linux-image-3.18.3 linux-image-4.2.5
Inst linux-image-3.18.3 [3a.x61] (3.x61 localhost [amd64])
Conf linux-image-3.18.3 (3.x61 localhost [amd64])
# apt-get -s dist-upgrade | grep image-4.2.
  linux-image-3.16.0-4-amd64 linux-image-3.18.3 linux-image-4.2.5
Inst linux-image-4.2.5 [0a.x61] (0.x61 localhost [amd64])
Conf linux-image-4.2.5 (0.x61 localhost [amd64])

Ich seh' da keinen Zuwachs an Info. Benötige, Kristallkugel betreffend, weiteres Scheunentorwinken

[rendegast]

Code: Alles auswählen

$ dpkg --compare-versions 3a.x61 lt 3.x61; echo $?
0

$ dpkg --compare-versions 0a.x61 lt 0.x61; echo $?
0

Inst linux-image-3.18.3 [3a.x61] (3.x61
Inst linux-image-4.2.5 [0a.x61] (0.x61

Ich erstelle das per

Code: Alles auswählen

#(VP, VPS werden aus dem Makefile extrahiert)
TMPf=$(makefile)
head Makefile | sed 's@[[:space:]]@@g' > $TMPf
. $TMPf
VP=${VERSION}.${PATCHLEVEL}
VPS=${VERSION}.${PATCHLEVEL}.${SUBLEVEL}
CUST=custom

make bindeb-pkg KERNELRELEASE=${VP}-$CUST  KDEB_PKGVERSION=$VPS

erstellt dann (Bsp.)
linux-image-4.2-custom_4.2.5_amd64.deb
Bei mir bleibt es bei einem Kompilat pro Sublevel,
>diverse< würden in CUST untergebracht.

[guennid]

Ich baue die Kerne mit

Code: Alles auswählen

make-kpkg --revision=???? linux-image

. Ich meine irgendwo hier aufgeschnappt zu haben, dass make-kpkg nicht mehr empfohlen werde, habe mich aber noch nicht darum gekümmert. Meine Version in der config anzugeben, habe ich nach einem Versuch schon vor Jahren aufgegeben. Das Ergebnis war mir in der Benennung zu monströs.

Die config und vmlinuz unter /boot, die bei der Installation des Images entstehen, benenne ich (in Anlehnung an die Revision) vor der Inbetriebnahme um, da die in der Numerierung bei meiner Methode immer gleich heißen, will sagen die Revision greift nur bei der Benennung des Images.

Meine Frage ging mehr dahin: Soweit ich erinnere, haben meine eigenen Kerne apt beim upgraden bisher nie interessiert. OK, apt veranstaltete nach der Installation eines Kernel-Images irgendas mit dem Bootloader, was eh nicht funktionierte - den richte ich mir selber ein.. Aber ich erinnere nicht, dass apt bei einem dist-upgrade Hand an die Eigenbau-Kerne legen wollte. Trügen mich da meine Erinnerungen?

[rendegast]

Wenn Du ein lokales Repo benutzt, greift der Auflösungsmechanismus von apt/apt-get/aptitude.

Code: Alles auswählen

apt-cache policy linux-image-4.2.5

ake-kpkg --revision=???? ...
...
Die config und vmlinuz unter /boot, die bei der Installation des Images entstehen, benenne ich (in Anlehnung an die Revision) vor der Inbetriebnahme um, da die in der Numerierung bei meiner Methode immer gleich heißen,

Und bei der Methode mit dem kerneleigenen debian-Skript heißt es dann
vmlinuz-$KERNELRELEASE
resp. hier würde daraus
vmlinuz-4.2-custom

[guennid]

Ok, hab's gesehen, aber vor allem wollte ich wissen, seit wann das so ist. Ich musste bisher nie einen Eigenbaukern auf hold setzen oder das deb aus meinem Repo verschieben. Mein Bestreben wäre eigentlich, dass der mir beim dist-ugrade keine solchen unsinnigen Upgrade-Vorschläge macht. Kann das daran liegen, dass ich die Kerne möglicherweise per dpkg, nicht über apt installiert habe?

[rendegast]

... dass der mir beim dist-ugrade keine solchen unsinnigen Upgrade-Vorschläge macht.

Mache Deine Kernelpaket-Versionen valide.

Ein Repo (auch wenn es für einen selbst ist) bedeutet da schon mit Sorgfalt vorzugehen.

Paketversions-Arithmetik ist dokumentiert,
resp. läßt sich mit obigem Instrument 'dpkg --compare-versions ... ... ...' per try+error nachvollziehen.
Deine Versionsvergabe scheint da eher "individuell".

... dass ich die Kerne möglicherweise per dpkg, nicht über apt installiert habe?

Das ist dem Resolver egal.



Aber zugegeben, machmal ist/scheint es auch verhext

Code: Alles auswählen

$ dpkg --compare-versions 3 gt 3a ; echo $?
1
$ dpkg --compare-versions 3.0 gt 3a.0 ; echo $?
0

Also 3a ist größer als 3,
aber 3.0 ist größer als 3a.0.

[guennid]

Mal sehen. Ich muss wissen, für welche meiner Maschinen welche Version des jeweiligen Kerns gebaut wurde. Ich weiß noch nicht, ob ich das via Config-Eintrag in make menuconfig hinkriege, so dass man's hinterher am Dateinamen des debs und vor allem der in /boot abgelegten config und vmlinuz erkennt. Ich will's versuchen. Deine shell-Syntax überfordert mich. Zur Not werden die debs eben aus meinem Repo entfernt.

[rendegast]

Du könntest arbeiten mit
--revision XXX
--append-to-version YYY
und
debian = ZZZ (in kernel-pkg.conf)(<-> '--revision')

ZBsp. ein Datumsstring

Code: Alles auswählen

# Makefile-artiger Syntax!
DTE = $(shell date +%Y%m%d)
debian = $(version)-$(DTE)-custom

Das Ergebnis Paketname/Paketversion ist am besten auszuprobieren.
ZBsp. gesetztes '--revision' überschreibt komplett 'debian =',
oder '--append-to-version' fließt in Paketname, Paketversion und vmlinuz-Name ein, wenn '--revision' NICHT gesetzt wird.


Außerdem kann mit Dateien localversion* im Kernelsource-Verzeichnis gespielt werden.

[guennid]

Danke für die Hinweise! Wie schon gesagt. Ich werd' mal experimentieren.

Und nochmal: Seit wann macht apt das: Berücksichtigung eigener kernel-debs im eigenen "Repo"? Ich meine immer noch, dass das Verhalten neu sei.

[rendegast]

Seit wann macht apt das: Berücksichtigung eigener kernel-debs im eigenen "Repo"?
Ich meine immer noch, dass das Verhalten neu sei.

Macht apt schon immer, das "eigen" und "kernel" ist ihm da egal.
Ist das Repo mit einem cert versehen, welches auf dem Client eingetragen ist,
braucht es keine explizite Bestätigung mehr, es ist dann auch automatisches Upgrade möglich.

[guennid]

Macht apt schon immer, das "eigen" und "kernel" ist ihm da egal

Hmmm, rendegast, ich spül' das nochmal hoch. Bist du dir da sicher?

Ich hab' das Spielchen jetzt mal auf zwei anderen Rechner nachgestellt, auf dem ich lange kein dist-upgrade mehr gefahren habe: Dort will apt keinen im Eigen-Repo vorhandenen Eigen-Kern nochmal upgraden. meine Versionsvergabe ist auch dort "speziell". Dort ist apt, z.B. 1.0.9.8.3. Auf der Maschine, auf der ich meine, es zum 1. Mal erlebt zu haben, ist apt 1.0.9.8.4

[pferdefreund]

Auf meinem alten 200Mhz hatte ich aus Performance-Gründen auch immer einen eigenen Kernel ohne initrd - notwendiges direkt einkompiliert. Den habe ich allerdings händig installiert und die offiziellen Debian-Kernel deinstalliert. Bootloader gecheckt und da gab es nie Komplikationen. So ein Eigenbau hat dann auch locker jedes dist-upgrade überlebt.

[rendegast]

Macht apt schon immer, das "eigen" und "kernel" ist ihm da egal

... Bist du dir da sicher?

Bin mir da sehr sicher, wenn Version und Priority stimmen, erfolgt ein upgrade.
Die Tools zur Kontrolle sind
'dpkg --compare-versions ...'
'apt-cache policy paket' (Paket-Priority)
'apt-cache policy | grep -v Translat' (Repo-Priority)

Eigen-Repo sind einfach nur Repo, Eigen-Kernel-Pakete sind einfach nur Pakete.
Für die Validität ist der Paketbauer/Repo-Admin verantwortlich.

[guennid]

Sag' ich doch! Genau das mache ich seit 2002 und apt hat sich nie um den Eigenbau-Kern gekümmert, agal ob via apt oder per dpkg installiert.

Bin mir da sehr sicher

Worüber? Wie gesagt: Bisher hat apt beim Upgraden meine eigenen Kerne ignoriert. Darüber bin ich mir mittlerweile auch sehr sicher. Ich wüsste nicht, was ich in letzter Zeit anders gemacht hätte. Das Verhalten ist definitiv neu. aber vielleicht lösen ja deine Tipps das Rätsel. Mal sehen.

[rendegast]

Bin mir da sehr sicher, ...

Worüber?

Über den Rest des Satzes:

Bin mir da sehr sicher, wenn Version und Priority stimmen, erfolgt ein upgrade.

Erläuterung

Bisher hat apt beim Upgraden meine eigenen Kerne ignoriert.

Du hast

Inst linux-image-3.18.3 [3a.x61] (3.x61 localhost [amd64])
Conf linux-image-3.18.3 (3.x61 localhost [amd64])

$ dpkg --compare-versions 3.x61 gt 3a.x61; echo $?
0

Beim Paket linux-image-3.18.3 wird eine höhere Version 3.x61 gefunden.
Das "-3.18.3" ist kein Teil der Version, sondern des Paketnamens.
Wenn Du mit "Bisher" einen Zustand meinst, daß bei einem Paket
linux-image-3.18.2 Version xxxxx
kein Upgrade durch ein Paket
linux-image-3.18.3 Version yyyyy
erfolgt, wäre das ein valides Verhalten, da es sich um verschiedene Pakete handelt.

[guennid]

Mache Deine Kernelpaket-Versionen valide.

Da hattest du wohl wieder mal recht

Irgendwie hatte ich wohl die image-Dateien wohl nach dem Kompilieren umbenannt. Ich hab's jetzt noch mal neu gebaut ohne nachträgliche Dateinamenänderung und nun verhält sich apt auch wie gewohnt, sprich, es versucht trotz meiner "speziellen" Versionierung nicht mehr, ein bereits installiertes Image beim dist-upgrade erneut zu installieren.

Grüße, Günther