Softwarepakete konvertieren mit alien oder tazpkg

Ein Problem bei kleineren Distributionen ist häufig, dass sie aus Zeit- und Ressourcengründen nicht genauso viele Binärpakete wie größere Distributionen anbieten können. Neue Pakete mit Hilfe der distributionseigenen Werkzeuge zu kompilieren, ist die gängigste Methode um den Softwareumfang zu vergrößern.
Möchte man sich nicht erst in die eher fortgeschrittene Thematik einarbeiten, gibt es zumindest bei Debian und Slitaz eine Alternativmethode. Irgendwann kam jemand auf die Idee, dass es bei manchen Paketen nur notwendig ist die Struktur der integrierten Dateien anzupassen und das Paket einer fremden Distribution in das eigene Format umzuwandeln.
Ich wollte unbedingt mein favorisiertes Musikprogramm cmus auch mit Slitaz benutzen, weswegen ich mir die neueste Version aus Debian Sid heruntergeladen habe und mit Hilfe von tazpkg das Paket dann umgewandelt habe. Der Weg ist schnell erklärt.

  1. Cmus als .deb Paket manuell oder mit apt herunterladen
  2. tazpkg convert "Paketname"

Das war es auch schon. Danach beginnt der Paketmanager das Paket in das Slitaz-Format umzuwandeln. Man sollte zumindest eine einigermaßen schnelle Kiste besitzen. Der Thinkpad 600 ist dafür ausreichend, bei einem Toshiba Satellite 220cs mit nur 16 MB RAM kann sich der Vorgang auch schon mal ein paar Stunden hinziehen. 🙄

Debian und Aliens

Debian hat für diese Art von Aufgabe ein vergleichbares Programm namens alien, mit dem sich z.B. Slackware- oder RPM-Pakete in das Deb-Format überführen lassen.

alien --to-deb /Pfad/zu/meinem/Paket.rpm

Die Methode muss nicht zwangsläufig bei jedem Paket funktionieren. Bei kleineren hatte ich aber bisher immer Erfolg. Die "saubere" Methode bleibt auch weiterhin ein Stück Software direkt aus den Quellen zu kompilieren. Aus diesem Grund gibt es ein solches Werkzeug bei Arch Linux erst gar nicht.

Partimage: Simple Backupmethode auch für ältere Rechner

Der neue Thinkpad 600 besitzt "nur" 128 MB RAM, womit die bequemste Backupmethode mit Clonezilla auf diesem Gerät für mich entfällt und ich eine Kernelpanic erhalte. Falls es doch jemand schon mit dieser begrenzten RAM-Zahl geschafft haben sollte, würde ich gerne wissen wie. 😉
Alles kein Problem, denn man kann natürlich auch direkt auf die Werkzeuge zugreifen, die Clonezilla unter einer ausgefeilten Oberfläche zum Einsatz bringt. Ich habe mich für Partimage entschieden, welches ich von der Debian-Squeeze-Installation aus benutze, um parallel installierte Distributionen zu sichern. Die Bedienung ist simpel. Zuerst wird die Partition für das Backup ausgewählt (in meinem Fall sda3) und dann in eine Image Datei geschrieben.
Der Zielpfad liegt bei meinem eingehängten USB-Stick in /media/data/. Mit F5 geht es danach zur nächsten Seite, wo man auswählen kann, ob man mit oder ohne Kompression sein Backup sichern möchte.



Viel mehr gibt es auch nicht zu sagen. Sowohl das Backup als auch die Rücksicherung funktionierten bisher immer einwandfrei. Je nach Größe des Abbilds dauert es auf dem alten Laptop mit USB 1.0 zwischen 5 und 20 Minuten ein Backup zu sichern.

Surfraw: Eine gottgefällige Erweiterung zur Shell

Ungläubige brauchen erst gar nicht weiterzulesen, hier kommt Surfraw!

Was die Schöpfer über ihr Programm sagen

Surfraw - Shell Users' Revolutionary Front Rage Against the World Wide Web
Surfraw bietet eine schnelle Unix-Kommandozeile zum Zugriff auf eine Vielzahl von beliebten WWW Suchmaschinen und andere mächtige Werkzeuge. Es holt google, altavista, dejanews, freshmeat, research index, slashdot und viele andere aus dem pockeninfizierten Reich des falschen Propheten der HTML-Formulare zurück und platziert diese Wunder dort, wo sie hingehören: tief in das Herz von Unix, als gottgefällige Erweiterungen zur Shell.

Surfraw ist eine Anwendung, die ich nicht mit vielen Screenshots präsentieren kann, die mir aber seit ihrer Entdeckung jeden Tag besser gefällt. Abgesehen vom ausgeprägten Humor der Entwickler hat diese in Bash programmierte Schnittstelle ins World Wide Web einiges zu bieten.

Installation

aptitude install -R surfraw

Der -R Schalter ist sinnvoll, damit das zusätzliche Paket surfraw-extra nicht automatisch mitinstalliert wird. Die im Paket surfraw angebotenen elvis reichen in der Regel vollkommen aus.

Wie es funktioniert

Was sind elvis? Der Name elvi ist eine Eigenkreation der Macher und lässt sich wohl auf einen Fan von Elvis Presley unter ihnen zurückführen. Im Prinzip steht elvi nur als Oberbegriff für die verschiedenen Suchmaschinen, die surfraw ansprechen kann. Eine Übersicht liefert:

surfraw -elvi

Möchte man z.B. direkt vom Terminal aus nach einem Youtube-Video des omnipräsenten (zumindest für amerikanische Youtube-Nutzer) Justin Bieber suchen genügt ein

surfraw youtube Justin Bieber

oder kürzer

sr youtube Justin Bieber

Noch besser wäre es auf das vorangestellte surfraw oder sr ganz zu verzichten, indem die elvis in den $PATH des Benutzers installiert werden. Das geht mit dem mitgelieferten surfraw-update-path. Als normaler Benutzer einfach folgendes ausführen

surfraw-update-path -add

Danach scheint die Suche nach Youtube-Videos im Terminal das Natürlichste auf der Welt zu sein.

youtube Justin Bieber

Surfraw verwendet den voreingestellten Browser zum Öffnen der Suchergebnisse. Je nach dem ob ich mich in einer grafischen oder rein konsolenbasierten Umgebung aufhalte, startet entweder Iceweasel, Midori oder elinks. Dieses Verhalten lässt sich global für alle Benutzer eines Systems überschreiben oder separat für jeden einzelnen festlegen.
Neben Youtube benutze ich Google, Ixquick, Duckduckgo und Wikipedia am häufigsten. Hat man das Terminal sowieso immer offen, bietet surfraw eine schnelle Möglichkeit eine Suche zu starten, ohne dabei zuerst den Browser zu öffnen und den Begriff in ein Suchfeld eingeben zu müssen. Insbesondere kann ich mir damit auch die Suche mit einem Smart Prefix in elinks ersparen, um Youtube Videos mit Hilfe von youtube-dl und mplayer abspielen zu können. 😉
Übrigens der Schöpfer von Surfraw war ein gewisser Julian Assange.

Die kleinen Dinge des Lebens

Das hier fällt vielleicht so ein bisschen unter Linuxtipps für Anfänger, dennoch stoße ich immer noch auf einige Kniffe, die ich nicht gekannt, nie gebraucht und nach denen ich zuerst auch nicht gesucht habe. Aber wie heißt es so schön: Wer suchet der findet.
Jeder kennt die praktische Fähigkeit einer guten Linux-Shell Befehle und Ausdrücke mit der TAB Taste zu vervollständigen. Außerdem möchte man sicher nicht die "History" Funktion vermissen. Mit den Pfeiltasten für hoch und runter, lassen sich die zuletzt eingetippten Kommandos wieder hervorholen.
Doch erst wenn man komplett auf grafische Werkzeuge beginnt zu verzichten und Kommandos im Terminal zu Dutzenden tippt, wird das Verlangen nach einer Suchfunktion immer größer.

Das gibt es natürlich schon lange für die Bash. Führt man die Tastenkombination STRG+R im Terminal aus, erscheint (reverse-i-search):
Nun genügt es die Anfangsbuchstaben des gesuchten Kommandos einzugeben und mit der Zeichenkette ssh erscheint dann der ssh oder sshfs Befehl, den man vor 100 Zeilen mal eingetippt hatte. Drückt man erneut STRG+R erscheinen weitere Befehle, auf die das eingegebene Muster passt. Mit der Enter Taste lässt sich das gefundene Kommando ausführen und mit ESC gelang man zur alten Eingabeaufforderung zurück. Wirklich simpel und äußerst nützlich.

Auch praktisch sind STRG+K, womit alles vom Cursor aus bis zum Ende der Zeile gelöscht wird oder STRG+U, womit alles in entgegengesetzter Richtung gelöscht wird. Mit STRG+A springt man zum Anfang und mit STRG+E zum Ende der Zeile und mit STRG+W werden einzelne Worte nach links gelöscht. Als Otto-Normal-Linuxbenutzer braucht man das meiste davon aber oft sowieso nicht. Doch wenn man erst einmal damit angefangen hat, möchte man es nicht mehr missen.

Apropos, mit Openbox wechsele ich mit STRG+ALT+Pfeiltaste links/rechts zwischen Arbeitsflächen hin und her. Das geht übrigens auch mit den schnöden TTY-Terminals. Mit STRG+ALT+F2 geht es auf die Konsole tty2 und mit ALT+Pfeiltaste links/rechts kann man ganz bequem und schnell, wie in einer grafischen Desktopumgebung, zwischen den Terminals wechseln.
Keine großen Neuigkeiten, aber die kleinen Dinge des Lebens machen es oft angenehm. 😉

cal: Ein Kalender für die Konsole

Mir ist aufgefallen, dass ich einige Programme, die standardmäßig bei Debian installiert sind oder als Standard gelten, selten bis gar nicht benutze. In den meisten Fällen brauche ich sie einfach nicht oder es gibt andere oder sogar bessere Alternativen.
Vielleicht könnte man dennoch eine Serie daraus machen und alten Stars wieder zu neuer Popularität verhelfen oder zumindest mehr über sie lernen. 😉

Cal

Cal befindet sich bei Debian im Paket bsdmainutils und ist scheinbar schon etwas angegraut. Das Paket enthält noch weitere Programme, die bei einem BSD ähnlichen Unix-System Standard sind.
Wirklich problematisch war die Datumssuche ja noch nie. In jeder Desktopumgebung gibt es ein Kalenderapplet, durch moderne Browser ist die Information nur einen Suchbegriff entfernt und mancher bekommt von seiner Apotheke heutzutage immer noch diese farbigen Kalender mit dem zum Monat passenden Spruch geschenkt.
Doch wer ein Linuxsystem sein eigen nennt hat cal und damit immer den perfekten Überblick in sekundenschnelle.

Schon gewusst? Weihnachten und Neujahr sind im Jahr 2200 an einem Mittwoch.

cal 2200

Wie sieht es dieses Jahr mit den Tagen im Dezember aus?

cal -m 12

Für eine alternative Darstellung gibt es auch ncal
Wann ist Ostern 2012? Antwort: Am 08. April 2012

ncal -e 2012

Ein Jahreskalender mit den Nummern der Woche

ncal 2012 -w

Und schließlich der vorangegangene Monat, der jetzige und zukünftige ausgegeben in einer Reihe

cal -3

Also nicht verzweifeln. Die Information ist eine Konsole entfernt. 😉

Debian-Derivate sauber und minimal halten

Jedes auf Debian basierende System lässt sich mit dem Paketmanager apt spielend leicht an die eigenen Bedürfnisse anpassen. In der Regel reicht täglich ein

aptitude update
aptitude safe-upgrade

um das System auf dem aktuellen Stand zu halten. Gerade wenn man aber regelmäßig Anwendungen auf einem sich häufig ändernden Debian Unstable oder Testing installiert oder deinstalliert, können mit der Zeit ein paar verwaiste Bibliotheken zurückbleiben, die keinem Programm mehr zugeordnet werden können.
Um Platz zu schaffen oder seine Installation einfach nur sauber zu halten, gibt es für dieses Problem zwei Debianprogramme.

  1. deborphan
  2. debfoster

Deborphan bringt das textbasierte Programm orphaner mit, welches als Supernutzer Root ausgeführt werden kann. Orphaner findet alle verwaisten Bibliotheken, die sich mit einem Druck auf die Space-Taste zum Deinstallieren auswählen lassen.
Debfoster hingegen führt man am besten einmal nach einer Minimalinstallation mit Debian aus und wählt alle dann installierten Pakete als erwünscht aus. Kommen später neue Pakete dazu und wird debfoster erneut aufgerufen, werden die vorher bestätigten Pakete nicht noch einmal zur Auswahl gestellt und man muss sich nur noch entscheiden, ob man die neuen behalten oder deinstallieren möchte.
Beide Programme interagieren im Prinzip nur mit apt und vereinfachen die Suche nach bestimmten Paketen und das Löschen derselben.

Empfohlene Pakete nicht mitinstallieren

