Entries tagged as linux
Tinnef a la Microsoft: winmail.dat
Friday, December 2. 2011
Man bekommt diese Attachments von Leuten, die ihre Mail mit outlook versenden, oben zwei Zeilen Text, dass alles wichtige in dem attachten 'Word.doc steht und dann kein lesbares attachment sondern eine Datei winmail.dat, mit der ausser dem Sender selbst niemand etwas anfangen kann.
Das Format ist ein Microsoft-Standard (Oxymoron?) mit dem treffend gewaehlten Namen tnef. So, zu meiner Freude kam ich jetzt mal darauf, dass debian eine Antwort darauf in den repositories hat:
apt-get install tnef
tnef -f winmail.dat -C Zielverzeichnis --unix-paths --verbose
klärt das Problem erstmal...
Alternativ kann man auch einen Webdienst dazu bemuehen, etwa bei tud.at, und sich die Dateien da auspacken lassen.
Dann gibt es für Thunderbird/Icedove das Addon LookOut, welches die Inhalte der winmail.dat wie zusätzliche attachments auflistet.
Den lieben Absender, der Outlook benutzt, sollte man bitten, seine Emails künftig nur noch im reinen Text Format zu versenden. Wie das geht, kann man bei Microsoft nachlesen.
device-mapper und Google Chrome
Wednesday, October 26. 2011
Ein seltsamer Effekt ist neuerdings aufgefallen, beim Einbinden der dm-crypt - devices liest sich das so:
cryptsetup luksOpen /dev/sdc silva
Geben Sie den Passsatz für /dev/sdc ein:
semid 131072: semop failed for cookie 0xd4df6e3: incorrect semaphore state
Failed to set a proper state for notification semaphore identified by cookie value 223213283 (0xd4df6e3) to initialize waiting for incoming notifications.
Grub anpassen, spacefun loswerden
Monday, October 24. 2011
Hier läuft Grub 2, Paket grub-pc, und anlässlich einer recht boot-freudigen Phase von Installationen nervten ein paar Eigenheiten des Boot genug, um mich zur Änderung zu treiben. Ärgernisse:
- mit usb-Tastatur ist das Boot-Menü des Grub nicht bedienbar
- nach dem grafischen Boot-Menü fällt Grub für die folgenden Meldungen in einen Textmodus zurück (gewünscht), und verwendet zur Ausgabe eine absurd grosse Schrift, so dass die Ausgaben mehrfach umgebrochen über den Schirm huschend kaum lesbar sind
- eigentlich mag ich die vorgegebene Grafik nicht und möchte das komplette spacefun theme des Debian Squeeze gerne verbannen.
Punkt eins ist wohl ein Timing-Problem, probehalber im Bios den schnellen Boot disabled und seither geht's.
Die Formatierung der Bootmeldungen und eine eigene Hintergrundgrafik kann man in /etc/default/grub und /etc/grub.d/00_header beeinflussen.
/etc/default/grub:
GRUB_GFXMODE=1280x1024x24
GRUB_BACKGROUND="/pfad/zu/beliebigem/Verzeichnis/und/Bild.png"
Der Eintrag in GRUB_GFXMODE muss natuerlich zu den Fähigkeiten der Grafik passen, eine Liste möglicher Modi gibt's nach:
apt-get install hwinfo
hwinfo --framebuffer
In /etc/grub.d/00_header ergänzt man (bei mir auf Zeile #127) nach
set gfxmode=${GRUB_GFXMODE} die Zeile
set gfxpayload=keep
Anschliessend update-grub. Es ist übrigens ratsam, zuvor ein Backup der Einträge in /etc/grub.d zu machen, denn wenn man versehentlich einen Fehler in die editierte Datei bringt (keine Ahnung, was da passiert war) dann moniert grub-mkconfig den Fehler in wenig hilfreicher Art. (fehlerhafte Dateien werden wie nicht vorhanden behandelt und man kratzt sich am Kopf, weshalb eine offenbar anwesende Datei NOT FOUND sei.)
Dann gibt es noch /usr/share/desktop-base/grub_background.sh
Wenn man den Ort des grub ändern will (zB grub in eine Partition installiert hatte, ihn jetzt aber lieber im MBR hätte) dann hilft (als root) grub-setup /dev/sdX (X mit eigener Konfig. ersetzen).
Wenn man space-fun auch vom Login-Screen verbannen will, hilft /etc/default/kdm.d/10_desktop-base
Für den Login kann man da ein eigenes Bild einsetzen, aber danach folgt eine Ladeanimation (ksplash) und der den spacefun abzugewöhnen war nicht ganz leicht.
Eine Suche auf "debian kde spacefun" liefert in vielen Varianten einen Thread "KDE4 , Squeeze: Space fun background keeps appearing under kde login splash" mit vielen Ansätzen, was man versuchen könnte. Aber keiner wirkte. Weder liess sich ein anderer Splash einstellen, ein neuer installieren oder sonst irgendwas bewegen, die erste irgendwie wirksame Massnahme war, testweise in /usr/share/kde4/apps/ksplash/Themes spacefun in spacefun-weg umzunennen: nun bekam ich statt des Splash ein weisses Rechteck auf Schwarz. Und so richtig elegant ist solche Wurschtelei ja auch nicht gerade...
Endlich fand ich die nirgends erwähnte entscheidende Referenz auf den spacefun in
~/.kde/share/config/startupconfig (das wirkte mit KDE 4.4)
Dort ein anderes Theme setzen, dass in /usr/share/kde4/apps/ksplash/Themes vorhanden ist, und dann geht's doch.
In KDE 4.6 war es dann wieder anders, hier liess sich alles aus den System Settings einstellen, wenn man sich System settings als Root eingerichtet hat. Das geht fix mit dem KDE MEnue editor, man kopiert den Eintrag der System settings, gibt ihm einen etwas anderen Namen und stellt unter Advanced / Run with a different user root ein. Das theme fuer den LoginScreen steht unter /usr/share/kde4/apps/kdm/themes, kann man sich leicht selbst erstellen aus der Kopie eines schon vorhandenen.
Update:
als ich später die Textfarbe auf dem Boot-Menü ändern wollte, habe ich einen Eintrag in /etc/grub.d/05_debian_theme vorgenommen, ab ca Zeile 95 steht da jetzt:
if [ -n "${2}" ]; then echo " set color_normal=${2}" fi if [ -n "${3}" ]; then echo " set color_highlight=${3}" fi if [ -z "${2}" ] && [ -z "${3}" ]; then
# auskommentiert und stattdessen konkrete Farben gesetzt # echo " true" echo " set color_normal=blue/black" echo " set color_highlight=cyan/black"Farbnamen und mehr Infos findet man zB hier.
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)
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...
Ram und Leistung
Friday, October 21. 2011
Manche Hardware kann mehr, als in der Beschreibung steht. Beispiel: mein Mainboard MSI P41-C31. Im Manual steht eindeutig, dass das Board max. 4GB DDR3 Ram unterstützt. Was mir, mit reichlichem Einsatz von vmware und virtualBox (und der Gewohnheit, viele viele Tabs in Google Chrome und Opera nebeneinander offen zu halten) unter Linux deutlich eng wurde. Ich habe aus Anwendersicht klar den Eindruck, dass Windows (2k - 7) mit knappem Ram und virtuellem Speicher besser umzugehen weiss als Linux, aber das nur nebenbei.
Als ich mal wieder unbedacht eine vm öffnend Viertelstundenlang meinem Kistchen beim Swappen zuschauen durfte, kam der Entschluss: anderes Board und mehr ram rein. Das Ram konnte ich direkt mitnehmen, das ausgesuchte Board steht immer noch aus. Einfach mal zur Probe die 2x4GB TEAM Elite CL9 PC3-10600 KIT eingesteckt, und zu meiner Verwunderung bootete die Kiste ohne einen Mucks. OK, dass hätte ich ruhig schon etwas früher versuchen können.
Aber natürlich kommt noch ein "Aber". Denn bald fiel auf, dass die Kiste doch ziemlich laut wurde, der Prozessor-Lüfter ging auf volle Drehzahl. Deckel auf und die Wärme der beiden Riegel leuchtete mir förmlich entgegen, für sie werde ich wohl einen Gehäuselüfter installieren müssen. Der Sellingpoint "Aluminiumschienen zur besseren Wärmeabfuhr" des Team Elite-Ram stand da in anderem Licht als zuvor.
Für mich eine Neuigkeit, ich hatte die Leistungsaufnahme des Ram bislang immer als vernachlässigenbare Größe eingeschätzt, (wie etwa auch der Energierechner es tut). Netzseitige Messergebnisse an einem Voltcraft Energy Check 3000 sehen 1-2 Watt Mehrverbrauch mit 8 statt 4GB Ram. Nicht viel, trotzdem werden die Dinger heiß.
Das war der Anlass, die zuvor nicht recht konfigurierten Temperatur-Sensoren einzurichten, lm-sensors war schon installiert aber der zweite Schritt war unterblieben. Dabei half mir "Monitoring your hardware's temperature" weiter. KDE 4 brauchte anschliessend noch einen Neustart des Desktop bis es die Werte anzeigen mochte, die xsensors oder, von der Kommandozeile, sensors schon gleich verriet.
Ein Bios-Update, Streifzug durch die Bios-Settings und Lüfterbastelei später läuft alles kühl und ruhig.
