Im Terminal ausgeführt zeigte sich folgendes:

/usr/bin/wine: Datei oder Verzeichnis nicht gefunden

Die Datei ist aber definitiv da. Ein bisschen Recherche später habe ich das Problem gefunden: Eine Bibliothek ist schadhaft. Bei mir reichte es, sie durch den Befehl

sudo aptitude reinstall libc6-i386

einfach neu zu installieren.

• das Notebook wurde vom Stromnetz getrennt
• das Notebook war im Akkubetrieb und erwachte aus dem Standby
• das Notebook war im Akkubetrieb und man schaltete das WLAN aus und wieder an

Sobald WLAN deaktiviert wurde, konnte man das Notebook problemlos vom Stromnetz trennen oder aus dem Standby aufwecken, ohne dass es einfror.

Dieses Verhalten war — gelinde gesagt — sehr nervig. Das Notebook war im Akkubetrieb also nicht wirklich WLAN-fähig. Ich konnte mich entscheiden zwischen Netzwerkkabel oder Stromkabel, aber ohne beides kam ich nicht aus.

Ich habe lange herumprobiert und herausgefunden, dass das Kernelmodul r8187se Schuld war (siehe auch hier). Allerdings habe ich es nie geschafft, das Problem mit diesem Kernelmodul ganz zu beheben.

Behoben habe ich das Problem jetzt mit einer neuen WLAN-Karte: Einer Intel Centrino Advanced N 6200. Das war nicht teuer, der Austausch ging dank dieser Anleitung problemlos vonstatten.

Damit sind die ärgerlichen WLAN-Probleme vorbei, denn das Kernelmodul für die Intel-Karten ist wesentlich stabiler.

Falls das Blinken der WLAN-LED bei Aktivität stört, kann dies mit einer Anleitung von ubuntuusers leicht ausschalten.

Leider ließ sich meine Kamera, eine DMx 41AU02.AS von “The Imaging Source” (TIS) nicht damit ansprechen. Trotz korrekter Installation aller Module (OpenCV, NumPy, SciPy) lieferte das Capture kein Bild zurück.

Lösen konnte ich das Problem mit einem weiteren Modul für Python: VideoCapture. Dieses Modul benötigt zusätzlich die Python Imaging Library (PIL). Hat man beides installiert, kann man folgendermaßen ein Bild auslesen und in eine Datei schreiben:
from VideoCapture import Device
cam = Device()
cam.saveSnapshot('image.jpg')
_{Quelle: http://videocapture.sourceforge.net/}

Um das Bild nicht direkt abzuspeichern, sondern für die interne Verarbeitung zu capturen, benötigt man folgenden Befehl:
pil_img = cam.getImage()

Möchte man zusätzlich das Bild mit OpenCV weiterverarbeiten (zum Beispiel in einem Fenster anzeigen), dann muss man es zunächst konvertieren:

import cv
import PIL

cv_img = cv.CreateImageHeader(pil_img.size, cv.IPL_DEPTH_8U, 3) # RGB image
cv.SetData(cv_img, pil_img.tostring(), pil_img.size[0]*3
_{Quelle: http://stackoverflow.com/questions/1650568/how-do-i-create-an-opencv-image-from-a-pil-image}

Zum Schluss habe ich noch ein komplettes Beispielprogramm, welches immer wieder ein Bild von der Kamera ausliest und in einem Fenster anzeigt, beenden kann man es mit “Esc”.
from VideoCapture import Device
import cv
import PIL

cam = Device()

cv.namedWindow("camera", 1)

#cam.displayCapturePinProperties() # Zum Einrichten der Kamera

while True:
    pil_img = cam.getImage()
    cv_img = cv.CreateImageHeader(pil_img.size, cv.IPL_DEPTH_8U, 3)
    cv.SetData(cv_img, pil_img.tostring(), pil_img.size[0]*3)
    cv.ShowImage("camera", cv_img)

    if cv.WaitKey(10) == 27:    # Achtung: ganz ohne WaitKey
        break                   # funktioniert namedWindow nicht!
cv.DestroyWindow("camera")

_{Der Vollständigkeit halber — folgende Programmversionen benutze ich dafür: Python 2.7, OpenCV 2.2, PIL 1.1.7, VideoCapture 0.9-4, NumPy 1.6.1, SciPy 0.9.0}

It’s not a bug — it’s a feature!

gehandelt wird: Die fehlende PostScript-Unterstützung des HP DesignJet 510ps. Denn obwohl es im Druckernamen drinsteht (“ps“) kann der Drucker PostScript nicht verarbeiten! Um das herauszufinden, musste ich eine halbe Stunde lang mit dem Support sprechen, denn: Überall auf der Homepage und in den Datenblättern stand bis vor kurzem, dass der Drucker “Adobe PostScript 3″ beherrscht. Bei fast allen Händlern steht das auch noch so. Allerdings kann es nicht der Drucker, sondern die Software.

Man muss also, um PostScript mit dem Drucker verarbeiten zu können, eine (veraltete) Software installieren (“efi Designer Edition”), die dann wiederum einen PostScript-Drucker emuliert und die Daten an die normale HP-GL/2-Schnittstelle schickt.

Aus diesem Grund, und vor allem auch weil der Support erbärmlich ist, kann ich also nur von dem Kauf eines HP DesignJet 510ps abraten. Im Allgemeinen gilt es bei HP wohl, sehr genau darauf zu achten, ob ein Feature im Gerät oder in der Software steckt. Außerdem macht es keinen Spaß, mit Leuten vom “Support” zu telefonieren, die immer wieder sagen: “Dafür bin ich nicht zuständig…”.

Ein geplanter Scan wird bei ausgeschaltetem PC nie nachgeholt, auch wenn das Häkchen nicht gesetzt ist. Somit ist auch die Voreinstellung (Sonntags um 2:00 Uhr nachts) relativ sinnfrei. Anscheinend hat man vergessen, ein Häkchen einzubauen, mit dem man den Scan auch dann nachholen lassen kann, wenn der Computer zum geplanten Zeitpunkt ausgeschaltet war.

Beheben lässt sich das in der Registry. Unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan finden sich die Werte DisableCatchupQuickScan und DisableCatchupFullScan. Setzt man diese auf 0, wird der Scan nachgeholt. Allerdings sollte man (vor allem bei “FullScan”) darauf achten, dass man die Prozessorlast während des Scans auf einen niedrigen Wert einstellt, da man sonst recht lange nach dem Einschalten warten muss, bis man arbeiten kann.

Hier nochmal das ganze zum direkten Import; einfach in eine Text-Datei einfügen, als MSE_Scan_nachholen.reg abspeichern und mit Rechtsklick + “Zusammenführen” in die Registry imporieren.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan]
"DisableCatchupQuickScan"=dword:00000000
"DisableCatchupFullScan"=dword:00000000

Weg bekommt man die schwarzen Ecken, indem man den gtk-Style ein bisschen anpasst. Das geht für den einzelnen Benutzer in der Datei .gtkrc-2.0-kde4 oder systemweit in der Datei /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc. Nach dem Öffnen mit dem Lieblingseditor fügt man ganz am Ende folgenden Abschnitt ein:


style "default-style"
{
GtkWindow::resize-grip-height = 0
GtkWindow::resize-grip-width = 0
}
class "GtkWidget" style "default-style"


Dadurch werden die “Grips” auf null gesetzt, wodurch die schwarzen Ecken verschwinden.

VERZ.-NR. VOLL

Das ist nicht weiter schlimm, aber nervig. Immerhin gibt es Abhilfe: Man kann die Kamera mit folgenden Schritten dazu bringen, bei einer bestimmten Verzeichnis- und Bildnummer weiterzuzählen.

Wir nehmen an, wir wollen die Kamera auf den Zustand mit Verzeichnisnummer 123 und Bildnummer 4567 bringen. Wer andere Zahlen braucht, möge sie entsprechend ändern.

1. Zunächst muss man eine formatierbare CF-Karte in die Kamera einlegen. (Achtung: Alle Photos sichern, die Karte wird gelöscht!)
2. Die Karte im Menü der Kamera formatieren.
3. Im Kameramenü die Dateinummerierung auf “Auto reset” stellen.
4. Ein Foto machen.
5. Die Kamera ausschalten, die CF-Karte in einen Kartenleser einlegen und an den PC anschließen.
6. Den Ordnernamen in “123CANON” und den Dateinamen des Bildes in “IMG_4566” umbenennen. (Alternativ die Zahl noch kleiner wählen, wenn man ein paar Testbilder machen möchte.)
7. Die CF-Karte auswerfen und wieder in die Kamera einsetzen.
8. Im Kameramenü die Dateinummerierung wieder auf “Reihenauf.” stellen.
9. Das nächste Bild ist das Bild mit der gewünschten Nummer 4567, bzw. 1 mehr als die Zahl aus Schritt 6. Jetzt kann man so viele Testbilder machen, bis man 1 unter der gewünschten Nummer ist.
10. Die Testbilder löschen. (Wenn keine grandiose Aufnahme dabei ist :) )

Ich nehme an, dass diese Anleitung auch mit anderen Kameras funktioniert; habe das aber nicht getestet.

edgar@discovery: ~/[...]/bin $ ./java
bash: ./java: Datei oder Verzeichnis nicht gefunden

Das Betriebssystem will mir also mitteilen, dass die Datei nicht existiert. Allerdings ist sie vorhanden und die Rechte stimmen auch, wie ls -la offenbart:

edgar@discovery: ~/[...]/bin $ ls -la
[...]
-rwxr-xr-x 1 edgar edgar 47308 2011-02-19 15:54 java
[...]

Nun gut, aber was soll das ganze?

Leider ist die Meldung “Datei oder Verzeichnis nicht gefunden” — zumindest in meinem Fall — völlig falsch. Es fehlt eine Bibliothek, weil hier ein 32-Bit-Programm auf einem 64-Bit-System ausgeführt werden soll. Allerdings erzählt einem das keiner. Eine Installation des Paketes ia32-libs hat bei mir das Problem behoben.

Der Vollständigkeit halber: Bei dem Notebook handelt es sich um ein Belinea o.book 1304 mit einer Realtek R8187SE WLAN-Karte, welche das Problem verursachte.

Nachdem pm_trace nichts brauchbares lieferte, sah ich mir die Logdateien erneut an. In /var/log/syslog fand ich einen Hinweis auf den Netzwerk-Manager:


Jan 17 20:22:53 discovery NetworkManager[961]: wake requested (sleeping: yes enabled: yes)
Jan 17 20:22:53 discovery NetworkManager[961]: waking up and re-enabling...
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): now managed
Jan 17 20:22:53 discovery kernel: [26104.861236] r8169 0000:02:00.0: eth0: link down
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): bringing up device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): preparing device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): deactivating device (reason: 2).
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): now managed
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): bringing up device.
Jan 17 20:22:53 discovery kernel: [26104.861678] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 17 20:22:53 discovery kernel: [26104.862500] r8180: Bringing up iface
Jan 17 20:22:53 discovery kernel: [26104.881316] Skipping EDID probe due to cached edid
Jan 17 20:22:54 discovery kernel: [26105.062340] r8180: Card successfully reset
Jan 17 20:22:54 discovery kernel: [26105.811381] r8180: WIRELESS_MODE_G
Jan 17 20:22:54 discovery kernel: [26105.811383]
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): preparing device.
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): deactivating device (reason: 2).
Jan 17 20:22:54 discovery kernel: [26105.828079] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): supplicant interface state: starting -> ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): device state change: 2 -> 3 (reason 42)


Dies war der letzte Eintrag vor dem Einfrieren (und damit vor dem Reboot).

Testweise habe ich den Netzwerk-Manager vor dem Energiesparmodus über /etc/init.d/network-manager stop angehalten und siehe da: Der Computer erwachte aus dem Standby. Nach dem Starten des Netzwerk-Manager fror er prompt wieder ein.

Die üblichen Verdächtigen bei Fehler dieser Art sind fehlerhafte Treiber. Deshalb habe ich das Kernelmodul meiner WLAN-Karte (r8187se) entsprechend einer Anleitung von Ubuntuusers in die Datei /etc/pm/config.d/unload_module folgendermaßen eingefügt:

SUSPEND_MODULES="$SUSPEND_MODULES r8187se"

Nachdem diese Datei mit sudo chmod +x /etc/pm/config.d/unload_module ausführbar gemacht wurde, funktioniert der Standbymodus wie gewohnt auch bei meinem Notebook.

Natürlich können auch andere Treiber ein Problem dieser Art hervorrufen. Ein Mögliches Vorgehen ist, sich mit sudo lsmod alle Kernelmodule anzeigen zu lassen und diese durch Eintragen in unload_module der Reihe nach darauf hin zu testen, ob sie das Problem verursachen.

OpenOffice stürzt einfach ab, sobald der Dateiauswahldialog geöffnet wird (also beim Öffnen, Speichern unter, PDF-Export). Das Problem lässt sich problemlos reproduzieren. Nach einem Neustart des Computers ist es (manchmal) weg. Allerdings ist dieses Problem insgesamt sehr nervig, weil man nicht mehr vernünftig arbeiten kann.

Wenn ich OpenOffice in der Kommandozeile starte, dann erhalte ich folgende Fehlerausgabe:

QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/edgar/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
X-Error: BadAtom (invalid Atom parameter)
Major opcode: 17 (X_GetAtomName)
Resource ID: 0x13121313
Serial No: 15681 (15681)
These errors are reported asynchronously,
set environment variable SAL_SYNCHRONIZE to 1 to help debugging

Weder der Hinweis zu iBus noch SAL_SYNCHRONIZE brachten mich bei diesem Fehler weiter. Falls jemand einen Grund oder eine Lösung findet, bitte hier posten.

Ich habe lediglich ein Workaround gefunden: Wenn der Fehler auftritt kann man bei “Extras” > “Optionen” unter “OpenOffice.org” > “Allgemein” > “Öffnen/Speichern Dialoge” das Häkchen vor “OpenOffice.org-Dialoge verwenden” setzen.