[erledigt] Jessie stürzt ab

[rendegast]

Noch keine bug-Reports bzgl. radeon
https://bugs.debian.org/linux-image-3.16.0-4-686-pae
https://bugs.debian.org/linux-image-3.16.0-4-amd64
auch ;dist=unstable <-> ;dist=stable


Der Vorkernel ist noch im Repo, muß beim Installieren die Version mitgegeben werden

Code: Alles auswählen

$ apt-cache policy linux-image-3.16.0-4-amd64
linux-image-3.16.0-4-amd64:
  Installed: (none)
  Candidate: 3.16.7-ckt25-1
  Version table:
     3.16.7-ckt25-1 0
        500 http://ftp.de.debian.org/debian/ jessie/main i386 Packages
     3.16.7-ckt20-1+deb8u4 0
        500 http://security.debian.org/ jessie/updates/main i386 Packages

# apt-cache policy linux-image-3.16.0-4-amd64
linux-image-3.16.0-4-amd64:
  Installed: 3.16.7-ckt20-1+deb8u4
  Candidate: 3.16.7-ckt25-1
  Version table:
     3.16.7-ckt25-1 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
 *** 3.16.7-ckt20-1+deb8u4 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status

[NAB]

rendegasts Methode ist natürlich eleganter, solange sie funktioniert. Die Befehle lauten dann wie folgt:
AMD64:

Code: Alles auswählen

apt-get install linux-image-3.16.0-4-amd64=3.16.7-ckt20-1+deb8u4

686-PAE:

Code: Alles auswählen

apt-get install linux-image-3.16.0-4-686-pae=3.16.7-ckt20-1+deb8u4

[Ulidor]

rendegasts Methode ist natürlich eleganter, solange sie funktioniert.

Wie groß ist denn die Gefahr, dass es jetzt, wo der defekte Kernel der aktuelle ist, Probleme mit dem alten Kernel gibt?

[rendegast]

Gibt keine Probleme mit der Installation.
Der Kernel wird nur irgendwann aus dem Repo genommen und müßte händisch über snapshot.debian.org besorgt werden.
(Bei snapshot gibt es aber auch die Möglichkeit eines Repoeintrags,
sprich apt-Verwendung.
Info auf der Website.)

[Ulidor]

Ich meinte damit, ob es beim jetzigen oder künftigen Upgrades Probleme geben könnte, weil z.B. Pakete vom neuen Kernel abhängen.
Und wenn ich wieder den alten Kernel installiere, wird der nicht gleich beim nächsten Upgrade wieder durch den neuen ersetzt?

[NAB]

Ich meinte damit, ob es beim jetzigen oder künftigen Upgrades Probleme geben könnte, weil z.B. Pakete vom neuen Kernel abhängen.

Klar "könnte" es Probleme geben. Im Moment gibt es keine. Deswegen schrieb ich "schnelle schmutzige" Lösung ... das ist keine Dauerlösung. Ich erwarte, dass in den nächsten Tagen bis Wochen ein korrigierter Kernel erscheint. Das könnte man vermutlich beschleunigen, wenn man einen Debian-Bugreport erstellt.

Sobald du wieder normal upgraden kannst, werden zukünftige Upgrades problemlos funktionieren.

Und wenn ich wieder den alten Kernel installiere, wird der nicht gleich beim nächsten Upgrade wieder durch den neuen ersetzt?

Richtig! Wie gesagt, das ist keine Dauerlösung.

Du kannst dir mit "apt-get -s upgrade" anschauen, welche Pakete aktualisiert werden müssten, und die dann einzeln mit apt-get install aktualisieren - außer dem defekten Kernel natürlich.

[sle85276]

Noch keine bug-Reports bzgl. radeon

Es kommt Bewegung in die Sache: https://bugs.debian.org/cgi-bin/bugrepo ... bug=819881

[LinAdmin]

