Von Squeeze zu Wheezy

Sunday, May 12. 2013

Ein wenig nervös macht mich ein Dist-Upgrade schon, man hofft auf di Linderung einer lang ertragenen Druckstelle durch das viel aktuellere Paket so.und.so und ahnt doch, dass das durch manchen neuen Kummer erkauft wird. Auf den ersten Blick schien auf dem meist headless laufenden Rechner auch alles zu laufen, die Überraschungen kamen mit den grafischen Oberflächen.

Die Kiste lief vorher schon mit LXDE, aber nach dem Upgrade war plötzlich wieder Gnome der Standard. Gnome3 und was mich nun wirklich störte, war die Fluppe, die mir Gnome nun ständig zog, weil es in der thightvnc-Umgebung nicht alle Features ausspielen konnte sondern im Fallback-Modus lief. 

Gnome3 in der tightvnc-Umgebung eine Zumutung gefunden, versucht, es durch LXDE zu ersetzen.LXDE soweit unbenutzbar gefunden, ein Grossteil der Probleme mögen nicht wiedergefundene config-Dateien sein aber auch nach vielen Stunden Mühen blieb es dabei, dass der pcmanFM nur für root startete und sichtbar wurde (incl Desktop-Bild, Icons, Config-Dialog), für user aber zwar startete, aber nicht angezeigt wurde.Endlich aufgegeben und stattdessen XFCE installiert, dass nun tut was es soll. Bei der Gelegenheit habe ich mich des überwiegenden Teils der Gnome3-Pakete entledigt.

Noch etwas hefiger war die Entdeckung, dass mit dem neuen Kernel 3.2.0-4-amd64 nicht mehr die ganze Bildschirmfläche benutzt wurde, sondern nur noch die oberen 1280x768. Den Kernel hatte ich anfangs nicht in Verdacht sondern Grub, denn der zeigte anfangs das Grub-Menue noch auf der vollen Fläche, wechselte dann aber nach den ersten Bootmeldungen in den beschnittenen Modus. 
Wie schon beim LXDE-Fiasko fand mir Google nur ganz wenige vergleichbare Faelle und kein Beispiel mit einer besseren Lösung als der, einen neuen Kernel zu installieren. Ich probierte es mit dem alten und weg war das Problem.
Auf dem Desktop von Arch Linux und dessen problemlosen Aktualisierungen verwöhnt begann ich schon, nach Alternativen zu schielen, aber das hätte nun gewiss nicht mehr in dies Wochenende gepasst. Und als Router und Gateway zum Wan ist der Rechner doch ziemlich unverzichtbar.
Also bleibe ich vorerst bei dem uralt-Kernel 2.6.32-5-amd64.

Squeeze mit aktuellerem Kernel

Monday, October 24. 2011

Anstoss der Unrast sind die heftigen Performance-Einbrüche meines Rechners während der regelmässigen incrementiellen Backups auf eine externe USB-Festplatte. Die ist wirklich nicht besonders schnell, hdparm -t ermittelt 30 MB in  3.09 seconds =   9.72 MB/sec. Mein HTC Desire ist da mit bis zu 14 MB/sec merklich schneller.

Das das Backup relativ langsam geschrieben wird ist aber an sich gar kein Problem. Wirklich nervend ist, dass die CPU sich dabei mit 80, 90% wait states eindeckt und kaum noch etwas anderes erledigen mag als, auf die lahme Platte zu warten. Auf der Suche nach möglichen Auswegen stiess ich auf Hinweise, dass Linux ab 2.6.37 mit solchen Situationen besser umgehen könne. Squeeze hat 2.6.32. Einen Versuch wär's wert.

Woher einen aktuelleren Kernel nehmen? Backports (hilfreich bei der Auswahl von Paketen), und eine schon brauchbare Anleitung für die konkreten Schritte fand sich auch bald, brauchte aber dann doch noch ein paar Änderungen und Ergänzungen.

- es schadet nicht, ein aktuelles Backup von /boot und /etc zu haben...
- nano /etc/apt/sources.list
- dort unten diesen Eintrag anfügen: 
  deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
- apt-get update
- und jetzt installieren:
   apt-get install -t squeeze-backports linux-image-2.6-amd64

Der install macht auch ein update der Grub-Konfiguration und fügt für den neuen Kernel oben auf der Liste zwei Einträge ein. Wenn nicht alles so geht, wie man gehofft hat, kann man im Grub-Menü nach unten wandern und den bisherigen Kernel booten, das ist die dritte Zeile im Menü.
Klappte soweit ganz gut, ein paar Sachen waren aber zu erledigen. So kam beim Install ein Hinweis auf fehlende (non-free) Firmware, die für diesen Rechner mit
apt-get install -t squeeze-backports firmware-realtek
kam. Weiter monierte der install schon:

dkms: running auto installation service for kernel 2.6.39-bpo.2-amd64:
      vboxhost (4.1.4)...failed.
      nvidia (195.36.31)...failed.

dkms: WARNING: linux headers are missing, which may explain the above failures.
      please install the linux-headers-2.6.39-bpo.2-amd64 package to fix this.

Wirklich landete ich nach dem ersten boot des neuen Kernels auf der Konsole, mangels Grafiktreiber. Google fand mir diese Anleitung, NVidia-Treiber auf dem backported Kernel zu nutzen. In der bash_history hat dieser Schritt solche Spur hinterlassen (das shell script nvidia_heilen.sh entspricht dem auf obiger seite gelistetem)

apt-get install -t squeeze-backports dkms nvidia-kernel-dkms
dpkg-reconfigure nvidia-kernel-dkms
grep -ie error /var/lib/dkms/nvidia/195.36.31/build/make.log
cd /usr/local/src
mkdir backportkernel
cd backportkernel/
nano nvidia_heilen.sh
chmod 755 nvidia_heilen.sh
./nvidia_heilen.sh
apt-get install -y nvidia-glx
apt-get install -y nvidia-glx-ia32
apt-get install -y nvidia-xconfig nvidia-settings
reboot

Nun lande ich wieder auf dem grafischen Desktop und nicht nur der nvidia-Treiber sondern auch der ebenfalls monierte vboxhost sind geheilt. Bleibt vmware. Hier die hilfreiche Webseite (leider ist sie jetzt, beim schreiben dieser Zeilen, nicht verfügbar). Infos und Beschreibung treffen, aber bei mir klappte es auch mit dem Patch nicht. Letztlich half der Link zu den gepatchten Sourcen. Der Vmware-Player (3) baute sich seine Module, die liefen aber erst nach einem reboot.

Fein, damit war das Update gelungen - hat es auch was gebracht? Sieht recht gut aus, top zeigt die wa während der rsync-Läufe zwischen 25 und 30%. Und gefühlt ist das Problem damit bereinigt.

Update:
Für die Aktion etwas zu spät stieß ich auf  smxi/sgfxi/svmi, eine Familie von Scripten, die sich ganz dem Kernel-Update und der Kompilierung von Grafik Modulen und Modulen für vmbox und vmware widmen und die Sache um einiges leichter machen...

Air Applikation und flashlog.txt

Friday, June 24. 2011

Unter XP war das alles gar kein Thema, die installierte Air Appl. schrieb ihre Traces in die Datei flashlog.txt und gut. Aber auf Linux? Denn natürlich trat der Fehler, den ich suchte, nur auf, wenn die Anwendung unter Linux lief...

Ich dachte zunächst, dass auch für AIR der installierte flashplayer entscheidend sei (und für Linux 64 baut Adobe keinen debug-flashplayer). Aber in einer vm mit Mint/32, debug-flashplayer, korrekter mm.cfg und allem blieb die Air trotzdem stumm.

Etwas Suchen musste ich schon bis ich hier den entscheidenden Hinweis fand: 
cd /opt/$applName/share/META-INF/AIR
touch debug

(Für $applName natürlich den Namen der jwlg. Applikation einsetzen...) Die Appl. neu starten und nun schreibt sie ihre traces brav nach ~/.macromedia/Flash_Player/Logs/flashlog.txt

An GoogleEarth habe ich so viele male rumgedoktert, und immer nur ein schwarzer Block da, wo die Erdkugel sein sollte. Für eine Weile hatte ich mich schon damit abgefunden, dafür eine dedizierte vm mit xp zu nehmen. Aber beim Schatzsuchen braucht man GE nun mal dauernd und als ich dann ein .deb für 64bit entdeckte, habe ich mich noch einmal darangemacht. Download, sudo dpkg -i google-earth-stable_current_amd64.deb und:?? Schwarzer Bildschirm.

Ok, also auf die Suche gemacht. Es finden sich viele Hinweise, dass lsb-core und lib32nss-mdns und ia32-libs-gtk installiert sein müssen. Sind es auch, trotzdem schwarz. Dann ein Hinweis auf sudo aptitude install nvidia-glx-ia32 - und heureka, endlich gehts.

Fein. Wäre es eigentlich zu viel verlangt, wenn Google's .deb solche Abhängigkeit prüft oder wenigstens einen Hinweis auf bekannte Problemquellen gibt? Die sind ja nun kein Fischgeschäft. Grummel.

(Page 1 of 1, totaling 4 entries)