[gelöst] Möchte gerne Testing testen, aber ...

[clue]

Es gibt scheinbar Probleme:

Ich möchte gerne schon einmal den neuen 4.8er Kernel NEBEN meinem Stable-Kernel (3.16) installieren. Leider will mir Synaptic aber dann 3/4 meines Systems zerschießen.

Woran liegt das oder wie kann ich dennoch einfach den neuen Kernel und Xorg testen, ohne dass er mir quasi mein komplettes System zerpflücken will?

Hab beides getestet: Einmal mit Testing als ZUSÄTZLICHE Paketquelle und einmal mit deaktiviertem Stable. Das Ergebnis ist in beiden Fällen identisch.

[hikaru]

Kernel 4.8 ist auch in den Jessie-Backports vorhanden.
Falls du mit "Xorg" eine neuere Version deines Grafiktreibers meinst, dann hättest du auch damit gute Chancen in den Backports. Falls es dir wirklich um xorg geht, dann wirst du die Stretch-Version nicht so ohne Weiteres nach Jessie kriegen. Ich weiß aber auch nicht, wozu das gut sein sollte.

Dass es keine gute Idee ist, verschiedene Releases zu mischen sollte sich nach 10 Jahren Debiannutzung eigentlich rumgesprochen haben.

[tobo]

Was genau willst du testen - den Kernel, den Kernel+xorg oder testing (stretch)? Für den Kernel kannst du die backports nehmen, für alles was darüber hinausgeht solltest du mit einem zusätzlichen System planen, da die Rückführung zu jessie dann wohl eher nicht mehr funktionieren wird!?

[clue]

Was genau ich testen will ist folgendes:

Ich habe auf meinem MSI-Notebook mit AMD-A10 und R9 M290X Graka das Problem, dass die Kiste sowohl beim Hoch- als auch beim Runterfahren des Öfteren mal hängen bleibt. Daher möchte ich jetzt gerne, solange Testing noch im freeze ist und Fehler, die berichtet werden, auch ernst genommen werden, testen, damit der/die Fehler dann auch upstream weitergereicht werden, damit ich endlich mal meine Hardware vernünftig benutzen kann.

Ein weiteres Beispiel sind meine nicht stabil funktionierenden USB3.0 Ports, die nach einer unbestimmbaren (zufälligen Zeit) einfach mal flugs abschmieren. Das macht sich z.b. beim Kopieren GROßER Dateien bemerkbar: Da wird die externe Platte dann nach 30-200GB remountet, so dass es mir nicht möglich ist, eine mehrere hundert GB große Datei sauber rüberzuschieben.

Darum möchte ich gerne schon einmal den "Unterbau" auf Testing upgraden, ohne meinen stabil laufenden KDE 4 Desktop zu gefährden. Ich bin nun einmal auf ein stabil laufendes System angewiesen, da ich Windows nur als Spielestarter verwende und denen nicht meine Daten anvertrauen möchte.

Nun wundere ich mich, dass es zum ersten mal seit Etch Zeiten es nicht möglich sein soll, sich mal eben einen neuen Kernel neben dem bereits installierten zu installieren. Früher konnte ich sogar mal eben Xorg upgraden, ohne den Rest des Systems in Mitleidenschaft zu bringen.

Warum geht das jetzt auf einmal nicht mehr? Der Kernel ist doch bloß ein Paket, welches unabhängig vom Rest installiert werden kann (war jedenfalls vor Stretch so).

EDIT: Danke für den Tipp mit den Backports. Ich werd mich dann mal schlau lesen.

[towo]

Warum geht das jetzt auf einmal nicht mehr? Der Kernel ist doch bloß ein Paket, welches unabhängig vom Rest installiert werden kann (war jedenfalls vor Stretch so).

Nein, ist es nicht! Der Stretch-Kernel ist mit einer gcc-Version gebaut, die es in Jessie gar nicht gibt.
Genau so verhält es sich auch mit Xorg.

[whisper]

...und wenn du dir eine LiveCD baust und dann dein System damit testest?
Die USB Geschichte kannst du damit erschlagen

[clue]

Ok, mal anders gefragt:

Um meine bugs zu testen, ist es dann ausreichend, wenn ich den Kernel und Xorg aus backports verwende?

EDIT: Sehe grade, dass Synaptic keinen neueren Xorg in backports anzeigt. Mach ich was falsch?

[schwedenmann]

Hallo


Setz doch testweise virtualbox ein und installiert da testing, da siehst du ja.

mfg
schwedenmann

[Liffi]

Setz doch testweise virtualbox ein und installiert da testing, da siehst du ja.

Damit testet er natürlich nicht, ob Testing auf seinem System besser läuft.

[whisper]

Hallo


Setz doch testweise virtualbox ein und installiert da testing, da siehst du ja.

mfg
schwedenmann

Nee, das ist Nicht sinnvoll, dann testest du nur die Software, den Treiber im Kernel für USB kannst du damit nicht testen, denn der greift natürlich auf den Treiber des Hostes zu.
Zusätzlich ist ein USB Port nicht direkt aus der virtuellen Umgebung verfügbar und kompliziert alles.
Nur eine richtige Installation oder eine Livd CD, oder USB Stick, wenn dann noch 2 Ports zum testen frei sind machen Sinn

[clue]

Des is der Hammer!

Dank des neuen Kernels hört mein Computer viel besser. Immer? Nicht immer, aber immer öfter

Spaß beiseite: Ich habe den Kernel 4.8 aus backports und den amd64-microcode aus Testing genommen.

Resultate:

A)
Meine USB3.0 Ports laufen jetzt stabil. Ein paar komische Meldungen erschienen noch bei einem Versuch 500GB auf meine externe Platte zu kopieren:

Code: Alles auswählen

JBD2: Detected IO errors while flushing file data on sdb1-8

Diese Meldung wiederholte sich im Sekundentakt (tail -f /var/log/messages). Dann habe ich den Kopiervorgang abgebrochen, die externe Platte unmounted und am anderen USB3.0 Port wiederangeschlossen. Ich habe dann nur 100GB kopiert und auf Fehlermeldungen geachtet.
Ergebnis: Die Meldung erschien nicht mehr. Eventuell war die Meldung ein Hinweis darauf, dass meine Platte wohl im fast vollständig gefüllten Zustand defekte Sektoren hat. Oder es handelt sich hierbei doch noch um ein Problem mit den USB3.0 Treibern. Jedenfalls konnte ich das Verhalten nicht reproduzieren. Hoffentlich schreddert das System nicht doch heimlich meine Daten ...

Außerdem passierte noch etwas ungewöhnliches nachdem ich die 500GB auf die Externe kopiert hatte:

Scheinbar ging die Platte irgendwann nach dem "erfolgreichen" Kopieren (siehe obige Fehlermeldungen) in den stand-by. Dabei verschwand sie aber einfach aus dem System, ohne korrekt unmounted zu werden. Ein anschließendes fsck hat dann tatsächlich ein unsachgemäßes Entfernen der Platte vom System attestiert.

Soll ich diese Probleme berichten?


B)
Das Hoch- und Runterfahren scheint jetzt zuverlässig zu laufen. Ich bin vorsichtig optimistisch, dass dieser bug somit vom Tisch ist. Allerdings muss das erst noch durch Langzeittests bestätigt werden.

C)
Ein kleiner bug besteht noch beim Hochfahren:

journalctl |grep sp5100_tco sagt:

Code: Alles auswählen

sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x780b, Revision ID: 0x16
sp5100_tco: I/O address 0x0cd6 already in use

Eine kurze Recherche hat ergeben, dass dieser bug bis einschließlich Kernelversion 4.9 auch bei anderen Distributionen existiert.

Jetzt wieder die Frage: Soll ich das dennoch im Debian-bug-tracker melden?

D)
Insgesamt hat sich die Zuverlässigkeit meines Systems drastisch verbessert. Darum bin ich jetzt versucht, auch den Rest meines Systems zu aktualisieren, inklusive meines KDE Desktops.

Darum die Frage: Hat jemand schon Erfahrung mit den aktuell in Testing verfügbaren KDE Paketen (soll heißen: sind die schon stabil genug, dass man damit arbeiten kann).

Vielen Dank dafür, dass Ihr bis hier her alles gelesen habt!

[breakthewall]

Spaß beiseite: Ich habe den Kernel 4.8 aus backports und den amd64-microcode aus Testing genommen.

Man kann es nicht oft genug betonen: Niemals die Repositorys mischen!

Resultate:

Meine USB3.0 Ports laufen jetzt stabil.

War zu erwarten wenn man zuvor einen verhältnismäßig uralten Linux-Kernel nutzte, der viele Verbesserungen nie erfahren hat.

Außerdem passierte noch etwas ungewöhnliches nachdem ich die 500GB auf die Externe kopiert hatte:

Scheinbar ging die Platte irgendwann nach dem "erfolgreichen" Kopieren (siehe obige Fehlermeldungen) in den stand-by. Dabei verschwand sie aber einfach aus dem System, ohne korrekt unmounted zu werden. Ein anschließendes fsck hat dann tatsächlich ein unsachgemäßes Entfernen der Platte vom System attestiert.

Soll ich diese Probleme berichten?

Die Frage die sich hier stellt ist: Was ist das genau für eine Festplatte? Könnte durchaus möglich sein, dass dieses externe Gerät eigenmächtig abschalten kann, was sich der Kontrolle des Betriebssystems entzieht.

Ein kleiner bug besteht noch beim Hochfahren:

journalctl |grep sp5100_tco sagt:

Code: Alles auswählen

sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x780b, Revision ID: 0x16
sp5100_tco: I/O address 0x0cd6 already in use

Eine kurze Recherche hat ergeben, dass dieser bug bis einschließlich Kernelversion 4.9 auch bei anderen Distributionen existiert.

Jetzt wieder die Frage: Soll ich das dennoch im Debian-bug-tracker melden?

Das sieht nicht nach einem Fehler aus, sondern mehr nach einem schlichten Hinweis. Nicht alles in den Logs was sich derart oder ähnlich präsentiert, ist auch zeitgleich ein akutes Problem. Vieles davon ist einfach nur informativ, ohne dass das etwas Negatives für den Nutzer zu bedeuten hat.

Insgesamt hat sich die Zuverlässigkeit meines Systems drastisch verbessert. Darum bin ich jetzt versucht, auch den Rest meines Systems zu aktualisieren, inklusive meines KDE Desktops.

Darum die Frage: Hat jemand schon Erfahrung mit den aktuell in Testing verfügbaren KDE Paketen (soll heißen: sind die schon stabil genug, dass man damit arbeiten kann).

Vielen Dank dafür, dass Ihr bis hier her alles gelesen habt!

Deine KDE-Version wird meines Wissens auch nicht länger weiterentwickelt, zugunsten von KDE Plasma 5. Doch persönlich empfinde ich KDE Plasma 5.8.2 (Testing) als auch 5.8.4 (Unstable) nicht als reif für die Nutzung. Hatte mir noch zu viele kuriose Fehler und Instabilitäten, was die Nutzung teils recht anstrengend gestaltet hat. War aber irgendwo zu erwarten, wenn man den ganzen KDE-Desktop vollständig portieren will.

Selbst bin ich schon jahrelang auf Debian-Testing gefahren, ohne auch nur das geringste Problem. Auch schon über zwei Jahre lang auf Debian-Unstable, was überraschenderweise nur sehr wenige minderschwere Probleme bereitet hatte. Doch an sich lief Debian-Testing sehr gut, und fühlte sich für mich nie an, als wäre das System nun instabil oder experimentell. Einzig bei den Sicherheitsaktualisierungen muss man Abstriche machen, weil diese erst etwas später im Testing-Repository eingepflegt werden. Wenn das ein relevantes Kriterium ist, dann besser bei Debian-Stable bleiben, oder sich testweise mit Debian-Unstable versuchen, was man gewissermaßen als Rolling-Release ansehen kann.

[clue]

Außerdem passierte noch etwas ungewöhnliches nachdem ich die 500GB auf die Externe kopiert hatte:

Scheinbar ging die Platte irgendwann nach dem "erfolgreichen" Kopieren (siehe obige Fehlermeldungen) in den stand-by. Dabei verschwand sie aber einfach aus dem System, ohne korrekt unmounted zu werden. Ein anschließendes fsck hat dann tatsächlich ein unsachgemäßes Entfernen der Platte vom System attestiert.

Soll ich diese Probleme berichten?

Die Frage die sich hier stellt ist: Was ist das genau für eine Festplatte? Könnte durchaus möglich sein, dass dieses externe Gerät eigenmächtig abschalten kann, was sich der Kontrolle des Betriebssystems entzieht.

Die Platte springt nicht an, wenn sie nicht mit einem laufenden Betriebssystem verbunden ist. Ob sie dann vom BS schlafen geschickt wird, oder einen eigenen Mechanismus besitzt, weiß ich nicht. Würd mich nur mal interessieren, ob das bei anderen auch so ist.

Ein kleiner bug besteht noch beim Hochfahren:

journalctl |grep sp5100_tco sagt:

Code: Alles auswählen

sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x780b, Revision ID: 0x16
sp5100_tco: I/O address 0x0cd6 already in use

Eine kurze Recherche hat ergeben, dass dieser bug bis einschließlich Kernelversion 4.9 auch bei anderen Distributionen existiert.

Jetzt wieder die Frage: Soll ich das dennoch im Debian-bug-tracker melden?

Das sieht nicht nach einem Fehler aus, sondern mehr nach einem schlichten Hinweis. Nicht alles in den Logs was sich derart oder ähnlich präsentiert, ist auch zeitgleich ein akutes Problem. Vieles davon ist einfach nur informativ, ohne dass das etwas Negatives für den Nutzer zu bedeuten hat.

Ok, dann hoff ich mal, dass die Mitarbeiter bei AMD dieses Problem bereits kennen und aktiv daran arbeiten .

Insgesamt hat sich die Zuverlässigkeit meines Systems drastisch verbessert. Darum bin ich jetzt versucht, auch den Rest meines Systems zu aktualisieren, inklusive meines KDE Desktops.

Darum die Frage: Hat jemand schon Erfahrung mit den aktuell in Testing verfügbaren KDE Paketen (soll heißen: sind die schon stabil genug, dass man damit arbeiten kann).

Vielen Dank dafür, dass Ihr bis hier her alles gelesen habt!

Deine KDE-Version wird meines Wissens auch nicht länger weiterentwickelt, zugunsten von KDE Plasma 5. Doch persönlich empfinde ich KDE Plasma 5.8.2 (Testing) als auch 5.8.4 (Unstable) nicht als reif für die Nutzung. Hatte mir noch zu viele kuriose Fehler und Instabilitäten, was die Nutzung teils recht anstrengend gestaltet hat. War aber irgendwo zu erwarten, wenn man den ganzen KDE-Desktop vollständig portieren will.

Selbst bin ich schon jahrelang auf Debian-Testing gefahren, ohne auch nur das geringste Problem. Auch schon über zwei Jahre lang auf Debian-Unstable, was überraschenderweise nur sehr wenige minderschwere Probleme bereitet hatte. Doch an sich lief Debian-Testing sehr gut, und fühlte sich für mich nie an, als wäre das System nun instabil oder experimentell. Einzig bei den Sicherheitsaktualisierungen muss man Abstriche machen, weil diese erst etwas später im Testing-Repository eingepflegt werden. Wenn das ein relevantes Kriterium ist, dann besser bei Debian-Stable bleiben, oder sich testweise mit Debian-Unstable versuchen, was man gewissermaßen als Rolling-Release ansehen kann.

