Dienstag, 6. Juli 2010
Bisher gab es nie Probleme mit der Installation eines proprietären Grafiktreibers für meine Onboard ATI Radeon HD3300, was sich aber in Ubuntu Lucid Lynx geändert hat. Nach dem Update von Karmic auf Lucid und dem Herunterladen des Treibers über das Applet Hardware Treiber erhielt ich einen bunten Brei an Farben und Linien, welcher sich auch noch bei jeder Mausbewegung änderte und bewegte. Verschob man ein Fenster, konnte man Glück haben, dass man eventuell Menüs oder Schriften wieder korrekt angezeigt bekam. Da dies aber in keinster Weise akzeptabel war, verschwand der verbuggte Treiber schnell wieder von meinem System und ich versuchte mein Glück diesmal mit dem Exemplar von der ATI Seite: Doch auch hier das gleiche Bild (im wahrsten Sinne des Wortes). Also, alle proprietären Treiber wieder entfernt und wieder den standard Open Source “radeon” aktiviert. Bisher lief damit eigentlich alles einwandfrei, bis, ja bis auf eine Kleinigkeit die eigentlich nich so besonders auffällig war aber doch ein wenig störte. Das System war träge, nicht wirklich langsam, aber träge. Mal ein ruckeliges Scrollen auf Websites während die CPU Last nach oben schoss, mal kurze Programmaussetzer, nichts gravierendes aber trotzdem nervig.
Also entschloss ich mich dem Problem auf den Grund zu gehen, was allerdings gar nicht so einfach war, denn was löste diesen Bug aus? Nach einiger Suche fand ich dann den Übeltäter: KMS (kernel-mode-settings), die neue Kernel-Videoarchitektur die eigentlich Probleme be- und die Performans anheben sollte. Laut Known Issues for Lucid Lynx eine bekanntes Problem was allerdings nur sehr selten auftreten soll – anscheinend gehöre ich auch zu diesen sehr seltenen Fällen. Die Lösung ist einfach und schnell gemacht:
Um KMS zu deaktiviern muss die Datei /etc/default/grub editiert werden. An der Stelle GRUB_CMDLINE_LINUX muss die Option nomodeset hinzugefügt werden.
Anschliessend muss noch ein sudo update-grub ausgeführt werden um die Änderung zu übernehmen. Nach einem Reboot ist das Problem behoben.
Schlagworte:ati, bug, CPU, driver, error, hd3300, kernel, kms, Linux, lucid, performance, radeon, slow, stutter, treiber, ubuntu
Veröffentlicht in Allgemein | Keine Kommentare »
Montag, 2. November 2009
Das altbekannte Problem mit USB Geräten in einem Virtalbox Gast ist auch in Karmic Koala nicht behoben. Hier kann man allerdings nicht mehr vorgehen, wie ich in diesem Artikel beschrieben habe, weil sich bei Karmic einiges “unter der Haube” getan hat und das Script mountkerfs.sh nicht mehr existiert. Dennoch lässt sich der USB Support wieder leicht und schnell aktivieren: Zuerst den eigenen Benutzer zur Gruppe “vboxusers” hinzufügen, dies kann über die “Benutzer und Gruppen”-GUI unter System –> Systemverwaltung geschehen. Um Zugriff auf die USB Geräte zu aktivieren, muss zuerst wieder die Gruppen ID der vboxusers Gruppe herausgefunden werden. Die geschieht per cat /etc/group|grep vboxusers , was in meinem Fall die Ausgabe vboxusers:x:121:nox liefert. Die Zahl, hier 121 ist die Gruppen ID. Nun öffen wir die Datei /etc/fstab mit Root Rechten in einem Editor (z.B. per sudo gedit /etc/fstab ) und fügen am Ende folgende Zeilen ein:
#virtualbox USB fix
none /proc/bus/usb usbfs devgid=121,devmode=664 0 0
Wichtig hierbei ist, das hinter devgid die korrekte Gruppen ID eingetragen wird! Dann die Datei speichern und den Rechner neu booten, danach sollten sämtliche USB Geräte mit Virtualbox benutzt werden können. Refernzsystem ist hier Ubuntu Karmic Koala AMD64 Kernel 2.6.31-14-generic mit Virtual Box 3.0.10-54097 Ubuntu Karmic amd64.
Schlagworte:error, fehler, geräte, gid, grau, grey, karmic, koala, sun, USB, virtualbox
Veröffentlicht in Computer, Linux, Misc | 9 Kommentare »
Freitag, 20. Februar 2009
Nachdem ich die äusserst kluge Idee hatte, Permalinks auf meinem Blog einzuführen, bin ich nun so klug jedem zu raten, dies tunlichst zu unterlassen! Das Einstellen der Permalinks hat das komplette Blog zerschossen! Error 404, Error 403 oder auch Error 500 (Internal Server Error), alles habe ich dabei gesehen. Durch stundenlange Googlei habe ich auch nicht viel gefunden, sodass ich die Lösung selbst erarbeiten musste, die ich gerne hier vorstellen möchte:
1. Durch die Umstellung auf Permalinks, hat WordPress die Datei .htaccess im Root Verzeichnis von WordPress geändert. Löscht man diese, hat man nun zumindest schon mal wieder Zugriff auf das Admin Backend.
2. Jetzt unter –> Einstellungen –> Permalinks die Einstellung wieder auf Standart ändern. Das sollte mal wieder einen Error 403 hervorrufen, aber die Einstellungen sollten trotzdem übernommen worden sein.
3. Nochmal die .htaccess löschen, damit wir wieder ins Backend kommen. Klicken wir wieder auf Permalinks, sollte der Radiobutton wieder auf Standart eingestellt sein. Noch können wir aber trotzdem nicht auf das Blog zugreifen. Eine weitere Möglichkeit zu prüfen, ob die Links wieder zurückgesetzt wurden, ist einen Artikel anzuzeigen. Klappt das, sollte einer erfolgreichen Wiederherstellung nichts im Weg stehen.
4. Jetzt klicken wir auf Werkzeuge –> Aktualisieren –> Automatisch Reinstallieren. Danach war bei mir der Fehler behoben und ich konnte wieder normal auf Blog und Adminbackend zugreifen.
Die Anleitung bezieht sich auf WordPress 2.7.1! Viel Erfolg!
Schlagworte:2.7, 2.7.1, 403, 404, 500, abrufen, absturz, ändern, artikel, aufrufbar, backend, backup, blog, crash, erreichbar, error, fehler, hilfe, htaccess, internal server error, kaputt, kill, lösung, mod_rewrite, permalink, permission, recht, root, rückgangig, save, sichern, wordpress, wp
Veröffentlicht in Allgemein, Computer, Me, Misc | 2 Kommentare »
Montag, 16. Februar 2009
Wer feste Netzwerkfreigaben in seinem System eingebunden hat, die auf Samba basieren, kennt vielleicht diese oder eine ähnliche Fehlermeldung:
CIFS VFS: server not responding.
No response for cmd 50 ...
So oder so ähnlich. Eigentlich nicht weiter schlimm, würde dies das Herunterfahren des Rechners nicht enorm herauszögern. Das Problem liegt darin, dass das Netzwerk beim Shutdown bereits deaktiviert wurde bzw. die Module entladen, die Cifs Freigabe aber immernoch gemountet ist. Da die Freigabe auf Grund der nicht mehr vorhandenen Netzverbindung nicht mehr getrennt werden kann, kommt es zu diesem Fehler. Um ihn zu beheben muss dafür gesorgt werden, dass die umountnfs.sh früher ausgeführt wird (in S14 statt erst in S31). Dazu geben wir folgendes ein:
sudo mv /etc/rc0.d/S31umountnfs.sh /etc/rc0.d/S14umountnfs.sh
sudo mv /etc/rc6.d/S31umountnfs.sh /etc/rc6.d/S14umountnfs.sh
Danach sollte das System ohne Murren herunterfahren und das Networkshare ordentlich trennen.
Schlagworte:50, ausschalten, cifs, cmd, error, fehler, freigabe, fstab, hardware, herunterfahren, Linux, mount, network, netzwerk, reboot, responding, response, runterfahren, samba, server, share, shell, shutdown, smb, ubuntu, umount, umountnfs, vfat
Veröffentlicht in Computer, Linux, Misc | Keine Kommentare »