Kernel-Updates unterbinden

[Hanisch]

Hallo,
für meinen DELL XPS L702x von 2010 brauche ich keine neueren Kernel mehr.
Wie kann ich das Update von Kernels auf neuere Versionen unterbinden?

Gruß
Ch. Hanisch

[DeletedUserReAsG]

Da würden mir zwei Möglichkeiten einfallen: das Paket auf hold setzen, oder das Paket mit der konkreten Version als manuell installiert markieren, statt das Metapaket zu nutzen.

Allerdings: warum glaubst du, bei dem Device keine Sicherheitsupdates zu benötigen? Am Netz hängt es ja offensichtlich – ansonsten würde sich die Frage schließlich nicht stellen.

[Hanisch]

Da würden mir zwei Möglichkeiten einfallen: das Paket auf hold setzen, oder das Paket mit der konkreten Version als manuell installiert markieren, statt das Metapaket zu nutzen.

Es handelt sich hier genau um die Distribution Siduction, wo die Kernels 6.2* beim Hochfahren Kernel-Panik bringen und ich ab Kernel 6.2* keine neueren Kernel mehr haben will. Also das gesamte Metapaket nicht mehr updaten möchte.

Grfuß
Ch. Hanisch

[DeletedUserReAsG]

Es handelt sich hier genau um die Distribution Siduction, wo die Kernels 6.2* beim Hochfahren Kernel-Panik bringen und ich ab Kernel 6.2* keine neueren Kernel mehr haben will.

Bei von Sid abgeleiteten Systemen würde ich den Kernel genau solange festnageln, bis das Problem behoben ist. Ansonsten wird es nämlich zwangsläufig irgendwann in der Zukunft passieren, dass dir das System zusammenfällt oder explodiert. Oder einfach so kaputt ist. Möglicherweise tötet es dann auch deine Topfpflanzen – aber das weiß man vorher nicht. Es ist jedenfalls nicht die Frage, ob das passiert, sondern nur wann – denn dass das nicht ewig gutgeht, ist sicher.

[Hanisch]

– denn dass das nicht ewig gutgeht, ist sicher.

Was also muß ich machen?

Code: Alles auswählen

$ sudo dpkg --configure -a
linux-headers-6.2.7-1-siduction-amd64 (6.2-7) wird eingerichtet ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.2.7-1-siduction-amd64:Sign command: /lib/modules/6.2.7-1-siduction-amd64/build/scripts/sign-file
Binary /lib/modules/6.2.7-1-siduction-amd64/build/scripts/sign-file not found, modules won't be signed
applying patch cc_version_check-gcc5.patch...patching file conftest.sh

...
Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j8 modules KERNEL_UNAME=6.2.7-1-siduction-amd64..........(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.2.7-1-siduction-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-legacy-390xx/390.157/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.

...
dpkg: Fehler beim Bearbeiten des Paketes linux-image-siduction-amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 linux-headers-6.2.7-1-siduction-amd64
 linux-headers-siduction-amd64
 linux-image-6.2.7-1-siduction-amd64
 linux-image-siduction-amd64

Gruß
Ch. Hanisch

[DeletedUserReAsG]

Was also muß ich machen?

Warten, bis nVidia den Treiber überarbeitet, gucken, ob die betreffende Karte mit Nouveau zum Laufen zu bekommen ist, oder halt den Kernel auf eine ältere Version festnageln und schonmal einplanen, dass es dann irgendwann in der Zukunft trotzdem nicht mehr funktionieren wird.

Vielleicht hat auch noch jemand Anderes eine Idee zu dem legacy-nvidia-Treiber in Verbindung mit aktuelleren Kerneln – dazu wär’s wohl sinnvoll, wenn du direkt alle Informationen auf den Tisch packen (Salamitaktik, also Informationen in kleinen Scheibchen zu reichen, so dass ausreichend lange ja keiner weiß, was denn eigentlich das Problem ist, ist eine sehr unschöne Sache) und den Threadtitel auf das tatsächliche Problem umformulieren würdest.

[Hanisch]

... oder halt den Kernel auf eine ältere Version festnageln und schonmal einplanen, dass es dann irgendwann in der Zukunft trotzdem nicht mehr funktionieren wird.

Ich möcht den Kernel:

Code: Alles auswählen

~$ uname -r
6.1.10-2-siduction-amd64

als letzten aktuellen Kernel haben und danach keine höheren mehr - wie geht das?

Der DELL XPS L702x benutzt sowohl Intel als auch NVIDIA

Code: Alles auswählen

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF106M [GeForce GT 550M] (rev a1)

Die GeForce GT 550M wird nur mit Bumblebee benutzt. Darauf kann ich aber verzichten.

Gruß
Ch. Hanisch

[DeletedUserReAsG]

Ich möcht den Kernel: 6.1.10-2-siduction-amd64 als letzten aktuellen Kernel haben und danach keine höheren mehr - wie geht das?

→

Da würden mir zwei Möglichkeiten einfallen: das Paket auf hold setzen, oder das Paket mit der konkreten Version als manuell installiert markieren, statt das Metapaket zu nutzen.

(dass ein von Sid abgeleitetes System irgendwann in der Zukunft nicht mehr mit einem veralteten Kernel funktionieren wird, erwähnte ich ja schon, glaube ich …)

[Hanisch]

Da würden mir zwei Möglichkeiten einfallen: das Paket auf hold setzen, oder das Paket mit der konkreten Version als manuell installiert markieren, statt das Metapaket zu nutzen.

(dass ein von Sid abgeleitetes System irgendwann in der Zukunft nicht mehr mit einem veralteten Kernel funktionieren wird, erwähnte ich ja schon, glaube ich …)

das sieht aber alles nicht gut aus.
Was mache ich mit dem META-Paket:

Code: Alles auswählen

~$ sudo apt show linux-image-amd64
Package: linux-image-amd64
Version: 6.1.15-1
Built-Using: linux (= 6.1.15-1)
Priority: optional
Section: kernel
Source: linux-signed-amd64 (6.1.15+1)
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Installed-Size: 13,3 kB
Provides: linux-image-generic, linux-latest-modules-6.1.0-6-amd64, virtualbox-guest-modules, wireguard-modules (= 1.0.0)
Depends: linux-image-6.1.0-6-amd64 (= 6.1.15-1)
Homepage: https://www.kernel.org/
Tag: admin::kernel, role::metapackage
Download-Size: 1.480 B
APT-Sources: http://deb.debian.org/debian unstable/main amd64 Packages
Description: Linux für 64-Bit-PCs (Metapaket)
 Dieses Paket hängt vom neuesten Linux-Kernel und seinen Modulen
 für PCs mit AMD64-, Intel-64- oder VIA-Nano-Prozessoren ab.

Ich habe gemacht:

Code: Alles auswählen

~$ sudo apt-mark hold 6.1.10-2-siduction-amd64
linux-headers-6.1.10-2-siduction-amd64 auf Halten gesetzt.
linux-image-6.1.10-2-siduction-amd64 auf Halten gesetzt.

Code: Alles auswählen

$ sudo apt-mark showhold
linux-headers-6.1.10-2-siduction-amd64
linux-image-6.1.10-2-siduction-amd64

Werden jetzt keine neueren Kernel mehr updated?

Gruß
Ch. Hanisch

[MaGe]

Werden jetzt keine neueren Kernel mehr updated?

Das sorgt für neue Kernel!

https://forum.siduction.org/index.php?t ... 0#msg70770

Das gegenteil müßte reichen um keine mehr zu bekommen.



gruss MaGe

[Hanisch]

Werden jetzt keine neueren Kernel mehr updated?

Das sorgt für neue Kernel!

https://forum.siduction.org/index.php?t ... 0#msg70770

Das gegenteil müßte reichen um keine mehr zu bekommen.

Welches Gegenteil meinst Du?

Gruß
Ch. Hanisch

[MaGe]

Welches Gegenteil meinst Du?

Noch ein tip, vom Debian forum.
viewtopic.php?t=178259

Und lies dir das bitte mal durch!

PS. Ich gehe davon aus das du ein backup hast.



gruss MaGe

[Hanisch]

Noch ein tip, vom Debian forum.
viewtopic.php?t=178259

Und lies dir das bitte mal durch!

Sorry, aber das Löschen des META-Pakets verhindert nicht die Installation neuerer Kernel.

Code: Alles auswählen

~$ sudo apt purge linux-image-$(dpkg --print-architecture) linux-headers-$(dpkg --print-architecture)
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paket »linux-image-amd64« ist nicht installiert, wird also auch nicht entfernt.
Paket »linux-headers-amd64« ist nicht installiert, wird also auch nicht entfernt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 347 nicht aktualisiert.

Aber:

Code: Alles auswählen

$ sudo apt dist-upgrade
...
Die folgenden NEUEN Pakete werden installiert:
  libharfbuzz-subset0 libnss3-tools
  linux-headers-6.2.7-1-siduction-amd64
  linux-image-6.2.7-1-siduction-amd64 puma ruby-nio4r

Hier werden
linux-headers-6.2.7-1-siduction-amd64 und linux-image-6.2.7-1-siduction-amd64
als neuere Pakete installiert.

Also stimmt es nicht, wenn die META-Pakete nicht installiert sind, daß dann keine weiteren Kernel updatet werden.

Gruß
Ch. Hanisch

[towo]

Also stimmt es nicht, wenn die META-Pakete nicht installiert sind, daß dann keine weiteren Kernel updatet werden.

Doch, das stimmt, wenn man sein Hirn benutzen würde, was bei dir aber meistens nicht dar Fall ist!

Die Meta-Pakete heissen nunmal

linux-image-siduction-amd64 und linux-headers-siduction-amd64

!!!

linux-image-amd64 hat damit also NULL zu tun.

Aber leider sind solche Dinge ja symptomatisch für dich.
Und dir wurde auch schon oft gesagt, dass unstable absolut das Falsche für dich ist.

[Hanisch]

Die Meta-Pakete heissen nunmal

linux-image-siduction-amd64 und linux-headers-siduction-amd64

Also

Code: Alles auswählen

~$ sudo apt purge linux-image-siduction-amd64 linux-headers-siduction-amd64
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paket »linux-image-siduction-amd64« ist nicht installiert, wird also auch nicht entfernt.
Paket »linux-headers-siduction-amd64« ist nicht installiert, wird also auch nicht entfernt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.

Damit sollte nach Eurer Theorie das Update auf neuere Kernel verhindert werden - tut es aber nicht.

Auch nach:

Code: Alles auswählen

~$ sudo apt-mark showhold
linux-headers-6.1.14-1-siduction-amd64
linux-image-6.1.14-1-siduction-amd64

werden die Pakete linux-image-6.2.7-1-siduction-amd64 und linux-headers-6.2.7-1-siduction-amd64
beim D-U mit installiert und beim Booten als erster Kernel angezeigt.

Erst nach:

Code: Alles auswählen

$ sudo apt purge linux-image-6.2.7-1-siduction-amd64 linux-headers-6.2.7-1-siduction-amd64

verschwindet diese Zeile im Boot-Menü.
Und bei einem erneuten D-U wird ein neuerer Kernel nicht mehr updatet.

Code: Alles auswählen

~$ sudo nala upgrade
╭─ Aktualisierung der Paketlisten ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│Keine Änderung: https://packages.siduction.org/fixes unstable InRelease                                                                                                 │
│Aktualisiert:   http://deb.debian.org/debian unstable/main amd64 Packages [9.4 MB]                                                                                      │
│Aktualisiert:   http://deb.debian.org/debian unstable/main amd64 Contents (deb).diff/Index [64 KB]                                                                      │
│Aktualisiert:   http://deb.debian.org/debian unstable/main amd64 DEP-11 Metadata [4.6 MB]                                                                               │
│Aktualisiert:   http://deb.debian.org/debian unstable/main DEP-11 48x48 Icons [3.7 MB]                                                                                  │
│Aktualisiert:   http://deb.debian.org/debian unstable/main DEP-11 64x64 Icons [7.6 MB]                                                                                  │
│Aktualisiert:   http://deb.debian.org/debian unstable/non-free amd64 DEP-11 Metadata [4 KB]                                                                             │
│Aktualisiert:   http://deb.debian.org/debian unstable/main amd64 Contents (deb) T-2023-03-18-2023.14-F-2023-03-18-2023.14.pdiff [449 Bytes]                             │
│Aktualisiert:   http://deb.debian.org/debian unstable/main amd64 Contents (deb) T-2023-03-18-2023.14-F-2023-03-18-2023.14.pdiff [449 Bytes]                             │
│Holte 25.6 MB in 10s (2.6 MB/s)                                                                                                                                         │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Alle Pakete sind aktuell.

Das ist alles sehr merkwürdig und unverständlich.

Gruß
Ch. Hanisch

[towo]

Das ist alles sehr merkwürdig und unverständlich.

Nein, das einzige was merkwürdig ist, bist Du.

[feltel]

Doch, das stimmt, wenn man sein Hirn benutzen würde, was bei dir aber meistens nicht dar Fall ist!

Ich hoffe innständig, das diese Aussage "im Eifer des Gefechts" erfolgte. Solcherlei Beleidigungen gehören absolut hier nicht her und ich baue darauf, das dies ein einmaliges Versehen war. Ich habe ein Auge drauf.

[michaa7]

Es handelt sich hier genau um die Distribution Siduction, wo die Kernels 6.2* beim Hochfahren Kernel-Panik bringen und ich ab Kernel 6.2* keine neueren Kernel mehr haben will.

Bei von Sid abgeleiteten Systemen würde ich den Kernel genau solange festnageln, bis das Problem behoben ist. Ansonsten wird es nämlich zwangsläufig irgendwann in der Zukunft passieren, dass dir das System zusammenfällt oder explodiert. ... denn dass das nicht ewig gutgeht, ist sicher.

Es ist bei dir immer wieder bedauerlich das du auf dieser und ähnlichen Aussagen herumnudelst und offenbar unbeirrbar das dir theoretisch mögliche erscheinende und unter anderen Umständen vielleicht wahrscheinliche stur und unbeirrbar als "gesicherte" Erkenntnis vertrittst und jahrelangen anderes belegende Realität tatsächlicher Anwender ignorierst.

Ich verwende seit Jahren siduction und Debian Kernel auf einer jahrealten Debian/sid(uction) installation. Falls mal ein siduction Kernel klemmt melde ich das im siduction Forum. towo, der dort den Kernel seit Jahren sehr gut betreut ist der erste der interesse an diese info hat. Und er ist meist sehr gut darüber informiert welcher allerneueste patch revidiert oder erneut gepatcht werden muss. Und dann gibt es schupps den nächst KErnel und allesse paletti isse ...

Und wenn es am Debian KErnel, den ich explizit dann boote wenn ich einen Bug gegen ein Debian Paket vermute, klemmt melde ich das dem Debian maintainer.

Und die beiden metapakete zur steuerung der updates für die jeweiligen kernel sind eben:

linux-image-siduction-amd64 für den siduction Kernel

und

linux-image-amd64 für den Debian kernel.

Analog für die heades.

[DeletedUserReAsG]

Es ist bei dir immer wieder bedauerlich das du auf dieser und ähnlichen Aussagen herumnudelst und offenbar unbeirrbar das dir theoretisch mögliche erscheinende und unter anderen Umständen vielleicht wahrscheinliche stur und unbeirrbar als "gesicherte" Erkenntnis vertrittst und jahrelangen anderes belegende Realität tatsächlicher Anwender ignorierst.

Gut, dann trete doch bitte den Gegenbeweis an, und installiere, sagen wir, 4.0 auf deinem Siduction. Dann bitte ein Video von dessen Bootvorgang bis X11 oder Wayland. Wenn ich raten sollte: schon systemd steigt aufgrund fehlender Features des Kernels aus – wenn du ihn aufgrund der Abhängigkeiten überhaupt installiert bekommst. Aber da du mir ja unbedingt zeigen willst, wie Unrecht ich habe, wirst du dir da bestimmt was einfallen lassen – oder?

Das hat nix mit drauf herumnudeln zu tun, sondern damit, dass sich die APIs nunmal ändern, und ein aktuelles System mit einem ausreichend alten Kernel gewisse Probleme erfahren dürfte. Und genau das wird zwangsläufig passieren, wenn der Kernel auf eine Version festgenagelt, und fortan nie wieder aktualisiert wird – wie’s der TE nunmal haben wollte, und worauf sich mein von dir zitierter Text eigentlich deutlich ersichtlich bezieht, in dem ich ausdrücklich dazu rate, den Kernel nur genau solange festzunageln, bis das Problem in neueren Versionen behoben ist – um dann wieder den aktuellen Kernel zu fahren.

[Hanisch]

...
Das hat nix mit drauf herumnudeln zu tun, sondern damit, dass sich die APIs nunmal ändern, und ein aktuelles System mit einem ausreichend alten Kernel gewisse Probleme erfahren dürfte. Und genau das wird zwangsläufig passieren, wenn der Kernel auf eine Version festgenagelt, und fortan nie wieder aktualisiert wird – wie’s der TE nunmal haben wollte, und worauf sich mein von dir zitierter Text eigentlich deutlich ersichtlich bezieht, in dem ich ausdrücklich dazu rate, den Kernel nur genau solange festzunageln, bis das Problem in neueren Versionen behoben ist – um dann wieder den aktuellen Kernel zu fahren.

Ja, das hatte ich auch vor.
Leider komme ich mit dem Patch gemäß dem Link
https://gitlab.com/herecura/packages/nv ... -6.2.patch
nicht zurecht.
Auch der Link https://gitlab.com/herecura/packages/nvidia-390xx-dkms/
gibt mir keine Erkenntnisse.

Also abwarten, daß der Maintainer von Siduction das Problem löst?

Gruß
Ch. Hanisch

[michaa7]

Also abwarten, daß der Maintainer von Siduction das Problem löst?

Soweit ich im siduction Forum sehe hast du *dort* den Fehler nicht gemeldet. Eigentlich wäre das der Erfolg versprechenste Lösungsansatz.

Und weißt du was ein Meta-paket ist? linux-image-6.2.7-1-siduction-amd64 ist *kein* meta-paket. linux-image-siduction-amd64 ist ein Meta-paket.

apt depends linux-image-siduction-amd64
linux-image-siduction-amd64
Hängt ab von: linux-image-6.2.8-1-siduction-amd64 (= 6.2-8)
Empfiehlt: linux-headers-siduction-amd64 (= 6.2-8

Es enthält immer die Abhängigkeit vom nächsten Kernel.

[towo]

Da es kein siduction Problem ist, wird das auch nicht in siduction gefixt.
Das Paket nvidia-legacy-390xx-driver kommt von Debian, wo gehört also ein Bugreport hin?

[Hanisch]

Also abwarten, daß der Maintainer von Siduction das Problem löst?

Soweit ich im siduction Forum sehe hast du *dort* den Fehler nicht gemeldet. Eigentlich wäre das der Erfolg versprechenste Lösungsansatz.

Im Chat von Siduction gab mir towo folgende Antwort:
"apt purge nvidia-legacy-390xx-kernel-dkms"
"alle anderen beschwerden sind direkt an debian zu richten"
"um es mit deinen worten zu sagen, das wurde seitens debian verschlimmbessert, da haben wir nix mit zu tun"
"Hanisch du hast es immer noch nicht begriffen, du kannst noch so oft in debianforum.de rumheulen, das interessiert niemanden, dort liest kein Maintainer auch nur ein Wort"

Also meine Frage an die Debian-Maintainer:
Wann wird der Patch
https://gitlab.com/herecura/packages/nv ... -6.2.patch
in Debian gemacht?

Gruß
Ch. Hanisch

[michaa7]

Hier liest tatsächlich kein Debian Kernel Maintainer mit. Wenn du den kontaktieren willst mußt du einen Bugreport gegen den Debian Kernel absenden.

Towo's Antwort bezieht sich aber auf den nvidia Treiber, nicht auf den Kernel. Ich vermute dass es darum geht nicht nur den Kernel festzunageln, sondern auch den nvidia Treiber (weil beide eng verknüpft sind.

Langfristig wir es vielleicht besser sein auf den OS nouveau Treiber umzusatteln. Dann bist du den nvidia Treiber los und kannst immer den neuesten Kernel nutzen.

[Hanisch]

Hier liest tatsächlich kein Debian Kernel Maintainer mit. Wenn du den kontaktieren willst mußt du einen Bugreport gegen den Debian Kernel absenden.

Ich habe einen Bug-Report abgesendet:
You can follow progress on this Bug here: 1033376: https://bugs.debian.org/cgi-bin/bugrepo ... ug=1033376.

Langfristig wir es vielleicht besser sein auf den OS nouveau Treiber umzusatteln. Dann bist du den nvidia Treiber los und kannst immer den neuesten Kernel nutzen.

ich habe auf den OS nouveau Treiber umgestellt:
1) Alle NVIDIA-Pakete löschen

Code: Alles auswählen

~$ sudo apt purge  nvidia*  *nvidia*

2) Nouveau installieren

Code: Alles auswählen

~$ sudo apt install xserver-xorg-video-nouveau

3) Neustart

Code: Alles auswählen

~$ sudo reboot

4) bumblebee installieren

Code: Alles auswählen

$ sudo apt install  bumblebee primus

5) bumblebee-nvidia entfernen

Code: Alles auswählen

~$ sudo apt purge bumblebee-nvidia primus-nvidia primus-vk-nvidia

6) /etc/bumblebee/bumblebee.conf editieren
Driver=nouveau
Bridge=primus
# Section with nvidia driver --> Alles auskommentieren
# Section with nouveau driver --> Alle Kommentarzeichen # entfernen

7) bumblebeed-service starten

Code: Alles auswählen

~$ sudo systemctl enable  bumblebeed.service
~$ sudo systemctl start bumblebeed.service
~$ sudo systemctl status bumblebeed.service
● bumblebeed.service - Bumblebee C Daemon
     Loaded: loaded (/lib/systemd/system/bumblebeed.service; enabled; preset: enabled)
     Active: active (running) since Fri 2023-03-24 12:35:03 CET; 4min 11s ago
   Main PID: 53409 (bumblebeed)
      Tasks: 1 (limit: 9365)
     Memory: 1.0M
        CPU: 15ms
     CGroup: /system.slice/bumblebeed.service
             └─53409 /usr/sbin/bumblebeed
Mär 24 12:35:03 siduction systemd[1]: Started bumblebeed.service - Bumblebee C Daemon.
Mär 24 12:35:03 siduction bumblebeed[53409]: [ 1124.512651] [INFO]/usr/sbin/bumblebeed 3.2.1 started

Aber bei

Code: Alles auswählen

~$ primusrun glxgears
294 frames in 5.0 seconds = 58.680 FPS
300 frames in 5.0 seconds = 59.997 FPS
301 frames in 5.0 seconds = 59.992 FPS
^C

drehen sich die Zahnräder nicht. Ich habe nur ein Standbild.
Ist das in Ordnung oder fehlt da noch etwas; liegt das an nouveau?

Gruß
Ch. Hanisch