Archiv-Seite 2

HP DesignJet 510ps – wo ist das PostScript?

14. September 2011 von edgar

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…“.

Microsoft Security Essentials holt geplanten Scan nicht nach

18. Juli 2011 von edgar

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

Schwarze Dreiecke in KDE

13. Juli 2011 von edgar

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.

Fehler „VERZ.-NR. VOLL“ bei EOS 400D

29. Juni 2011 von edgar

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.

  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.

Datei oder Verzeichnis nicht gefunden

13. Juni 2011 von edgar

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.

Notebook wacht bei Akkubetrieb nicht aus dem Standby-Modus (Suspend) auf

17. Januar 2011 von edgar

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.

Absturz von OpenOffice beim Dateiauswahldialog

19. Dezember 2010 von edgar

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.

luksOpen tut nichts bei (falsch) zusammengebautem RAID

6. Dezember 2010 von edgar

Hier kommt mal wieder ein sehr nerviges Problem. Mein Szenario ist folgendes:

Man hat ein RAID 1 (Festplattenspiegelung), darin liegt eine mit LUKS verschlüsselte Partition. Dabei ist mindestens eine der RAID-Partitionen die einzige Partition der Festplatte. Nachdem man zunächst das RAID von Hand angelegt und dann alles getestet hat, trägt man die Daten für das RAID (welche man über mdadm --detail --scan bekommt) in die Datei /etc/mdadm/mdadm.conf ein. Nach dem nächsten Reboot läuft auch alles (scheinbar) ganz normal. Allerdings passiert nichts, wenn man mit

sudo cryptsetup luksOpen /dev/md0 [label]

sein verschlüsseltest Laufwerk aktivieren möchte. Es kommt nicht einmal eine Meldung. Hier hilft der Parameter -v:

edgar@atlantis: ~ $ sudo cryptsetup -v luksOpen /dev/md0 backup
Command failed with code 22: /dev/md0 is not a LUKS device.

Natürlich ist hier weder das Cryptolaufwerk noch LUKS kaputt, sondern das RAID. Vermutlich würde auch alles andere (z.B. mount) einen Fehler melden. Was genau kaputt ist liefert ein Blick in /proc/mdstat:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[0] sdc[1]
488351744 blocks [2/2] [UU]
unused devices: none

Seht ihr den Unterschied? Ein Eintrag lautet „sdb1“, der andere nur „sdc“. mdadm hat aus versehen die gesamte Festplatte (/dev/sdc) als RAID-Device interpretiert und nicht die Partition (/dev/sdc1). Das ist sehr ärgerlich und lässt sich laut ubuntuusers dadurch vermeiden, dass man die Partition mindestens 128 KB kleiner macht als die Plattengröße.

Sicherer ist aber eine Definition in der /etc/mdadm/mdadm.conf. Der vordefinierte Eintrag „DEVICE partitions“ allein hilft allerdings nicht. Man sollte die Partitionen entweder komplett für jedes RAID in der Form „DEVICE /dev/[partition1] /dev/[partition2]“ angeben, oder aber einen Wildcard-Eintrag der Form „DEVICE /dev/hd*[0-9] /dev/sd*[0-9]“ benutzen.

Achtung: Bei einem RAID sollte man immer zuerst prüfen, ob es korrekt zusammengebaut ist! Sobald man irgendwelche Tools wie z.B. fsck auf ein falsch gebautes RAID loslässt, gehen die Daten mit hoher Wahrscheinlichkeit verloren!

rdiff-backup bei vorhandenen Daten initialisieren

30. November 2010 von edgar

Angenommen man möchte von einer anderen Backup-Variante (z.B. rsnapshot, rsync, unison, cp, … ) auf rdiff-backup umsteigen. Dann hat man zumeist ein Datenverzeichnis, in dem eine Kopie der Originaldaten liegt. Jetzt wäre es schön, wenn man dieses „reine“ Datenverzeichnis mit rdiff-backup in ein rdiff-backup-Ziel umwandeln könnte, ohne alle Dateien neu übertragen zu müssen*. Leider beschwert sich rdiff-backup aber, wenn man das vorhat:

Fatal Error: Destination directory
/mnt/backup/home
exists, but does not look like a rdiff-backup directory. Running
rdiff-backup like this could mess up what is currently in it. If you
want to update or overwrite it, run rdiff-backup with the --force
option.

Laut den alten Listenarchiven kann man die Option –force hier problemlos benutzen, um ein Verzeichnis mit rdiff-backup zu initialisieren. Die Daten werden dabei nicht komplett neu übertragen, sondern nur die Änderungen. Allerdings wird das Backup trotzdem recht lange dauern, weil rdiff-backup zuerst seine Datenbank erstellt und die Metadaten aller Dateien auslesen bzw. anlegen muss.

*: Ein ähnliches Szenario wäre es, wenn man das Backup über das Internet machen möchte. Dabei will man vermutlich zuerst den Datenbestand auf einer externen Festplatte übertragen (Initialbackup), damit man nicht alles über das Internet verschicken muss.

Backup mit rsnapshot auf einen SSH-Server ausführen (push)

30. November 2010 von edgar

Bevor man lange Zeit mit Suchen vergeudet: es geht nicht. Zumindest nicht mit einfachen Mitteln. rsnapshot kann mit einem SSH-Server nur als Quelle umgehen, nicht als Ziel. Wenn man aber die Daten eines Desktoprechners per SSH auf einen Backupserver sichern möchte, kommt man mit rsnapshot nicht weit. Auch ein Weg über SSHFS (ein Verzeichnis auf einem SSH-Server lokal mounten) ist keine Lösung – es unterstützt nämlich die für rsnapshot essentiellen Hardlinks nicht.

Die einzige Möglichkeit die ich mir vorstellen kann, ist ein SSH-Tunnel: man baut mit
edgar@desktop: ~$ ssh -R 22222:localhost:22 backupserver
eine Verbindung zum Backupserver auf. Dabei wird auf backupserver der Port 22222 über den SSH-Tunnel auf Port 22 des lokalen Rechners (desktop) zurückgeschickt. Wenn man also mit
edgar@backupserver: ~$ ssh localhost -p 22222
eine SSH-Verbindung aufbaut, landet man auf dem Desktop-Rechner. Somit kann man auch rsnapshot auf dem Backupserver so konfigurieren, dass man als Quelle den localhost mit SSH über Port 22222 angibt. Da die Verbindung über den SSH-Tunnel an den Desktop-Rechner zurückgeschickt wird, ist dieser die Quelle für das Backup… Wer das mal getestet hat, möge mir einen Kommentar hinterlassen. :)

Da mir das ganze aber zu konfus war und rdiff-backup sowieso wesentlich speicherplatzeffizienter arbeitet als rsnapshot, steige ich nun auf rdiff-backup um. Da es bei der Umstellung aber auch Probleme geben kann, gibt es gleich einen weiteren Artikel.

Update: Es gibt eine nette Alternative zu rsnapshot. Im Wiki von Ubuntuusers gibt es ein Skript, welches sich ähnlich verhält wie rsnapshot, aber auch auf SSH-Server pushen kann. Man findet es hier: Backup_mit_RSYNC.



css.php