Tag: MultiBoot

Posted on

FreeDOS: Multiboot-System mit dem Toshiba Satellite 220cs

Es macht Spaß FreeDOS in einer virtuellen Maschine unter Linux auszuprobieren oder das sehr praktische DOSEMU zum Starten von DOS-Programmen und Spielen zu benutzen. Ich denke, das ist die einfachste Möglichkeit um mit FreeDOS den Einstieg in die DOS-Welt zu wagen. Natürlich war mein nächstes Ziel das Freie Betriebssystem auch auf dem Toshiba Satellite 220cs zum Laufen zu bringen, was schon fast als logische Konsequenz für einen Laptop aus dem Jahr 1996 mit 16 MB RAM anmutet.

Installation

Ich habe mich erneut für die Installation mit Qemu entschieden, die Festplatte des 220cs ausgebaut und mit Hilfe des USB-IDE-Adapters und mit dd ein Abbild der Festplatte erzeugt. Der große Vorteil liegt darin, dass man gleichzeitig ein Backup hat und bedenkenlos experimentieren kann. Eine einfache Lösung ist sicherlich ein leeres Raw-Image zu erstellen, FreeDOS zu installieren und mit dd auf die Festplatte zu schreiben. Wie es geht, hatte ich bei meiner Vorstellung von FreeDOS gezeigt.
Da ich die bestehenden Betriebssysteme Slitaz und KolibriOS behalten wollte, habe ich das Dateisystem meiner Slitazinstallation verkleinert und anschließend die Partition mit fdisk verändert. Mit Hilfe der Debian Netzinstallations-CD habe ich im Rettungsmodus folgendes gemacht.

e2fsck - f /dev/hda2
resize2fs -p /dev/hda2 600M


Mit fdisk wurde die Partition hda2 neu angelegt und auf 700M verkleinert und zusätzlich hda3 als dritte primäre Partition mit W95 FAT32 erstellt. Nach einem Neustart in Slitaz konnte ich dort erneut

resize2fs -p /dev/hda2


ausführen, damit das Dateisystem exakt an die neue Partitionsgröße angepasst wurde. Bei der Operation muss auf jeden Fall das Dateisystem vor der Partitionierung verkleinert werden, ansonsten kommt es zum Datenverlust. Mit dem zusätzlichen "resize2fs"-Schritt ohne Angabe der Größe wird das Dateisystem schließlich exakt an die Partitionsgröße angepasst.
Hat man diese Vorbereitungen abgeschlossen, kann man FreeDOS mit Hilfe von Qemu installieren, wobei das Installationsprogramm automatisch die erste FAT32-Partition als Laufwerk C: erkennt. Wem das nicht geheuer ist, kann es auch mit xfdisk überprüfen.

qemu -hda toshiba.img -cdrom fdfullcd.iso -boot d

Da ich schon ein vollständiges FreeDOS-Abbild hatte, verzichtete ich dieses Mal auf die meisten zusätzlichen Anwendungen und installierte nur base, games und media.

GRUB-Menü in Slitaz anpassen

Slitaz 3.0 benutzt noch GRUB 1. Meine /boot/grub/menu.lst sieht momentan so aus.

title Slitaz GNU/Linux (Kernel 2.6.30.6-slitaz)
root (hd0,1)
kernel /boot/vmlinuz-2.6.30.6-slitaz root=/dev/hda2 vga=788
title KolibriOS
root (hd0,1)
kernel /boot/memdisk
initrd /boot/kolibri/kolibri.img
title FreeDOS
rootnoverify (hd0,2)
chainloader +1
makeactive

FreeDOS-Einstellungen

Ein paar Änderungen der Voreinstellungen halfen mir auf dem 220cs Laptop weiter. Wer gerne Startzeiten von Betriebssystemen vergleicht, wird sich bei FreeDOS über die 2 Sekunden von GRUB bis zum Prompt freuen. Dazu sollte in der fdconfig.sys
MENUDEFAULT=3,0
stehen. Dabei stellt die Zahl 3 sicher, dass FreeDOS mit dem HIMEM-XMS-Memory-Treiber geladen wird, um Programme im erweiterten Speicher ausführen zu können und mit 0 wird die Verzögerung bei der Wahl des Menüpunkts auf 0 Sekunden gesetzt.
Standardmäßig werden zwei Treiber in den XMS-Speicher geladen, die 12 MB von 16 MB RAM belegten. Um später das Musikprogramm Mpxplay starten zu können, musste ich zumindest einen davon in der fdconfig.sys für Auswahl 3 deaktivieren.
12?DEVICEHIGH=C:FDOSbincdrcache.sys FDC0001 CDRCACH0 6000
Erwähnenswert ist auch, dass man die Energiesparfunktionen mit fdapm APMbios oder fdapm APMoff des BIOS ein- und ausschalten kann, was verhindert, dass die Festplatte nach jedem Kommando in den Ruhezustand versetzt wird. FreeDOS APM-Modus lässt sich mit fdapm APMdos wieder einschalten.

Mpxplay

FreeDOS bringt das Freie Musikprogramm Mpxplay mit, mit welchem sich zahlreiche Formate wie z.B. mp3, ogg oder FLAC abspielen lassen. Damit Mpxplay funktionierte, änderte ich die DMA-Einstellung für den Soundblaster-Treiber in der autoexec.bat für die Yamaha-Opl3sa2-Soundkarte von 1 auf 0.
SET BLASTER A220 I5 D0 H5 P330
Soundkarte und Lautsprecher des Toshiba Laptops sind zwar nach wie vor vermutlich nicht die beste Lösung für eine audiophile Umgebung, um einen Raum zu beschallen sind sie aber ausreichend. Leider habe ich noch nicht das Screenshotprogramm gefunden, deswegen hier nur ein Foto. Ich bin auf jeden Fall beeindruckt. MP3- und OGG-Dateien ließen sich problemlos abspielen.

USB und Netzwerk

USB und Internet waren in den 80igern und Anfang der 90iger noch in weiter Ferne. Erst mit Windows 95 gab es später eher schlecht als recht USB-Support. Umso mehr überrascht es deswegen vielleicht, dass es sowohl USB-Support als auch Netzwerkunterstützung für FreeDOS gibt. Im folgenden finden sich einige Links zu Seiten, die ich für lesenswert halte und für die Zukunft hier dokumentiere.

  • USB with DOS - Ein Artikel von 2003 zum USB Support mit DOS
  • cholla.mmto.org - Englischer Beitrag zum Thema Netzwerken mit DOS
  • FreeDOS on a Compaq Contura Aero - Englische Anleitung zur FreeDOS Installation auf einem Compaq Laptop von Ulrich Hansen (empfehlenswert)
  • Networking FreeDOS - Ulrich Hansens 40 Seiten umfassende Arbeit zum Thema FreeDOS und Networking im Wiki Format (beeindruckend, sehr empfehlenswert, es gibt auch ein nahezu identisches pdf Dokument namens dosnet.pdf, welches sich leicht im Netz finden lässt)
  • Das Dokument wurde auch ins Deutsche übersetzt und befindet sich in der FreeDOS Hilfe und lässt sich dort als Netzwerken unter FreeDOS finden.
  • FreeDOS Hilfe in Deutsch

Scheinbar wird darin sogar die Inbetriebnahme einer meiner 3com-Netzwerkkarten beschrieben, weswegen ich zuversichtlich bin, dass ich später einmal mit FreeDOS im Internet unterwegs bin. 😉
Ich denke die Installation der Treiber und das Einrichten des Netzwerks ist momentan mit Slitaz zwar einfacher. KolibriOS und FreeDOS ergänzen den Laptop jedoch um einige coole Funktionen. Die Installation von FreeDOS empfand ich als eher einfach, die Soundkarte war mit einer kleinen Änderung sofort einsatzbereit und zahllose Spiele für FreeDOS gibt es obendrauf. Für ein Multibootsystem auf jeden Fall mehr als einen Blick wert.

Posted on

Wenn Zwei zusammenkommen: Arch Linux und Debian

Eine Entscheidung zu treffen war. Tue ich es oder tue ich es nicht? Sollte ich den Inspiron 4000 verschrotten oder Arch Linux parallel zu Debian Sid installieren? Ok, es gab schon dramatischere Situationen, aber bevor ich Arch Linux installiere....Spaß, Spaß.
Der Dell-Laptop ist mittlerweile zehn Jahre in Gebrauch, dreieinhalb davon hat er bei mir verbracht und er hat sich gut gehalten. Nun ja zumindest bis vor kurzem. Nach dem Scharnierbruch ist er nicht mehr der Mobilste. Wäre ich ein geschickter Handwerker, dann würde die Sache schon längst repariert sein und ich käme nicht auf die Idee mich erneut an einem Multi-Boot-System zu versuchen. Nicht dass es besonders schwierig wäre, wie alles hat es seine Vor- und Nachteile.
Da der Laptop ansonsten immer noch einwandfrei funktioniert und nach wie vor der meistgenutzte Rechner ist, macht es Sinn einen kleinen Versuch zu starten. Debian Sid und Arch Linux im direkten Vergleich. Fairerweise muss ich hinzufügen, dass es mir nicht um das "bessere" Linux geht, sondern einfach nur darum herauszufinden, welche Unterschiede es zwischen beiden gibt.

Was man bei der Installation von Arch Linux auf dem Dell Inspiron 4000 beachten sollte

Keine Sorge, ich werde nun niemanden mit der Installation von Arch Linux langweilen. Eine der großen Stärken von Arch Linux ist die ausgezeichnete Dokumentation. In der Regel benutze ich das englische Arch Linux Wiki, weil es umfangreichere Informationen enthält. Für die Installation ist das deutschsprachige Wiki aber nicht schlechter.
Arch Linux verlangt von seinen Benutzern absichtlich mehr Aufmerksamkeit. Entscheidungen von Grund auf zu treffen, ist bei Arch die Regel. Für den Inspiron 4000 musste ich dennoch nur bei den schon bekannten Problemen aufpassen. Die xorg.conf muss separat für dieses Modell erstellt und angepasst werden. Für Arch Linux lautet der Xorg-Treiber xf86-video-ati. Da noch keine Linuxdistribution den X-Server perfekt eingerichtet hat, hatte ich schon etwas Erfahrung. Eine einfache Kopie meiner xorg.conf von Debian nach Arch Linux reichte vollkommen aus.
Zu Testzwecken probierte ich die Linksys-WLAN-Karte mit Broadcom-Chipsatz zum Laufen zu bringen. Wie gehabt wird sie mit dem freien Kernelmodul b43 aktiviert, lediglich die Firmware der Karte ist unfrei und muss separat installiert werden. Im Gegensatz zu Debian muss die Firmware aus AUR installiert werden. Konkret bedeutet das, dass ein Tarball mit einem sogenannten PKGBUILD manuell heruntergeladen und entpackt wird. Diese Datei enthält lediglich Informationen, von wo man die ursprünglichen Quelldateien bezieht und notwendige formale Einträge über die Zielarchitektur, den Uploader usw.
Man sollte sich diese Textdatei auf jeden Fall genauer anschauen, da sie auch für ein System schadhafte Informationen enthalten kann. PKGBUILDS lassen sich aber bewerten, es gibt Feedback dazu auf der offiziellen Webseite, so dass in der Regel diese Methode durch eine Vielzahl von anderen Nutzern getestet worden ist.
Hat man das PKGBUILD entpackt und das Paket fakeroot installiert, genügt lediglich ein makepkg -s, um ein Arch Linux Paket zu bauen. Dieses wird dann lokal mit Hilfe von Pacman installiert. pacman -U Paketname.
Nachdem ich sowohl Xorg als auch Openbox installiert hatte, musste ich lediglich noch meine Konfigurationsdateien von Debian nach Arch Linux kopieren. Hier gab es erwartungsgemäß keine Probleme, da ich viele Ideen aus dem Arch Linux Wiki schon umgesetzt hatte und sowohl Debian als auch Arch hier keine Unterschiede gemacht hatten.
An dieser Stelle könnte ich nun einen Screenshot präsentieren, aber das System sieht exakt so aus wie es die Screenshots z.B. hier oder hier zeigen.
Mein Fazit ist: Arch Linux verlangt von seinen Benutzern mehr Aufmerksamkeit als Debian, das einige triviale Optionen einfach als gegeben voraussetzt. Das macht es einfacher, ein System von Grund auf an die eigenen Bedürfnisse anzupassen. Arch Linux hingegen will ausdrücklich, dass sich der Nutzer mit jeder Systemeinstellung auseinandersetzt und versteht wie das Ganze funktioniert. Zeigt man aber Eigeninitiative und folgt den Anweisungen im Arch Wiki, lässt einem Arch Linux nicht im Stich. Es gibt bei Freien Betriebssystemen kaum eine bessere Dokumentation.
Positiv fiel mir wieder einmal die Geschwindigkeit und das simple Konzept von Pacman, dem Paketmanager von Arch Linux, auf. Mittlerweile hat man auch die Sicherheitsprobleme angepackt. Danke auch an Daniel für den Hinweis!
In Zukunft werde ich versuchen Unterschiede von Debian Sid und Arch Linux zu dokumentieren und einfach etwas mehr über diese Distribution zu schreiben ohne Debian Sid in irgendeiner Weise zu vernachlässigen.

Posted on

Teste dein Multi-Boot System

Wie findet man heraus, welche Linuxdistribution die "bessere" ist? In was besser eigentlich und wie misst man am besten?
Natürlich braucht man geeignete Werkzeuge und Irgendetwas, mit dem sich die Ergebnisse vergleichen lassen.
In meinem Beitrag zu Speicherverbrauch und Compiz von Ubuntu 11.04, habe ich versucht es etwas lockerer mit dem Systemmonitor und etwas Gefühl zu versuchen.
Für großangelegte Benchmarks gibt es für Linux aber schon eine Lösung - die Phoronix Test Suite.
Mit ihr lässt sich zwar nicht der Leistungsunterschied zwischen Programm X und Y messen, jedoch bietet sie umfangreiche Tests an, um Komponenten eines Computers auf Herz und Nieren zu prüfen. Wie performant ist mein Rechner gegenüber Modell xy eigentlich? Mit der Phoronix Test Suite kann man einer Antwort auf diese Frage näher kommen.
Mich interessierte für mein Multi-Boot System hingegen wie sich die drei unterschiedlichen Distributionen Ubuntu 11.04 (64bit), Debian Testing (32 bit) und Arch Linux (64bit) auf dem gleichen Rechner schlagen. Würde es große Unterschiede zwischen den beiden 64 bit Systemen von Arch Linux und Ubuntu 11.04 geben und wie würde Debian Testing als 32 bit Betriebssystem abschneiden?
Ich habe mich schließlich für die linux-system Test Suite entschieden, welche mit vielen Untertests nach eigener Aussage die Gesamtperformance eines Linux Systems im Vergleich zu anderen darstellen kann.
Die Phoronix-Test-Suite ließ sich wie gewohnt installieren. In allen drei Distributionen gab es schon vorgefertigte Pakete. Die Tests sind bei jeder Distribution die gleichen und mussten nur ein einziges Mal heruntergeladen werden. Danach genügte ein phoronix-test-suite make-download-cache, wodurch die Tests im versteckten Ordner ~/.phoronix-test-suite/download-cache abgelegt wurden und nur noch zwischen den Systemen kopiert werden mussten.
Die Test-Suite selbst wird mit dem Kommando

phoronix-test-suite benchmark linux-system

ausgeführt. Möchte man nur die Tests herunterladen genügt install anstelle von benchmark, zum Ausführen ist es der Befehl run.
Insgesamt sollte man für eine so umfangreiche Test-Suite genug Zeit einplanen, da die Pakete teilweise auf dem Zielsystem noch kompiliert werden und zusätzliche Pakete über die Paketverwaltung installiert werden. Bei Debian und Ubuntu verlief dieser Prozess meistens reibungslos, bei Arch Linux musste ich öfter manuell nachhelfen. Selbst dann gelang es mir nicht alle Tests erfolgreich auszuführen. Da es aber genug vergleichbare Tests auch mit Arch schafften durchzulaufen, sieht das Ergebnis am Ende meiner Meinung nach eindeutig aus.
Das Ergebnis habe ich der Einfachheit halber gleich auf openbenchmarking.org veröffentlicht. Dort finden sich auch Details zu den getesteten Komponenten des Rechners. Alle Distributionen waren zum Zeitpunkt des Tests auf dem aktuellen Stand. Kernel 2.6.38 und das ext4 Dateisystem kamen standardmäßig bei allen zum Einsatz. Als Desktopumgebung setzte ich bei Debian Testing auf Gnome 2.30, bei Ubuntu 11.04 auf Unity und mit Arch Linux auf Gnome 3.

Das Ergebnis

Phoronix-Test-Suite: pts/linux-system Intel Core 2 Duo e7400, Ubuntu 11.04, Debian Testing (wheezy), Arch Linux
Nicht ganz überraschend ist mein 32 bit Debian Testing System bei dieser Test-Suite abgeschlagen Letzter geworden. Lediglich bei Minion, dem Threaded I/O Tester und POV-Ray liegt wheezy vorne. Die restlichen Tests zeigen deutlich, dass zwischen den beiden 64 bit Distributionen Ubuntu 11.04 und Arch Linux kein großer Unterschied besteht. Wenn überhaupt liegt Ubuntu bei Encoding und rechenintensiven Tests, bei denen ein 64 bit System seine Vorteile deutlich ausspielen kann, knapp vorne.
Die größten Ausreißer gab es bei dem Postmark Test, wo wheezy komplett aus der Reihe fällt und dem Apache Benchmark, wo Arch Linux deutlich hinterher hinkt. Die Werte weichen zu deutlich von den anderen ab, weshalb ich denke, dass hier ein Messfehler vorliegt.
Die ganzen Tests haben nachträglich noch einmal bestätigt, dass es absolut sinnvoll ist für Audio-, Video- und Bildbearbeitung ein 64 bit Betriebssystem einzusetzen. Ob es nun Arch Linux oder Ubuntu 11.04 ist, scheint weniger wichtig zu sein. Letzteres war scheinbar keine schlechte Wahl.
Die Phoronix Test-Suite bietet aber auch Kritikpunkte. So sinnvoll ich es halte, dass es sich immer um die gleichen Tests handelt, es wird dadurch aber nicht einfacher herauszufinden, ob es eventuell distributionsspezifische Vorteile bei einzelnen Programmen gibt.
Des weiteren ist eine solche Test-Suite immer auch ein Extremtest und spiegelt nicht den alltäglichen Gebrauch eines Computers wider. Sollte ich aber irgendwann den ganzen Tag nichts anderes tun als 1GB große Dateien mit GnuPG zu verschlüsseln, mache ich das am besten mit Ubuntu 11.04 (64bit). Komprimiere ich Dateien mit LZMA sollte es wohl besser Arch Linux(64bit) sein.
Wenn ihr euch den Spaß machen möchtet und genau diese Testumgebung auf eurem Rechner ausprobieren wollt, können die Resultate direkt mit folgendem Befehl verglichen werden:

phoronix-test-suite benchmark 1105157-IV-20110514D92

Zum Schluss habe ich mir ein anderes Resultat vorgenommen, welches die Tests Unigine Heaven und Openarena schon ausgeführt hatte. Im Prinzip ging es um den Vergleich Radeon 4870 gegen meine Nvidia 9600 GT. 32 bit versus 64 bit spielte hierbei keine Rolle. Die Auflösung betrug 1680x1050 Pixel. Alle Distributionen konnten auf die aktuellen Nvidia Treiber zurückgreifen.
Unigine Heaven Test Nvidia 9600 GT Ubuntu 11.04, Debian Testing (wheezy), Arch Linux
Bedauerlicherweise erreichte ich mit keinem der Distributionen die vorgegebenen Framewerte. Am schlechtesten schnitt dabei Arch Linux ab. Ich versuchte es deshalb mit OpenArena erneut, wo Ubuntu 11.04 (+compiz) 346,23 fps erzielen konnte.
Debian Testing (+compiz) erreichte 330 fps und Arch Linux (Gnome 3) 329,57 fps. Die Unterschiede waren also nur marginal.
Ergebnis OpenArena Wheezy
Ergebnis OpenArena Arch Linux
Interessant wurde es noch einmal als ich den OpenArena Test mit wheezy ohne compiz wiederholte und dabei 376,27 fps erreichte.
Ergebnis OpenArena Wheezy ohne compiz
Das Ergebnis lässt den Schluss zu, dass 32 bit oder 64 bit bei den Tests keine große Rolle spielte. Wichtiger sind verwendete Grafiktreiber, die Grafikkarte selbst und ob ein Compositing Fenstermanager wie compiz aktiviert war oder nicht. Für Spieler lässt das nur den Schluss zu, dass weniger Compiz beim Spielen mehr ist.
Alles in allem zeigen die Phoronix Tests, dass die allgemeine Grundperformance bei vergleichbarer Architektur sehr ähnlich ist. Optimierungen und Verbesserungen einzelner Anwendungen konnte die Test-Suite aber nicht messen. Ob ein System mit speicherhungrigen Programmen überladen war oder dezent nur das Notwendige installiert war, ließ sich mit den Tests nicht feststellen.

Posted on

Die Vor- und Nachteile eines Multi-Boot-Systems

Mehr als ein Monat ist vergangen, seitdem ich Ubuntu 10.10 gegen ein Multi-Boot-System ausgetauscht habe. Falls ihr euch ebenfalls für ein solches System interessiert, findet ihr in diesem Beitrag eine Übersicht über die Vor- und Nachteile. Die gemachten Erfahrungen mit den drei neuen Betriebssystemen Ubuntu 11.04, Debian Testing und Arch Linux habe ich zusammengefasst und zu den einzelnen Schritten des Projekts verlinkt.

Warum überhaupt Multi-Boot?

Vorteile

Vergleichbarkeit: Mit einem Multi-Boot-System ist es unkompliziert sich die Vor- und Nachteile verschiedener Linuxdistributionen oder Desktopumgebungen unter realistischen Bedingungen anzuschauen. Zwar bieten Virtualisierungslösungen wie z.B. Virtualbox und Qemu einen weniger aufwendigen Überblick. Diese hinken in Sachen Performance einem Multi-Boot System in der Regel aber deutlich hinterher.
Klare Aufgabentrennung: Ein Multi-Boot-System eignet sich hervorragend, um typische Arbeiten am Computer zu trennen. So lässt sich ein Betriebssystem ausschließlich zum Arbeiten, ein anderes für Videobearbeitung und ein drittes vielleicht zum Spielen nutzen.
Flexibilität und Integrität: Nicht nur die Software kann flexibel an die eigenen Bedürfnisse angepasst werden, auch unterschiedliche Dateisysteme können eingesetzt werden, um die Performance für spezielle Anwendungen zu erhöhen. Bei getrennten Partitionen und Betriebssystemen wiegt ein Schaden am Dateisystem weniger schwer und Fehler wirken sich nicht auf alle Daten gleichzeitig aus.
Sicherheit: Ein Multi-Boot-System kann so eingerichtet werden, dass nur diejenigen Anwendungen installiert sind, die man tatsächlich braucht. Was nicht installiert ist, kann auch nicht kompromittiert werden. Nutzt man ein System z.B. ausschließlich für private Korrespondenz und Büroarbeit lässt sich mitunter auf einen Browser und diverse Internet- und Multimediaanwendungen als potentielle Einfallstore für Schadsoftware verzichten.
Performance: Je nach Geschmack und Vorlieben lassen sich Multi-Boot-Systeme für ihren jeweiligen Anwendungszweck optimieren. Ein Linuxsystem für Spiele braucht z.B. keine Textverarbeitung, kein Multimedia, kein Emailprogramm und auch kein Compiz. Nur das Spiel, ein Terminal, eventuell IRC- und VoiP-Client der Wahl, der aktuellste Grafiktreiber und ein auf das notwendigste optimierter Linuxkernel sind wirklich notwendig.
Eingewöhnung: Gerade bei einem Umstieg von Windows oder Mac auf Linux oder zwischen zwei verschiedenen Linuxdistributionen, macht es Sinn für eine Übergangszeit zwei Systeme parallel zu nutzen, zumindest solange bis man sich an die neue Umgebung gewöhnt hat.

Nachteile

Mehr Aufwand: Für ein Multi-Boot-System fällt zusätzlicher Installations- und Konfigurationsaufwand an. Nicht nur muss der Installationsvorgang ggf. mehrmals wiederholt werden. Auch die Wartung, Pflege und Administration der Systeme kostet je nach Distribution und Vorstellungen zusätzliche Zeit. Noch nicht vertraute Konzepte anderer Distributionen müssen erst erlernt werden.
Reboot: Um das System zu wechseln ist immer ein Neustart notwendig. Auch das kostet Zeit und kann manchmal störend sein, wenn man "nur mal kurz" etwas ausprobieren möchte.
Doppelte Funktionalität: Idealerweise gibt es für die Multi-Boot-Systeme jeweils einen spezifischen Verwendungszweck. Es besteht aber die Gefahr, dass Programme doppelt installiert werden und sich Aufgaben überschneiden. Beispiel Browser: Hiermit lassen sich schnell Informationen im Internet finden, was sowohl für reine Büroarbeit als auch für Videobearbeitung und Spiele sinnvoll sein kann. Um Redundanz zu vermeiden, muss man sich vorher genau überlegen, was man sich von seinem Multi-Boot System überhaupt erwartet.

Partitionierung und Installation

Debian Testing: Manuelle Partitionierung eines verschlüsselten LVM
Ubuntu 11.04: Download der Beta mit jigdo und Installation
Arch Linux: Installation mit der Multi-Arch CD

Überblick über das Partitionsschema

PartitionBeschreibung
/dev/sda1 (Primär)Unverschlüsselte Bootpartition für Debian Testing (ext2)
/dev/sda2 (Primär)Daten- und Austauschpartition zwischen den verschiedenen Distributionen (ext4)
/dev/sda5 (Logisch)LVM auf einem verschlüsselten Volume mit den Logical Volumes root, swap und home für Debian Testing
/dev/sda6 (Logisch)Ubuntu 11.04 installiert in eine logische Partition (ext4)
/dev/sda7 (Logisch)Swap Partition für Ubuntu 11.04 und Arch Linux
/dev/sda8 (Logisch)Arch Linux installiert in eine logische Partition (ext4)

Die drei Linuxdistributionen im Überblick

Debian Testing (Gnome 2 + Compiz)

Gnome 2

Ursprünglich wollte ich Linux Mint Debian mit verschlüsseltem LVM installieren. Mit LMDE beschäftige ich mich seit Ende 2010 und habe mich dann auf Basis einer Debian Netzinstallation für "The Debian Way" entschieden.
Nach einigem Rumprobieren und Abwägen zwischen Linux Mint Debian und dem reinen Debian, blieb ich schließlich bei Debian Testing. Zu gering erschienen mir die Vorteile und in der Tat war LMDE dann doch nur ein mint-meta Paket.
Debian Testing ist nun das Haupt- und Arbeitssystem, von dem auch die anderen Systeme mit Hilfe von GRUB im MBR eingebunden werden. Als Desktopumgebung nutze ich Gnome 2, das ich nach der Installation des gnome-core Pakets nur noch geringfügig konfigurieren musste, um die von Ubuntu gewohnten Eigenschaften zu erhalten. Zur Zeit bin ich wunschlos glücklich mit Debian und warte nun geduldig auf Gnome 3.

Ubuntu 11.04 (Unity+Compiz+Gnome)


Ubuntus Natty Narwhal dient mir seit neustem als Videoschnittplatz, worunter bei mir auch Bild- und Audiobearbeitung fallen.
Zukünftig möchte ich Ubuntu für die Realisierung kleinerer Videoprojekte einsetzen und dabei ausschließlich Open-Source-Software nutzen. Das Ganze ist ein Projekt im Entstehen. Sollten die Ergebnisse interessant und vorzeigenswert seien, gibt es eventuell auch einen Blogbeitrag. 😉
Die ersten Eindrücke zu Ubuntu 11.04 waren gemischt, aber mit ein paar kleinen Optimierungen lässt sich mit dem schicken Narwal leben.

Arch Linux (Gnome 3)


Arch Linux war schon seit längerem ein Testkandidat für mich. Obwohl etwas Einarbeitungszeit erforderlich ist, sind die erstklassige Dokumentation im Netz und das Ergebnis alle Mühen wert. Wer gar nicht auf ein gut getestetes Gnome 3 in Debian warten kann, hat mit Arch die besten Chancen die Zeit zu überbrücken.
Da ich Stabilität und Zuverlässigkeit bei Betriebssystemen sehr hoch einschätze, wird Arch vermutlich auch in Zukunft Debian nicht verdrängen. Zu unterschiedlich sind hier die beiden Ansätze. Das heißt nicht, dass Arch Linux notorisch instabil ist, aber allein aus grundsätzlichen Überlegungen kann ein Rolling Release, welches auf brandaktuelle Software abzielt, nicht genauso umfangreich wie Debian Stable getestet sein. Archs besonders hervorzuhebendes Qualitätsmerkmal ist die erstklassige Dokumentation. Für ein leichtgewichtiges Linux oder gerade wenn man auf neue Feature Wert legt, ist Arch mit Sicherheit eine Option, die man im Hinterkopf behalten sollte.

Fazit

Ein Multi-Boot-System ist nützlich, lehrreich und macht Spaß. So bleibt in Zukunft die Möglichkeit die Vor- und Nachteile verschiedener Distributionen unter realistischen Bedingungen zu testen. Insgesamt ist das Hauptsystem mit Debian Testing deutlich aufgeräumter und besser auf die Anforderungen angepasst als das eine Standardinstallation von Ubuntu naturgemäß vorher leisten konnte.
Die Reaktionsfähigkeit einer reinen Debian Installation gegenüber Ubuntu ist, nicht ganz überraschend, besser, obwohl es nicht leicht ist dieses Gefühl in Zahlen auszudrücken. Fakt ist aber auch, dass keine der Distributionen auch nur annähernd das gesamte Potenzial eines drei Jahre "alten" Dual Core Rechners unter durchschnittlichen Bedingungen ausreizen musste.
Für mich funktioniert ein Multi-Boot-System momentan sehr gut. Wer den Aufwand scheut, wird die gleichen Probleme aber sicher auch anders lösen können.

Posted on

Das Multi-Boot Projekt: Ubuntu 11.04 Natty Narwhal

Heute habe ich den nächsten Schritt mit dem Multi-Boot Projekt getan und die aktuelle AMD64-Beta-Version von Ubuntu 11.04 mit Hilfe von jigdo installiert.
Zur Zeit ändert sich jeden Tag etwas an Ubuntu Natty Narwhal, weswegen es sinnvoll ist auf ein Werkzeug wie jigdo zurückzugreifen, welches sehr effizient große iso Dateien verteilen kann. Mit jigdo ist es nicht notwendig jedes Mal einen kompletten ISO-Download zu starten. Gut erklärt wird das Ganze auch in einem kleinen, englischen Mini-Howto.
Es werden ähnlich wie bei rsync nur neue Pakete von den Spiegelservern heruntergeladen und zu dem schon bestehenden ISO zusammengefügt, was nicht nur sehr zeitsparend ist sondern Debian und Ubuntu auch eine Menge Bandbreite spart. Ansonsten nutze ich bei der finalen Version immer Bittorrent.
Nach der Installation von jigdo genügt es den folgenden Befehl im Terminal einzugeben, um das natty-alternate-amd64 Abbild von der offiziellen Ubuntu Seite herunterzuladen. Alle weiteren Abfragen können beim ersten Herunterladen mit Enter bestätigt werden.
jigdo-lite http://cdimage.ubuntu.com/daily/current/natty-alternate-amd64.jigdo
Das Image lässt sich danach in Qemu oder Virtualbox ausprobieren, sofern die 3D Beschleunigung in der VM funktioniert. Um dieses am nächsten Tag auf den neuesten Stand zu bringen, genügt es das Abbild als loop device zu mounten, das alte ISO sicherheitshalber umzubenennen und die noch vorhandene .template und .jigdo Datei zu löschen.
mount -o loop Pfad zu natty-alternate-amd64.iso /media/cdrom
Der einzige Unterschied zum ersten jigdo Einzeiler besteht darin, dass bei der Abfrage "Files to scan" der Pfad zum eingehängten ISO, also /media/cdrom, eingetragen wird. Danach setzt man den Download mit Enter fort und die geänderten Dateien werden heruntergeladen und zum aktuellen Abbild zusammengefügt.
Danach lässt sich alles z.B. mit Brasero brennen oder mit UNetbootin auf einen USB Stick schreiben. Als Konsolenalternative sollte natürlich auch dd funktionieren.
Die Installation unterscheidet sich bei der alternativen Ubuntu-Installation nicht von einer Debian-Netzinstallation, da beide auf den Debian Installer setzen. Ich nutzte erneut die manuelle Partitionierung für das Multi-Boot System mit der schon vorgestellten Aufteilung.
Aus dem freien Speicher wurde eine 20 GB große, logische ext4 Partition sda6 und eine weitere Swap-Partition sda7, da ich auf das verschlüsselte LVM in sda5 natürlich nicht zurückgreifen konnte.
Für meine Zwecke genügte eine Partition für Ubuntu, da ich nach der Konfiguration später alles mit Clonezilla sichern werde und ansonsten es mit dem Backup einfach handhabe.
Der wichtigste Punkt bei der zweiten Installation ist die Frage, wohin der Bootmanager GRUB installiert werden soll. Auf gar keinen Fall durfte er jetzt in den MBR geschrieben werden, da dort schon GRUB von meiner Debian Testing Installation saß. Bei der darauf folgenden Abfrage in welche Partition GRUB installiert werden soll, musste ich für meine Partitionierung konsequenterweise /dev/sda6 wählen.
Nach dem Neustart hat sich an dem Bootmenü nichts geändert, da GRUB im MBR noch nichts von dem neuen Betriebssystem Ubuntu 11.04 weiß. Das lässt sich aber leicht mit Debian ändern, indem man sich als root im Terminal anmeldet und

os-prober
update-grub

ausführt. Das Programm os-prober erkennt parallel installierte Betriebssysteme und update-grub aktualisiert GRUB im MBR. Nachdem Neustart lässt sich danach dann zwischen Debian und Ubuntu wählen.
Einen vollständigen Bericht zu Ubuntu 11.04 spare ich mir an dieser Stelle. Vielleicht komme ich nach der offiziellen Veröffentlichung auf einige neue interessante Facetten zurück. Außerdem gibt es schon mehr als genug informative Youtube-Videos zur Beta.
Man merkt Ubuntu an manchen Stellen den Beta Status an und zur Zeit ist die deutsche Sprachunterstützung bei der Installation noch nicht komplett. Der neue Unity Desktop setzt auf jeden Fall die Nvidia Treiber voraus, welche sich aber wie gewohnt leicht mit Jockey nachinstallieren lassen.
Nicht mehr ganz geheim ist Ubuntus Anlehnung an Design Entscheidungen von MacOS. Nicht nur die Fensterknöpfe sind schon länger auf die linke Seite gerutscht, auch die Integration des Programmmenüs in das obere Systempanel, sobald ein Programm fokussiert wird, sticht hervor. Wer schlichtes Design ohne Augenschmaus mit Compiz bevorzugt, muss sich definitiv umstellen. 😉

Posted on

Das Multi-Boot Projekt: Manuelle Partitionierung mit Debian

Der Monat April steht im Zeichen des Multi-Boot Projektes. Nach fünf Jahren mit Ubuntu auf dem Hauptrechner und den anstehenden großen Umwälzungen im Desktopbereich, Stichwort Gnome 3 versus Unity, wollte ich wieder etwas Neues ausprobieren.
Da Ubuntu 11.04 erst Ende April erscheint, nutze ich die Zeit, und beginne mit der schon vorgestellten Installation von Linux Mint Debian auf einem verschlüsselten Logical Volume.
Um überhaupt die Möglichkeit zu haben Linux Mint Debian zu verschlüsseln, greife ich auf die Netzinstallation von Debian Squeeze mit dem Debian-Installer zurück. Leider ist die Partitionierung nicht mehr ganz so einfach wie bei meinem ersten Test auf dem Inspiron 4000, da ich mir für das Multibootsystem und meine 500 GB große Festplatte folgendes überlegt habe.

Primäre Partition sda1: /boot 256 MB ext2

Um das verschlüsselte Volume mit der Root-Partition öffnen zu können, muss es eine unverschlüsselte Boot-Partition geben.

Primäre Partition sda2: /data 430 GB ext4

Die Datenpartition, auf der alle Daten zwischen den verschiedenen Distributionen ausgetauscht werden. Wenn man möchte, kann man diese einzelne Partition später immer noch ganz einfach verschlüsseln.

Logische Partition sda5: LVM auf einem verschlüsselten Volume mit dm_crypt

Darin enthalten sind drei logische Volumes, ein 6,5 GB großes Swap, 10 GB root und 12,5 GB home Volume.
Die restlichen ca. 40 GB sind freier Speicher, den sich später Ubuntu 11.04 und eine weitere Distro teilen werden.
Leider bietet der Debian-Installer keine automatisierte Vorlage für ein solches Schema an und es besteht bei der manuellen Partitionierung schnell die Gefahr verschlüsselte Volumes auf LVM einzurichten, die später beim Booten alle einzeln entsperrt werden müssen.
Die wichtigsten Schritte bei der manuellen Partitionierung habe ich aus diesem Grund in Qemu noch mal nachgestellt, deswegen nicht von den Zahlenwerten für den Speicher verwirren lassen. Spätestens jetzt sollte von allen wichtigen Daten ein Backup gemacht worden sein. 😉

Nachdem man sich für die manuelle Partitionierung entschieden hat, wird der Freie Speicher ausgewählt und /boot und /data als primäre Partitionen angelegt. Für /boot nutzt Debian bei der geführten Installation immer ext2, weshalb ich hier die gleiche Einstellung gewählt habe.
Der reservierte Speicher kann meiner Meinung nach auf 1% verkleinert werden, da ich 5% bei heutigen Festplattengrößen für Verschwendung halte. Die Boot-Markierung (Boot Flag) sollte auf EIN stehen.

Als nächstes wird die logische Partition Nr. 5 angelegt. Anstatt bei "Benutzung als" ein Dateisystem auszuwählen, muss man hier "pysikalisches Volume für Verschlüsselung" wählen und das Ganze anlegen. Danach wählt man "Verschlüsselte Datenträger konfigurieren", selektiert die crypto Partition und gibt nach dem Fertigstellen das Passwort zum Entschlüsseln der Partition ein, womit der Stand wie auf dem nächsten Bild sein sollte.
Einschränkung hier: Primäre Partition 2 muss natürlich auf /data eingebunden sein und nicht auf /. Das Dateisystem für das verschlüsselte Volume lässt sich später beim Anlegen der Logical Volumes noch ändern.


