Linux im RAM: Erfahrungen mit TinyCore auf dem Thinkpad 600

Nachdem die allgemeinen Hardwareprobleme wieder im Griff sind, wird es Zeit die Erfahrungen mit TinyCore zusammenzufassen. Ich habe mich nach meinem letzten Beitrag zum Thema „TinyCore remastern“ noch etwas mit der Konfiguration dieser minimalistischen Linux-im-RAM-Distribution beschäftigt und lade die gefundenen Erkenntnisse hier einfach mal ab.

TinyCore auf dem Thinkpad 600

Da ich festgestellt habe, dass der standardmäßig installierte XVesa-Treiber nur eine unzureichende Bildschirmauflösung bietet und alles grünlich verzerrt, habe ich den Xorg-Server in Version 7.6 installiert. Als Ausgangsbasis zum weiteren Testen habe ich mir den Vorschlag von Heinz zu Herzen genommen und den Browser „Bon Echo„, alias Firefox 2.0 mit GTK1-Bibliothek, Fluff, ein Dateimanager auf Basis von FLTK und kmaps für die deutsche Tastaturbelegung installiert. Nur an der Option „Add app inside intitrd on boot“ konnte ich danach nicht mehr festhalten.
Ich denke, es liegt nicht an der Größe meines Arbeitsspeichers, 128 MB sind ausreichend um all diese Erweiterungen direkt beim Booten in den RAM zu kopieren. Dennoch wird der Xorg-Server nicht aktiviert und TinyCore fällt auf den XVesa-Modus zurück. Das Problem ließ sich nur durch Remastern mit der Option „Add app outside initrd on boot“ beseitigen. Das bedeutete zwar, dass ich den USB-Stick nicht mehr entfernen konnte, gleichzeitig sinkt dadurch aber auch der benötigte Verbrauch an RAM, weswegen diese Methode für die älteren Rechner mir nun als der bessere Weg erscheint. Die Startzeit beim Booten wird ebenfalls verkürzt, hingegen erhöht sich die Wartezeit beim ersten Aufruf der Erweiterung.

Apps Audit

Natürlich kann man TinyCore auch komplett in Virtualbox remastern und wie im letzten Beitrag zu diesem Thema erwähnt, überflüssige Extensions der Multicore-Version entfernen und Konfigurationsdateien schon vor dem ersten Remastern bearbeiten.
Da das langweilig war, bin ich sofort nach dem Beenden von Ezremaster auf den Thinkpad 600 gewechselt und habe dort dann alle weiteren Anpassungen vorgenommen. Mit Hilfe der Anwendung „Apps Audit“, grob vereinfacht eine Mischung aus Ubuntus Softwarecenter und Synaptic :D, lassen sich Extensions entfernen und das System auf den neusten Stand bringen und einstellen, welche Erweiterungen schon beim Booten (OnBoot) und welche erst auf Nachfrage (OnDemand) in den RAM geladen werden.

  • Pakete entfernen. Dependencies -> Build Reporting Database -> Extension auswählen -> Mark for Deletion -> Rebooten (mit Backup!)
  • System aktualisieren. Updates -> Check for Updates
  • Erweiterungen beim Booten laden. OnBoot -> Maintenance -> Extension wählen
  • Erweiterung nach Anfrage laden. OnDemand -> Maintenance -> Extension wählen
Apps Audit

AppBrowser

Applikationen, Softwarepakete sagen die einen, TinyCore nennt es Extensions. Diese Anwendungen lassen sich mit dem AppBrowser installieren. Er ist denkbar einfach zu bedienen. Mit Connect verbindet man sich zum TinyCore-Repositorium, danach nur noch die Erweiterung auswählen und aus den vier Modi wählen. Ich habe hier wie auch zuvor OnDemand gewählt und als weiteres App Dropbear, den winzigen SSH-Client und -Server installiert.
Alle Erweiterungen werden als Loop-Device eingehängt und dann lediglich mit dem Dateisystem verlinkt. Im Prinzip verhalten sich deshalb TinyCores Extensions ähnlich wie die IMG-Dateien eines Mac. Möchte man Programme deinstallieren genügt es einfach die TCZ-Datei zu löschen.

AppBrowser

Netzwerk

Das Letztere wäre ohne funktionierendes Netzwerk nicht möglich gewesen. Ich versuchte es zuerst mit meiner WLAN-Karte ASUS WL-107G mit Ralink-Chipsatz und dem Kerneltreiber rt2500pci. Der Linuxkernel erkannte die Karte wie gewohnt automatisch und da ich sowohl alle Wifi-Programme und auch wpa_supplicant von der Multicore-Version behalten hatte, funktionierte die minimalistische Netzwerkanwendung wifi.tcz problemlos. Zumindest für ca. 30 Sekunden hatte ich danach drahtlosen Internetzugang mit WPA-Verschlüsselung. Danach fror das System leider ein. Auch der Weg über die Kommandozeile half nicht weiter.
Ich tauschte danach die Karte gegen eine der 3com PCMCIA Karten aus, mit der es schließlich problemlos möglich war eine kabelgebundene Verbindung mit eth0 als Schnittstelle aufzubauen.

Netzwerk + Control Panel

Persistenz