Nach dem Upgrade auf 8.04 auch hier 2 Systeme nicht mehr brauchbar: Das eine crasht mit dem beschriebenen GPF beim Booten, das andere ein paar Minuten nachdem der xscreeensaver den Schirm übernommen hat

https://bugs.debian.org/cgi-bin/bugrepo ... bug=819881 betrifft diesen Fehler.
Ist es zweckmässig, sich dort auch einzutragen oder reicht das Vorhandene?

[kuleszdl]

Ich bin übergangsweise auf den backport-Kernel (4.4.0-0.bpo.1-amd64) gewechselt, das funktioniert bislang ohne Abstürze oder sonstige Probleme. Ich wollte auch schon den Bug reporten, aber leider ist es bei Debian sehr mühsam einen Bugreport zu eröffnen. Hoffen wir mal, dass es da bald einen Fix geben wird und man wieder zurückwechseln kann...

So eine üble Regression hatte ich bei Debian schon lange nicht mehr, echt traurig. Eigentlich darf sowas bei "stable" nie passieren, aber scheinbar passiert es ja doch.

[NAB]

Soweit ich den von sle85276 und LinAdmin gefundenen Bugreport verstehe, hat Ben Hutchings sofort den passenden Patch gefunden und erklärt, dass er das Problem vorher wohl irgendwie verschusselt hat. Ich würde erwarten, dass in den nächsten Stunden bis Tagen ein korrigierter Kernel 3.16 in den Upgrades ist. Derweil kann man sich mit der Notlösung oben behelfen oder einen 4er Kernel aus den Backports nehmen.

[rendegast]

Ich bin übergangsweise auf den backport-Kernel (4.4.0-0.bpo.1-amd64) gewechselt, das funktioniert bislang ohne Abstürze oder sonstige Probleme.

Der hat lustigerweise ein Problem mit sound / ZONE_DMA.

Code: Alles auswählen

$ grep ZONE_ /boot/config-*
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA32=y
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA=y
/boot/config-3.16.0-4-amd64:CONFIG_ZONE_DMA_FLAG=1

/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA32=y
/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA=y
/boot/config-4.3.0-0.bpo.1-amd64:CONFIG_ZONE_DMA_FLAG=1

/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DMA32=y
/boot/config-4.4.0-0.bpo.1-amd64:# CONFIG_ZONE_DMA is not set
/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DMA_FLAG=0
/boot/config-4.4.0-0.bpo.1-amd64:CONFIG_ZONE_DEVICE=y

Wir haben einen historischen Zustand,
beide Kernel für debian-stable sind gleichzeitig kaputt.

(Näher betrachtet nicht "kaputt", denn es gibt Gründe für das Handeln der Maintainer (Sicherheitslücke beim 3.16, valides 64bit beim 4.4-amd64),
und es liegt eher an nicht valide konstruierter Hardware
(2GB-DMA der Soundkarten).
Klingt aber reißerischer,
und im worst-case kann sich Benutzer aussuchen
3.16 jessie ohne Bild oder 4.4 jessie-backports ohne sound)

Ist der auslösende radeon-Patch jetzt einfach unsauber implementiert
oder besteht ein Dilemma zwischen einer Sicherheitslücke und nicht funktionierender Hardware?

aber leider ist es bei Debian sehr mühsam einen Bugreport zu eröffnen.

Paket reportbug, braucht nur eine valide email-Adresse.

[kuleszdl]

Also ich merk nichts von dem Sound-Bug, aber ich nutze auch nicht den Sound über die Radeon-Karte.

Und was reportbug angeht: Ich würde gerne auch einen Bug eröffnen dürfen ohne gleich irgendwelche Logs beizufügen wo ich nicht immer so genau weiß, was da alles mitgeschickt wird. Außerdem weiß man ja auch nicht immer welches Package betroffen ist, aber okay in diesem Fall ist es ja eh klar.

[rendegast]

Ich würde gerne auch einen Bug eröffnen dürfen ohne gleich irgendwelche Logs beizufügen wo ich nicht immer so genau weiß, was da alles mitgeschickt wird.

Es wird ein Mailkörper erzeugt,
aus Abfragen zur Beschreibung und einer (automatischen) Auswahl an mit dem angegebenen Paket verbundener Software.
Halt so wie sich die Maintainer der bug-Listen eine bug-Meldung wünschen um die Effektivität zu erhöhen.
Anfänger unterlassen naturgemäß Sachen, die erst durch Nachfragen geklärt werden müssen.
Und es ist natürlich einfacher als diese Liste selber aufzustellen.

Angehängte Dateien/Logs unterliegen Deiner Auswahl
und sollten natürlich erstmal durchgesehen und entsprechend vorbereitet werden,
zBsp. kritische Informationen entfernen oder auf wesentliche Teile kürzen.

[kuleszdl]

Angehängte Dateien/Logs unterliegen Deiner Auswahl
und sollten natürlich erstmal durchgesehen und entsprechend vorbereitet werden,
zBsp. kritische Informationen entfernen oder auf wesentliche Teile kürzen.

Und genau das wäre mir auf einem Produktivsystem zu heikel bzw. zu aufwändig. Aber naja, die Diskussion hier ist eh OT und der Bug bereits angelegt, kann man also Tee trinken und hoffen dass es bald neue Pakete geben wird.

[albundy]

Hallo,

nun ist Abhilfe in Sicht:

https://lists.debian.org/debian-release ... 00195.html

Jetzt ist er in s-p-u. Möglicherweise kommt er noch als reguläres Update.

[NAB]

Jupp, in "proposed-updates" ist jetzt Kernel Version 3.16.7-ckt25-2 erhältlich, im Gegensatz zur kaputten Version 3.16.7-ckt25-1.

Wer die proposed-updates nutzen will, findet hier eine Erklärung:
https://www.debian.org/releases/propose ... es.de.html

[LinAdmin]

nun ist Abhilfe in Sicht:
https://lists.debian.org/debian-release ... 00195.html

Kann mir jemand erklären, warum es derart lange dauert bis es dann als reguläres Update verfügbar ist?

Ich würde meinen, dass im Falle solcher Instabilitäten im "stable" unverzüglich reagiert werden müsste?

[dirk11]

Stable ist halt auch bei Fehlern "stable"...

[NAB]

Kann mir jemand erklären,

Nein, nicht wirklich. Ich finde das auch reichlich Panne.

Anscheinend wollte Ben Hutchings, dass der korrigierte Kernel den üblichen Weg durch proposed-updates, updates und stable durchläuft ... vermutlich um sich abzusichern, dass die Korrektur nicht weitere Fehler einführt.

Allerdings war das Problem hier schon am 14.3. absehbar ... wurde aber erst am 3.4. an Debian gemeldet. Das hätte auch schneller gehen können ...

[Ulidor]

Jedenfalls habe ich seit dem 11.4. wieder einen Kernel ohne diesen Bug. Zwar hatte ich nach der Diskussion hier die jessie-proposed-updates deaktiviert, aber die jessie-updates sind weiterhin aktiv. Die werde ich auch erst mal weiterhin aktiviert lassen, denn immerhin habe ich dadurch nun schneller einen heilen Kernel bekommen.

Code: Alles auswählen

$ apt-cache policy linux-image-3.16.0-4-amd64
linux-image-3.16.0-4-amd64:
  Installiert:           3.16.7-ckt25-2
  Installationskandidat: 3.16.7-ckt25-2
  Versionstabelle:
 *** 3.16.7-ckt25-2 0
        500 http://ftp2.de.debian.org/debian/ jessie-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.16.7-ckt25-1 0
        500 http://ftp2.de.debian.org/debian/ jessie/main amd64 Packages
     3.16.7-ckt20-1+deb8u4 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages