Zum neuen Kernel 4.10:

[KBDCALLS]

@niemand:

Jo, dann warte mal, bis dein Testing knallt.

Nö - - wenn ich bis zum Stretch/Freeze kein Knallen (?) erlebt habe, dann ist so ein Knallen (?) beim Stretch/Stable erst recht nicht zu erwarten.

Debian betreibt imho eine sehr verantwortliche Systempflage. Versauen kann sich das System eigentlich nur der unsachgemäß frickelnde Benutzer. Deshalb verzichte ich auch auf das Verwenden von Backports oder gar Fremdquellen.

Backports ist eigentlich relativ unkritisch. Den das sind ja Debianentwickeler. Bei Paketen aus fremden Quellen sollte man besser die Finger lassen . Denn da kriegt man manchmal das gruseln.

[breakthewall]

Kompiliere doch den Kernel selbst und musst nicht extra auf testing gehen.

Mein Distributor liefert standardmäßig Kernel-4.4 aus und aus Spaß habe ich einen 4.9-Kernel compiliert und es ist jetzt mein Default.

Und dir ist auch bewusst, inwieweit sich der Debian-Kernel vom Mainline-Kernel unterscheidet? Klar kann man immer kompilieren, nur bei Letzterem hat man keinen freien und sauberen Kernel mehr. Der Debian-Kernel dagegen, enthält nur noch freie Bestandteile, und nichts mehr was weder Source-Code mitbringt noch gegen die Debian eigenen Richtlinien verstößt. Daher hoffe ich für dich, sofern das für dich Relevanz hat, dass den Kernel mit einer entsprechenden Konfiguration kompiliert hast.

[guennid]

Ich benutze seit über 10 Jahren nahezu ausschließlich selbstkompilierte Kerne von kernel.org

[Revod]

@ rockyracoon

Ja richtige " Knaller " meinte ich auch nicht. Mit " Ostereiern " war eher schwerwiegendere Funktion Fehler. Habe Testing ja... ca. über 2 Jahren und ging auch lange Zeit sehr gut mit den Update ( Auch mit meine eigene Bedienung Konfiguration und der eine oder andere fremde Software und echt jetzt, unbedeutende gepingte Tools, wie das LXPanel, weil die höhere Version buggy ist ).

Auch welches Desktop man benutzt spielt eine Rolle, da gab es in letzter Zeit einige User mit " Magenbeschwerden " mit Testing.

Hatte die Idee Testing wie eine " Rolling Release " Distri zu behandeln, weil ich nicht immer das grosse " Update Risiko " mitmachen wollte ( Auch schon erlebt, nach drei misserfolgte voll Update und Back zurück spulen war eine neue Installation nötig, was ich nicht wieder riskieren will. Auch ein Grund warum ich vor 10 Jahren die " WSUS " velassen hatte ).

Nun ja, dieser " Rolling Release Testing Test " hat am Ende nicht geklappt. Seid 6 Monate keine gültige Sitzung mehr, Mate-Tools vom Mate-Control-Center starten unter lxde-gtk2 nicht mehr, keinen Shutdown / Neustart aus dem Benutzer mehr möglich.

Konnte vor ca. 3 Monate alle diese Fehler beheben, doch nach dem 3. Update waren die gleichen Fehler wieder da, da kommt man sich wie Sisyphos vor wozu ich echt keine Lust darauf habe und erst Recht keine Zeit. Mit Systemd kann ich Debian auf meinen ca. 12 jähriges Fuji echt nicht gebrauchen, nur noch schwarzes Monitor, egal mit ob mit nouveau oder non-free und keine Tastatur Befehl Funktionen mehr möglich usw. Nun ruht es seid drei Monate unberührt vor sich hin und fahre vorerst " nur " mit meiner ersten Distri, PCLinuxOS 32 bit, die die 32 bit seid 6 Monate auch eingestellt wurde ( Dafür kommt eine neue 32 bit aus PCLinuxOS, " Uplos " entwickelt von PCLinuxOS User / Entwickler was in kürze ganz fertig sein wird, fehlt nur noch die Lizenz Entscheid ).

Sind noch 2 bis 5 weitere " Kleinigkeiten " doch die obigen " Ostereiern Erlebnisse " waren / sind ziemlich die fettesten. Nun heisst es für mich abwarten und Tee trinken, bezüglich Debian 32 bit, weiss noch nicht ob ich auf Old-Stable-Jessie zurück gehe und dabei auf " ewig " darauf bleibe, oder mit einer neue Installation auf Testing weiter mache. Unter Jessie, damals Testing hat ausser auf meinen erwähnten Fuji alles funktioniert bei allen anderen Rechner, auch mit meinen " extra Spezial Konfigurationen und ca. 5 Fremde Software und gepingtes LXPanel " . Also wie Du nun liest meine Ostereier in Stretch, resp. Testing kommen gerne immer wieder Mal...

[ViNic]

Und dir ist auch bewusst, inwieweit sich der Debian-Kernel vom Mainline-Kernel unterscheidet? Klar kann man immer kompilieren, nur bei Letzterem hat man keinen freien und sauberen Kernel mehr.

Man kann auch die Debian-konfiguration wählen und somit erhält man einen Debian-kompatiblen Kernel.

Der Debian-Kernel dagegen, enthält nur noch freie Bestandteile, und nichts mehr was weder Source-Code mitbringt noch gegen die Debian eigenen Richtlinien verstößt.

In der Regel "besudelt" man es im nach hinein ohnehin mit modulen aus non-free, wenn man seine Hardware vollständig nutzen will.

Daher hoffe ich für dich, sofern das für dich Relevanz hat, dass den Kernel mit einer entsprechenden Konfiguration kompiliert hast.

Ich nutze kein Debian, folglich habe ich keine Probleme damit

Edit: Was ich noch ergänzen wollte. Kernel kompilieren bringt mMn. den Vorteil, das man sich gewissen Unabhängigkeiten schafft gegen über dem Distributor. Was passiert wenn man aus den Backports oder anderweitigen Quellen, den gewünschten Kernel und Funktionalität nicht bekommt. Was ist wenn die gewünschte Firmware zwar existiert, aber es noch nicht in den Linux-Sources selbst ist und man selbst Hand anlegen muss? Es kann Sinn machen, sich mit solchen Sachen zu beschäftigen.

[rockyracoon]

@Revod:

...Auch mit meine eigene Bedienung Konfiguration (?) und der eine oder andere fremde Software...

Da hast Du Dir vermutlich Deine eigenen "Ostereier" gelegt und solltest nicht Debian ohne Selbstfrickelei für entstehende Probleme verantwortlich machen. Geschweige denn vorsichtige Leute wie mich unnötig und auch vergeblich verunsichern wollen.

Und abgesehen von dem Kauderwelsch in dem Du schreibst, spricht der Rest Deines Posts von verquerem Denken, bei dem mich gar nichts mehr wundert.

@ViNic:

Was ich noch ergänzen wollte. Kernel kompilieren bringt mMn. den Vorteil, das man sich gewissen Unabhängigkeiten schafft gegen über dem Distributor. Was passiert wenn man aus den Backports oder anderweitigen Quellen, den gewünschten Kernel und Funktionalität nicht bekommt.

Ich habe nie eine Funktionalität vermisst. Im Gegenteil, bei Debian habe ich viele wertvolle Anwendungen gefunden. Daher brauche ich keine "Unabhängigkeit" vom Distributor.
Ich teile vielmehr den Post von breakthewall, der vor einem - zudem unnötigen - Kernel-Gefrickel (sprich "Kompilation" - https://debian-handbook.info/browse/de- ... ation.html ), warnt. Es sei denn, man will experimentieren.

[Revod]

Du hättest " Richter " werden sollen, oder doch nicht wegen der viel zu rasche Beurteilung ( Beurteilungen lese ich es nicht nur, nun Richtung meiner Person ).

Zwei reale Beispiele, soeben mein Testing fertig geupdatet ( nach 3 Monate knapp 900 Pakete, in mehrere Etappen und einen Neustart 2 Std Zeit gebraucht ) und immerhin zwei Bugs weg. LXDE meldet nun nach dem einloggen " Keine gültige Sitzung " nicht mehr.

Das System kann nun aus dem Anmeldemanager auch neu gestartet und runter gefahren werden, will heissen die damaligen Befehle, die ich mir damals per Scripte ( Tastenbefehle ohne Rückfrage im lxde, eben lxde hat keine Tools wie Mate, KDE usw. ) eingerichtet hatte nicht mehr gültig sind ( wird ein Klacks sein die Befehle neu zu editieren ). Vor drei Monate wollte das System nicht mehr runter fahren, auch nicht aus dem Anmeldemanager.

Aus Mate nur die [deb]mate-system-tools[/deb] installiert. Wie Du siehst da ist nix im Stretch davon aufgelistet. Allerdings und eigenartigerweise in mein Synaptic noch nicht unter " veraltet " angezeigt. Ich vermute schwer, dass Mate aus Stretch von Grund auf neu rekompiliert werden muss. In Meine sources.list habe ich allerdings " testing " eingetragen.

Habe heute nix neues konfiguriert, oder meine Konfigurationen neu angepasst und trotzdem die obigen zwei Bug weg und wenn Du nun noch " mate-system-tools " nicht im Stretch gelistet berücksichtigst, will heissen dass noch ein paar Dingens in Arg sind im Stretch.

Ach ja, am " init 3 " habe ich auch nichts " rum geschraubt " und trotzdem, es wird nicht geladen, von init 3 bis init 6 nicht.

Alles andere funktioniert nun wieder, ausser die " root pexec " Befehle zum starten eines Tools mit root Berechtigungen, Synaptic, gParted .... Jedoch mit " gksu " , oder aus der Konsole " su und Passwort und synaptic Eingabe und Enter " starten diese Anwendungen, auch " Gufw Firewall Einstellung tool "

Für mich heisst das, dass das ganze pexec Zeug im Stretch noch nicht richtig angepasst wurde, und auch an diese Pexec Scripte habe ich nix rum gefrickelt). Einige user mit Testing mussten die starter.desktop Dateien neu editieren, von " Exec=synaptic-pexec " auf " gksu synaptic " und gut ist. Bin also nicht der einzige mit gleichen und ähnliche Bugs so um nur wegen eigene Konfigurationen anzudeuten. Das sind keine System eigene Konfigurationen, sondern lediglich die lxde Bedienung etwas " komfortabler " damit bereichert, das ist alles.

[simpel]

@rockyraccon

Du kannst sicher sein, manch eine/r frickelt so lange am System rum, bis irgendwas nicht mehr funktioniert, damit er/sie wieder was zu frickeln hat.
Allerdings handelt es sich dann idealerweise um ein Testsystem, welches auf einem separaten Rechner oder einer separaten Platte installiert ist.
Vielleicht hast du irgendwann die Möglichkeit dir ein solches Testsystem einzurichten. Du wirst feststellen, die Lernkurve steigt sehr schnell. Und es vermittelt ein gutes Gefühl, sein System selbst zu administrieren - so gesehen meint frickeln ungefähr das Gleiche

[Revod]

... jepp und ist die richtige Vorgehensweise, auf separate HD, oder Rechner. Anderweitig kann man bei stable bleiben, sich einen Desktop wie XFCE, oder Gnome3, oder Mate, oder und KDE installieren, die ihre eigene " komfortable " Tools von Haus aus mit bringen und doch bloss nix verändern aus Angst Gründe was Kaputt zu machen, sondern nur nutzen so wie es daher kommt.

Dann würde mir die Funktion " Supertaste+1 = Laufwerk Schublade öffnen und alt+1 = Laufwerk Schublade schliessen, oder Supertaste+X = runter fahren ohne Rückfrage usw. " und gelernt hätte ich auch nix, stimmt.

Das alles und die " mate-system-tools " haben alles unter Jessie-Testing bis hin zum Stretch vor 6 Monate funktioniert, die Rede ist über eine langfristige Zeit von gut 3 bis 4 Jahre, also nicht nur für ein paar Minuten / Tage. Will heissen, dass meine extra Konfigurationen über Bedienung im LXDE Desktop nicht soooo verkehrt, oder gar falsch sind, auch weil ich die genau gleichen Konfigurationen in PCLinuxOS seid über 6 Jahren eingerichtet habe und niemals das System in keiner, minimalster weise beeinträchtigten.

@ rockyraccon

- Und ja, mein Kauderwelsch... das Land Deutschland ist nicht die Welt ( Auch " Amis " nicht, die meinen alle müssen ihre Sprache können, wenn sie in einen fremdes Land reisen ), es gibt auch noch andere Nationen.

- Schuld an Debian Distri, oder Linux habe ich niemals gegeben und nochmals, seid über ca. 7 Jahren nutze ich ausschliesslich Linux ( vor 10 Jahren damit angefangen, Vista sei Dank, doch war 3 Jahre lang zu faul wegen xy.doc um ins odf Format zu portieren und daher nutzte noch mein w2k-pro SP4 nur deswegen ).

- Wie Du nun aus meiner, obige Erklärung vielleicht ( ... na ja, wegen meinen Kauderwelsch ) erkennen kannst, es sind keine eigene selbst gelegte Ostereiern.

- Vergessen zu sagen, empfehle Dir weniger zu beurteilen, dafür sachlicher und mehr argumentieren zu versuchen.

[Dogge]

Zwei reale Beispiele, soeben mein Testing fertig geupdatet ( nach 3 Monate knapp 900 Pakete, in mehrere Etappen und einen Neustart 2 Std Zeit gebraucht ) ...

Bei einem rolling release (ja, gleich kommt ein Rabulist und erzählt mir warum Testing kein echtes RR ist ) sollte man regelmäßig updates durchführen. 3 Monate sind schon eine sehr lange Zeit, da hat sich viel geändert, wie du ja an den 900 Paketen siehst. Ich mache bei Testing tägliche Updates und bin nach 3 Wochen Urlaub schon erschlagen wie viel da heruntergeladen werden muss.
Bei einem RR kann es bei langer Zeit zwichen den Updates passieren, dass bei manchen Paketen Versionen übersprungen werden weil in der Zeit schon 2 oder 3 Updates für das Paket kamen und dabei kann es halt mal knallen. Bei täglichen Updates hab ich mit Testing keine negativen Erfahrungen gemacht.

2007/2008 hatte ich mal Arch, dann hatte ich zu Hause mal für 6 Monate kein Internet. Nach dem Update habe ich ein paar Tage versucht das zu reparieren und irgendwann entnervt Arch den Rücken zugewandt.

[rockyracoon]

@Dogge:

Bei täglichen Updates hab ich mit Testing keine negativen Erfahrungen gemacht.

So ging es mir auch. Trotzdem freue ich mich darauf, mit Stretch/Stable etwas kontinuierlicher und upgradeärmer zu fahren.

Zum anderen verquasten Posts gilt ab jetzt für mich: "Dont Feed The Troll..."

[Revod]

@ Dogge

.... 900 Pakete .... jo eben von " jessie-stable später auf stretch-stable " voll zu upgraden sind es vermutlich weitaus mehr... Daher meinen " sinnlichen Testing-RR Testversuch " und eben, es ging über 3 - 4 Jahre immer sehr gut...

Hatte ich ja auch gemacht ( alle 3 bis 4 Tage geht's auch, sehr selten über ca. 80 Pakete ). Doch nach dem ich die Bugs vor 3 Monate gefixt hatte und nach dem zweites Update alle meine Fixes nichts mehr nutzten stellte ich es zurück wie es vor dem Fix war und trotzdem blieben die Bugs erhalten. Und ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt. Deswegen dachte ich in einen Post von mir an Wheezy zurück zu gehen.

Ich vermute auch schwer richtung Systemd, weil immer nach einen udev und Systemd Update die Probleme erschienen sind, bei allen anderen Pakete und Kernel nicht nicht. Genau so war es mit zweiten Systemd Update in Jessie damals, auf meinen FujiTsu Amilo Notebook, schwarzes Monitor und keine Maus, oder Tastatur Funktion mehr vorhanden.

Und als drittes, ich weiss auch nicht wie gut der Code von Systembibliotheken für 32 bit Systeme noch ist. Ob man sich vlt. mehr mühe für 64 bit gibt und unbewusst das 32 bit eher mehr nachlässiger behandelt sein könnte, weisst ja warum.

Kann mich nur wiederholen, ein anderer User hat, oder hatte mit Mate auch seine grosse Probleme, bei einige anderen funktionierte das pexec nicht mehr auch so wie bei mir.

Meinen Jessie ( Testing von damals ) Buck-UP habe ich. Nun eröffnen 2 neue Möglichkeiten, das Buck-Up zurück zu spielen und alles updaten und gucken, oder Stretch neu installierien und von Grund auf wieder neu beginnen und gucken....

... der Rest ist klar ( RR ) ...

[Dogge]

@ Dogge

.... 900 Pakete .... jo eben von " jessie-stable später auf stretch-stable " voll zu upgraden sind es vermutlich weitaus mehr... Daher meinen " sinnlichen Testing-RR Testversuch " und eben, es ging über 3 - 4 Jahre immer sehr gut...

Ich nutze auf meinem Hauptrechner seit 2010 Debian Testing (zuerst als LMDE, nachdem ich feststellte, dass ich außer dem Design alles deinstalliert hatte was aus den Mint-Repos kam hab ich dann irgendwann Anfang 2011 auf Debian Testing umgestellt) und habe auch mal Arch genutzt. Dass man regelmäßig updaten sollte, damit immer alle Änderungen gemacht und nicht beim "Sprung" über 2-3 Versionen verloren gehen ist meine persönliche Erfahrung. YMV.

Ein Vergleich vom Upgrade eines Debian Releases zum nächsten mit einem Testing-Upgrade nach mehrmonatiger Pause zu vergleichen macht meiner Meinung nach keinen Sinn, da das Update von Stable zu Stable gründlich getestet wird, das Testing-Upgrade vom Stand Zeitpunkt x und Update-Pause bis x+n Monate hat halt niemand getestet. Die Entwickler die Testing oder Unstable benutzen werden wohl immer auf dem aktuellsten Stand arbeiten, da sie ihre Pakete ja im Zusammenspiel mit dem state-of-the-art Debian testen wollen.

[simpel]

... ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt.

Dass ist durchaus möglich - neue Kernel enthalten neue Treiber, Treiber für veraltete Hardware fliegen irgendwann raus.

Für so alte Hardware verwende ich den 2.6er Kernel. Keine Ahnung, ob es den für Debian überhaupt noch gibt? CentOS6 wäre da meine erste Wahl (Support noch bis 2020, meine ich gelesen zu haben)

[Tintom]

... ich vermute auch schwer, meinen ca. 13 Jahres altes AMD Athlon HW Chipsätze werden nicht mehr richtig unterstützt.

Dass ist durchaus möglich - neue Kernel enthalten neue Treiber, Treiber für veraltete Hardware fliegen irgendwann raus.

13 Jahre sind für Hardware aus Sicht des Kernels noch jungfräulich
Zum Vergleich: Der SCSI-Controller meines ersten Rechners (Baujahr 1994) wird upstream immer noch gepflegt. Deine Probleme müssen eine andere Ursache haben

[Revod]

@ simpel

CentOS kenne ich. Nutze jedoch als Hauptdistri PCLinuxOS, die auf allen meine Rechner / Notebooks funktioniert, Kernel 4.1, etwas konservative Distri abgesehen davon, dass sie die 32 bit seid 6 Monate eingestellt hat.

...
Ein Vergleich vom Upgrade eines Debian Releases zum nächsten mit einem Testing-Upgrade nach mehrmonatiger Pause zu vergleichen macht meiner Meinung nach keinen Sinn, da das Update von Stable zu Stable gründlich getestet wird, das Testing-Upgrade vom Stand Zeitpunkt x und Update-Pause bis x+n Monate hat halt niemand getestet. Die Entwickler die Testing oder Unstable benutzen werden wohl immer auf dem aktuellsten Stand arbeiten, da sie ihre Pakete ja im Zusammenspiel mit dem state-of-the-art Debian testen wollen.

Prinzipiell hast Du Recht. Hatte jedoch auch andere Erfahrungen, einen konkretes Beispiel, FileZilla, liess sich über 2 bis 3 Monate wegen unerfüllte Abhängigkeiten nicht updaten ( wurde gar wegen einer Lieb Aktualisierung automatisch deinstalliert und beim Versuch neu zu installieren nachdem alle Update eingespielt wurden eben wegen unerfüllte Abhängigkeit nicht mehr installieren liess. Synaptic neu laden half auch nicht ). Geduldig gewartet und dann liess sich FileZilla wieder installieren.

Noch eine 3. Möglichkeit besteht,. Die sources.list auf " testing " belassen und täglich schön brav immer weiter updaten, zwei Bugs sind ja seid heute schon Mal weg geupdadet worden. Neu installieren kann ich ja dann immer noch, habe minim. noch 2 Jahre Zeit für " jessie-oldstable "

Einen Grund muss es doch wohl geben warum die Pakete " mate-system-tools und mate-system-tools-common " Komponente des " mate-control-center " nur noch unter jessie gelistet werden ( eben, nur diese starten nun nicht mehr. Zwei weitere Bugs sind lösbar ). Und wenn ich mir die Abhängigkeiten von,

https://packages.debian.org/stretch/mate-control-center

angucke gehe ich davon aus, dass " mate-system-tools und mate-system-tools-common " aus dem " mate-control-center " raus genommen wurden, oder darin implementiert wurden, könnte ich morgen mit einer Installation des " mate-control-center " testen ( Mal gucken was es mir sonst noch vom Mate mit installieren will ).

@ Tintom

... und wie ich das gerne wüsste, wenn die logs es auch verraten würden, doch leider steht darin auch nur das was ich direkt vom Monitor aus sehe, kommt Zeit kommt Rat... habe noch eine Idee über die Mate Pakete, doch morgen / in nächster Zeit weiter experimentieren....

[simpel]

13 Jahre sind für Hardware aus Sicht des Kernels noch jungfräulich
Zum Vergleich: Der SCSI-Controller meines ersten Rechners (Baujahr 1994) wird upstream immer noch gepflegt.

Bei SCSI-Controllern mag das durchaus zutreffen - immerhin ist Debian ein Server OS.
Und ich möchte bestimmt auch nicht rechthaberisch wirken, jedoch kann ich meine Aussage konkret belegen.
Ich habe ein original IBM ThinkPad aus 2003 mit einer relativ exotischen ATI-Grafik und einem ebenso exotischen Ali Chipsatz - was ich damals beim Kauf nicht ahnen konnte. Ab irgendeinem 3er Kernel wurde die Hardware nicht mehr unterstützt. Installiert habe ich dann CentoOS 6.1., welches auf einem aufgebohrten 2.6er Kernel basiert - die betreffende Hardware wird sozusagen out of the box unterstützt.
Alle anderen Versuche ein brauchbares Linux mit vollständiger Hardwareerkennung zu installieren, schlugen mehr oder weniger fehl.

[DeletedUserReAsG]

immerhin ist Debian ein Server OS.

Achso, deswegen die ’zig Windowmanager und Desktopumgebungen im Repo ….

Ansonsten: dass alte HW mitunter rausfliegt, ist kein Geheimnis. Viele alte Grafikkarten lassen sich z.B. nicht mehr sinnvoll nutzen, und bei Hardware, zu welcher der Hersteller den Treiber mitgeliefert hat, sieht’s auch ganz düster aus: einmal geschrieben, für den zu der Zeit aktuellen Kernel, und dann nie wieder angefasst.

[ViNic]

Achso, deswegen die ’zig Windowmanager und Desktopumgebungen im Repo ….

Für die ganzen verirrten und verwirrten ... Debian ist ganz klar ein Server OS, Linux wurde für die Server erfunden

[scientific]

immerhin ist Debian ein Server OS.

Achso, deswegen die ’zig Windowmanager und Desktopumgebungen im Repo ….

Ansonsten: dass alte HW mitunter rausfliegt, ist kein Geheimnis. Viele alte Grafikkarten lassen sich z.B. nicht mehr sinnvoll nutzen, und bei Hardware, zu welcher der Hersteller den Treiber mitgeliefert hat, sieht’s auch ganz düster aus: einmal geschrieben, für den zu der Zeit aktuellen Kernel, und dann nie wieder angefasst.

NDAS von ximeta ist da auch so ein Fall... Hab mir vor Jahren so eine Platte wider besseres Wissen zugelegt... Die Firma wurde mehrfach verkauft, die Linux-Treiber waren immer instabil und sind seit Kernel 2.26 oder so ungepflegt... Zum "Glück" hat die Platte von selber den Geist aufgegeben (Controller kaputt oder so) und ich hab sie ins Nirvana geschickt und unter "Fehlkäufe" verbucht

lg scientific

[Revod]

Irgend jemand ne Idee...

viewtopic.php?f=12&t=164005

( ... Bezug auf Problemlos HW, Lib's, Systemd usw. ... )?

Nicht falsch verstehen und will auch nicht rechthaberisch sein, es bestätigt nur meine Annahmen, es sind nur Annahmen... Solche Probleme hatte ich bis vor 4 - 5 Jahren ( bis und mit wheezy ) noch nie mit Debian erlebt.

Bei Testnig kann bei manchen problemlos sein und bei manchen andere user mit andere HW Zusammenstellung unterschiedliche Probleme verursachen. Ob das nun bei neue Testing Versionen so bestehen bleibt, oder explizit nur Stretch solche Probleme verursacht kann ich auch nicht sagen.

Bestärkt mich in meinen Gedanke, abwarten und Tee trinken.

PS: Hatte vergessen zu erwähnen, dass unter den Update auch lxde Pakete sich darunter befanden, daher wurden die zwei Bugs unter LXDE beseitigt.

PS 2: Habe heute noch nichts updadet nur weiter getestet, Pexec Befehl root funktioniert nun. Hatte gestern noch das Paket " pexec " nach installiert und nun startet Synaptic mit dem Pexec Befehl nach Passwort Abfrage korrekt, gPartet auch und alle root Tools mit Pexec auch. Weiss nicht warum seid ca. Mitte letztes Jahres tägliche Update Synaptic das Paket stets ausgelassen hat zu installieren. Auch die Standard reboot und runter fahren vom lxde klappen nun wieder.

Somit 4. schweres Bug behoben ( Bin frog keine unzählige starter.desktop Dateien um zu editieren zu müssen ). Die " mate-system-tools " starten jedoch immer noch nicht, meine schwere Vermutung, diese sind nicht mehr mit Stretch kompatibel, daher werden sie auch nur unter jessie gelistet.

Bleibt nur noch einen schwerer Bug, der sich im Laufe der Update seid ca. 6 Monate eingeschlichen das Wechsel zur Konsole, werden nur 10 Zeilen untereinander angezeigt, die

Authentication failure

lauten. Weiss jemand einen schnelles, einfaches Rat der hier gepostet werden kann, oder soll ich einen Thread starten ( zurück zur lxde Anmeldung klappt jedoch anstandslos ctrl+alt+F3 und zurück ctrl+alt+F7 )? Anmelde Manager, " lghtdm mit lightdm-kde-greeter " installiert.

... ok mache neuen Thread auf in " Grafische Oberflächen "...