Ein ganz wichtiges Thema bei TinyCore ist Persistenz. Nach dem Ausschalten des Computers sind gewöhnlich alle Daten, die vorher in den RAM geladen wurden verschwunden. Damit man sowohl seine Erweiterungen als auch wichtige Systemeinstellungen nach dem Reboot weiterverwenden kann, bietet TinyCore zwei grundlegende Möglichkeiten an.

  1. Dauerhaftes /home-, /opt- und /tce-Verzeichnis. Mit Hilfe von Bootcodes lässt sich TinyCore schon beim Starten anweisen die /home-, /opt- und /tce-Verzeichnisse dauerhaft auf einem Datenträger anzulegen. Beim Remastern mit dem schon vorgestellen Ezremaster ist das Schritt Nr.2. Die Bootparameter lassen sich auch nachträglich ändern. Die entsprechende Datei befindet sich in /mnt/sdb1/boot/extlinux und heißt extlinux.conf, wobei sdb mein eingehängter USB-Stick ist.Die Bootparameter lassen sich an die Zeile APPEND anhängen. Wer wie ich TinyCore auf einen USB-Stick installiert und Extensions außerhalb der initial ramdisk installiert hat, stellt fest, dass das TCE-Verzeichnis automatisch persistent angelegt wurde. D.h. alle Erweiterungen, die man mit dem Appbrowser in /mnt/sdb1/tce/optional installiert, werden gespeichert.
    Ausführlicher erklärt wird es im TinyCore-Wiki im Artikel „Persistence for Dummies„.
  2. Backup. Die intuitivste und wahrscheinlich auch einfachste Methode ist es ein Backup zu machen. Beim Abmelden kann man zwischen den drei Optionen None, Backup und Safe auswählen, also entweder nicht speichern, ein Backup machen oder ein Backup machen und das alte Backup zusätzlich sichern. Alle Dateien und Informationen werden dann gepackt und im /tce-Verzeichnis als mydata.tgz gesichert. Was genau gespeichert oder nicht gespeichert werden soll, lässt sich in zwei einfachen Textdateien festlegen. Im /opt-Verzeichnis befinden sich die versteckten Dateien .filetool.lst und .xfiletool.lst. Die erste Datei ist eine Whitelist, in der Verzeichnisse und Dateien aufgeführt sind, die gesichert werden sollen. Die .xfiletool.lst ist das Gegenstück dazu, in der Dateien vom Backup ausgeschlossen werden können.Dabei gilt: .xfiletool.lst > .filetool.lst, wodurch es möglich ist Verzeichnisse auf eine Whitelist zu setzen, aber darin enthaltene Dateien vom Backup auszuschließen.

Folgende Dateien und Verzeichnisse habe ich zusätzlich zu den Voreinstellungen zum Backup hinzugefügt oder ausgeschlossen.

.filetool.lst

etc/X11/xorg.conf
opt/eth0.sh
opt/wpa_supplicant.conf
etc/passwd
etc/shadow
etc/dropbear

.xfiletool.lst

.mozilla/

Deutsche Tastaturbelegung

Xorg

Da ich den Xorg-Server benutze, ist es notwendig, dass man die Einstellungen zur deutschen Tastaturbelegung manuell in /etc/X11/xorg.conf ändert. Die Vorgehensweise habe ich vor kurzem etwas ausführlicher beschrieben. Im Prinzip ist es das gleiche Spiel wie bei ConnochaetOS oder Slitaz. Als Eintrag genügt aber in der Regel schon:

Section "InputDevice"
  Identifier "Keyboard"
  Driver "kbd"
  Option "XkbLayout" "de"
EndSection

Für Leserinnen und Leser aus der Schweiz und Österreich sollte natürlich auch ch und at funktionieren. 🙂 Nicht vergessen die xorg.conf in die .filetool.lst einzutragen!

Konsole

Für die virtuelle Konsole benötigt man das Paket kmap.tcz und die passende deutsche Keymap. Der folgende Befehl sollte in /opt/bootlocal.sh eingetragen werden. Er wird dann automatisch beim Start ausgeführt.

loadkmap < /usr/share/kmap/qwertz/de-latin1.kmap

Dropbear

Dropbear ist ein kleiner SSH-Client und -Server und der passende Ersatz, wenn man die gleiche Sicherheit wie mit OpenSSH haben möchte, aber auf die sftp Fähigkeit verzichten kann. Zum Starten von Dropbear trägt man den Befehl
/etc/init.d/dropbear start
in die /opt/bootlocal.sh ein. Gleichzeitig muss der Standardbenutzer tc ein Passwort erhalten (passwd) und die Dateien /etc/passwd, /etc/shadow und das gesamte /etc/dropbear Verzeichnis persistent gemacht werden.

Hintergrundbild einrichten

Das Hintergrundbild lässt sich spielend leicht ändern. Kopiert euer bevorzugtes Bild einfach nach /opt/backgrounds. Anschließend lässt sich im Control Panel unter „Wallpaper“ das neue Hintergrundbild einrichten. So lässt sich ganz leicht aus TinyCore ein Ubuntu Oneiric Ocelot machen. 😉

Auf ein Wort

Es ist schon erstaunlich, dass es Freie Betriebssysteme gibt, die nicht nur auf 13 Jahre alter Hardware funktionieren, sondern dann auch noch komplett im RAM laufen können.
Ich denke TinyCore ist ein Beispiel dafür, dass man sowohl ältere Hardware als auch innovative Konzepte unter einen Hut bringen kann. TinyCore ist kein Abklatsch irgendeines bekannten Mainstream-Linux, dass sich an der Vorarbeit anderer gütlich tut und nur das Desktopthema austauscht.
Vollkommen zufrieden bin ich aber noch nicht. Die WLAN-Karte muss/sollte funktionieren. TinyCore auf eine Festplatte zu installieren ist zwar möglich, das halte ich aber nicht für den eigentlichen Verwendungszweck dieser Minidistribution. Zu rudimentär ist auch der Installer, als dass er einen ernsthaften Vergleich mit Debian oder Ubuntu standhalten könnte. Ideal ist TinyCore für den privaten Desktopbenutzer, der ein maßgeschneidertes Linux für einen USB-Stick und für den RAM sucht.
TinyCore bietet einige technisch einfache und effiziente Systemprogramme, die ideal für ältere Rechner geeignet sind, da sie kaum Ressourcen in Beschlag nehmen. Sie sehen zwar optisch nicht überwältigend aus, verrichten aber zielgerichtet ihren Dienst.
Debian, Slitaz oder ConnochaetOS halte ich für eine Festplatteninstallation auf dem Thinkpad 600 für die bessere Alternative, keine der Drei lässt sich aber so schnell und einfach mit 128 MB oder weniger in den RAM installieren, wobei man mit TinyCore eine grafische Oberfläche standardmäßig geboten bekommt.
Wenn man also ein bestehendes Betriebssystem nicht verändern möchte und gleichzeitig verschiedene Optionen von „Was man mit alten Computern machen kann“ ausprobieren will, bietet sich TinyCore als eine ideale Möglichkeit an.
Wie immer muss man die Vor- und Nachteile für sich selbst abwägen. Fakt ist, TinyCore belegt momentan mit allen Erweiterungen gerade einmal 65 MB Speicherplatz, was es ideal für meinen 128-MB-USB-Stick macht. 😉
Nach dem Booten zeigt mir htop an, dass TinyCore 30 MB RAM in Anspruch nimmt. Mit Bon Echo, Fluff und ein paar Systemprogrammen komme ich auf 68 MB. Mehr als genug gute Gründe, um die Entwicklung von TinyCore in Zukunft weiter zu verfolgen.

Speicherverbrauch und Fluff
BonEcho

Links

TinyCore Wiki
TinyCore Forum
Anleitung zu TinyCore als Webserver

Alt-Gr-Taste unter X in Betrieb nehmen und Tastaturlayout auf Deutsch ändern

Letzte Woche wurde die Frage gestellt, warum die „Alt-Gr“-Taste des Thinkpad 600 bei Slitaz nicht funktionieren würde. Mir war dieses Problem damals nicht aufgefallen und für gewöhnlich muss ich mich zumindest bei Debian nicht um das manuelle Einstellen des Tastaturlayouts kümmern.
Der X-Server ist mittlerweile so smart, dass er alle Optionen automagisch einrichtet. Sollten aber Probleme mit dem Tastaturlayout auftreten, lässt sich die Einstellung für Xorg nach wie vor entweder in /etc/X11/xorg.conf oder mit einer Konfigurationsdatei in /etc/X11/xorg.conf.d/ manuell ändern. Der Abschnitt sieht dann für eine deutsche Tastatur ähnlich wie dieser aus:

Section “InputDevice”
  Identifier “Generic Keyboard”
  Driver “kbd”
  Option “XkbRules” “xorg”
  Option “XkbModel” “pc105″
  Option “XkbLayout” “de”
  Option “XkbVariant” “nodeadkeys”
EndSection

Tastaturlayout für ConnochaetOS und den Thinkpad 600 ändern

Später fiel mir dann auf, dass ConnochaetOS die AltGr-Taste des Thinkpad 600 ebenfalls nicht automatisch eingerichtet hatte, obwohl es eine extra angelegte /etc/X11/xorg.conf.d/20-keyboard.conf gab. Da ConnochaetOS auf Arch Linux basiert, konnte ich schnell eine Lösung für das Problem finden, dank dieses Beitrags im deutschen Arch-Linux-Forum.
Damit die AltGr-Taste wieder funktioniert, muss man einen Parameter für die Option „XkbOptions“ mit Hilfe des Programms setxkbmap temporär übergeben oder permanent in der Datei 20-keyboard.conf eintragen.

Temporär

setxkbmap -option lv3:ralt_switch_multikey

Permanent

Option „XkbOptions“ „lv3:ralt_switch_multikey“

Bei ConnochaetOS sieht die 20-keyboard.conf dann so aus:

Section "InputClass"
  Identifier "txkbmap keyboard catchall"
  MatchIsKeyboard "on"
  Option "XkbModel" "thinkpad"
  Option "XkbLayout" "de"
  Option "XkbVariant" "nodeadkeys"
  Option "XkbOptions" "lv3:ralt_switch_multikey"
EndSection

Die Systemeinstellungen und das Tastaturlayout für die Konsole lassen sich bei Arch Linux und ConnochaetOS in /etc/rc.conf ändern. Hilfreich ist der Artikel „Arch Linux auf Deutsch stellen“ im Arch Linux Wiki.

Fehlerdiagnose

Mit dem Kommando xev lässt sich herausfinden, mit welchem Keycode eine Taste im Moment belegt ist, indem man die betreffende Taste danach einfach drückt. Mit xmodmap -pke wird eine komplette Übersicht angezeigt. Beide Befehle eignen sich gut für die Fehlerdiagnose.
In /usr/share/X11/xkb/rules/base.lst befindet sich die Dokumentation zu allen Optionen im Zusammenhang mit Xorg und xkb.

Eine gute und eine schlechte Nachricht

Der erste Eindruck hat nicht getrogen und tatsächlich hatte das Netzteil des Thinkpad 600 durch den Kurzschluss auf dem Weihnachtsmarkt ordentlich etwas abbekommen. Mit dem neuen Universalnetzteil funktioniert die Kiste aber wieder, Debian, ConnochaetOS, KolibriOS und Co. laufen einträchtig im Multibootsystem und alle Daten sind nach wie vor intakt. Eine gute Nachricht, weswegen weiteren Experimenten nichts entgegenstehen sollte. 🙂
Auf der anderen Seite hat mich in letzter Zeit der etwas verrückt spielende Core Duo in Atem gehalten, weshalb weniger Zeit für interessantere Computerprobleme geblieben ist. Die weniger gute Nachricht lautet dann auch, dass das System weiterhin instabil ist, obwohl ich mittlerweile einige Zeit damit verbracht habe, um mich über den Unterschied von Single- und Dual-Channel-RAM zu informieren, schon wieder gelernt habe :roll:, dass man selbst bei sorgfältiger Recherche immer noch Fehler machen kann und zu guter Letzt nicht mehr unterscheiden kann, ob es nun ein Hardware- oder doch eher ein Softwareproblem ist. Aber der Reihe nach.
Der Core Duo besaß einmal 2x 2GB-RAM-Module des Herstellers Team Group aus Taiwan mit der genauen Produktbezeichnung TVDD2048M800. Nachdem mehrere Anwendungen kontinuierlich abstürzten und ich mit Memtest86+ festgestellt hatte, dass offenbar der Speicher defekt war, entfernte ich ein Modul und alles schien wieder in Ordnung zu sein.
Nach einiger Zeit wiederholte sich das Spiel aber und ich beschloss das Übel loszuwerden und mir neuen Arbeitsspeicher zu kaufen. Da der Hersteller meines Mainboards ASUS war, begab ich mich auf dessen Homepage um mehr über geeigneten RAM für mein P5N73-CM Motherboard herauszufinden. Dort gab es tatsächlich ein PDF-Datenblatt mit einer „Qualified Vendor List“.
„Großartig“, dachte ich, dort werde ich sicherlich den passenden RAM für mein Board finden. Ich wählte natürlich den schnellstmöglichen PC6400 RAM mit 800Mhz Speichertakt und entschied mich für Kingston KHX6400D2LLK2/1GN. Stutzig machte mich nur, dass der ehemals verbaute RAM von TEAM gar nicht in der Liste auftauchte.
Ich bestellte daraufhin also KHX6400D2LLK2/4G, wobei ich gutgläubig aber leider auch naiv annahm, dass das der gleiche Speicher war, der lediglich als 2×2 GB RAM Kit verkauft wurde. Das 11. IT Gebot lautet aber, „Du sollst dir über Hardware kein Bildnis machen!“.
Augenscheinlich funktionierte nur ein Modul gleichzeitig mit meinem Board, so dass ich nur 2 GB installieren konnte. Ein Blick danach auf die Kingston Homepage offenbarte mir dann meine Fehleinschätzung. Ich hatte mir ein Dual-Channel-Memory-Kit gekauft, mein Motherboard unterstützte aber nur Single Channel.
Da ich nun keine Lust mehr auf weitere Experimente hatte, bestellte ich einfach zwei 2GB-Module des Original-TEAM-RAMs. Gleicher Typ, gleicher Hersteller, eine narrensichere Angelegenheit.
Als ich jedoch beide Bausteine eingesetzt hatte und mich schon über die Anzeige 4096 MB im Bios gefreut hatte, wurde mein Freudentaumel jäh durch eine GRUB-Fehlermeldung beendet.
Egal was ich auch tat, entweder startete der Rechner nach dem Erreichen des GRUB-Menüs neu, fror ein oder zeigte mir diese Fehlermeldung. Jedoch mit einem RAM-Modul und 2 GB RAM scheint es keine Probleme zu geben. Möglicherweise ist sogar das Motherboard selbst defekt. Passend dazu bekomme ich seit neustem, aber nur mit dem Nvidia-Treiber, diese Fehlermeldung.

NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00001338 0000fd20 0000000c
[28271.390112] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015f404 00000004
[28276.495279] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015ff04 00000004
[28278.719604] NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context

Im offiziellen Nvidia-Forum habe ich diesen Thread dazu gefunden, der aber scheinbar nicht weiterverfolgt wird. Die Symptome sind ein manchmal kurz flackernder Bildschirm und teilweise ein komplettes Einfrieren des gesamten X-Servers, der sich danach nur noch über SSH beenden lässt. Hängt dies nun ebenfalls mit dem RAM-Problem zusammen oder ist das nur eine unglückliche Verquickung von Hardware- und Softwarefehlern?
Ich weiß zur Zeit nur eins. Solange ich 2 GB RAM und die freien Nouveau-Treiber benutze, scheint das System stabil zu laufen, benutze ich hingegen den Nvidia-Treiber ist ein Neustart des X-Servers vorprogrammiert. Für einen Rechner, der mehr als doppelt soviel gekostet hat wie alle gebrauchten Laptops des Haushalts zusammen, eine eher schlechte Nachricht.

Der Thinkpad 600 als DJ auf dem Weihnachtsmarkt

Alle Jahre wieder findet in einem kleinen Dorf im Zentrum der Welt ein weltbekannter Weihnachtsmarkt statt. Am letzten Wochenende versammelten wir uns erneut im Glühweinzelt, um Glühwein mit und ohne Schuss, Lumumba und Kinderpunsch auszuschenken. Dieses Mal erklärte ich mich bereit, stimmungsvolle Musik mit Hilfe des Thinkpad 600 zur Verfügung zu stellen.
Alle Theorie ist trocken und grau, weshalb etwas Praxis nicht schaden konnte. Mit Debian und dem effizienten C*mus war die musikalische Unterhaltung des Weihnachtsmarkts gesichert. Da ich es darauf angelegt hatte, gab es zusätzlich für den ein oder anderen Bildschirmschonertrick mit Screen einige „Ohs und Ahs“. 😉


Unauffällig in einer Ecke stehend erfüllte der Thinkpad seine Aufgabe. Der gesamte Tag verlief in musikalischer und technischer Harmonie. Zumindest bis wir uns dem Ende des Abends näherten. Denn spätestens wenn die Gäste einem mit wässrigem Blick anstarren und fordern: „Ich will Rum mit Glühwein. Du hast mich verstanden? RUM mit Glühwein!“, ist es mal wieder Zeit das alljährliche Fest ausklingen zu lassen.
Wäre da nicht der kleine Kurzschluss beim Abbauen des Standes gewesen, der das Netzteil meines treuen Laptops abrauchen ließ, es hätte wieder einmal ein perfekter Abend werden können. 🙁
Mal schaun, ob die Bestellung, die in Kürze hier eintreffen wird, den Laptopoldie noch retten kann.

Linux im RAM: TinyCore am Beispiel Xorg-Server remastern

Vergangene Woche habe ich begonnen TinyCore etwas genauer unter die Lupe zu nehmen und die kleine Linuxdistribution auf einen USB-Stick installiert, von dem aus schließlich alles in den RAM meines Thinkpad 600 kopiert werden konnte. Noch nicht alles war perfekt. Der voreingestellte XVesa-Treiber versperrte mir den Blick auf den Desktop mit einem grünlich-blauen Schleier. Ich habe zwar noch eine Weile im Internet recherchiert, konnte aber keine Lösung zu dem XVesa-Problem finden.
Es wurde also Zeit TinyCore zu remastern, was in der Fachsprache dieser Linuxdistribution nichts anderes bedeutet als zusätzliche Softwarepakete zu installieren, überflüssige zu deinstallieren und die Stellschraube an der oder anderen Config-Datei zu drehen. TC bietet hier verschiedene Lösungsmöglichkeiten an:

  1. Die Zu-Fuß-Methode auf der Kommandozeile
  2. qremaster
  3. Ezremaster

Alle drei Methoden haben Vor-und Nachteile. Die Zu-Fuß-Methode setzt voraus, dass man sich wohl auf der Konsole fühlt, qremaster ist ein Shellskript, welches den Vorgang stark vereinfacht und Ezremaster ist ein grafisches Frontend, welches den gesamten Vorgang noch besser visualisiert und möglicherweise am intuitivsten ist.

TinyCore mit Hilfe von Ezremaster erweitern

  1. Pfad zum TinyCore-Abbild und zum temporären Verzeichnis


    Im ersten Schritt wählt man das Verzeichnis, indem sich entweder das multicore.iso, tinycore.iso, microcore.iso oder eine gemountete CD befindet. Die ISO-Dateien als Loop Device zu mounten funktioniert auch. Für mich war das /mnt/sr0 in Virtualbox. Für den Vorgang des Remasterns ist ein temporäres Verzeichnis notwendig, welches standardmäßig /tmp/ezremaster ist. Wer sehr viele Extensions, also neue Pakete, installieren möchte, sollte darüber nachdenken das Verzeichnis ggf. außerhalb von /tmp anzulegen, vor allem wenn RAM knapp ist.

  2. Boot-Codes und Backup


    Als nächstes lässt sich festlegen, mit welchen Boot Codes TinyCore gestartet werden soll. Für mich musste ich hier keine Einstellungen vornehmen. Wer aber z.B. Probleme mit der Auflösung hat, kann hier einen entsprechenden Parameter wie vga=791 für 1024×768 übergeben. Die sogenannte Backupdatei bietet die Möglichkeit gesicherte Einstellungen aus einer anderen TC-Installation in das neue Abbild zu übernehmen.

  3. Extensions installieren


    Der dritte Schritt ist das Installieren der zusätzlichen Software. Damit mein Thinkpad 600 wieder ein klares Bild liefert, habe ich mich für Xorg-7.6 entschieden, wozu ich mich zuerst mit dem Repositorium von TinyCore verbinden musste. Mit einem Klick auf „Connect to App Repo“ ist dieses Thema abgehakt. Danach hat man folgende Möglichkeiten laut TinyCore Wiki.

    • Add App Outside initrd on boot / Add App Outside initrd. Diese Optionen werden die Erweiterungen im ISO-Image unter /tce/optional installieren. Wählt man Outside initrd apps on boot werden die Extensions zusätzlich in der Datei /tce/optional/onboot.lst aufgeführt, so dass sie automatisch beim Booten in den Arbeitsspeicher geladen werden. Die Methode Erweiterungen außerhalb der initial ramdisk zu installieren hat den Vorteil, dass weniger RAM notwendig ist um die Programme auszuführen. Die CD oder der USB-Stick darf dann aber nicht entfernt werden. Des Weiteren gibt es noch die Möglichkeit „copy2fs.flg“ zu setzen, was dazu führt, dass die Erweiterung beim Booten schon in den RAM kopiert werden und das Installationsmedium danach entfernt werden kann. Das führt aber wieder zu mehr Speicherverbrauch.
    • Add App inside initrd on boot / Add App inside initrd. Diese Option installiert die Erweiterungen in die Initial-RAM-Disk (tinycore.gz) unter /opt/tce/optional. Wenn man „Inside initrd on boot“ ausgewählt hat, werden die Namen der Extensions in die Datei /opt/tce/optional/onboot.lst geschrieben, so dass sie direkt beim Booten in den RAM kopiert werden und die CD/USB-Stick danach entfernt werden kann. Eine gute Methode, wenn man genügend Arbeitsspeicher zur Verfügung hat.
    • Add App Extract TCZ to initrd. Bei dieser Methode wird jede Extension beim Remasterprozess gemountet und in die extrahierte initrd installiert. Das soll eine bessere Performance als die „inside initrd“ Option liefern bei gleichzeitig aber etwas größerem Speicherverbrauch, da nun die Extensions nicht mehr als komprimierte TCZ-Dateien vorliegen.

    Ich habe mich für „Add App inside initrd on boot“ entschieden, da ich später alle Anwendungen im RAM laufen lassen und den USB-Stick entfernen möchte.

  4. Remaster-Prozess: Anfang


    Ab hier beginnt das eigentliche Remastern. Wer den Vorgang im Terminal beobachten möchte, wählt einfach die Checkbox aus. Der Vorgang kann, je nach dem wie viele Erweiterungen installiert werden sollen, eine Weile dauern.

  5. Remaster-Prozess: Finale


    Im letzten Schritt wird schließlich eine neue ISO-Datei erstellt, die sich danach erneut auf eine CD schreiben oder in Virtualbox mounten lässt. Bevor das aber geschieht, kann man ab jetzt noch verschiedene Konfigurationsdateien ändern und Veränderungen am Dateisystem selbst vornehmen. Wie in Schritt 3. schon erklärt, befinden sich die Extensions später in /opt/tce/optional. Hat man den Standardpfad für die temporären Dateien beibehalten, findet man die Erweiterungen vor dem Erstellen der ISO-Datei unter /tmp/ezremaster/extract/opt/tce/optional und kann überprüfen, ob zuvor alles glatt gelaufen ist.
    Im Verzeichnis /tmp/ezremaster/image/cde/optional befinden sich die Erweiterungen für die MultiCore-Version. Falls man in der neu erstellten ISO-Version auf die Tools zum Remastern verzichten kann, ist hier der richtige Ort um sie zu entfernen.
    Wenn man wieder alles auf einen USB-Stick schreiben möchte, muss man nur die neue Datei tinycore.gz in /tmp/ezremaster/image/boot/ auswählen und wie im alten Beitrag geschrieben weiter verfahren.

Das Ergebnis


Der X-Server wird automatisch mit Xorg eingerichtet. Insgesamt belegt das System ca. 100 MB im RAM und ist naturgemäß äußerst schnell. Der Speicherverbrauch ist aber noch zu hoch, da ich die zusätzlichen Extensions der MultiCore-Version noch nicht entfernt habe. Hier muss ich also in Zukunft noch ein wenig Hand anlegen. Positiv ist auch, dass meine ASUS WL-107G WLAN Karte automatisch erkannt wurde und mir TinyCores Wifi-Programm nun schon den Access Point anzeigt.
Als nächstes werde ich noch Dropbear als SSH-Server und einen Browser installieren und dann….mal schaun. 😉

Eine Reise in die Vergangenheit: Der Wert der Laptops gestern und heute

Was machst du von heute an in zehn Jahren? Wie wird dein Leben aussehen? Wo wirst du wohnen, arbeiten, deine Zeit verbringen? Wenn du ein Medium mit Interessen für ältere Computer und Linux bist und durch einen aberwitzigen Zufall auf diese Seite geraten sein solltest, kennst du die Antwort vielleicht schon. Für Normalsterbliche ist ein Blick in die Glaskugel mitunter jedoch ziemlich trübe. Auch ich weiß nicht, was in der Zukunft passieren wird, weshalb ich mich in diesem Post einer verlässlicheren Größe zuwende – der Vergangenheit.
Ich hatte Lust mir alte Rezensionen zu meiner Hardware anzuschauen und herauszufinden wie hoch die Verkaufspreise damals ausfielen. Hier also ohne Wertung ein paar Informationen dazu.

Dell Inspiron 4000

Der Inspiron kam Ende 2000 zum ersten Mal in den Handel. Auf pcpro.co.uk kostete er damals 1.996 Englische Pfund (1999: 1 Pfund = ca. 3DM) . Bei Testberichten auf dooyoo.de variierte der Preis im Jahr 2001 zwischen 5500DM (2.812€) bis ca. 1.700€ im gleichen Jahr. Ich kaufte ihn im Jahr 2008 gebraucht für 100€ inklusive Zubehör. Die meisten Kommentatoren hoben das helle und gute Display hervor und störten sich manchmal am Gehäuse oder den Lautsprecherboxen. Insgesamt sei er ein solider Laptop und diesen Eindruck kann ich auch heute noch bestätigen.

Toshiba Portégé 3110CT

Das Toshiba Subnotebook erschien im Jahr 1999 und wurde am 1.10.1999 auf pcpro.co.uk vorgestellt. Es kostete damals ca. 1.992 Englische Pfund. Auf dooyoo.de wurde er als ideal für Präsentationen oder als „mobile office“ angepriesen. Auch im Jahr 2001 scheint er noch stolze 5000DM gekostet zu haben. Wer aber den 3110CT mal in Echt gesehen hat, wundert sich bei der kompakten Bauweise aus dem Jahr 1999 auch nicht mehr über den damaligen Preis. 2008 habe ich ihn netterweise für lau als Geschenk erhalten.

Toshiba Satellite 220cs

Cnet.com preist das „multimedia excitement and versatility“ an. Auf expertreviews.co.uk wird das verbesserte 800×600 Pixel Display gegenüber den älteren 640×480 Pixeln hervorgehoben. Preislich musste man dafür am 01.09.1997 1.757 Englische Pfund hinlegen, was ca. 2500€ damals entsprochen hätte. Den 220cs habe ich letztes Jahr für 18 € bei ebay ersteigert.

IBM Thinkpad 600

Den Cnet.com Artikel zum Thinkpad 600 hatte ich schon vorgestellt. Der Artikel ist voll des Lobes über den nur 5 Pfund schweren Laptop mit einem „schreiend schnellen Pentium II Prozessor“. Ersteigert habe ich ihn vor wenigen Monaten für 27,50 € bei ebay. In der offiziellen Pressemitteilung von IBM aus dem Jahr 1998 wird ein Verkaufspreis von 3199$ offeriert. Das war noch zu einer Zeit als der Dollar etwas mehr wert war als heute. 😉

Linux im RAM: TinyCore auf einem USB-Stick

Ein aktueller Trend ist der Austausch der althergebrachten elektromechanischen Festplatte gegen ein Solid State Drive und über kurz oder lang wird SSD die hergebrachte Magnetfestplatte vollständig ersetzen. Einziger Nachteil momentan ist der relativ hohe Preis pro GB für die neue Technologie. Für einen älteren Laptop mit einer zehnjährigen Vergangenheit lohnt ein solcher Umbau schon nicht mehr. Wer aber dennoch mit SD-Technik liebäugelt, aber nicht gerne Geld zum Fenster herauswirft, sollte sich auch einmal K.Mandlas SSD-Lösung näher anschauen. 😉
Für meinen Teil sehe ich sowohl für ältere als auch für brandneue Rechner eine noch preisgünstigere und noch schnellere Alternative.

RAM Installation

Machen wir uns nichts vor, heutzutage sind ja nun mehr 8 GB RAM Standard. Tendenz weiter steigend. Man muss schon ein außergewöhnliches Kunststück vollbringen, um mit einem Desktop-PC hier an die Grenzen zu stoßen. Hält man das System hingegen sogar schlank und minimal, lässt sich auch mit weit weniger RAM eine Linuxdistribution komplett in den RAM kopieren und darin dann ausführen. Und mal ehrlich, welchen Grund außer Nostalgie könnte es geben, dass Anwendungen nicht mit Lichtgeschwindigkeit starten sollten?
In der Vergangenheit habe ich mir einige Linuxe angeschaut, die sich zur Hauptaufgabe gemacht haben, ein Betriebssystem für den RAM zu entwickeln. Darunter waren Slitaz, Puppy Linux, auch ArchBang bietet einen RAM-Modus an und nicht zu vergessen das winzige TinyCore.
Im Grunde genommen lässt sich jede Linuxdistribution zum RAM-Linux umrüsten. Der Unterschied besteht hauptsächlich darin, wie viel Arbeitsspeicher vorausgesetzt wird und wie einfach oder schwer es gemacht wird das System an die eigenen Vorstellungen anzupassen. Gut gefallen hat mir das einfache Konzept von Slitaz, wo man dem im RAM laufenden Linux Anwendungen hinzufügen oder entfernen kann und mit dem sich das fertige Ergebnis sofort wieder zu einer neuen ISO-Datei zusammenstellen lässt.

TinyCore auf einem USB-Stick

Um den Horizont zu erweitern versuche ich mich derzeit an TinyCore Linux, welches den Thinkpad 600 und vielleicht später sogar den Toshiba Portégé 3110CT komplett als RAM-Distribution antreiben soll. Ähnlich wie bei Slitaz bietet TinyCore einen eigenen Installer, der das Image auf den USB-Stick schreibt und diesen zugleich bootfähig macht.
Die Dokumentation dazu ist meiner Meinung nach etwas inkonsistent. Gleichzeitig ist die Installation auf den USB-Stick aber ziemlich einfach. Ansehen sollte man sich die Installationsanleitung, das Quick&Easy Overview und auch das TinyCore-Wiki.

    1. Zuerst habe ich mir das MultiCore Image heruntergeladen, auf dem sich die zusätzlichen Programme zum Installieren befinden.
    2. Anschließend wurde die ISO-Datei in Virtualbox als CD-Laufwerk in einer virtuellen Maschine gemountet und von dort die MultiCore-Version gestartet. Natürlich habt ihr auch die Möglichkeit das Abbild auf CD zu brennen.

  1. Auf dem Desktop angekommen, startet ihr den TC-Installer (zweites Icon von rechts auf dem Screenshot).
  2. Wählt die Datei tinycore.gz aus, die sich im Boot-Verzeichnis der gemounteten ISO-Datei befindet. (hier Laufwerk sr0) und selektiert alles so wie auf dem Screenshot. Mein USB-Stick wurde an die virtuelle Maschine als Laufwerk sdb durchgereicht. Anschließend wird eine „Frugal“-Installation durchgeführt und der Inhalt des gesamten USB-Sticks überschrieben.
  3. Die folgenden Installationsschritte können wie in der Voreinstellung beibehalten werden. Lediglich als Dateisystem sollte ext2 gewählt werden, um zusätzliche Schreibvorgänge auf den USB-Stick zu vermeiden, die bei Journaling-Dateisystemen wie z.B. ext3 und ext4 auftreten.

Nach einer weiteren Bestätigung wird daraufhin TinyCore auf den USB-Stick geschrieben. Mit Hilfe des ausgezeichneten Plop Bootmanagers lässt sich dann mit dem Thinkpad 600 TinyCore von USB starten.

Probleme und To-Do

Mit TinyCore auf USB bootet der Thinkpad 600 ohne Probleme. Problematisch ist aber der verwendete XVesa-Treiber, der zwar die Auflösung mit 1024×768 korrekt einrichtet, die Darstellung jedoch grünlich verzerrt, so dass sich praktisch nichts erkennen lässt. Ich muss hier in Zukunft einen Weg finden, um XVesa in Einklang mit meiner MagicGraph-Grafikkarte zu bringen oder TinyCore mit dem X-Server von Xorg zu remastern. Da ich sowieso zusätzliche Erweiterungen installieren möchte, komme ich um das Remastern nicht herum.
TinyCore auf einen USB-Stick zu installieren war einfach. Die Konfiguration kann aber unter Umständen länger dauern.

Alpine: Konfiguration für Fortgeschrittene

Das Konsolensetup auf dem Thinkpad 600 ist bereit. Zeit um etwas Butter bei die Fische zu geben. Debian Squeeze ist installiert und die üblichen ohne-X Verdächtigen laufen einträchtig in Screen und manchmal zusätzlich noch in FbTerm.

Das alles war eine gute Gelegenheit um einmal zu testen, ob ich mit meinen eigenen Anleitungen auch noch nach einem Jahr etwas anfangen kann. Ich konfigurierte mein Text-E-Mail Programm Alpine genau nach den Vorgaben und richtete mir zwei POP3 und einen IMAP Account ein, wobei es mir bei letzterem genügte Mails zu lesen und in den IMAP-Ordner von einem anderen Konto aus zu speichern.
Für den ersten Start reichen die alten Einstellungen vollkommen aus. Bei Alpine hilft es aber noch folgende Ideen im Hinterkopf zu behalten. Die folgenden Optionen lassen sich sowohl innerhalb von Alpine unter Setup->Config ändern als auch in der versteckten Konfigurationsdatei .pinerc im Homeverzeichnis.

  1. Bestätigungsnachfrage beim Wechsel in ein Postfach abschalten
    Auf die Dauer zeitraubend kann die ewige Nachfragerei von Alpine sein, ob man tatsächlich das POP-Postfach öffnen möchte. Diese Nachfrage lässt sich wie folgt deaktivieren:

    folder-reopen-rule=yes-ask-y
    Yes for POP/NNTP, Ask for other remote yes
    
  2. Die Felder zum Verfassen der E-Mail bearbeiten
    Ich benötigte noch BCC und das FROM-Feld. Damit lässt sich der Absender schnell ändern, wenn man eine E-Mail verfasst. Eine flexiblere Möglichkeit bieten Regeln.

    default-composer-hdrs=From,
    	To,
    	CC,
    	Bcc,
    	Attchmnt,
    	Subject
    
  3. Externe Programme definieren
    Als externen Editor bevorzuge ich Vim, als Rechtschreibprüfung aspell.

    editor=vim
    speller=aspell
    
  4. Ort des lokalen Mailordners ändern
    Mich störte ein wenig, dass der Ordner Mail in meinem Homeverzeichnis angelegt wurde. Um ihn an einen anderen Ort zu bringen oder zu verstecken, ist diese Option da:

    folder-collection=mail .mail/[]
    

    Das /[] darf am Ende des neuen Namens nicht fehlen. Der Name mail wird so innerhalb von Alpine dargestellt.

  5. Auf alle IMAP-Ordner von Google Mail zugreifen
    Mit den sogenannten Collection Lists, lassen sich auch entfernte IMAP-Ordner anzeigen. Um dies bei Google Mail zu erreichen, geht man so vor.
    Setup->Collection List->Add

    Nickname: Google Mail IMAP
    Server: imap.googlemail.com/user=DeinBenutzername/ssl
    Path: [Google Mail]
    View:
    

    Mit CTRL+X wird dieser Eintrag abgespeichert. Anschließend befindet sich unter Folder List der IMAP-Ordner von Google Mail, in dem sich wiederum alle entfernten IMAP-Ordner befinden.

Mit Hilfe von Regeln lassen sich wesentlich feinere Einstellungen treffen. Zum Beispiel können so Filter definiert werden, mit denen festgelegt wird, wohin E-Mails verschoben werden oder, wie am Anfang schon erwähnt, die FROM-Adresse an Regeln angepasst werden. Unter Setup->Rules geht es zu den Regeln.
Mein Benutzerszenario sieht so aus. Ich rufe meine beiden POP3-Accounts ab, wobei standardmäßig die E-Mails auf dem Server belassen werden. Genauso möchte ich es auch haben, da ich unterwegs auf dem Laptop nur die Mails lesen will und auf den anderen Rechnern zu Hause dann die Filter laufen lasse. Die E-Mails werden über den Smtp-Server eines POP3-Anbieters verschickt. Das IMAP-Konto dient als Zwischenspeicher und Zugriff auf alte E-Mails. Mails lassen sich mit ; selektieren und mit S abspeichern. Den entsprechenden Ordner wählt man dann manuell mit CTRL+T aus.
Insbesondere die Regeln sind bei Alpine für weitere Kontrolle empfehlenswert. Für meine bescheidenen Ansprüche brauche ich sie zur Zeit aber nicht. Wer mehr darüber lesen möchte, sollte sich auch die offizielle Dokumentation der Alpine Entwickler anschauen.
Ebenfalls möglich ist das Versenden von E-Mails über eine verschlüsselte Verbindung. Am schnellsten lässt sich das unter Setup->Config einstellen. Die Smtp-Variable wird in der für Alpine üblichen Form angepasst. Z.B.

smtp.googlemail.com/tls/user=DeinBenutzername

