[GELÖST] 10.1-Update zerschießt Gnome-Fenstermanager

[eet]

Hoffentlich habe ich das richtig ausgedrückt.

Nach dem Update auf das heutige 10.1er 'base'-repository auf ftp.gwdg.de ließ sich erstmal der Gnome-Fenstermanager 2 Minuten(!) Zeit zu starten. Danach sah die Umgebung ganz normal aus; XGL funktionierte prima, usw. Danach habe ich beim Abmelden des Benutzers 'Einstellungen speichern' gewählt.

Beim nächsten Starten des Benutzerkontos lud der Fenstermanager dann gewohnt schnell, nur: Alle Fensterleisten sind verschwunden; XGL funktioniert nicht mehr; Fenster, die einmal geöffnet werden, lassen sich nicht mehr in den Hintergrund verbannen; Menüs verschwinden, einma aufgerufen, nicht mehr vollständig; nach dem Scrollen ist alles verwischt...Argh! Inzwischen habe ich das ganze reproduziert. Nach 'Einstellungen speichern' ist alles im Eimer.

Hätte nicht gedacht, dass ich nochmal den Tag erleben muss, da bei SUSE das base-repository 'gefährlich' ist.

Aber es muss einem ja nur gesagt werden...

Klasse gebastelt, Freunde. Da möchte man doch innerlich das Wort 'gefrickelt' zumindest denken. So, das ist jetzt der Zeitpunkt, da ich erstmals seit SUSE 9.2 einen Wechsel zu einer anderen Distro ins Auge fasse.
Goodbye Novell, hello Red Hat?

Edit: Nachdem die erste Wut sich gelegt hat, habe ich alle Pakete auf den Stand der Installtations-CDs zurückgespielt; brachte nichts. Schließlich habe ich einen neuen Benutzer angelegt und: voila! Also steckt da der Teufel wieder in einer Einstellungsklamotte in gconf, schätze ich mal. Schön, schön, einen neuen Benutzer anlegen musste ich ja das erste mal nach der Installation auch, um XGL ans Laufen zu bringen. Vermutlich hätte ich mir das Rückspielen der Pakete sparen können. Aber toll finden kann ich das nicht, wenn mir sowas nach einem Update auf das aktuelle 'base' passiert. Und wie ich mein root-Konto wieder ansehnlich bekommte, weiß ich immer noch nicht.

 

[traffic]

Kann ich nicht reproduzieren - keine Ahnung, was da "gefrickelt" sein soll.

Wahrscheinlich doch eine "Frickelei" auf Benutzerseite (Gemisch aus 10.0- und 10.1-Paketen, Updateversuche mit nicht unterstützten Tools etc.).

 

[eet]

Nope. Es sei denn, Smart ist jetzt ein 'nicht unterstütztes Tool'.

root-Partition formatiert, 10.1 installiert, /home von 10.0 eingebunden. Problem dass XGL nicht lief, neuen Benutzer erstellt, alte Dokumente rüberkopiert, lief.

Update mit Smart auf 10.1er Base-Pakete auf ftp.gwdg.de führte zu beschriebenen Problemen.

Rückspielen der DVD mit Smart (DVD eingebunden, rpm-sys auf Priorität -1 gesetzt). Lief immer noch nicht. Neuen Benutzer angelegt --> läuft wieder.

So. Irgendeine andere Idee?

Meine wohlmeinendste Vermutung ist, dass einer der Mirror-Server, die ich bei Smart benutze, falsche Pakete lieferte. Aber um das zu verifizieren, müsste ich es nochmal versuchen.

 

[traffic]

Nope. Es sei denn, Smart ist jetzt ein 'nicht unterstütztes Tool'.

Ist es.

Warum wird aus der Tatsache, dass ein alternativer Paketmanager lediglich mitgeliefert wird, eigentlich immer geschlussfolgert, dass dieser vollständig unterstützt sei und dass damit alles geht, was gehen soll bzw. erwartet wird?

Ein richtiges Update führt man so durch:

- Rechner herunterfahren
- In den BIOS-Einstellungen überprüfen, dass der Rechner eingestellt ist, bevorzugt von der CD zu booten
- CD1 der zu installierenden neuen Version ins Laufwerk einlegen
- Rechner einschalten
- Bootvorgang des Installations-Systems abwarten
- Die Anfangsfragen beantworten, dann an der richtigen Stelle "Aktualisierung" statt "Neuinstallation" auswählen

Fertig und funktioniert. Anders kann es auch gehen, muss es aber nicht.

So. Irgendeine andere Idee?

Vermurkste Konfigurationsdateien in irgendwelchen Dotfiles im Homeverzeichnis.

 

[Keepers]

Nope. Es sei denn, Smart ist jetzt ein 'nicht unterstütztes Tool'.

Ist es.

Warum wird aus der Tatsache, dass ein alternativer Paketmanager lediglich mitgeliefert wird, eigentlich immer geschlussfolgert, dass dieser vollständig unterstützt sei und dass damit alles geht, was gehen soll bzw. erwartet wird?

Ein richtiges Update führt man so durch:

- Rechner herunterfahren
- In den BIOS-Einstellungen überprüfen, dass der Rechner eingestellt ist, bevorzugt von der CD zu booten
- CD1 der zu installierenden neuen Version ins Laufwerk einlegen
- Rechner einschalten
- Bootvorgang des Installations-Systems abwarten
- Die Anfangsfragen beantworten, dann an der richtigen Stelle "Aktualisierung" statt "Neuinstallation" auswählen

Fertig und funktioniert. Anders kann es auch gehen, muss es aber nicht.

So. Irgendeine andere Idee?

Vermurkste Konfigurationsdateien in irgendwelchen Dotfiles im Homeverzeichnis.

Bitte huete dich stark vor dem Punkt "Fertig und funktioniert."...
Diese Aussage ist ueberhaupt nicht zutreffend und sollte auch nicht mit Einschraenkungen getroffen werden... Ein Upgrade birgt IMMER ein Risiko und bloß weil 1000 Upgrades funktionierten muss es nicht beim 1001ten Mal so sein.

 

[eet]

Nope. Es sei denn, Smart ist jetzt ein 'nicht unterstütztes Tool'.

Ist es.

Warum wird aus der Tatsache, dass ein alternativer Paketmanager lediglich mitgeliefert wird, eigentlich immer geschlussfolgert, dass dieser vollständig unterstützt sei und dass damit alles geht, was gehen soll bzw. erwartet wird?

Ein richtiges Update führt man so durch:

- Rechner herunterfahren
[...]
- Die Anfangsfragen beantworten, dann an der richtigen Stelle "Aktualisierung" statt "Neuinstallation" auswählen

Fertig und funktioniert. Anders kann es auch gehen, muss es aber nicht.

So. Irgendeine andere Idee?

Vermurkste Konfigurationsdateien in irgendwelchen Dotfiles im Homeverzeichnis.

Vielleicht habe ich mich missverständlich ausgedrückt. Mit Update meinte ich nur das Einspielen der 300irgendwas Pakete, die seit Erscheinen des ISOs in neuerer Version im base-repository der 10.1 aufgetaucht sind.

Die Installation von 10.1 (nennen wir es mal 'Upgrade') lief als 'Neuninstallation' mit Formatieren von /root. Der 'Update'-Funktion des Installers trau ich nicht so ganz, ich habe lieber alles neu. Smart habe ich lediglich für das Einspielen der Updates benutzt.
Definitiv sind Dotfiles in irgendeinem Verzeichnis verantwortlich. Sonst würde es wohl nicht nach dem Anlegen eines neuen Benutzers wieder funktionieren. Nur welche? Root kann ich ja nicht neu anlegen. Natürlich ist das von akademischem Interesse, man kommt ja gut aus, ohne sich als root einzuloggen. Na ja, ich hatte mir halt eher erwartet, dass in Base Pakete ergänzt würden, um kleine Missstände auszuräumen, die man vor dem offiziellen Stichtag nicht mehr zu beseitigen geschafft hat. Na ja, nix is ohne Risiko.

Edit: A-ha! Da stimmt doch irgendetwas nicht! Als ich jetzt smart update laufen lasse, zeigt mir Smart im base-repository nur drei neuere Pakete als die Ursprungsinstallation (db, glibc und glibc-devel). Das letzte mal waren es über 300, und ich dachte nur, 'da gab es wohl viel nachzubessern' - was habe ich da wohl installiert...? Die Channelliste habe ich nicht geändert (http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/...).

Mea culpa; ich hätte den anderen Threads über die 10.1 besser folgen sollen, dann hätte ich gemerkt, dass das mit den 300 neueren Paketen ja wohl nicht sein kann.
Ich denke, da darf ich mich nicht wundern, dass es alles zerhauen hat, was, wie gesagt, auch immer ich da installiert habe.

 

[Keepers]

Du hast unter /root alles neu installiert ??

Die Installation von 10.1 (nennen wir es mal 'Upgrade') lief als 'Neuninstallation' mit Formatieren von /root.

 

[eet]

Nee, nee; entschuldige wenn ich mich immer noch kryptisch ausdrücke. Also:

Partitionierung unter SUSE 10.0:
/-Partition
/home-Partition

Installations-CD von 10.1 rein, von CD gestartet.

Auwahl: Neuinstallation.

/-Partition gelöscht, formatiert, Mountpoint auf '/' gesetzt.

D.h., altes System weg, /home erhalten.

Mountpoint von altem /home auf /home gesetzt.

Nach manueller Installation des nvidia-Treibers und XGL-Installation nach 'Cool Solution'-How-to funktionierte XGL zunächst nicht.

--> Neuen Benutzer in /home erzeugt, nur Dokumente und Dotverzeichnisse einzelner Anwendungen dorthin rüberkopiert --> funktionierte. Root-Benutzer funktionerte natürlich, da per se neu.