Seit Squeeze werden empfohlene Pakete automatisch bei der Auswahl eines Pakets mitinstalliert. In der Regel hat das keine Nachteile, sondern ist einfach ein sinnvoller Bequemlichkeitsfaktor. Anstatt sich darum zu kümmern, welche weiteren Programme im Zusammenhang mit Paket X noch sinnvoll sind, nimmt apt einem diese Aufgabe einfach ab.
Manchmal möchte man aber tatsächlich selbst bestimmen, welches Paket wirklich gebraucht wird und auf einem absoluten Minimalsystem ist es deswegen oft besser das automatische Installieren der empfohlenen Pakete zu deaktivieren.
Dazu muss folgende Zeile in der /etc/apt/apt.conf nachgetragen werden.

APT::Install-Recommends "false";

Möchte man lieber von Paket zu Paket entscheiden, ob man empfohlene Pakete mitinstallieren möchte, geht das am einfachsten mit der Option -R, z.B.
aptitude -R install surfraw
Hier wird zwar das Paket surfraw installiert, das empfohlene und mehrere Megabyte große surfraw-extra aber nicht. Natürlich lässt sich der Schuh auch anders herum aufziehen. Man kann standardmäßig das Installieren empfohlener Pakete in der apt.conf deaktivieren und dann wieder je nach Paket entscheiden

aptitude -r install surfraw

Man beachte hier nun das kleine r. Übrigens lässt sich als normaler Benutzer das Installieren und Deinstallieren von Paketen simulieren. Hierzu gibt es den Schalter -s, z.B.

aptitude -r -s install surfraw

Ein paar Tipps zum Leben auf der Konsole

Ich wurde vor kurzem gebeten ein paar Tipps zum Thema "Leben auf der Konsole" zu schreiben. Das ist gar nicht so einfach, denn mit der Kategorie versuche ich gleich mehrere Themen unterzubringen, ein Ziel, was ich mir Anfang des Jahres vorgenommen habe.
Zum einen ist es eine Möglichkeit Konsolenanwendungen, die ohne grafische Oberfläche auskommen oder nur auf ncurses basieren, auszuprobieren und dann hier darüber zu schreiben. Für einen wirklich alten Rechner sind solche Programme eine Notwendigkeit, viele davon benutze ich aber auch täglich auf den leistungsfähigeren Rechnern, weil ich sie für eine bestimmte Aufgabe schlicht für das beste Programm halte. Auf der anderen Seite soll "Leben auf der Konsole" auch zeigen, dass man mit einigen wenigen Kommandos ein bestimmtes Problem lösen kann und das praktisch auf jeder Art von Hardware auf der eine Linuxdistribution läuft. Kurz zusammengefasst landet in dieser Kategorie alles, was ich überwiegend in einem Terminalemulator oder direkt in der Konsole ausführe.
Hier einmal sechs allgemeine Punkte, die vielleicht am Anfang nützlich sind.

  1. Bücher. Als ich im Jahr 2001 mit Linux angefangen habe, war mir weder genau klar, welche Linuxdistribution ich verwenden sollte, noch wie ich am effektivsten an Informationen komme. Mir wurde damals als Einstieg Michael Koflers Buch "Linux. Installation, Konfiguration, Anwendung." empfohlen, was in der 6. Auflage noch heute in meinem Bücherregal steht. Ich kann es als Überblick über wichtige Linuxthemen und für die ersten Schritte mit Linux allgemein und auf der Konsole heute noch empfehlen. Am besten ihr schaut z.B. bei ebay nach einer aktuellen und kostengünstigen Version vorbei.
  2. Wikis. Heutzutage ist es nicht mehr weiter schwer an Wissen zu Linux zu gelangen. Man muss sich nur etwas Zeit nehmen und das Wiki bei ubuntuusers.de oder archlinux.org bzw. archlinux.de durchstöbern. Garantiert hat man danach sein Wissen über Linux vervielfacht.
  3. Blogs. Mein Interesse speziell für ältere Laptops kommt daher, dass ich mir 2008 einen Dell Inspiron 4000 gekauft habe und darauf zuerst Gnome und später Xfce ausprobiert habe. Mit Debian Etch war Xfce damals noch als Desktopumgebung in Ordnung, stellte mich aber später auf diesem Modell nicht mehr vollständig zufrieden. 2009 begann ich mich deshalb nach Alternativen umzuschauen und stieß auf Urukramas Weblog, wo ich viele neue Ideen zu Fenstermanagern und speziell zu Openbox fand. Dort erfuhr ich auch zum ersten Mal von K.Mandlas Blog.
    K.Mandla hat seit 2006 über 2000 Blogartikel zum Thema Linux auf älteren Rechnern geschrieben. Sein Blog ist eine echte Fundgrube, wenn es um Ideen zu Leichtgewichtigen Linuxdistributionen, Software und speziell älteren Rechnern geht. Dabei hat er auch über eine längere Zeit ein reines Konsolensetup auf seinen ältesten Laptops vorgestellt. Viele seiner Tipps habe ich schon ausprobiert, doch es gibt immer noch Neues zu entdecken. In vielen seiner Gedanken finde ich mich auf der gleichen Wellenlänge wieder. Kurzum ist es das Blog, was ich nicht nur wegen dem Fokus auf ältere Hardware, sondern auch wegen den wertvollen Informationen zu Linux im Allgemeinen jedem empfehlen kann, der sein Linuxsystem an die eigenen Vorstellungen anpassen möchte.
    Ich versuche mit manchen Blogartikeln, die Posts aus dem Englischen ins Deutsche zu bringen, die mich am meisten interessiert haben. Meine Laptops und Schwerpunkte unterscheiden sich dabei natürlich. Im Prinzip könnte ich jeden Tag einen Post zu einer bestimmten Konsolenanwendung schreiben, es ist aber besser, wenn man erst einmal schon auf bestehendes Wissen zurückgreift.
    Leider kenne ich kein deutsches Blog, welches den gleichen Fokus und auch die Qualität wie das von K.Mandla hat. Möglicherweise bin ich aber auch einfach nur ignorant. Wenn also jemand ein deutschsprachiges Blog kennt, welches die gleichen Themen abdeckt, dürft ihr mich gerne in den Kommentaren darauf stoßen.
  4. Leichtgewichtige Anwendungen. Unter diesem Schlagwort findet man im Internet tonnenweise Informationen. Leichtgewichtig wird heutzutage schon beinahe inflationär genutzt. Nicht jedes Programm ist wirklich so genügsam und gleichzeitig flexibel. Das erfährt man aber erst, wenn man den Realitätscheck auf einem älteren Computer macht. Wenn man auf der Suche nach leichtgewichtigen Programmen ist sollte man auf jeden Fall diesen Seiten einen Besuch abstatten.Gunnix
    K.Mandlas Software Seite
    K.Mandlas Wiki
    Archlinux Wiki Lightweight Apps
    Übersicht zu Konsolenprogrammen und ihren grafischen Entsprechungen
  5. Übung macht den Meister. Am besten ist es, man schnappt sich einen alten Computer/Laptop, den es bei ebay teilweise für wenig Geld gibt und versucht alle Anwendungen, die man auf seinem leistungsfähigen Computer nutzt in Konsolenanwendungen zu übersetzen. Das Ziel ist es den älteren Rechner genauso zu nutzen als sei er ein brandneues Modell. Als Distributionen kann ich Debian, Arch Linux oder Slitaz empfehlen und die vielen anderen leichtgewichtigen, die ich in der Kategorie Distributionen schon vorgestellt habe. Wer sich nicht extra einen neuen Rechner zulegen möchte, kann natürlich auch mit einer Virtuellen Maschine experimentieren, der z.B. nur 128 MB RAM oder weniger zugewiesen wurde. Natürlich wäre ein Multiboot-System ebenfalls eine gute Möglichkeit um verschiedene Distributionen oder Setups parallel auf einem Rechner zu vergleichen.
  6. Geduld. Linux ist sehr vielseitig. Man kann praktisch alles auf der Konsole machen, man muss es aber nicht tun. Niemand kann sich alle Befehle oder Programme merken, die es für Linux gibt. Deshalb hilft oft ein Blick in die Handbuchseite des Programms mit man weiter. Wenn etwas nicht auf Anhieb klappt, sollte man Linux nicht gleich verdammen, sondern schauen, ob es vielleicht ein Hardwareproblem, das falsche Programm oder schlicht falsche Handhabung ist. Wenn man sich genug Zeit nimmt, lösen sich viele Probleme oft von selbst.

Ich hoffe, ich konnte ein paar Denkanstöße geben.

Den Speicherverbrauch im Blick behalten mit ps_mem.py

Um den Speicherverbrauch von Anwendungen zu messen, gibt es in Debian diverse Programme, die über den belegten Arbeitsspeicher Aufschluss geben. Teilweise wird man aber nicht richtig schlau daraus, wieviel Speicher ein Programm tatsächlich für sich allein beansprucht.
Mit htop erhält man z.B. gleich drei unterschiedliche Werte in kb VIRT, RES und SHR.
VIRT gibt dabei den virtuellen Speicherverbrauch an, welcher eine Summe aus tatsächlich belegtem und mit anderen Prozessen geteiltem Speicher ist. Zusätzlich kann auch der Inhalt einer Datei mit Hilfe von Memory Mapping direkt in den virtuellen Adressraum eines Prozesses abgebildet werden. Jeder Prozess hat seinen eigenen virtuellen Adressraum und ist dadurch von allen anderen getrennt. Kurz gesagt ist es eine Technik um die Schranken des begrenzten physikalischen Speichers zu umgehen und Prozessen Speicher dynamisch zuzuteilen, so wie er gerade benötigt wird.
Sollten also mehrere Programme die gleiche Bibliothek benötigen wird der Speicher nicht jedesmal extra neu zugeteilt sondern zwischen den Prozessen, die ihn anfordern, geteilt, worüber der Wert SHR genauer Aufschluss gibt.
RES hingegen ist die Kennzahl, die den aktuell physikalisch genutzten Speicher repräsentiert. In den meisten Fällen ist VIRT nicht der Wert, der mich interessiert, wenn ich untersuche, welches Programm gerade das System herunterzieht.
Eine ausführliche Erklärung zum Speichermanagement eines Linuxsystems gibt es im Linux Documentation Project zu lesen.
Mir ist schon beim Vergleich des Speicherverbrauchs von Ubuntu 11.04 und Debian Testing aufgefallen, dass man die Thematik nicht einfach mit dem Gnome-Systemmonitor und ein paar Zahlen erschlagen kann. Der Linuxkernel handelt auch getreu dem Motto: "Ungenutzter Speicher ist verschwendeter Speicher." So ist es auch kein Wunder, wenn sich der belegte physikalische Speicher mit der Zeit nach und nach füllt, weil Linux anfängt nicht nur Programme sondern auch aufgerufene Dateien zu cachen, was einen deutlichen Performancegewinn beschert.

Vor längerer Zeit entdeckte ich bei K.Mandla ein in Python geschriebenes kleines Skript namens ps_mem.py, welches den Speicherverbrauch von Programmen in privaten und geteilten Speicher aufteilt. Prozesse werden nicht getrennt betrachtet sondern eine Summe pro Anwendung gebildet. Klingt vielleicht anfangs verwirrend, aber mir erschien es damals als ob das Skript damit die Antwort auf die Frage liefert, wieviel RAM eine einzelne Anwendung tatsächlich einnimmt.
Um die Genauigkeit der Messergebnisse zu verbessern, lässt sich das Skript nur mit Root-Rechten und dem Befehl python ps_mem.py ausführen. Ich empfehle daher einen kurzen Blick in den Code zu werfen, ob irgendetwas Merkwürdiges dort zu finden ist und es nicht blind zu verwenden. Mir ist bisher noch nichts besonderes aufgefallen.
Ich werde es in Zukunft dazu nutzen, um eine weitere Vergleichsmöglichkeit zu den bekannten Systemmonitoren zu haben. Eines kann man jetzt schon sagen, die Textausgabe des Skripts ist übersichtlich. Die aktuelle Ausgabe auf dem Inspiron 4000 sieht so aus.

Private  +   Shared  =  RAM used	Program
  4.0 KiB +  12.5 KiB =  16.5 KiB	dhclient
  4.0 KiB +  39.0 KiB =  43.0 KiB	dbus-launch
  8.0 KiB +  45.0 KiB =  53.0 KiB	getty (2)
 48.0 KiB +  13.5 KiB =  61.5 KiB	ssh-agent
 52.0 KiB +  12.5 KiB =  64.5 KiB	polipo
 44.0 KiB +  24.0 KiB =  68.0 KiB	init
 40.0 KiB +  32.0 KiB =  72.0 KiB	acpid
  4.0 KiB +  77.5 KiB =  81.5 KiB	sshd
 84.0 KiB +  24.0 KiB = 108.0 KiB	sleep
  4.0 KiB + 105.0 KiB = 109.0 KiB	xfconfd
 76.0 KiB +  36.0 KiB = 112.0 KiB	cron
108.0 KiB +  10.0 KiB = 118.0 KiB	.wallpaper
  8.0 KiB + 110.0 KiB = 118.0 KiB	su
 16.0 KiB + 112.0 KiB = 128.0 KiB	gvfs-gphoto2-volume-monitor
  4.0 KiB + 132.5 KiB = 136.5 KiB	gdm3
 24.0 KiB + 130.0 KiB = 154.0 KiB	gvfs-afc-volume-monitor
  4.0 KiB + 160.0 KiB = 164.0 KiB	polkitd
  4.0 KiB + 171.0 KiB = 175.0 KiB	gvfsd-trash
 48.0 KiB + 128.0 KiB = 176.0 KiB	gvfsd-dnssd
  4.0 KiB + 182.0 KiB = 186.0 KiB	gdm-session-worker
  8.0 KiB + 179.0 KiB = 187.0 KiB	udevd (3)
  4.0 KiB + 189.5 KiB = 193.5 KiB	gdm-simple-slave
