Hier für: Ubuntu 7.10 auf einem bootbaren USB-Stick, nach der Anleitung unter www.pendrivelinux.com/2007/09/28/usb-ubuntu-710-gutsy-gibbon-install/ .

1. Man füllt zuerst verbleibenden Platz auf den Dateisystemen mit Nullen um später bessere Kompressionsraten zu erreichen. Dazu prüft man für jede Partition, wieviel Platz »df« als freien Platz (in 1K-Blöcken) ausweist und setzt diese Zahl in den folgenden Befehl ein:
   1. sudo dd bs=1024 count=134112 if=/dev/zero of=/media/ubuntu710/fillfile.raw; sudo rm fillfile.raw;
   2. sudo dd bs=1024 count=134112 if=/dev/zero of=/media/caper-rw/fillfile.raw; sudo rm fillfile.raw;
2. Man archiviert das ganze Image. Befehl mit on-the-fly-Komprimierung:
   1. sudo dd if=/dev/sdb | bzip2 -c > /home/matthias/Desktop/Ubuntu_7.10.2GB_USB_Stick.img.bz2
3. Mit »kill -USR1 « kann man den Fortschritt des Lesevorgangs beobachten und mit ls natürlich die aktuelle Größe der komprimierten Datei.
4. Verwenden der Sicherung: man kann das Image nachher auf den USB-Stick zurückspielen wenn er mindestens die Größe des originalen USB-Sticks hat. Der Befehl inkl. Entkomprimierung on-the-fly:
   1. sudo bunzip2 /home/matthias/Desktop/Ubuntu_7.10.2GB_USB_Stick.img.bz2 | dd of=/dev/sdb

Das ist z.B. sinnvoll bei Computern die kein optisches Laufwerk besitzen oder deren optisches Laufwerk
(zumindest die Boot-Funktion) defekt ist. Dazu wird hier angenommen dass man zur Erstellung des bootbaren USB-Sticks nicht von einer Live-CD booten kann, während in der existierenden Anleitung (
www.pendrivelinux.com/2007/09/28/usb-ubuntu-710-gutsy-gibbon-install/ ) das Booten von der Live-CD benötigt wird.

Prinzipiell ist es jedoch auch möglich, die Dateien der Ubuntu-Live-CD korrekt auf dem USB-Stick zu speichern ohne dazu von der Ubuntu-Live-CD zu booten. Das wird nämlich unter Windows ausgeführt wie beschrieben in www.pendrivelinux.com/2007/09/21/usb-ubuntu-704-persistent-install/ . Dort werden mit fixu.bat im Wesentlichen folgende Anweisungen ausgeführt (hier als Linux-Äquivalente):

-- entpacken des Ubuntu-ISO-Images in einen Ordner ./ubuntu/
  -- cp syslinux.cfg ./ubuntu/
  -- cp initrd.gz ./ubuntu/
  -- cp isolinux.txt ./ubuntu/
  -- cp ./ubuntu/isolinux/*.* ./ubuntu/
  -- cp ./ubuntu/casper/vmlinuz ./ubuntu/
  -- cp ./ubuntu/install/mt86plus ./ubuntu/
  -- rm -R ./ubuntu/isolinux/

syslinux.cfg und isolinux.txt sind im »Patch« für Ubuntu 7.10 enthalten
( pendrivelinux.com/downloads/U710fix.zip ). Die anderen Schritte (inkl. Kopieren von initrd.gz) sind vermutlich bei Ubuntu 7.10 im Gegensatz zu Ubuntu 7.04 nicht mehr notwendig.

Schritt für Schritt:

• Man lade herunter: Ubuntu 7.10 (Gutsy Gibbon) PC (Intel x86) desktop CD von releases.ubuntu.com/7.10/ubuntu-7.10-desktop-i386.iso . Dies ist wichtig, denn die weiteren Schritte funktionieren (ohne Änderung) weder mit Kubuntu noch mit einer »Alternate install CD«. Dann treten Fehler auf wie “No space left on device” beim Kopieren der Dateien von der CD, oder es können nicht alle Dateien kopiert werden weil z.B. der »Kubuntu 7.10 (Gutsy Gibbon) PC (Intel x86) alternate install CD« folgende Dateien fehlen: casper, disctree, ubuntu.ico, casper/vmlinuz, casper/initrd.gz. Bei Bedarf weiter zu untersuchen: Wie kann man nun eine »Kubuntu 7.10 (Gutsy Gibbon) PC (Intel x86) alternate install CD« so auf einem USB-Stick speichern dass man das System davon installieren kann?
• Man folge der Anleitung www.pendrivelinux.com/2007/09/28/usb-ubuntu-710-gutsy-gibbon-install/ , jedoch ohne von der Live-CD gebootet zu haben. Dabei sollte man die Größe der ersten Partition etwas größer wählen (etwa eingeben: +850M, beachte dass fdisk keine Eingabe wie +1G akzeptiert). Die Anleitung kann trotzdem ausgeführt werden, und das Ergebnis funktioniert (im vorliegenden Fall: nach dem für Probleme empfohlenen »lilo -M /dev/sda«).

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«.

Symptom: »gammu –identify« meldet »Keine Rückmeldung. Telefon möglicherweise nicht angeschlossen?«. Das tritt auf unabhängig davon ob irda0 in der Ausgabe von ifconfig erscheint.

In der Ausgabe von »dpkg-reconfigure irda-utils« wird erwähnt: »Wenn FIR benutzt werden soll, müssen auch die entsprechenden Treibermodule gebaut werden. Die hier angebotenen Module können sich von den im laufenden Kernel verfügbaren Modulen unterscheiden. In diesem Fall müssen /etc/modutils/irda-utils (2.4) oder /etc/modprobe.d/irda-utils (2.6) von Hand bearbeitet werden.«

In /etc/modprobe.d/irda-utils steht nach der (korrekten, ehemals funktionierenden) Konfiguration des Pakets irda-utils:

irda0 erscheint nur in der Ausgabe von ifconfig wenn die irda-utils (genauer: der Service irattach) laufen, also wenn »/etc/init.d/irda-utils restart« ausgeführt wurde. irattach verbraucht dabei nach dem Starten die gesamte Rechenzeit, was jedoch interessanterweise durch ein »gammu –identify« behoben wird, selbst wenn überhaupt kein Mobiltelefon über IrDA angeschlossen ist. Lässt man die Optionen »io=0×2f8 irq=3 dma=3« aus so ist die »Störung« nur kurz und behebt sich selbst.

Möglicher Fehler: »/etc/init.d/irda-setup start« führt zur Fehlermeldung
»/etc/init.d/irda-setup: line 76: echo: write error: Device or resource busy
/etc/init.d/irda-setup: line 77: echo: write error: Device or resource busy«
Das betrifft jedoch nur ein (eventuell nicht erforderliches) Schreiben auf das BIOS-Device o.ä..

Führt man irdadump aus während »/etc/init.d/irda-utils restart« so erkennt man dass die IrDA-Schnittstelle tatsächlich Pakete sendet. Die Ausgabe enthält etwas wie:

oder

Die Konfiguration funktioniert wenn man ausführt:

Siehe die Beispiele in »man irattach«.
Das erzeugt ein Netzwerk-Gerät irda0, sichtbar in der Ausgabe von ifconfig.

Es funktioniert auch wenn man »irattach irda0 -s« oder »irattach irda0« ausführt und /etc/modprobe.d/irda-utils den korrekten Inhalt hat. Das ist also die korrekte Art den Daemon irattach zu starten. Nichts anderes müsste also in
/etc/init.d/irda-utils geschehen. Dort wird ausgeführt:

Das ist korrekt und funktioniert nun auch (warum aber nicht auch vorher?). Auch »/etc/init.d/irda-setup start« funktioniert. Ein Symptom des Fehlers scheint zu sein wenn »/etc/init.d/irda-utils restart« alle Rechenzeit aufbraucht - das trat nun nämlich nicht mehr auf und auch nicht beim manuellen Ausführen von irattach.

Eventuell hat ein »irattach /dev/ttyS0« (zum Betreiben der IR-Schnittstelle im SIR-Modus) das Problem behoben. Wohl dadurch entstand dauerhaft ein irda1-Netzwerkgerät.

Das Problem liegt nicht an Suspend-to-RAM denn irda0 funktioniert danach weiter wenn es davor funktionierte.

(Die Verdopplung der Option -f scheint etwas wie ein undokumentiertes Feature zu sein; -f allein reicht nämlich nicht aus.)

Der Fehler liegt tatsächlich an Suspend mit ACPI, denn USB funktioniert nach einem Neustart stets einwandfrei. Um solche Probleme zu beheben wird vorgeschlagen in www.thinkwiki.org/wiki/How_to_configure_acpid : vor Suspend-to-RAM führe man aus »rmmod uhci_hcd«, danach »modprobe uhci_hcd«. »rmmod uhci_hcd« wirkt zwar tatsächlich so dass z.B. eine USB-Maus nicht mehr funktioniert, dieses Verfahren beugt aber nicht dem Fehler stromloser USB-Anschlüsse nach Resume vor und kann diesen Fehler auch nicht beheben nachdem er einmal aufgetreten ist.

Der Fehler könnte evtl. behoben werden indem man Hotplugging neu startet. »/etc/init.d/hotplug restart« ist in Ubuntu Feisty jedoch nicht mehr der Weg dazu. Das liegt an der Umstellung von hotplug auf udev. Aber ein »/etc/init.d/udev restart« bringt keine USB-Geräte zum Funktionieren obwohl es jetzt der Weg ist, Hotplugging neu zu starten, auch für USB ( ubuntuforums.org/showthread.php?t=404801&highlight=USB ). Es liegt also nicht an fehlerhafter Erkennung sondern wohl einfach daran dass den USB-Ports der Strom fehlt während alles andere normal ist.

usbmodules, lsusb, lspci -vvnn, dmesg helfen nicht (alle Meldungen scheinen normal, USB-Hubs werden erkannt trotz dass USB-Ports ohne Strom sind). lsusb listet nur die Hubs, nicht aber die Geräte wie es der Fall sein sollte. Links zu Bugs die keine Duplikate dieses Bugs sind:
bugs.launchpad.net/ubuntu/+bug/99267
bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-savage/+bug/37328

Lösung derzeit: APM verwenden, d.h. die Kerneloptionen »noacpi acpi=off apm=on«. Damit kann USB auch nach einem Suspend-to-RAM/Resume-Zyklus verwendet werden. Notwendig sind aber: »rmmod uhci_hcd; modprobe uhci_hcd« nach Resume, sonst reagiert die Maus nicht sehr zögerlich; Auswerfen einer PCMCIA-Netzwerkkarte vor Suspend-to-RAM, sonst geht das System nur in einen Standby-Zustand; Korrektur des Sounds.

Das Problem besteht bei Kernel 2.6.22 nicht mehr.

Interessanterweise funktionieren ACPI-Funktionen nur wenn X vollständig gestartet ist (nur KDM ohne Login oder ein Terminal helfen nicht).

Fehler: das Notebook geht normal in Suspend, wacht aber nach einer Sekunde von selbst auf und verbleibt in einem unansprechbaren Zustand (Standy-LED blinkt, Bildschirm schwarz; Koma?). Der hier beschriebene Fehler liegt nicht an einer veralteten BIOS-Version (denn er tritt auch mit BIOS 1.20 und Embedded Controller 1.06a auf).

Der Fehler liegt nicht daran dass eine eingesteckte WLAN-Karte per ifup konfiguriert ist.

Der Fehler liegt auch nicht an Problemen mit USB-Modulen: USB funktioniert nach jedem Neustart problemlos, und ein Suspend/Resume-Zyklus von diesem Zustand aus funktioniert ohne den beschriebenen Absturz (USB ist danach ohne weiteres noch nicht verwendbar, aber das ist ein anderes Problem).

Der Fehler tritt entweder beim ersten Suspend/Resume-Zyklus nach einem Neustart auf (was einen weiteren Neustart nötig macht) oder über beliebig viele Resume-Zyklen überhaupt nicht.

Weitere Hilfen:
www.google.de/search?hl=en&q=site%3Alinux-thinkpad.org+T23+acpi+suspend&btnG=Google+Search

Am besten durch Downgrade auf eines der Pakete das Teil eines Ubuntu-Releases war. Solche Pakete kann man herunterladen von packages.ubuntu.com/ . Etwas wie Debian’s Snapshot-Server ( snapshot.debian.net/ ) scheint es in Ubuntu nicht zu geben.

You run an older program and get a message like this:

This means the binary “jad” needs a library which is not installed. Using Google you find out is that the package “libstdc++2.10-glibc2.2.deb” used to contain the file but sadly it’s not available any more in 8.04.

The solution is to download the old Ubuntu 7.10 / Gutsy Gibbon package and to install it on 8.04. The package is available at: packages.ubuntu.com/gutsy/i386/libstdc++2.10-glibc2.2/download . After installing the command above is working well again.

Der Chip der Karte ist: »Intel 82540EP«, benötigt den Treiber: »e1000«
( www.thinkwiki.org/wiki/Ethernet_Controllers ). Man führt aus:

Nun sollte in der Ausgabe eth0 erscheinen.