Schon länger hatte ich dieses Problem, aber erst heute Zeit, mich damit zu beschäftigen: Wine (was man z.B. für Teamviewer braucht) ließ sich nicht starten. Dabei habe ich es auf meinem relativ neu installierten ubuntu 11.10 (oneiric) schon neu installiert, entfernt, wieder installiert und so weiter. Allerdings ließ es sich trotzdem nicht starten.
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.
Heute möchte ich von einem Problem berichten, welches mich schon lange geplagt hat: Mein Notebook (ein Belinea o.book 1304, aus der 1301er-Serie) fror unter Ubuntu immer dann ein, wenn WLAN aktiv war und einer der folgenden Punkte zutraf
- 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.
Vermutlich funktionieren viele USB-Webcams unter Windows ganz einfach auch in Python mit Hilfe von OpenCV, wie zum Beispiel in diesem Artikel beschrieben.
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
Heute kommen wir zu einem Problem, das herstellerseitig wohl wirklich unter dem Motto
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…”.
Viele Menschen fragen sich, warum Microsoft Security Essentials (MSE) einen automatischen bzw. geplanten Scan nicht nachholt, wenn der Computer ausgeschaltet war. Es gibt zwar bei den Einstellungen ein Häkchen “Geplanten Scan nur starten, wenn der Computer eingeschaltet, aber nicht verwendet wird.”, allerdings scheint sich das nur darauf zu beziehen, dass der Scan nicht startet, wenn der Computer gerade benutzt wird.
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
Nach der Installation von Ubuntu 11.04 (Narry Narwhal) hatten viele Programme (OpenOffice bzw. LibreOffice, Firefox, Thunderbird, …) ein hässliches schwarzes Dreieck an der rechten unteren Fensterecke. Das musste unbedingt weg, schließlich kann man sein hübsches KDE nicht so verhunzt lassen. Nach einigen Nachforschungen fand ich heraus, dass es sich dabei um den “Griff” für die Größenänderung handelt, den es bei gtk-Programmen unter KDE verhaut.
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.
Mein heutiges Sorgenkind: eine Canon EOS 400D. Nachdem sie bei der Reparatur war, hatte sie eine sehr hohe Verzeichnisnummer (über 900) und neulich erreichte sie 999. Die Kamera fängt dann nicht wieder von unten an (wie sie das nach Überschreiten des 9999. Bildes tut), sondern meckert bei jedem Einschalten.
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.
- Zunächst muss man eine formatierbare CF-Karte in die Kamera einlegen. (Achtung: Alle Photos sichern, die Karte wird gelöscht!)
- Die Karte im Menü der Kamera formatieren.
- Im Kameramenü die Dateinummerierung auf “Auto reset” stellen.
- Ein Foto machen.
- Die Kamera ausschalten, die CF-Karte in einen Kartenleser einlegen und an den PC anschließen.
- 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.)
- Die CF-Karte auswerfen und wieder in die Kamera einsetzen.
- Im Kameramenü die Dateinummerierung wieder auf “Reihenauf.” stellen.
- 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.
- 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.
Nun, manchmal hat es den Anschein, als möchte das Betriebssystem den Benutzer gezielt ärgern. So auch bei diesem Problem:
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.
Heute habe ich ein sehr seltsames Problem bei meinem Notebook behoben: Im Akkubetrieb erwachte es nicht aus dem Standby-Modus, und zwar weder aus S3 (Suspend to Disk, STD) noch aus S4 (Suspend to RAM, STR). Naja, eigentlich wachte das Notebook schon auf, ist aber jedesmal kurz danach eingefroren (freeze). Im Netzbetrieb zeigten sich jedoch keinerlei Probleme.
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.
Dieser Fehler trat bei mir immer mal wieder auf, und zwar völlig unregelmäßig. Die meiste Zeit ging alles ganz normal, aber an manchen Tagen tauchte folgendes Problem auf:
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.