148.0 KiB + 115.5 KiB = 263.5 KiB	gvfsd
184.0 KiB +  85.5 KiB = 269.5 KiB	gvfsd-metadata
220.0 KiB +  77.5 KiB = 297.5 KiB	wpa_supplicant
180.0 KiB + 182.5 KiB = 362.5 KiB	gnome-keyring-daemon
 16.0 KiB + 361.0 KiB = 377.0 KiB	gvfsd-network
404.0 KiB +  45.5 KiB = 449.5 KiB	rsyslogd
256.0 KiB + 205.0 KiB = 461.0 KiB	console-kit-daemon
244.0 KiB + 266.0 KiB = 510.0 KiB	gconfd-2
392.0 KiB + 203.0 KiB = 595.0 KiB	upowerd
460.0 KiB + 268.5 KiB = 728.5 KiB	conky
604.0 KiB + 193.0 KiB = 797.0 KiB	gvfs-gdu-volume-monitor
644.0 KiB + 248.5 KiB = 892.5 KiB	udisks-daemon (2)
640.0 KiB + 381.0 KiB =   1.0 MiB	dbus-daemon (2)
524.0 KiB + 613.5 KiB =   1.1 MiB	notification-daemon
436.0 KiB + 796.5 KiB =   1.2 MiB	python2.6
640.0 KiB + 782.5 KiB =   1.4 MiB	bash (3)
  1.1 MiB + 452.5 KiB =   1.5 MiB	tint2
860.0 KiB + 764.5 KiB =   1.6 MiB	xfce4-power-manager
  1.6 MiB + 356.0 KiB =   1.9 MiB	openbox
  2.4 MiB + 274.5 KiB =   2.7 MiB	urxvt
  1.9 MiB +   1.4 MiB =   3.3 MiB	leafpad
  2.0 MiB +   3.2 MiB =   5.2 MiB	osmo
  9.0 MiB + 185.5 KiB =   9.2 MiB	tor
  8.8 MiB + 996.0 KiB =   9.8 MiB	Xorg
  7.7 MiB +   2.5 MiB =  10.3 MiB	claws-mail
 96.9 MiB +   4.5 MiB = 101.4 MiB	midori
---------------------------------
                        159.9 MiB
=================================

Slitaz rootfs in Virtualbox gefunden und erfolgreich transplantiert

"Good news everyone". Nein, ich musste weder eine Lieferung zum Planeten Kannibalia machen noch ist mir ein Rechner um die Ohren geflogen. Die kleine gute Nachricht ist, Virtualbox 4.1 hat nun eine benutzerfreundliche GUI-Option zum Klonen von Virtuellen Maschinen und man ist nicht mehr gezwungen auf der Kommandozeile rumzukrauchen, wenn man das Gleiche erreichen will. Wirklich neu ist diese Meldung nicht, aber mit Debian Testing kann man sich über so etwas ja eben immer zeitversetzt noch einmal freuen. Auch das Schaf als Icon für das Klonen rang mir einen Schmunzler ab. In 100 Jahren wird sicher mal ein Mensch daraus. 😉
Doch nun zu den harten Fakten. Ich habe mir Slitaz Base, das 8 MB kleine Miniimage, geschnappt und eine VM mit einer 1 GB großen virtuellen Festplatte erstellt. Da war ich noch so im alten Trott gefangen, dass ich die Größe mindestens um den Faktor 10 überdimensioniert hatte. Am Ende belegte Slitaz in der Minimalinstalltion nämlich nur 16 MB auf der Platte. Irgendetwas war aber bei der Installation anders als noch vor ein paar Monaten mit Qemu und ich erhielt nach Eingabe von slitaz-installer auf der Konsole die Fehlermeldung

unable to find rootfs.gz

Der Installer wollte mir damit sagen, dass er das als sekundären Master eingehängte slitaz-base.iso nicht als CD-ROM in /media/cdrom finden konnte, von wo aus er alle Daten zur Installation bezog. Der Trick war das schon entpackte Root-Dateisystem in / noch einmal in /media/cdrom als loop device zu mounten.

mount -o loop / /media/cdrom

Danach wurde alles wieder gefunden und die ganze Geschichte ratterte in wenigen Sekunden durch bis schließlich alles auf die zuvor mit fdisk eingerichtete Partition /dev/sda2 installiert worden war und sda1 mir wieder als Swap-Partition dienen sollte. Danach drehte und schraubte ich noch kurz an der ein oder anderen Config-Datei und wandelte schließlich das VDI-Image in ein Raw-Image um, was ich hier schon mal als Gedankenstütze niedergeschrieben habe.
Nun sollte alles wieder auf die Festplatte des Toshiba Satellite 220cs transplantiert werden, wozu ich meinen USB zu IDE Adapter auspackte und die 1,4GB große Festplatte mit dem Hauptrechner verband. Das Operationsbesteck war erneut der wunderbare Disk Destroyer dd.

dd if=slitaz.img of=/dev/sdb

Die Zeile führte nach kopierten 41 MB erst einmal zu einer Input/Output-Fehlermeldung und das bitweise Kopieren brach einfach ab. Erst als ich die Anzahl der Bytes, die auf einmal mit der Option bs gelesen und geschrieben werden vergrößerte, klappte es dann.

dd if=slitaz.img of=/dev/sdb bs=1M

Das war in der Tat seltsam und ich war auch schon kurz davor die Kiste aus dem Fenster zu werfen, konnte mich aber beherrschen und als Belohnung das erfolgreiche Booten in eine superminimale Slitazinstallation beobachten.
Als Fazit bleibt, dass man sowohl ein Image in Qemu als auch in Virtualbox erstellen und nach der ggf. notwendigen Umwandlung in ein Rohformat, dieses auch mit dd auf eine Festplatte schreiben kann. Ein Kinderspiel. 🙂

Webseiten mit elinks in screen über eine SSH-Verbindung mit rxvt-unicode solarisiert betrachten

Die Überschrift sagt schon alles. Ich vermute ein ähnliches Problem dürfte weniger als ein Milliardstel der Weltbevölkerung betreffen, aber aus Spaß hier die kurze Geschichte.
Ich hatte mich per SSH in den Toshiba Portégé 3110CT alias speedy eingeloggt und wollte nun mit Solarized und meinem neuen 256-Farben-Terminal rxvt-unicode das System updaten und überprüfen, ob mein Blog in elinks irgendwie anders als zuvor aussah. Wenn ich mich remote zu meinem mit Debian Stable betriebenen Laptop verbinde, starte ich danach für gewöhnlich screen, womit es mir leichter fällt mehrere Anwendungen parallel wie mit einem grafischen Fenstermanager zu nutzen.
Als erstes erhielt ich die Fehlermeldung

Error opening terminal: rxvt-unicode

als ich versuchte eine Anwendung wie htop zu starten. Das Problem resultiert daraus, dass das System den Terminal rxvt-unicode-256color nicht kennt und deshalb auch nicht weiß, wie es das aufgerufene Programm darstellen soll. Da das scheinbar ein uraltes Problem ist konnte ich sowohl im englischen Gentoo als auch im deutschen Arch Linux Wiki eine Lösung hierzu finden. Kurz gesagt, muss die Terminfo Datenbank auf den aktuellen Stand gebracht werden und eine Infodatei im versteckten Ordner .terminfo im Home-Verzeichnis des Benutzers auf dem entfernten Rechner angelegt werden.
Im Gentoo-Wiki wird das elegant so gelöst:

infocmp rxvt-unicode | ssh USER@REMOTE_IP 'mkdir -p .terminfo && cat >/tmp/ti && tic /tmp/ti'

Auf dem lokalen Rechner werden die Informationen über den verwendeten rxvt-unicode-Terminal abgefragt und über SSH auf die entfernte Maschine geschickt, wo die Infodatei mit Hilfe von tic von einem Quellformat in ein kompiliertes Format umgewandelt wird. Danach konnte ich dann wie gewohnt Programme öffnen.
Obwohl ich den Terminaltyp in elinks nicht auf 256 Farben eingestellt hatte, sondern weiterhin bei den 16 ANSI Farben belassen hatte, wurde meine Webseite ohne weiteres Zutun schon in den Solarized-Farben dargestellt. Als allgemeiner Tipp solltet ihr bei Farbproblemen % in elinks drücken, womit man zwischen verschiedenen Dokumentfarben umschalten kann. Ich verstehe nur noch nicht, warum bei manchen Farbkombinationen die Schrift fett dargestellt wird und bei manchen normal. Vermutlich hat das etwas mit dem ANSI-Farbcode zu tun. Und so sieht gambaru in elinks solarisiert aus. 😉