Thinkpad 600 und Lubuntu 11.10: Ein Nachtrag

Es war nicht ganz einfach Lubuntu 11.10 auf dem Thinkpad 600 zum Laufen zu bekommen. Wie zuvor schon erwähnt, musste ich mir einige Male die Haare raufen. Ich benutzte die alternative i386 Lubuntu-CD und hatte eigentlich keine großen Komplikationen erwartet. Leider stellte sich später heraus, dass eine normale alternative Installation zu keinem Erfolg führte. Entweder brach die Installation beim Installieren des Basissystems ab oder das System fror schon vorher mit einer Kernel Panic einfach ein.
Daraufhin überprüfte ich die CD mit Lubuntus eingebauter Testfunktion. Doch die CD war in Ordnung. Auch das Deaktivieren von ACPI oder APIC im F6-Menü brachte keinen Erfolg…bis ich die Experten-Installation wählte. Hiermit hat man eine noch viel feinkörnigere Kontrolle über den Installationsvorgang, der in diesem Modus scheinbar auch weniger RAM benötigt. Zur absoluten Sicherheit blieb ich auch bei Englisch als Systemsprache und sparte mir dadurch ebenfalls noch etwas Arbeitsspeicher.
Es dauerte danach mehr als zwei Stunden bis ich mit der Installation durch war und schließlich in Lubuntu 11.10 bootete. Wie zu erwarten war, sind 128 MB RAM und ein PII Prozessor die Untergrenze für diese Linuxdistribution. Das System funktioniert zwar, aber um wirklich flüssig damit arbeiten zu können, müsste man diverse Anpassungen vornehmen oder eine Schippe RAM drauflegen. Schon nach dem Login war der Arbeitsspeicher ausgereizt und Daten wurden auf die SWAP Partition ausgelagert.

Ich bleibe dabei, dass die anderen bisher auf dem Thinkpad 600 installierten Distributionen Debian, ConnochaetOS und Slitaz die bessere Alternative auf dem Modell sind.

Slitaz und der Thinkpad 600 kurz und knapp

Keine Angst ich werde nun nicht jeden zweiten Tag (sagen wir jeden dritten) eine andere Distribution vorstellen, die sich auf dem Thinkpad 600 installieren lässt. Ich muss auch gar nicht mehr so ins Detail gehen, denn im Prinzip haben schon Debian und ConnochaetOS gezeigt, dass es ohne viel Aufwand möglich ist den Thinkpad 600 in Betrieb zu nehmen.
Für Slitaz interessiere ich mich nun schon seit einem Jahr und die kleine Linuxdistribution macht wirklich Spaß. Damit ich noch in einem Jahr weiß, was ich beachten muss, hier eine kurze Liste.

Vorbereitung

Alles begann wieder mit dem Download der Slitaz-LoRAM-Version, die lediglich 80 MB RAM voraussetzt. Um keine CD unnötig zu verbrennen und meinem alten 128 MB USB-Stick noch eine sinnvolle Rolle zukommen zu lassen, habe ich die ISO-Datei mit Hilfe von Tazusb wieder auf den Stick geschrieben. Mit Hilfe von Plop ging es dann in eine Liveumgebung.

Installation

Slitaz benutzt hier und auch nach der Installation den generischen VESA-Treiber, so dass die Auflösung noch nicht optimal ist. Das System lässt sich aber bedienen und man kann auf die Konsole oder in den Terminalemulator wechseln.
Bei meinem Setup (/dev/sda1 = Swap, /dev/sda2 = Debian und /dev/sda3 = Slitaz) und nur 128 MB RAM sollte man am besten die Swap-Partition vor der Installation von Slitaz aktivieren.

swapon /dev/sda1

Die Slitaz-Installation lässt sich wie gehabt mit slitaz-installer starten. Die Root-Partition ist dann natürlich /dev/sda3. Soweit so gut, die Installation ist wirklich unkompliziert und die Fragen des Installers sind leicht beantwortet. Sollte es eine Fehlermeldung wie „rootfs“ nicht gefunden geben, hilft eventuell dieser Beitrag weiter.
Nach dem Reboot sollte als erstes die Grafikkarte mit dem richtigen Treiber angesprochen werden. Neomagic ist hier das Zauberwort. Das entsprechende Paket bei Slitaz heißt xorg-xf86-video-neomagic. Anschließend muss noch in der /etc/X11/xorg.conf in der „Driver“-Zeile vesa durch neomagic ersetzt werden. Fertig.
Nach einem Neustart sind die grafischen Beschränkungen des Vesa-Treibers aufgehoben und man kann sich auf die volle 1024×768 Pixel Auflösung stürzen. 😉

Sound

Ganz so einfach wie bei Debian und ConnochaetOS war es mit dem Einrichten der Soundkarte nicht. Erneut muss man wieder etwas alte ISA-Magie und Modprobe-Zauberei anwenden.
Nachdem ich mir die entsprechende Zeile ergoogelt hatte, trug ich alles in /etc/init.d/local.sh ein.

modprobe snd-cs4236 port=0x530 cport=0x538 irq=5 isapnp=0 dma1=1 dma2=0

Slitaz Hauptkonfigurationsdatei

In /etc/rcS.conf landen viele wichtige Slitazeinstellungen. Um die neue ASUS WL-107G WLAN-Karte nach jedem Reboot automatisch in Betrieb zu nehmen, genügt es das entsprechende Modul in der „LOAD_MODULES“-Zeile einzutragen.

LOAD_MODULES=“ yenta_socket rt2500_pci

Fazit

Slitaz Installationsschritte sind potentiell einfacher. Dafür richtet Slitaz weder die Neomagic-Grafikkarte noch die urtümliche ISA-Soundkarte automatisch ein. Etwas Nachhilfe ist erforderlich. Absolut umwerfend ist aber der geringe Verbrauch an Festplattenspeicher für all die Programme, die standardmäßig bei Slitaz installiert werden (<150MB). Immer dort, wo Festplattenspeicher noch eine Rolle spielt, spielt Slitaz seine Stärken aus. Genauso wie bei ConnochaetOS ist die Auswahl an vorkompilierten Paketen begrenzt, aber zum Anfang vermisst man die wichtigsten Programme auch nicht. Halten wir mal fest: Debian, ConnochaetOS, Slitaz auf dem Thinkpad 600 versus Müllgrube irgendwo in Afrika: 3:0