Dann:
'Seltsames Update' --> Jetzt dauerte das Starten des Gnome-Desktops plötzlich geschlagene zwei Minuten, XGL war aber nach wie vor funktional. Nach Ausloggen des Benutzers mit 'Aktuelle Einstellungen Speichern' kam es aber zu oben beschriebenem Problem; keine Fensterleisten mehr, kein Xgl, andere Grafikquerelen. (Leider war ich so doof, das auch mit Root zu probieren, so dass Root bis jetzt ohne jegliche Fensterleisten usw. daherkommt.)

Dann: Rückspielen der Pakete der Installationsmedien mit Smart. --> Keine Änderung.

Daraufhin: Erneut neuen Benutzer angelegt --> Problem verschwunden.

 

[Morlon]

Update mit Smart auf 10.1er Base-Pakete auf ftp.gwdg.de führte zu beschriebenen Problemen.

Rückspielen der DVD mit Smart (DVD eingebunden, rpm-sys auf Priorität -1 gesetzt). Lief immer noch nicht. Neuen Benutzer angelegt --> läuft wieder.

So. Irgendeine andere Idee?

Meine wohlmeinendste Vermutung ist, dass einer der Mirror-Server, die ich bei Smart benutze, falsche Pakete lieferte. Aber um das zu verifizieren, müsste ich es nochmal versuchen.

Sicher, dass du die richtigen 10.1er Isos hattest? In Base wurden nur 3 Pakete geändert, der Rest ist identisch zu den GM des Release und die 3 Pakete rufen das nicht hervor.

Entweder hattest du in den Verzeichnissen aus dem alten home irgendwelche Leichen, die jetzt Probleme machen, oder noch Beta-Isos.

MfG

 

[eet]

Hm, also eigentlich habe ich oben schon geschrieben:

- JETZT zeigt Smart tatsächlich nur 3 Pakete aus dem base für Updates an
- Das Problem tritt auch unter root auf, das natürlich NICHT Überbleibsel der 10.0 aufweist...

Also: Bis auf das Mysterium, warum es beim ersten Update so absolut schief ging, ist eigentlich alles paletti. Ich werde den Titel mal entsprechend ändern. Öh, und bis auf das root-Konto.

 

[Morlon]

Hast du mal versucht ohne XGL zu starten?
Es ist immerhin noch im Anfangsstadium, wo Bugs auftreten können.

Du kannst auch mal versuchen, alles im root-Verzeichnis zu sichern und den Ordner dann leeren.

MfG

 

[erdballer]

hallo,

ich habe das gleiche problem und keine lust, schon wieder neu zu installieren. ich habe vor dem problem KEIN update irgendeines paketes vorgenommen, ich habe auch KEINE softwarepakete außerhalb der suse 10.1-dvd installiert, allerdings das design im kontrollzentrum verändert (application + symbole, NICHT die fensterdekorationen).
nach dem klick auf "einstellungen speichern" beim abmelden und dem erneuten anmelden sind alle fensterleisten verschwunden. xgl war aktiviert, läuft ja auch normalerweise ohne probleme.
natürlich aktiviert man diese option erst, wenn man alles schön eingstellt hat - zum X-TEN Mal...

xgl akzeptiert keine zusätzlichen fensterdekorationen, daher habe ich die auf dem systemstandard gelassen (gilouche?)
nach dem deaktivieren von xgl ergab sich keine besserung.

was ich nicht testen konnte: ob das problem auch ohne (vorher) aktiviertes xgl auftritt.

nun möchte ich einen neuen benutzer als abhilfe installieren, habe aber wohl einige fehler gemacht (falsche angabe home-verzeichnis)

[[offtopic: ich bekomme den (von einer früheren suse 10.1 installation bekannten) fehler
"die datei $HOME/.dmrc besitzt ungültige zugriffsrechte und wird deshalb ignoriert. dadurch kann standardsitzung und sprache nicht gespeichert werden. die datei sollte eigentum des benutzers sein und die oktalen rechte 644 haben". anpassen der rechte damals nützte nichts, jetzt ist noch mehr schief gelaufen, wie es scheint]].

suse scheint nun ganz abgeraucht zu sein.
wie bei den X installationen zuvor wird eine reparatur per dvd eh nichts bringen / abstürzen...

benutzerkonfiguration:
-windows-umsteiger
-maus- und gui-orientierter, aber konsolen-fähiger linux-laie im lernstadium

systemkonfiguration:
- samsung x20 notebook, SXGA (1400x1050), 1024 MB RAM, 1,6 Ghz
- centrino 2200bg (128 mb shared, kommt weitestgehend mit xgl klar)
- suse 10.1 (12 stunden alt), gnome + kde komplett, keine zusatz-pakete
- xlg aktiv
- keine eigenständigen manipulationen an system-dateien ohne yast, ausnahme wpa_supplicant
- /home liegt bei mir auf einer zweiten ext3-partition - ich glaube hinter der root-partition (auch ext3).

was vergessen?

kann jemand helfen oder dieses problem weiterhin nachvollziehen?

danke und grüße,

karsten