Tja, also bei mir friert KDE5 in Minutenabständen regelmäßig für 1-2 Minuten ein, um dann kurz "normal" weiterzulaufen, um dann wieder einzufrieren. Ich warte jetzt auf die neuen Pakete, die hoffentlich bald in Testing landen. Sollte der Bug weiterhin bestehen, melde ich ihn.

Insgesamt habe ich schon 7 bugs berichtet. Das ist doch etwas zeitaufwändiger, als ich gedacht hätte. Hoffentlich werden die Probleme bis zum release noch gefixt.

Eine Sache habe ich noch:

Ich kann SDDM momentan nicht mehr installieren. Ich habe das Paket purged und versucht neu zu installieren. Aber die Installation bricht dann immer mit Fehler 255 am Ende ab. Das ist aber neu, und wahrscheinlich durch eines der letzten updates hinzugekommen. Ich tippe auf das update der libc6 von neulich.

EDIT:

Die Fehlermeldung lautet wie folgt:

Code: Alles auswählen

E: Sub-process /usr/bin/dpkg returned an error code (1)
Ein Paket konnte nicht installiert werden. Wiederherstellung wird versucht:
sddm (0.13.0-1) wird eingerichtet ...
debconf: kann Oberfläche nicht initialisieren: Gnome
debconf: (Can't locate Gtk2.pm in @INC (you may need to install the Gtk2 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Gnome.pm line 91.)
debconf: greife zurück auf die Oberfläche: Dialog
Unknown terminal: qterminal
Check the TERM environment variable.
Also make sure that the terminal is defined in the terminfo database.
Alternatively, set the TERMCAP environment variable to the desired
termcap entry.
debconf: whiptail output the above errors, giving up!
sh: printf: I/O error
dpkg: Fehler beim Bearbeiten des Paketes sddm (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 255 zurück

Code: Alles auswählen

E: sddm: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 255 zurück

[pferdefreund]

Da exisitiert wohl ein Mix mit eigenen Geschichten /usr/local/lib sagt da alles. Eventuell das Zeug mit checkinstall ordentlich ins System integrieren. Der will ja noch Gtk2. usw.

[clue]

Da exisitiert wohl ein Mix mit eigenen Geschichten /usr/local/lib sagt da alles. Eventuell das Zeug mit checkinstall ordentlich ins System integrieren. Der will ja noch Gtk2. usw.

Könntest Du mir kurz eine Anleitung geben, was ich genau zu machen habe, damit das wieder läuft? Von checkinstall hab ich in all den Jahren bei Debian noch nicht mal was gehört

[clue]

Wollte noch kurz Rückmeldung geben:

Ich hab jetzt die allermeisten Probleme lösen können:

Die SDDM Installation ging deshalb schief, weil Synaptic die Umgebungsvariablen meines Standardbenutzers (also desjenigen, mit dem ich angemeldet war) verwendet hat. Und bei diesem war als Terminal-Variante qTerminal und nicht Xterm eingetragen (ich hatte Synaptic über sudo gestartet). Anscheinend kennt Syntaptic qTerminal nicht und deswegen ging die Installation von einigen, aber nicht allen Paketen, in die Hose. Die Lösung bestand also darin, bei meinem Standardbenutzer die Terminalvariable auf Xterm umzustellen.

Dass KDE Plasma 5 bei mir ständig einfrohr und keine 10 Sekunden am Stück die Fenster sauber darstellen konnte lag an folgendem: Ich hatte vor dem upgrade auf testing alle Pakete von KDE und dem xserver runtergerupft um dann sauber die testing Varianten installieren zu können. Um das ganze aber weiterhin unter Synaptic zu machen, habe ich mir kurz Openbox installiert.
Nun kommts: Obwohl ich kwin-x11 mitsamt dem restlichen KDE installiert hatte, stand als Standardfenstermanager immernoch Openbox drin. Und der konnte mit KDE wohl nicht.

Lösung: update-alternatives --config x-window-manager und dann die Priorität auf kwin-x11 gesetzt.

Nun läufts recht brauchbar

[whisper]

Glückwunsch.
Dass der Openbox mit KDE nicht kann ... gut zu wissen.
...warum nutzt du sudo?