Normalerweise sollte funktionieren: ThinkVantage Rescue and Recovery (Version 4.1 verweigerte jedoch auf einem ThinkPad T40 die Installation weil es das Betriebssystem für Windows Vista hielt). Oder: »IBM Rapid Restore Ultra« aus »Access IBM«. Leider nicht möglich weil zum Erstellen der Sicherungspartition ein Diskettenlaufwerk benötigt wird und es auch bei Neuinstallation nicht möglich ist die Option auszuwählen die eine Sicherung nur auf einem USB-Laufwerk bewirkt.

Ein dritter Weg wird hier beschritten: als komprimiertes Image auf DVD. Vorgehen:

1. Damit das komprimierte Image möglichst klein ist sollte man die freien Bereiche zuerst mit logisch Null überschreiben. Dazu bietet sich SDelete von www.microsoft.com/technet/sysinternals/FileAndDisk/SDelete.mspx an, allerdings ergibt »sdelete -c -p 1 c«: »Cannot clean free space for UNC drive.«. Dieselbe Aufgabe erledigt jedoch »Eraser 5.84« (wwww.heidi.ie/eraser/download.php) wenn man ein entsprechendes Null-Muster zum Überschreiben freien Platzes konfiguriert.
2. Das Image erstellt man mit dd indem man die Festplatte in einem USB-Gehäuse oder einem UltraBay-Adapter in einem anderen ThinkPad ausliest. Oder indem man eine Linux Live-CD startet und das komprimierte Image auf einem USB-Laufwerk oder einem Ultrabay-Adapter ablegt. Der Befehl mit Ultrabay-Adapter und on-the-fly-Komprimierung:
   1. sudo dd if=/dev/hdc | gzip -c > /home/matthias/Desktop/hda.img.gz

   Der Befehl schaffte auf einem ThinkPad T40 mit 1,3GHz-Prozessor einen Durchsatz zwischen 3 MByte/s (Plattenanfang und aufwändig zu komprimierende Daten) und wohl um 10 MByte/s (Plattenende, nur Nullen zu komprimieren da ein Bereich ohne Dateien). Durchschnittlich lag der Durchsatz bei 6,5 MByte/s, so dass eine Festplatte mit 30GB in 76 Minuten kopiert wurde. gzip wurde statt bzip nur verwendet weil auf der Kubuntu 7.04 Live-CD kein bzip enthalten ist. bzip und bzcat haben jedoch dieselben Aufrufkonventionen wie gzip und zcat. Mit »kill -USR1« kann man den Fortschritt des Lesevorgangs beobachten und mit ls natürlich die aktuelle Größe der komprimierten Datei. Es sollte sogar möglich sein, das Festplatten-Image auf mehrere Dateien und damit auf mehrere DVDs aufzuteilen indem man die skip-Option von dd verwendet.

3. Verwenden der Sicherung: man kann das Image nachher auf Festplatten aufspielen die mindestens die Größe der originalen Platte haben. Das Aufspielen ist möglich indem man von einer DVD bootet die eine (möglichst kleine) Linux Live-CD enthält der das Image als weitere Datei hinzugefügt wurde. Der Befehl inkl. Entkomprimierung on-the-fly:
   1. sudo zcat /home/matthias/Desktop/hda.img.gz | dd of=/dev/hdc (als Pendant zum obigen Befehl) sudo dd if=/dev/hdc | zcat | dd of=/dev/hda

   (im realen Einsatz, wobei angenommen wird dass die DVD ohne Dateisystem gebrannt wurde)

Man kann die WAV-Dateien korrekt abspielen mit dem Befehl »play«; dieser Befehl erkennt die Dateien als:

Anscheinend akzeptiert lame keine ADPCM kodierten WAV-Dateien (egal ob MS ADPCM oder IMA ADPCM) als Eingabe, ebenso scheitert der Import in audacity, auch über »Rohdaten importieren«. Deshalb konvertiere man zuerst in normale PCM-kodierte WAV-Dateien (diese haben etwa fünffache Größe …) und dann in MP3 (hier in sinnvoller Qualität für Sprachaufzeichnungen):

Das Ergebnis sind MP3-Dateien die etwa die halbe Größe der von der Kamera produzierten WAV-Dateien haben.
Noch kleiner wird das Ergebnis mit dem folgenden Befehl, der für Sprachaufzeichnungen immer noch gute Ergebnisse liefert:

Alternativ auch mit durchschnittlicher Bitrate:

Das ist z.B. notwendig wenn man eine bereits konfigurierte ISDN-Anlage ohne Neukonfiguration betreiben will und die alten ISDN-Telefonnummern auf den Anbieter sipgate.de (Tarif sipgate plus) umgezogen hat. Eingehende Telefonate kommen dann per VoIP-Account an, und zu diesen Accounts gehören eigentlich nicht die umgezogenen ISDN-Nummern sondern weitere drei Telefonnummern die mit dem Tarif sipgate plus bereitgestellt wurden.

Lösung: es funktioniert, eine Art »Rufnummernübersetzung« einzustellen dort wo in der FritzBox die Anmeldedaten für die drei Internetrufnummern hinterlegt sind … dort trägt man dann unter »Internet-Telefonnummer« statt der Telefonnummer die eigentlich zum jeweiligen VoIP-Account gehört eine der alten ISDN-Nummern ein. Die FritzBox verwendet diese dann als MSNs bei der Weiterleitung der ankommenden Gespräche über die eingebaute ISDN-Telefonanlage. Dass diese Einstellung möglich ist liegt an der Entkopplung von VoIP-Account und Telefonnummer: VoIP funktioniert per se ohne Telefonnummer, auch z.B. direkt mit IP-Adressen. Deshalb kann die FritzBox jeden VoIP-Account mit jeder beliebigen Telefonnummer verbinden, wodurch mittelbar die MSNs für die interne ISDN-Vermittlung gesetzt werden.

Dieser Scanner benötigt vor jeder Benutzung einen Firmware-Upload. Die entsprechende Firmware ist im Windows-Treiber enthalten und kann daraus extrahiert werden (Datei kopieren nach Installation unter Windows oder das CAPI-Archiv entpacken). Orte wo man solche Firmware herunterladen kann sind in ubuntuforums.org/archive/index.php/t-26911.html aufgelistet. Zur Konfiguration muss man dann noch in
/etc/sane.d/snapscan.conf eintragen wo die Firmware zu finden ist, z.B. »firmware /usr/local/lib/sane/Snape20.bin«.

Dann verwende man »sane-find-scanner« um den Scanner erkennen zu lassen, die Meldung sollte etwas sein wie: »found USB scanner (vendor=0×06bd [AGFA], product=0×2091 [ SNAPSCAN e20 ]) at libusb:001:006«. In manchen Fällen mit ein und demselben Scanner kam:
»found USB scanner (vendor=0×06bd [AGFA ], product=0×2091 [SNAPSCAN]) at libusb:001:008«

Dass SANE diesen Scanner unterstützt zeigt sich daran dass er in der Liste der für scanimage verfügbaren Geräte auftaucht: »scanimage -L« liefert »device `snapscan:libusb:001:006′ is a AGFA SNAPSCAN e20 flatbed scanner«.

SANEs gerätespezifische Optionen findet man dann mit: »scanimage –help -d snapscan:libusb:001:006«.

Nun besteht jedoch noch ein Problem beim Selbsttest von SANE: »scanimage -T« liefert:
»scanimage: open of device snapscan:libusb:001:006 failed: Error during device I/O«.

Fehlersuche:

• Das Problem liegt nicht an der falschen Firmware.
• Das Problem liegt nicht daran dass die Firmware oder /etc/sane/snapscan.conf aufgrund ungenügender Zugriffsrechte nicht erreichbare wäre. Denn es tritt auch unter dem Benutzer root auf.
• Jedoch tritt das Problem nicht immer auf: üblicherweise funktioniert es wenn man den Scanner aus- und wieder einschaltete und direkt als ersten Befehl »scanimage -T« (oder einen Befehl zum Scannen) ausführte.
• Das Auftreten des Problems hing nicht von der zum Scannen gewählten Auflösung ab.
• Folgendes Verhalten war reproduzierbar: Scanner aus- und sofort wieder einschalten, die Scanner-Deviceadresse ermitteln mit »sane-find-scanner« (ohne Wartezeit möglich) und damit einen Befehl zum Scannen starten (hier: getestet mit scanimage). Nach der Aufwärmphase wird dann ein erfolgreicher Scan durchgeführt, jedoch bleibt der Schlitten nach dem Scan auf halbem Rückweg stehen. Weitere Befehle funktionieren bis zum nächsten Neustart des Scanners nicht mehr oder nicht mehr zuverlässig, tw. wird nicht einmal mehr das Device erkannt.

Damit ist das Problem dasselbe wie in bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/94226 beschrieben … es liegt, wie dort argumentiert, wahrscheinlich am Kernel bug 8231 ( bugzilla.kernel.org/show_bug.cgi?id=8231 ). Weitere Diskussion gibt es auf ubuntuforums.org/archive/index.php/t-26911.html bzw. ubuntuforums.org/showthread.php?t=26911 (derselbe thread). Dort wird berichtet dass ein möglicher Workaround manchmal sei, das Modul ppdev oder ehci-hcd zu entladen. Ersteres half nicht, letzteres Modul gab es nicht; und wenn man uhci-hcd entlädt so geht kein Scanner mehr; und nach erneutem Einfügen des Moduls besteht der Fehler weiterhin.

Mögliche Lösung: Kernel 2.6.20 rekompilieren ohne die Option USB_SUSPEND. Details: »This bug has been around since Feisty was released. It has to do with the experimental feature “USB selective suspend/resume and wakeup (EXPERIMENTAL) (USB_SUSPEND)” that is enabled in the Feisty kernel. If you recompile the kernel with this option disabled then you will be able to scan normally again. Even better, if you compile the 2.6.21 vanilla kernel with this enabled things will work as they should. There was a bug in the 2.6.20 kernel that has been fixed.« (nach ubuntuforums.org/archive/index.php/t-26911.html ).

Weitere mögliche Lösung: Kernel von Gutsy unter Feisty installieren. Oder alternativ: Gutsy Beta installieren. Beides siehe ubuntuforums.org/showthread.php?t=424397&page=4 .

Die einfachste Lösung ist aber folgendes Workaround: der USB-Port wird nicht sofort nach dem Ende des Scanvorgangs auf »SUSPEND« gesetzt denn der Scanner-Schlitten hat ja noch Zeit einen Teil des Rückwegs zurückzulegen. In dieser Zeit ist der scanimage-Befehl beendet, d.h. die Hardware steht wieder für weitere Befehle zur Verfügung. Wenn diese neuen Befehle den USB-Port so lange »wach halten« bis der Scanner-Schlitten in seine Ausgangsposition zurückgekehrt ist dann kann nach einer beliebig langen Zwischenzeit erfolgreich ein weiterer Scan durchgeführt werden. Das könnte z.B. ein weiterer scanimage-Befehl sein der den Scan-Schlitten bewegen muss (z.B. ein Vorschauscan) - dieser hält den USB-Port also bis zur Rückkehr des Schlittens wach und darüber hinaus, allerdings wird das Problem noch nicht gelöst: wie kehrt der Schlitten _danach_ zurück? Eine mögliche Lösung ist aber tatsächlich, alle benötigten Scans direkt als Befehle hintereinander zu schreiben und die Vorlage zu wechseln während der Schlitten zurückfährt. Leider ist die Option »–batch-prompt« von scanimage hier keine Lösung: vor dem ersten Scan und zwischen den Scans wird der Scanner hier auf SUSPEND gesetzt. Auch mit lsusb und sane-find-scanner kann man einen USB-Port »wach halten«: man wiederholt diese Aufrufe bis der Schlitten zurückgekehrt ist, mit »sleep 0.3« zwischen den Aufrufen. Allerdings tritt dann (zumindest im Fall von lsusb) dasselbe Problem auf - vielleicht tritt es also auf wenn der USB-Port des Scanners überhaupt in SUSPEND gesetzt wird, egal ob der Scanner dabei noch arbeitet oder nicht mehr? Dann wäre ein kleines Script eine Lösung das so lange »lsusb; sleep 0.3« ausführt bis der Benutzer Return drückt um den nächsten Scan zu machen. Dieser Gedankengang stimmt tatsächlich: nach einem Neustart des Scanners führe man eine Endlosschleife von »sleep 0.3; lsusb;« aus und kann dann mit dem Scanner ganz normal arbeiten, inkl. Vorschauscans und Scans mit xsane usw.. Der Befehl für die Endlosschleife: »while [ true ]; do sleep 0.3; lsusb; done«. Oder auch, um zu sehen dass / wann dieser Befehl arbeitet: »a=0; while [ true ]; do sleep 0.3; lsusb; ((a++)); echo iteration $a; done«. Oder auch, noch besser: »watch –interval=0,3 lsusb«.

Die restlichen Pixel (ab einer bestimmten horizontalen Linie) erscheinen entweder weiß (bei Scannen mit GIMP) oder als Wiederholung der letzte korrekt gescannten Zeile (bei Scannen direkt in xsane). Das Problem verschwindet mehr und mehr und schließlich ganz, wenn man denselben Ausschnitt in immer geringeren Auflösungen scannt oder wenn man den Ausschnitt verkleinert. So z.B. lässst sich z.B. eine vollständige Seite A4 problemlos in 150dpi scannen. Scans werden deutlich beschleunigt, wenn man die Option »Hohe Qualität« in den Standard-Optionen ausschaltet, das Problem verschwindet dadurch jedoch nicht. Das Problem hat auch nichts mit den Optionen »Qualitäts-Weißabgleich« oder »Verwende benutzerdefinierte Gammatabelle« zu tun. An der kritischen Stelle ist während des Scanvorgangs selbst kein geändertes Verhalten des Scannerschlittens zu beobachten, es scheint also ein Softwareproblem zu sein. Die kritische Stelle ist reproduzierbar, wenn Auflösung und Ausschnitt unverändert bleiben. Das Problem tritt nur beim Scannen in Farbe auf, nicht beim Scannen in Graustufen. Das Problem wird nicht behoben, wenn man de Option »Farbzeilen pro Lesevorgang« auf »Auto« oder »1« oder »16« stellt (Standardwert war 4). Das Problem trat auf mit xsane 0.97-4 und wird durch ein Update auf xsane 0.98b-1 nicht behoben (stattdessen werden dabei Fehler engeführt, die xsane erst einmal unbenutzbar machen).

Lösung: Das Problem liegt an xsane (nicht an SANE oder der Scanner-Hardware), denn es tritt bei Verwendung von QuiteInsane nicht auf. Also verwende man QuiteInsane, bis dieser xsane-Bug behoben ist.

Man lege die Schablone zum Scannen von Dias ein. Darauf lege man drei Dias so, dass sie im Scan von unten oder rechts richtig abgelesen werden können. Die auf der Schablone liegende Seite muss dabei natürlich die seitenrichtige Seite des Dias sein (meist die graue Seite des Diarahmens).

Man lege die Dias im Hochformat auf die Schablone. Man kann sie auch im Querformat auflegen, muss dann nur den unten gezeigten Scanbefehl anpassen. Hochformat macht jedoch die Wahrscheinlichkeit geringer, farbige Streifen durch defekte Elemente der CCD-Einheit im Bild zu haben (diese sieht man sonst deutlich, weil mit maximaler Auflösung gescannt wird). Wenn die CCD-Einheit dekete Elemente hat, kann man die Streifen evtl. durch Verwendung von Hochformat umgehen, ansonsten indem man die Schablone zum Scannen der Dias so anpasst, dass die Dias in einem Bereich gescannt werden, in dem die CCD-Einheit keine defekten Elemente hat.

Man schiebe die Schablone zum Scannen von Dias in die Ecke des Scannerglases, die der linken oberen Ecke beim Einscannen einer ganzen Seite entspricht. Auch schiebe man die Dias innerhalb der Schablone in die dorthin orientierte Ecke. So sind die Dias stets genau gleich positioniert, d.h. die im unten gezeigten Befehl zum Scannen von Dias gezeigten Maßangaben stimmen dann.

Man achte darauf, dass sich auf den Dias und dem Scannerglas kein Staub oder Dreck befindet. Bei einer Auflösung von 1200dpi sieht man das sonst deutlich.

Man lege ein neues Verzeichnis an, das die gescannten Bilder (eines Diamagazins) aufnehmen soll.

Befehl zum Scannen von drei aufgelegten Dias in Dateien, so dass der Dateiname eine sequentielle Nummer im Namen enthält, die so beginnt dass sie sich an die letzte Datei mit so aufgebautem Dateinamen im aktuellen Verzeichnis anschließt. Dieser Befehl scannt die drei Dias unter dem Scannerglas mit 1200 dpi in etwa 2min 45s ein.

Man wählt vor der Rufnummer *2# um die Verbindung über die Rufnummer und Verbindungsart aufzubauen die dem zweiten Eintrag der inder Fritz!Box für dieses Telefoniegerät konfigurierten Rufnummern entspricht. Statt Telefoniegerät steht in der Konfigurationsoberfläche mancher Fritz!Boxen auch »Nebenstelle«.

Die übliche Rückmeldung ist bloß: »Sending SMS 1/1….waiting for network answer..OK, message reference=[...]«. Das Problem trat nur bei SMS an manche Rufnummern auf, im vorliegenden Fall bei einer Nummer mit (deutscher) Vorwahl
0170. In diesen Fällen war die dort ankommende SMS entweder leer oder unlesbar. SMS an die eigene Rufnummer funktionierten problemlos.

Man benötigt dazu: eine Fritz! Box mit einem daran angeschlossenen Computer auf dem ein SSH-Server läuft; SSH-Zugangsdaten zu diesem Computer; DynDNS für diesen Computer mit Freischaltung des SSH-Ports; ein weiterer entfernter Computer mit Internetzugang auf dem ein SSH-Client läuft. Dann führe man aus auf dem entfernten Computer: