Category Archives: Uncategorized

svnsync und relocate

Ich spiegel bei mir zu Haus ein paar Subversion-Repositories von Software, die mir sehr wichtig ist oder wo ich persönlich schon mal in den Quellcode geschaut oder auch mal einen Patch eingereicht habe. Das ganze geschieht mit svnsync und einem kleinen Shell-Skript, das per Cronjob alle acht Stunden läuft. In den letzten Tagen bekam ich Fehlermeldungen, dass ein Quell-Repository nicht mehr auffindbar war. Eine kurze Recherche ergab, dass der anonyme Zugriff per https eingestellt wurde und nur noch Zugriff per http möglich ist, was de facto einer anderen URL gleich kommt, quasi einem Umzug des Repos. Bei einer normalen Working Copy von Subversion hat man kein Problem, da macht man in einem solchen Fall

svn switch --relocate https://svn.quelle.foo/svn/trunk 
    http://svn.quelle.bar/svn/trunk

und fertig. Bei svnsync gestaltet sich das etwas schwieriger. Die URL des Quellrepos wird dort in den Properties der Revision 0 des Zielrepos gespeichert, so dass man bei der Synchronisation nur noch die Ziel-URL angibt. Ein “Relocate” muss dann durch eine Änderung des entsprechenden Properties geschehen, in meinem Fall sah das dann so (ähnlich) aus:

svn ps svn:sync-from-url --revprop -r 0 
    'http://svn.licq.org/svn' https://foo.local/svn/licq-mirror 
    --username syncuser --password syncpass

Man überschreibt also einfach die bisherige Quell-URL mit der neuen, das ist alles, danach einfach wie gewohnt

svnsync sync https://foo.local/svn/licq-mirror 
    --username syncuser --password syncpass

aufrufen und alles funktioniert wie vorher auch, nur eben mit neuer Quell-URL.

Probleme beim Upgrade von Debian Sid

Nachdem Tux ja schon in XOrg vs. Eclipse über Probleme beim normalen Ugrade von Debian Sid berichtet hat, könnte dies zu einer kleinen Artikelserie werden. Heute in diesem Kino: libdjvulibre21. Bei Debian gibt’s schon einen Bugreport und die Lösung hab ich in einem Wiki gefunden:

dpkg --purge libdjvulibre15

purge mit aptitude reichte nicht aus. Danach braucht’s nur noch das einfache aptitude safe-upgrade und alles ist wieder in Butter.

Grub auf mehreren Festplatten

Leute spielen mit Eisenbahnen, sammeln Briefmarken oder züchten Rosen. Ich probiere neue Betriebssysteme aus und pflege verschiedene Installationen für den einen oder anderen Zweck. In einem Testrechner sind hier drei Festplatten verbaut, alles alte Dinger, aber genug Platz für mehrere Betriebssysteme.

In diesem speziellen Fall sind auf der ersten Platte (80 GB) Windows 98 und XP installiert sowie ein Ubuntu und ein Eisfair-1. Auf der zweiten Platte (40 GB) residiert ganz allein ein Debian Etch als Host für Xen und last but not least ist auf der dritten Platte (4 GB) noch Platz für eine Beta-Version von Eisfair-2. Wäre nur die erste Platte eingebaut, hätte ich kein Problem. Ubuntu benutzt Grub und Grub erkennt bei der Installation andere Systeme. Ubuntu selbst und das Eisfair-1 von der ersten Platte starten ohne Probleme, Ubuntu hat die Hand auf dem Bootloader und aktualisiert bei Kernel-Updates seine eigenen Einträge. Die beiden Windosen lassen sich über chainloader ebenfalls problemlos booten.

Interessant wird es mit Betriebssystemen auf den anderen beiden Platten. Die bringen für gewöhnlich ihren eigenen Bootloader mit und verwalten die entsprechenden Einträge bei Kernel-Updates oder ähnlichem auch selbst. Der neue Eisfair-Installer schreibt sich in den MBR der Platte, wo das System landet, in dem Fall die dritte Platte hdc. Debian lässt einem da mehr Freiheit, aber in Frage kommen im Prinzip nur der MBR von der zweiten Platte (hdb) oder direkt die Bootpartition /dev/hdb1. Will ich die Systeme booten, kann ich natürlich die Namen, Orte und Optionen der Kernel von Hand bei jedem Update in die Grub-Konfiguration des Ubuntu auf hda eintragen, aber das ist mir ehrlich gesagt zu umständlich.

Die nächste Möglichkeit ist der bereits erwähnte chainloader. Ja, aber… der funktioniert nur, wenn z.B. Debian seinen Bootloader an den Anfang einer Partition und nicht in den MBR schreibt. Ich habe es nicht hinbekommen, mit dem chainloader sozusagen den MBR einer anderen Platte zu starten. Klar, ich könnte jedesmal ins BIOS und die Bootplatte umstellen, aber das ist mir dann auch zu umständlich.

Heute habe ich eine weitere Möglichkeit herausgefunden. Es ist aus dem Grub-Menü heraus möglich, eine andere Grub-Config zu laden. Anstatt eines langen Eintrags mit kernel usw. reicht dann folgendes:

title       hdb: Debian
configfile  (hd1,0)/grub/menu.lst

Trage ich das bei den zusätzlichen Systemen in die /boot/grub/menu.lst meines Ubuntu ein, kann ich ganz locker die menu.lst laden, die unter der Fuchtel des Debian auf der zweiten Platte steht. Umgekehrt geht’s natürlich auch, so dass ich munter hin und her springen kann, auch zu dem Grub vom Eisfair-2 oder zurück zum Debian-Bootmenü und von da wieder zum Bootmenü vom Ubuntu und wenn ich dann vom Umherspringen in meinen Grub-Menüs genug habe, boote ich einfach das System, das ich will.

Subversion Relocate mit Eclipse und TortoiseSVN

Wir sind vor einigen Tagen mit unserem Projekt IMPULS von Sourceforge auf unseren eigenen, diesen Webserver umgezogen. Das heißt, wir haben nicht nur die Homepage migriert und ein Trac eingerichtet, sondern auch das Subversion-Repo verschoben. Für ausgecheckte Working Copies ist dann ein sogenannte Relocate fällig. In Verbindung mit Eclipse kann man da auf die Nase fallen.

Subversion mit Eclipse ist eigentlich erstmal kein Problem. Es gibt Subclipse und da funktionieren Checkout, Update, Commit usw. wunderbar. Rechtsklick auf auf’s Projekt, »Team« angeklickt und los geht’s – leider ohne Relocate. Wenn ich das jetzt einfach außerhalb von Eclipse machen würde, zerschieße ich mein Projekt, weil in den Projekteinstellungen der Pfad auf’s Repository vermerkt ist. Es gibt aber eine Lösung. Zunächst vergewissern wir uns, welche URL grad für das Projekt angegeben ist:

Subversion Pfad in Projekteinstellungen

Hier ist also noch der alte Pfad des Repos bei Sourceforge eingetragen. Der nächste Schritt in der Punkt »Disconnect« im bereits erwähnten Menü »Team«. Draufklicken und dann kommt folgender Dialog. Dort bestätigt man mit der Option, die Subversion-Dateien zu behalten.

Disconnect im Menü »Team« von Eclipse

Dann kommt das eigentliche Relocate. Das geschieht unter Windows am einfachsten mit TortoiseSVN, wie im folgenden Bild zu sehen ist. Natürlich kann man hier auch die Kommandozeilenversion von Subversion benutzen, wenn man grad kein TortoiseSVN zur Hand hat. Wie das geht, steht im Subversion-Buch.

Relocate mit TortoiseSVN

Der letzte Schritt besteht darin, dem Projekt in Eclipse wieder beizubringen, dass es eigentlich ein mit Subversion verwaltetes ist. Dazu wieder ein Rechtsklick auf das Projekt und im Menü »Team« den Punkt »Share« und dann natürlich »SVN«. Subclipse erkennt, dass es sich bereits um eine korrekte Working Copy handelt und übernimmt den richtigen Pfad aus Schritt drei. Nur noch einmal den folgenden Dialog abnicken und fertig ist die Laube.

Subversion Working Copy Eclipse wieder bekannt machen

Ausgabeprofil »LaTeX => HTML« für TeXnicCenter

Angenommen ich möchte ein LaTeX-Dokument mit tex4ht in HTML umwandeln und benutze TeXnicCenter als Editor für das eigentliche Dokument. Da liegt es nahe, sich ein passendes Ausgabeprofil zu basteln, so dass man direkt aus TeXnicCenter die gewünschte Ausgabe produzieren kann. Man muss dabei aber aufpassen, was für Optionen man htlatex.exe mitgibt. Die folgenden zwei Screenshots illustrieren funktionierende Einstellungen.

Ideal wäre natürlich, wenn nicht jedesmal ein neuer Tab im Firefox aufgemacht werden würde, wenn man im TeXnicCenter F5 drückt, sondern der alte aktualisiert/ersetzt würde. Wenn da jemand einen Tipp hätte, wie man das realisieren kann, würde ich mich freuen.

Nicht das gesamte System verschlüsseln

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:

modprobe aes
modprobe dm-crypt
modprobe dm-mod
aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3
cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…

mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind

aes
dm-crypt
dm-mod
sha256

Danach nochmal die initrd neu bauen lassen mit

update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:

data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…

Alte Grenzen neu entdeckt

ASUS TUSL2-C – lange habe ich von dem Board geträumt, irgendwann hab ich es mir geleistet und es sehr lange und zu meiner vollsten Zufriedenheit mit einem Celeron 1400 mit Tualatin-Kern betrieben. Jetzt hat es bei mir seine Schuldigkeit getan und es wird Weihnachten die Rechenpower bei meinen Eltern verdreifachen. (Dort werkelt immernoch ein Pentium-III 500 MHz mit Katmai-Kern.) Da sich im Laufe der Zeit einige Riegel SD-RAM angesammelt haben, dachte ich, ich gönne dem Board so 768 MB oder sogar ein Gigabyte, damit die Herrschaften auch vernünftig arbeiten können. Meine Tests mit Memtest86+ waren aber frustrierend. Egal welche Kombination von Riegeln ich ausprobierte, keiner wollte mit dem 512er Kingston (Infineon-Chips) zusammen laufen. Die Aura des TUSL2-C war angekratzt, aber ich hatte mich schon mit den 512 abgefunden.

Gestern dann habe ich noch eine Erweiterungskarte für Firewire 1394a und USB 2.0 bekommen, die die Anbindung schneller externer Speichermedien ermöglichen soll und dazu noch eine schicke Frontblende mit den entsprechenden Schnittstellen, beides von Reichelt, seit Jahren mein Lieblingsversandhaus. Die Beschreibungen der beiden Teile sind ausführlich genug, dass man sie mit ein bisschen Bastelei zur Zusammenarbeit überreden können wird. Außerdem sind in der Frontblende noch Anschlüsse für Kopfhörer und Mikro. Diese müssten mit dem Onboard-Sound verdrahtet werden. Zu diesem Zweck schaute ich nochmal ins Handbuch und konnte nicht widerstehen, auch nochmal das RAM-Problem zu verfolgen. Das Ergebnis:

PC100/PC133 Memory Support: Equipped with three Dual Inline Memory Module (DIMM) sockets to support PC100/PC133-compliant SDRAMs (available in 64, 128, 256, 512MB densities) up to 512MB.

Man beachte den letzten Teil! Verwundertes Augenreiben hilft nicht. Dieses Board mit Chipsatz Intel 815ep limitiert den maximal möglichen RAM auf ein lumpiges halbes Gigabyte. Das erklärt natürlich, warum Memtest regelmäßig Fehler meldete, wenn ich mehr als 512MB installiert hatte – enttäuschend ist das trotzdem, zumal ältere Boards da schon weiter waren. In meinem Heimserver werkelt seit Jahren ein ASUS CUBX-L mit dem sagenumwobenen Intel BX440 und was soll ich sagen? Lassen wir das Handbuch sprechen:

PC100 Memory Support: Equipped with four DIMM sockets to support Intel PC100-compliant SDRAMs (8, 16, 32, 64, 128, or 256MB) up to 1GB. These new SDRAMs are necessary to meet the critical enhanced 100MHz bus speed requirement.

Fazit: Trotz aller Erfahrung: bei alter Hardware doch mal ins Handbuch schauen – wer lesen kann…

Die Auferstehung des Zaurus: Anforderungen

Nach dem ersten Beitrag zu diesem Thema geht es nun um die Anforderungen, die ich an ein mobiles PIM-Gerät stelle. Natürlich beziehe ich mich an dieser Stelle wieder speziell auf meinen Zaurus, jedoch denke ich, dass auch für andere Geräte interessante Anregungen dabei sind.

Ich gehe dabei von drei Aspekten aus:

  • Benutzerfreundlichkeit (im Neusprech auch als Usability bekannt)
  • Sicherheit
  • Aktualität der Daten

Benutzerfreundlichkeit bedeutet dabei, dass sich die Software unterwegs gut bedienen lassen muss, also auf eine vorhersehbare Interaktion und gegebenenfalls auch eine stiftlose Bedienung zugeschnitten ist.

Wer gerade in der Stadt unterwegs ist, möchte nicht ständig den Blick auf dem Display haben, weil die Bedienschritte selbst bei Routineaufgaben ständig unerwartete Wendungen nehmen (einige Mobiltelefone sind mit dieser Interface-Krankheit geradezu verseucht) und auch nicht jedes Mal den Stift herausholen, um nachzuschauen, was am Tag noch ansteht oder einen Punkt auf der TODO-Liste abzuhaken. Das besonders kleine Display und eine mögliche Bedienung des Touch-Screens mit dem Finger müssen bedacht werden.

Genauso wichtig ist aber, dass die Anwendungen selbst auf ihren speziellen Verwendungszweck zugeschnitten sind. Eine Kalenderanwendung wird verwendet, um nachzuschauen, welcher Termin als nächstes ansteht oder um einen Termin zu vereinbaren. Dabei sehe ich immer wieder Anwendungen, die den Prozess der Terminvereinbarung eher behindern als unterstützen: Nicht nur, dass es keine Unterstützung zum Finden freier Termine gibt, häufig wird z.B. auch verlangt, dass erst einmal Betreff und Ort eingegeben werden, bevor es möglich ist, eine Zeit festzulegen. Hier wird missachtet, dass bei der Terminvereinbarung die Zeit im Mittelpunkt steht – die übrigen Metadaten lassen sich selbständig und im Nachhinein ergänzen. Gleiches passierte mir schon regelmäßig beim Anlegen von Kontakteinträgen: Es gibt nicht wenige Mobiltelefone, die zuerst die Eingabe des Namens verlangen, bevor eine Telefonnummer eingegeben werden kann. Wenn ich jedoch das Telefon heraushole, um eine Nummer zu speichern, ist es eben die Nummer, die mir zuerst und vor allen Dingen von meinem Gegenüber diktiert wird. Und diese Nummer möchte ich zuerst speichern können. Das sind Kleinigkeiten, die sich jeoch ganz massiv auf die Zweckmäßigkeit des Gerätes auswirken.

Wichtig für mich ist vor allem eine schnelle Übersicht der Dinge, an die ich zu dem Zeitpunkt denken sollte, zu dem ich auf meinen PDA schaue.

Sicherheit wird dann wichtig, wenn unbefugte Personen Zugriff auf meinen PDA erhalten. Sei es in einem unbeaufsichtigten Moment oder bei Verlust des Gerätes. Schlimmer als die Notwendigkeit, Hardwareersatz und die verlorenen Daten zu beschaffen ist nämlich der Umstand, dass diese Daten in fremden und sehr wahrscheinlich den falschen Händen sind.

Ebenfalls nicht zu verachten ist die Möglichkeit, dass man abends, nachts oder zu einer beliebigen anderen Zeit auf der Straße angehalten und zur Herausgabe seines Gerätes gezwungen wird. Mir ist das zum Glück noch nie passiert, aber bei der Entscheidung Hardware oder Gesundheit gewinnt eindeutig letztere. Wenn es dann möglich ist, die Daten zu entfernen oder wenigstens unzugänglich zu machen, verliert diese Situation an Schrecken.

Wie erreicht man das? Die Lösung setzt sich für mobile Datenträger und auch auf einigen Desktops mittlerweile schon durch: Sämtliche persönlichen oder sensiblen Daten sollten ausschließlich verschlüsselt abgelegt werden. Beim Einschalten des Gerätes muss eine PIN eingegeben werden (unter Berücksichtigung der Benutzerfreundlichkeit), die den Crypto-Container freischaltet. Wer versucht, unbefugt an die Daten zu gelangen, wird nichts vorfinden, was von Nutzen ist. Da der Zaurus über einen SD-Port verfügt, bietet sich an, diesen Container auf einer SD-Karte abzulegen. So sind auch Datensicherungen sehr schnell gemacht, weil nur ein Image der SD-Karte gezogen werden muss. Einen halbwegs intelligenten Räuber kann man vielleicht sogar noch dazu überreden, auf die SD-Karte zu verzichten. So bleiben aktuelle Daten erhalten.

Grundsatz sollte auf jeden Fall sein, keine sensiblen Daten offen und unverschlüsselt zu lassen. Mit einer vernünftigen Verschlüsselung hat der PDA einen gewaltigen Vorteil gegenüber jedem low-tech-Papierplaner.

Aktualität der Daten muss durch entsprechende Synchronisationsverfahren gewährleistet werden. Nur wenn die Daten überall auf dem neusten Stand sind, kann man sich auch auf sie verlassen und auf deren Basis Entscheidungen treffen.

Der Zaurus, wie ich ihn beschrieben habe, hat zwei Schnittstellen: Den USB-Port und eine CF-WLAN-Karte.

Der USB-Port ist in ein Cradle integriert, das auch zum Aufladen des Gerätes verwendet werden kann. Beim Einstellen des Gerätes sollte also ein Abgleich sämtlicher Daten erfolgen. Wenn möglich, vollautomatisch. Auftretende Konflikte sollten an einem beliebigen Gerät gelöst oder später bearbeitet werden können. (Warum schließlich soll ich mich mit dem Mini-Display des PDA abmühen, wenn direkt daneben ein ausgewachsener Desktop-PC steht?)

Die Synchronisation mittels WLAN sollte ähnlich laufen, kann jedoch auch von unterwegs erfolgen. Zu beachten ist hier, dass es auch zu einem Abbruch der Verbindung kommen kann, also eine entsprechende Transaktionsverwaltung nötig ist.

Ziel der synchronen Datenhaltung ist, jede Information auch nur einmal eingeben zu müssen und sie trotzdem an jedem meiner PIM-Geräte zur Verfügung zu haben.

Fazit: Wer sich sein eigenes Handy oder einen handelsüblichen PDA betrachtet, wird schnell feststellen, dass keines der Geräte alle diese Aspekte erfüllt. Spätestens bei der Verschlüsselung wird auf aktive Sicherheit gesetzt und nicht beachtet, dass insbesondere Speichererweiterungen auch am System vorbei ausgelesen werden können. Benutzerinterfaces sind häufig nur verkleinerte Varianten eines Desktops und für kleine Touch-Screens oder die Bedienung mit nur wenigen Tasten ungeeignet. Auch die Synchronisation klappt in den wenigsten Umgebungen reibungslos. Es gibt viel Nachholbedarf, bis ein PDA wirklich effektiver ist, als ein Papierplaner und man mit solch einem Gerät Zeit spart.

Örbenn Ledschänd

Ich hätte es nicht geglaubt, wenn mir jemand anders erzählt hätte, was ich erlebt habe. Ich hätte es als Urban Legend abgetan, in den Bereich dieser neuzeitlichen Mythen, mit denen man so gerne Büros, Stammtische, konspirative Gentoo-Installationsparties und Flashmobs (Fläschmopps — ist das nicht der sprechende Hund von Loriot?) unterhalten kann. Ich hätte mich geweigert, es als wahr zu akzeptieren. Bis eben… (ja, mir ist bewusst, dass ein Absatz wie dieser ebenfalls dazu gehört, wenn man eine fiktive Urban Legend erzählt :-) )

Die Ausgangssituation: Kollege A. beratschlagt sich im Büro mit mir über die Abgründe der gepflegten Zeigerarithmetik und der Typenkonvertierung in der schönen Sprache C(++).

Der Plot: Unsere hitzige Erörterung wird durch Teamassistentin Y. (gelernte Bürokauffrau) unterbrochen, die gerade einige Informationen verteilt. Es dauert keine zwei Minuten, dann kommt Kollege K. herein, der wissen möchte, warum wir gerade über ihn lästern. Kollegin Y. hätte es ja gerade mitgehört und überhaupt fühlt er sich nicht wohl, wenn hinter seinem Rücken Unwahrheiten erzählt werden.

Verdutzt schauen A. und ich uns an und brechen wenige Augenblicke später in schallendes Gelächter aus. Einige Sekunden und eine kurze Erklärung später dann auch der bis dahin sehr konsternierte K.

Meine Worte gegenüber A. waren “Beim Casten passiert leicht mal eine kleine Katastrophe, wenn man nicht höllisch aufpasst.” Und K. heißt Karsten.

Alter schützt vor Treibern nicht

Mein aktuelles Bastelprojekt ist ein alter Rechner. Eingebaut ist ein Pentium mit 133 MHz, ein wenig EDO-RAM, eine alte Soundkarte vom Typ Terratec Base 1, 3com Netzwerkkarte und eine große Festplatte, auf der Daten gesichert werden. Für Konsole reicht das gut hin und Musik kann er auch abspielen. Installiert hatte ich Debian Etch.

Die Kiste hängt an einem 17″-Röhrenmonitor, eine Konsole mit 80×25 Zeichen ist nett, aber 800×600 Pixel sind locker drin – immerhin 100×37 Zeichen. Damit lässt sich gut chatten, für E-Mails ist genug Platz und auch im Midnight Commander steigt die Übersicht. Das ganze steht und fällt mit dem dafür nötigen Betrieb der Grafikkarte im Framebuffer-Modus. Bei neuen Karten geht das leicht über den VESA-Treiber, einfach vga=789 an die Kernel-Optionen von Grub angehängt und fertig. Leider ist in dem Rechner eine alte S3 Trio64V+ eingebaut und die unterstützt der VESA-Treiber nicht.

Zum Glück gibt es noch andere Framebuffer-Treiber. Bei der ersten Recherche im Netz stellte sich aber Ernüchterung ein. S3 nur für PPC oder Amiga, warum auch immer. Dann stieß ich auf eine erst ein paar Monate alte Neuigkeit. Da hatte doch tatsächlich jemand für Kernel 2.6.21 noch einen neuen Treiber für die Karte geschrieben. Ich finde das reichlich bemerkenswert, schließlich reden wir hier von einer Grafikkarte aus den späten Neunzigern!

Der Ehrgeiz war geweckt, jetzt galt es das Ding zum Laufen zu bringen. Zunächst schaute ich, was nach Debian Etch an Kernel-Versionen bereit stand. Der aktuelle Testing-Zweig bringt 2.6.22 mit, also machte ich ein Dist-Upgrade von Etch nach Lenny. Das war nicht weiter aufregend, allerdings noch nicht alles. Um den Treiber jetzt auch zu benutzen waren (als root!) folgende Schritte notwendig:

  • s3fb in die Datei /etc/initramfs-tools/modules eintragen
  • update-initramfs -u -k all
  • in /boot/grub/menu.lst die entsprechende Zeile wie folgt ändern:
    # defoptions=video=s3fb:800x600@85

Anschließend neu booten und freuen. Der Rechner läuft tatsächlich mit Framebuffer-Konsole auf S3 Trio64V+.

happy