Als nächstes geht es daran innerhalb des verschlüsselten physikalischen Volumes eine Volume Gruppe anzulegen (hierzu verwendet Debian bei der geführten Verschlüsselung den Rechnernamen, man kann sich natürlich auch etwas Eigenes ausdenken) und wiederum innerhalb dieser Gruppe drei logische Volumes root, swap und home mit dem jeweiligen Dateisystem und der festgelegten Größe. Dies wird erreicht, indem "Logical Volume Manager konfigurieren" ausgewählt wird, wonach man das Menü auf dem nachfolgenden Bild erreicht, wo die oben beschriebene Gruppe und die logischen Volumes angelegt werden.


Nach diesem Schritt gilt es als letztes nur noch die Einbindungspunkte für /root, /home und die Swap-Partition festzulegen. Dazu muss man sich wieder im Hauptmenü befinden und die einzelnen logischen Volumes bearbeiten. Die für Linux Mint Debian endgültige Partitionsstruktur sieht dann wie folgt aus.


Ich hoffe, damit habe ich auch für mich beim nächsten Mal die größten Stolperfallen ausgeräumt. Weicht man von der geführten Partitionierung mit Verschlüsselung ab, sind sehr viele Menüs durchzuarbeiten. Leider ist die grafische Variante nicht einfacher, da sie 1:1 auf den Optionen der menügesteuerten Partitionierung aufbaut.
Die Frage ist natürlich auch, muss es denn unbedingt so kompliziert sein und geht es nicht auch einfacher? Wem Verschlüsselung nicht wichtig ist, kann sich auch drei primäre Partitionen mit Root-, Swap- und Home-Partition anlegen und dann mit logischen Partitionen weitermachen. Die erste logische Partition wäre dann die Datenpartition und die zweite die Root-Partition für Ubuntu, die dritte für "Lieblingsdistro XY" usw.
Alle weiteren Distributionen greifen dann auf die primäre Swap-Partition zurück, die bei meiner gewählten, verschlüsselten Partitionierung nicht von mehreren Systemen angesprochen werden kann.
Das Ganze soll die Möglichkeiten einer manuellen Partitionierung mit und ohne Verschlüsselung demonstrieren, wobei ich ersteres insbesondere für Laptops oder Netbooks immer für sinnvoll halte.
Der Rest der Installation verlief übrigens reibungslos und genauso wie bei der letzten Installation von LMDE. Demnächst wieder mehr Schockierendes. 🙂

Posted on

Pläne für ein Multi-Boot-System

Mein Entschluss steht fest. Mit Erscheinen von Ubuntu 11.04 werde ich ein Multi-Boot-System auf meinem Dual Core Rechner einrichten. Nein, ich werde nicht wieder zu Windows zurück wechseln. 😉
Mein erstes Multi-Boot-System entstand ganz am Anfang meiner Linux-"Karriere". Damals steckten viele Lösungen für Open-Source-Virtualisierung noch in den Kinderschuhen oder waren zumindest noch nicht so verbreitet wie das heute der Fall ist. Oft mangelte es auch an Wissen und leistungsfähiger Hardware.
Für viele war und ist der erste Schritt zu Linux ein Dual-Boot-System mit Windows. Natürlich unterstützt Windows bis heute nicht mehrere Betriebssysteme parallel auf einem Computer und auch fremde Dateisysteme lassen sich nicht ohne weiteres lesen oder sogar beschreiben.
Aus diesem Grund testete ich früher schon viele Betriebssysteme parallel und war Linux schon damals dankbar sich so geräuschlos um Multi-Boot-Systeme zu kümmern. Zuletzt waren fünf verschiedene Linuxdistributionen auf einem Rechner installiert, die alle mit Hilfe von GRUB gestartet wurden.
Heutzutage nutze ich weder Windows noch brauche ich zwingend verschiedene Linuxsysteme auf einem Rechner, ein paar alten Laptops sei Dank. 😉 Wenn überhaupt läuft ein weiteres Betriebssystem in Virtualbox oder Qemu.
Der Grund für ein Multi-Boot-System ist also wiedermal die Neugier und ein bisschen Experimentierfreude. Mit Ubuntu 11.04 setzt Ubuntu erneut andere Maßstäbe und favorisiert ab sofort eine eigene Desktopoberfläche namens Unity.
Prinzipiell lässt sich natürlich weiterhin zwischen Unity und Gnome 3 und jeder anderen Desktopumgebung wählen. Es besteht also keine Notwendigkeit Ubuntu den Rücken zu kehren.
Nichtsdestotrotz kommt mit Debian Testing und etwas Mint alias LinuxMintDebian mehr Abwechslung herein und schließlich komplettiert dies auch Debian Squeeze auf dem Toshiba Portégé und Debian Sid auf dem Dell Inspiron Laptop. 🙂
Momentan ist die Idee also LinuxMintDebian als Betriebssystem für alle typischen Desktopanwendungen zu nutzen und Ubuntu 11.04 gezielt für Video- und Audiobearbeitung einzusetzen, ohne dabei auf das schon vorgestellte Ubuntustudio zurückzugreifen.
Das dritte und eventuell vierte Betriebssystem dient dann mehr dem Ausreizen aller Möglichkeiten und ich wollte schon immer mal ein persönlich angepasstes ArchLinux erstellen. 🙂
Schade, dass Ubuntu 11.04 erst Ende April erscheint. 😈