O
OuI
Jungspund
Hallo,
Mein PC
startet nicht mehr seit (mindestens) Anfang Herbst 2023 mit den neuen Kernels von Debian / Devuan höher als 6.1.0 (2 verschiedene Störungen, die zweite vermutlich nur die extrem verschärfte Form der ersten: der Cursor-Punkt "wackelt" extrem, das Bild wird damit und dadurch instabil / völlig dunkler Bildschirm). Ich benutze effektiv mehrere PC von DELL scheinbar mit den befürchteten INTEL chips... 2 davon sind Transformer-Laptop mit Touch-Screen und relativ noch niedriger Auflösung, die auch im geschlossenen Zustand einsetzbar sind (hinter dem Fernseher, daher die Wahl), 1 ist ein Laptop mit norm. Bildschirm, und 1 weiteres ist ein Laptop mit hochauflösendem Bildschirm.
Heute gab es eine Aktualisierung, worunter auch der Kernel aktualisiert wurde. Der Kernel 6.7.irgendwas wurde durch den neuen Kernel 6.8.2 ersetzt. Dadurch wurde (zum zigten Mal passiert mir die Panne) und dadurch der gut funktionierende Kernel 6.1.0 deaktiviert.
Warum?
scheinbar, weil ich den richtigen Weg nicht kenne, und daher nicht anwende, wie man einen neuen Kernel ablehnt und dann «total unschädlich und vergessen» macht (denn, es ist ja klar: nur eine neue Version mit einer neuen Versionnummer kann helfen. Der also neue schlechte Kernel wird an meiner Installation nie besser...). Ich dachte bislang, auf Grund der Tatsache, dass man "uns" in / (bei Debian / Devuan), oder /boot/ (ubuntu) immer die alte Konfiguration xyz.old belässt, dass es der richtige Weg wäre, einfach umzubenennen, und damit wäre alles erledigt! Aber so geht es scheinbar nicht ganz. Wenn man das so macht (vor dem Pflicht-Reboot muss man auch, wenn man Blackscreen befürtet, lightDM / sddm / slim vorsorglich entfernen, und später reinstallieren!) reicht es dann aus, nach dem neuen Start nach dem Login ohne Displaymanager sich in Konsolemodus einzuloggen, und dann mit startx weiter zu gucken, ob man Glück hat, und falls nicht, dann restart man ein 2. mal, umnennt die vmlinuz und initrd.img-Dateien in vmlinuz.false / initrd.img.false und die vmlinuz.old und initrd.img.old dafür in vmlinuz und initrd.img wie sie unmittelbar vor der gescheiterten Aktualisierung waren, und alles ist scheinbar repariert. Man reinstalliert slim oder ein der zwei anderen. Das System ist aktuell einerseits, aber mit dem alten Kernel, und alles läuft wieder bestens.
Nur so wird man bei der weiteren nächsten Aktualisierung gekniffen: Der alte Kernel, in meinem Fall 6.1.0, ist scheinbar nicht mehr angemeldet. Der verworfenen Kernel, in meinem Fall 6.7.irgendwas wird immer noch als der gültige Kernel angesehen, und er kommt also im neuen Link für vmlinuz.old zur Anwendung und nicht der Kernel 6.1.0! Und dann scheitert man, weil man sowohl in /vmlinuz als in /vmlinuz.old je einen unverträglichen Kernel hat.
War also nicht der richtige Weg.
Wie macht man das richtig nach den offiziellen Debian-Vorgaben (ich finde die Stelle nicht)?
(In Ubuntu / gentoo kommt die Störung seit Anfang Herbst 2023 nicht mehr vor, zumindest nicht in Noble 24.04 testing noch jetzt stabil!)
Mein PC
startet nicht mehr seit (mindestens) Anfang Herbst 2023 mit den neuen Kernels von Debian / Devuan höher als 6.1.0 (2 verschiedene Störungen, die zweite vermutlich nur die extrem verschärfte Form der ersten: der Cursor-Punkt "wackelt" extrem, das Bild wird damit und dadurch instabil / völlig dunkler Bildschirm). Ich benutze effektiv mehrere PC von DELL scheinbar mit den befürchteten INTEL chips... 2 davon sind Transformer-Laptop mit Touch-Screen und relativ noch niedriger Auflösung, die auch im geschlossenen Zustand einsetzbar sind (hinter dem Fernseher, daher die Wahl), 1 ist ein Laptop mit norm. Bildschirm, und 1 weiteres ist ein Laptop mit hochauflösendem Bildschirm.
Heute gab es eine Aktualisierung, worunter auch der Kernel aktualisiert wurde. Der Kernel 6.7.irgendwas wurde durch den neuen Kernel 6.8.2 ersetzt. Dadurch wurde (zum zigten Mal passiert mir die Panne) und dadurch der gut funktionierende Kernel 6.1.0 deaktiviert.
Warum?
scheinbar, weil ich den richtigen Weg nicht kenne, und daher nicht anwende, wie man einen neuen Kernel ablehnt und dann «total unschädlich und vergessen» macht (denn, es ist ja klar: nur eine neue Version mit einer neuen Versionnummer kann helfen. Der also neue schlechte Kernel wird an meiner Installation nie besser...). Ich dachte bislang, auf Grund der Tatsache, dass man "uns" in / (bei Debian / Devuan), oder /boot/ (ubuntu) immer die alte Konfiguration xyz.old belässt, dass es der richtige Weg wäre, einfach umzubenennen, und damit wäre alles erledigt! Aber so geht es scheinbar nicht ganz. Wenn man das so macht (vor dem Pflicht-Reboot muss man auch, wenn man Blackscreen befürtet, lightDM / sddm / slim vorsorglich entfernen, und später reinstallieren!) reicht es dann aus, nach dem neuen Start nach dem Login ohne Displaymanager sich in Konsolemodus einzuloggen, und dann mit startx weiter zu gucken, ob man Glück hat, und falls nicht, dann restart man ein 2. mal, umnennt die vmlinuz und initrd.img-Dateien in vmlinuz.false / initrd.img.false und die vmlinuz.old und initrd.img.old dafür in vmlinuz und initrd.img wie sie unmittelbar vor der gescheiterten Aktualisierung waren, und alles ist scheinbar repariert. Man reinstalliert slim oder ein der zwei anderen. Das System ist aktuell einerseits, aber mit dem alten Kernel, und alles läuft wieder bestens.
Nur so wird man bei der weiteren nächsten Aktualisierung gekniffen: Der alte Kernel, in meinem Fall 6.1.0, ist scheinbar nicht mehr angemeldet. Der verworfenen Kernel, in meinem Fall 6.7.irgendwas wird immer noch als der gültige Kernel angesehen, und er kommt also im neuen Link für vmlinuz.old zur Anwendung und nicht der Kernel 6.1.0! Und dann scheitert man, weil man sowohl in /vmlinuz als in /vmlinuz.old je einen unverträglichen Kernel hat.
War also nicht der richtige Weg.
Wie macht man das richtig nach den offiziellen Debian-Vorgaben (ich finde die Stelle nicht)?
(In Ubuntu / gentoo kommt die Störung seit Anfang Herbst 2023 nicht mehr vor, zumindest nicht in Noble 24.04 testing noch jetzt stabil!)
