aktueller Kernel?

[RobertDebiannutzer]

In der Debian-wiki wird der Anschein erweckt, als ob man einfach einen Kernel aus einem anderen Release installieren könnte.
Link: https://wiki.debian.org/HowToUpgradeKernel
Zitate daraus:
Erst heißt es zwar:

for DebianStable, use StableProposedUpdates or Backports;
for DebianUnstable and DebianExperimental, use something like:

Doch dann:

(You might want to use unstable instead of experimental and/or choose a different mirror and flavour. Also the kernel version and ABI-version is probably different for you.) This might have some further dependencies, but generally they should not affect your stable (or testing) system. You still can select the old kernel in your bootloader afterwards.

Aber man kann doch in stable z.B. nicht einfach den Kernel aus unstable ohne Neu-Kompilierung installieren, oder?
Fällt sowas nicht eher unter "FrankenDebian"?
Wobei auch beim "FrankenDebian" (https://wiki.debian.org/DontBreakDebian ... nkenDebian) nicht das Problem des fremden Paketes an sich angesprochen wird, sondern auf durcheinandergebrachte Abhängigkeiten abgezielt wird. Und die Abhängigkeiten des stretch-Kernels (linux-image-4.9.0-6-amd64) und des sid-Kernels (linux-image-4.15.0-3-amd64) wären ja gleich...

Sorry für die Anfängerfrage - wäre nett, wenn mir jemand ein Licht aufsetzen könnte.

[RobertDebiannutzer]

76 Klicks und keiner weiß was?
Ich hab's jetzt einfach mal probiert, schließlich kann ich ja im Problemfall immer noch den Debian-stable-Kernel booten.
Würde mich aber dennoch über etwas theoretischen Hintergrund freuen!

Erstmal

Code: Alles auswählen

$ cat /etc/apt/preferences.d/10-new_kernel.pref
Package: linux-image-*
Pin: release o=Debian,a=unstable
Pin-Priority: 1

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: -1

dann zur stable-sources.list Folgendes hinzugefügt

Code: Alles auswählen

deb [ arch=amd64 ] http://ftp.de.debian.org/debian/ unstable main

und voilà!

Code: Alles auswählen

$ uname -rsv
Linux 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19)

Ja, ist eigentlich kein Unterschied bemerkbar... Außer, dass es nach dem Erscheinen von den init-Meldungen zweimal etwas länger blinkt statt einmal kürzer.

Übrigens: Falls euch der Sinn der Übung suspekt sein sollte* - ich habe es tatsächlich geschafft, mich für einen neuen Laptop zu entscheiden und will für alle Fälle vorbereitet sein. Nebenbei interessiert es mich aber auch so einfach.

*...was der Fall ist, so wie ich Leute in Fach-Foren kenne...

[KBDCALLS]

Auch wenns funktioniert , ist das die schlechteste Lösung, die einem einfallen kann. Das merkt man spätestens dann wenn man versucht ein Kernelmodul zu kompilieren. Das wäre besser gewesen du hättest den Kernel aus den Backports genommen.

• Code: Alles auswählen

  rmadison linux
  linux      | 3.2.78-1                 | oldoldstable               | source
  linux      | 3.12.9-1~bpo70+1         | wheezy-backports           | source
  linux      | 3.13.10-1~bpo70+1        | wheezy-backports           | source
  linux      | 3.14.12-1~bpo70+1        | wheezy-backports           | source
  linux      | 3.14.15-2~bpo70+1        | wheezy-backports           | source
  linux      | 3.16.7-ckt9-2            | oldstable-kfreebsd         | source
  linux      | 3.16.7-ckt25-2~bpo70+1   | wheezy-backports           | source
  linux      | 3.16.39-1+deb8u1~bpo70+1 | wheezy-backports           | source
  linux      | 3.16.51-2                | oldstable                  | source
  linux      | 3.16.51-3                | jessie-updates             | source
  linux      | 3.16.51-3                | oldstable-proposed-updates | source
  linux      | 3.16.51-3+deb8u1         | oldstable-new              | source
  linux      | 3.16.51-3+deb8u1         | oldstable-proposed-updates | source
  linux      | 3.16.56-1                | new                        | source
  linux      | 4.9.82-1+deb9u3~bpo8+1   | jessie-backports           | source
  linux      | 4.9.82-1+deb9u3          | stable                     | source
  linux      | 4.9.82-1+deb9u3          | stable-debug               | source
  linux      | 4.9.88-1                 | stable-new                 | source
  linux      | 4.12.13-1~bpo9+1         | stretch-backports-debug    | source
  linux      | 4.13.13-1~bpo9+1         | stretch-backports          | source
  linux      | 4.13.13-1~bpo9+1         | stretch-backports-debug    | source
  linux      | 4.14.7-1~bpo9+1          | stretch-backports          | source
  linux      | 4.14.13-1~bpo9+1         | stretch-backports          | source
  linux      | 4.14.13-1~bpo9+1         | stretch-backports-debug    | source
  linux      | 4.15.11-1~bpo9+1         | stretch-backports          | source
  linux      | 4.15.11-1~bpo9+1         | stretch-backports-debug    | source
  linux      | 4.15.11-1                | unstable                   | source
  linux      | 4.15.11-1                | unstable-debug             | source
  linux      | 4.15.17-1                | testing                    | source
  linux      | 4.15.17-1                | unstable                   | source
  linux      | 4.15.17-1                | unstable-debug             | source
  linux      | 4.16~rc6-1~exp1          | experimental               | source
  linux      | 4.16~rc6-1~exp1          | experimental-debug         | source
  linux      | 4.16-1~exp1              | experimental               | source
  linux      | 4.16-1~exp1              | experimental-debug         | source
  linux      | 4.16.5-1                 | buildd-unstable            | source
  linux      | 4.16.5-1                 | unstable                   | source
  linux      | 4.16.5-1                 | unstable-debug             | source
  linux      | 4.17~rc3-1~exp1          | buildd-experimental        | source
  linux      | 4.17~rc3-1~exp1          | experimental               | source
  linux      | 4.17~rc3-1~exp1          | experimental-debug         | source
  

[RobertDebiannutzer]

Naja, backports scheinen mir beim Kernel irgendwie nicht Fisch, nicht Fleisch.
Ich denke mal: Entweder hat man stable + security updates oder die neueste Version. Aber backports ist gerade bei 4.15.11, das ist doch irgendwie doof...
Ich wundere mich auch, denn zweitweise lief die Entwicklung des backport-Kernels ganz eng an der Entwicklung von unstable. Jetzt sieht das irgendwie so halblebig aus. Oder schauen sich die Debian-Maintainer die jeweiligen Changelogs an und entscheiden dann, ob sich ein backport lohnt oder nicht?

Kernelmodule kompiliere ich sowieso nicht, das wäre jetzt nicht das Problem.

BTW: Danke für rmadison, das kannte ich noch nicht.

[rendegast]

Nur irgendein Kernel hat normalerweise nur eine höhere Abhängigkeit initramfs-tools höherer Version,
welches sich normalerweise mit dem aus *-backports problemlos erfüllen läßt.

Problematisch wird es wirklich erst wenn für irgendwelche Zusatzmodule die entsprechenden headers benötigt werden,
die dann normalerweise einen Rattenschwanz nach sich ziehen (gcc -> cpp -> ...).

[RobertDebiannutzer]

Danke, rendegast. Der aktuelle sid-Kernel braucht sogar nichtmal eine neue initramfs-Version.
Auch

Code: Alles auswählen

$ uname -rsv
Linux 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29)

nicht.

Jetzt habe ich noch zum Thema "unstable-Paket in stable" was in der Debian-wiki gefunden:
https://wiki.debian.org/DebianUnstable# ... _stable.3F

Can I use sid packages on stable?

No. Don't even bother trying. If you do it anyway, you get to keep all the pieces, and we get to laugh at you. You can, however, backport them to stable yourself which is explained below.

Can I use sid packages on testing?

Only if the dependencies are satisfied. In general, sid and testing are usually close to each other, except for when RC (release critical) bugs in some major package like libc or perl cause a slew of things to be held up. So your odds of getting the binary package to work in testing are pretty good... but you still need to check it out yourself.

If the library dependencies aren't satisfied, then you'll need to backport it.

Ja, und warum gilt für stable nicht, was für testing gilt? Ist es nicht völlig egal, mit was für einer compiler-Version das Paket kompiliert wurde, solange nicht Funktionen aus Bibliotheken verwendet werden, die in älteren Versionen dieser Bibliotheken noch nicht zur Verfügung stehen? Was ja aus den Abhängigkeiten ersichtlich ist!
Warum wird da so ein Hokus-Pokus draus gemacht?
Oder wird nur übervorsichtig getan, damit unvorsichtige Leute ihr System nicht total durcheinanderbringen (weil sie z.B. keine apt-preferences einrichten, etc.)?

[KBDCALLS]

Das ist kein Hokus Pokus. Beim Kernel schon mal garnicht. Wenn Module und Kernel nicht mit dem selben Kompiler erstellt worden sind, funktionierts nicht.

Damit du mal siehst was passieren kann .

Debian wechselt zu GCC 5 und libstdc++6

Und das ist nicht ausgeschlossen, das das wieder passiert.

PS. Und das ist noch garnicht solange her das es hier eine Diskussion über ein Grafikprogramm gab welches sich nicht mehr mit den aktuellen Kompilern kompilieren ließ.

[RobertDebiannutzer]

Danke für die Antwort.
Ich glaube, ich habe noch nicht alles von Deinem Link verstanden, aber zusammengefasst ist es ja dennoch so, dass sich das nur auf Sachen bezieht - wie z.B. Kernelmodule -, die ich selbst kompiliere und die dann zusammenhängen mit Paketen, die anders kompiliert wurden, oder?

Aber wenn ich jetzt keine Kernelmodule selber kompiliere (habe keine farbige Tastaturbeleuchtung gewählt ), und einfach nur das Kernel-Paket aus unstable verwende, dürfte sich doch das Problem nicht stellen, sonst müsste das doch irgendwie aus den Abhängigkeiten ersichtlich sein. Oder wird sowas nicht von den Abhängigkeiten erfasst?

zum PS: Ich lese ja auch nicht alles hier im Forum, obwohl ich den Thread (Du meinst doch den?) tatsächlich gelesen habe (trackt ihr mich? ). Habe ihn allerdings nur überflogen und ihn sowieso nur gelesen, weil ich mich für die Diskussion um flatpak interessiert habe. Jetzt habe ich mal nach der Kompliations-Thematik sondiert, habe aber nur die Klage gefunden, dass sich das sid-Paket wegen anderer Abhängigkeiten nicht einfach in stretch installieren lässt. Was ja logisch und ein anderes Problem ist...

[KBDCALLS]

Du kommst aber spätestens bei Virtualbox damit in Berührung. Auch bei bestimmter Hardware wird man damit konfrontiert.

[RobertDebiannutzer]

Nur zu Info, falls es auch andere interessiert:

Wenn man nicht aus anderen Gründen den aktuellen sid-Kernel möchte - der Prozessor i5-8250U (intel) ist wohl kein Grund für einen neueren Kernel. (Ist eben "Kabylake Refresh", also auch sowas wie Kabylake). Ich jedenfalls habe bei meinem neuen Notebook (welches ich aus mehreren Gründen jetzt kaufen wollte) keine Probleme. Nur den microcode habe ich wegen der Sicherheitsupdates aus den backports genommen. (Komisch, dass der nicht als Sicherheitsupdate nach stretch durchrutscht. Naja, wurde wahrscheinlich schon irgendwo diskutiert.)