Die Entwicklerversion

Aktuelle Entwicklerversionen (Development-Tree) von coLinux haben deutliche Änderungen in der Konfiguration zu verzeichnen. Damit mußte ich auch diese Seite entsprechend anpassen. Das hat zur Folge, daß alle Angaben die ich hier mache, nicht mehr auf die Versionen kleiner 0.7.1 anzuwenden sind. audio

Einordnung

coLinux ist ein Linux-Kernel, der gegen die Windows API compiliert ist. Der Kernel wird als normales ELF-Binary betrieben. Er kann auch ganz normal unter Linux compiliert werden. Ein kleines Programm fungiert dann für Windows als Wrapper um Linux zu starten.

Damit geht coLinux einen ähnlichen Weg wie UserMode Linux nur eben auf der Windows Plattform. coLinux unterscheidet sich von virtuellen Maschinen wie VMWare dadurch, daß das Gast-System auf Linux festgelegt ist und speziell für coLinux angepaßt wird. Wie bei VMware ist das coLinux ein einziger Windows-Task. D.h. Linux-Prozesse werden nicht wie z.b. beim Modell Wine direkt auf jeweils einen Windows-Task umgesetzt.

Die Vorteile liegen auf der Hand: coLinux ist deutlich flexibler in der Speicherverwaltung und bei der CPU-Nutzung als VMware. Das schlägt sich im laufenden Betrieb nieder, wenn der coLinux-Task erstaunlich wenig Speicher belegt. Bemerkenswert ist auch die enorme Geschwindigkeit beim Start des Kernel. Sowohl Host- als auch Gastsystem fühlen sich subjektiv flüssiger an.

Konfiguration

Die Installation ist Windows-typisch einfach. Wer gerne immer die aktuellsten und zum Teil unstabilen Versionen von coLinux verwendet wird dazu sicherlich bei Henry Nestler fündig.
Die Konfiguration von coLinux hat sich zwischen den Versionen 0.6 und 0.7 massiv verändert. Früher wurde alles mit Hilfe einer XML-Datei konfiguriert. Heute werden prinzipiell nur noch die Kommandozeilen-Parameter, die auch schon früher funktionierten unterstützt. Dazu ist die Möglichkeit gekommen, Kommandozeilenparameter in eine Konfigurationsdatei zu schreiben. Das Ganze ist also immernoch sehr trickreich da die Software noch sehr im Fluß ist und neue Features wie der Framebuffer (CoFB) oder der Zugriff auf das Hostdateisystem (CoFS) hinzugefügt werden. Das alles verwirrt noch mehr in sofern, weil man irgendwelche Konfigurations-Optionen zu coLinux z.B. irgendwo auf einer japanischen Webseite findet und sich wundert, wieso das mit dem eigenen Stand der Software nicht funktioniert.

Deshalb gehe ich hier schrittweise die typischen Anwendungsfälle durch. Wer es lieber auf eigene Faust versuchen will, kann sich auch meine komplette config.txt runterladen.

Das Konfigurationsdatei-Format

XML ist tot, es leben die Kommandozeilenparameter. Die kann man in eine Konfigurationsdatei packen und hat dann alle Parameter praktisch bei einander. Das sieht dann konkret so aus

# Dis ist ein Kommentar

# Kernel Kommandozeile als Parameter für den Linux-Kernel
root=/dev/hda6 ro 

# Die initiale Ramdisk als Parameter für coLinux
initrd=initrd.gz 

# Die Speicherangabe als Parameter für coLinux
mem=128

Zugriff auf Festplatten/Partitionen

coLinux kommt mit einem vorgefertigten Linux-Kernel daher. Dazu kann man sich angepaßte Distributions-Dateisysteme für Fedora, Debian oder Gentoo von Sourceforge holen. Beispiele für die Konfiguration von Festplatten und Partitionen unter coLinux:

cobd0=c:\coLinux\Fedora_Core_1
hda=\Device\Harddisk0\Partition0
hda6=\Device\Harddisk0\Partition3
fd0=\Device\Floppy0 
In der /etc/fstab im Linux-Gast finden sich dann beispielsweise
/dev/hda6	/                       ext3    defaults        1 1
/dev/fd0	/floppy			auto	user,noauto	0 0
Die hier verwendeten Pfade sind Windows-Pfade zum Dateisystem. Das ist bei den runtergeladenen, angepaßten Distributions-Dateisystemen der Pfad zu der entsprechenden Datei.
Allerdings kann man hier auch andere Windows-Pfade einsetzen wie z.B. \Device\Floppy0 oder \Device\CdRom0 für den Zugriff auf Floppy oder CD-Rom-Laufwerk auf Block-Device-Ebene. Das geht sogar noch weiter für die erste Festplatte \Device\Harddisk0\Partition0 und Partitionen von Festplatten z.B. \Device\Harddisk0\Partition3.
Hat man bereits ein Linux im Dual-Boot installiert, kann man es auf als coLinux-Basis nutzen. Leider ist etwas trickreich rauszufinden, welche Partitions-Nummer Windows, für welche Linux-Partition hält. Eine Liste der gültigen Partitionsnummern erhält man mit dem Programm diskpart.exe. Wichtig für unsere Anwendung ist es, die Festplatte auszuwälen select disk 0 und die Partitionen anzuzeigen list partition. Damit kann man versuchen anhand der Partitionsgrößen und der Typ-Information auf die Linux-Partitionen zu schließen.
Deutlich komfortabler um Partitionen zu lokalisieren ist der Port von dd unter Windows mit dem Aufruf: dd.exe --list. Das zeigt alle bekannten Block-Devices und Partitionen an.

Leider sind mit dem Devicenamen /dev/hda nicht automatisch auch alle Partitionen auf /dev/hda eingebunden, weil der Treiber nicht selbstständig danach sucht. Vieleicht macht eine spätere Version von cobd dies möglich.

Intern werden für den Zugriff auf Blockdevices und Partitionen immernoch die Devices cobd0-9 angelegt. /dev/hda6 oder /dev/fd0 sind eigentlich nur Alias-Namen. Neu ist, daß man die nicht mehr manuell zuordnen muß, sondern daß es automatisch geht.

Das Kernel-Image

Den Pfad zum Kernel-Image gibt man schlicht mit Hilfe des Parameters kernel=. In den meisten Fällen steht hier nur:

# Das Kernel-Image
kernel=vmlinux 

Kernel Parameter

Um Linux die Lage seiner Boot-Partition mitzuteilen, braucht man die Kernel-Kommandozeile. Paramter die coLinux selbst nicht kennt, werden automatisch als Kernel-Kommandozeile durchgereicht. So z.B.

# Kernel Kommandozeile 
root=/dev/cobd0 ro

Das Erfolgserlebnis

Mit einwenig Glück kann man nun schon in ein Linux-System hineinbooten. Das geht auf der Kommandoeingabe per

c:\Programme\colinux\> colinux-daemon.exe @config.txt
Ist man sich bei der Zuordnung der Block-Devices nicht ganz sicher, lohnt es sich zunächst alle Partitionen als cobd1=, cobd2=, ... usw. zu definieren, mit init=/bin/bash auf der Kernel-Kommandozeile in ein Minimalsystem zu booten und in aller Ruhe unter Linux die Block-Devices /dev/cobd0, /dev/cobd1 anzuschauen.

Zuweisung von mehr Speicher

Aufgrund früherer Versionen ist die Speichermenge, die coLinux nutzt auf 32 MB festgelegt. Aktuell kann man aber viel mehr Speicher nutzen. Das wird mit dem Parameter mem= eingestellt. Bsp.:

# wieviel Speicher haben wir?
mem=128 

Die initiale Ramdisk (initrd)

Manche Distributionen bringen eine initiale Ramdisk mit, die verschiedene magische Einstellungen vornimmt, bevor schließlich das eigentliche Dateisystem gemountet werden soll. Die Ramdisk kann in coLinux mit dem Parameter initrd= eingestellt werden. Bsp.:

# Die initiale Ramdisk
initrd=initrd.gz

Zugriff auf Dateisysteme

Recht jung ist in coLinux der Zugriff auf Dateisysteme des Host-Systems. Dabei wird Linux kein Block-Device zur Verfügung gestellt. CoFS ist nur ein virtuelles Dateisystem wie /proc oder /sys dessen Zugriffe direkt in Dateioperationen des Windows-Hosts umgesetzt werden. Auf diese Art kann Linux z.B. normal lesend und schreibend auf das NTFS Dateisystem des Windows-Hosts zugreifen ohne irgendwas über NTFS wissen zu müssen. CoFS ist zur Zeit nur in den Snap-Shot-Versionen aus dem CVS zu erhalten. Konfiguriert wird der Zugriff auf Dateisysteme mit dem Parameter cofs0=, cofs1= usw. Beispiele für die Konfiguration der Zugriffes auf Dateisysteme unter coLinux:

# Fremde Dateisysteme
cofs0=d:\
cofs1=e:\
cofs2=a:\ 
In der /etc/fstab im Linux-Gast finden sich dann beispielsweise
0		/d/daten                cofs    user,noauto     0 0
1		/media/cdrom            cofs    user,noauto     0 0
2		/floppy                 cofs    user,noauto     0 0

USB Platten und Sticks

Bisher unterstützt coLinux USB Zugriffe gar nicht. D.h. will man z.B. einen USB-Stick unter Linux ansprechen geht das nicht über den von Linux gewohnten Weg. Es gibt aber 2 Alternativen: Entweder man richtet sich auf den entsprechenden Laufwerksbuchstaben von Windows ein CoFS ein oder schleift das Blockdevice, welches unter Windows den Zugriff auf den USB-Stick regelt als /dev/cobdn durch. Der erste Weg ist nervig, weil das CoFS kein Locking auf Device-Ebene machen kann und so Linux bei konkurierendem Zugriff manchmal stehen bleibt, wenn man zufällig unter Windows im selben Verzeichnis ist.
Das Weg über das Blockdevice ist allerdings sehr schick, weil man coLinux komplett auf ein noch gar nicht vorhandenes Block-device konfigurieren kann. Das startet auch so und greift erst zu, wenn man wirklich ein Dateisystem mounten will. D.h. wenn der USB-Stick nicht angeschlossen ist, startet coLinux dennoch. Ist der USB-Stick angeschlossen und greift Windows bereits darauf zu, gibt es eine Fehlermeldung. Greift Windows noch nicht darauf zu, kann man den USB-Stick ganz normal unter Linux mounten (vorrausgestzt man hat das richtige Dateisystem in den Kernel compiliert). So lange Linux den USB-Stick gemountet hat, kann Window nicht auf den entsprechenden Laufwerksbuchstaben zugreifen. Das ist deutlich eleganter als z.B. vmware mit den USB-Devices umgeht.
Konfiguriert wird das dann wie ein normales Blockdevice:

# USB Device unter Windows wie eine normale Festplatte
# colinux nervt nicht rum, falls die Platte nicht eingesteckt ist
sda1=\Device\Harddisk1\Partition1 

Netzwerk-Betrieb

Nachdem nun die Basis für unser Linux gelegt ist, ist eine Haupt-Anwendung sicherlich die Netzwerknutzung. Dazu dienen die Parameter eth0=, eth1= usw. Dieser Parameter hat 2 Attribute:

Konfiguriert wird das dann wie folgt:
# Die Netzwerkkarten
eth0=slirp
eth1=tuntap,"TAP" 

Kernel selber compilieren

Auf jeden Fall sollte man darüber nachdenken, den coLinux Kernel selbst zu compilieren. Zum einen ist der Distributions-Kernel meist veraltet. Zum anderen fehlen momentan NLS und CHARSET-Support sowie das UDF in dem Kernel. Desweiteren erhält man tieferen Einblick in die Arbeitsweise von coLinux.
Die nötige Basis .config findet sich im /proc-Filesystem als /proc/config.gz. Der Patch, welche einen normalen Linux-Kernel mit den coLinux-Devices ausstattet, ist im Source-Tarball von coLinux unter patch/linux zu finden.
Danach kann man eigentlich loslegen und den Kernel anpassen. Vorsicht vor allen hardwarenahen Treibern. Die werden selbstverstäntlich nicht von coLinux abgebildet.
Zu beachten ist noch, daß coLinux momentan auf den gcc-3.3 besteht.
Anbei ist mein selbst compilierter 2.6.11.5, der mit daemons-20050322.zip zusammenarbeitet.

Die Console

Nach dem Start von coLinux erscheint die Cooperative Linux Console mit den Kernel-Meldungen und den Meldungen der Distribution zum Systemstart. Diese Console ist nur ein Frontend für den coLinux-daemon, der im Hintergrund auch ohne diese Console weiterlaufen kann. D.h. das Beenden der Konsole beendet coLinux nicht.
Persönlich verwende ich die Cooperative Linux Console überhaupt nicht, weil sie sehr langsam ist. Stattdessen logge ich mich per ssh auf meinem coLinux ein und habe damit eine vollwertige Terminal-Emulation, mit ordentlicher Tastatur und voller Geschwindigkeit.
Im laufenden Betrieb ist es jederzeit möglich die Cooperative Linux Console zu starten und damit den laufenden coLinux-daemon anzusprechen.

Abschluß und Ausblick

coLinux ist zur Zeit sicherlich noch nicht reif für den Massenmarkt. Dem Bastler bietet die Software jedoch bereits eine erstaunlich stabile, sehr schnelle und resourcenschonende Art Linux unter Windows zu betreiben. Als Alternative zur VMware oder der Cygwin-Shell taugt das System so schon allemal. X11 kann momentan per vnc oder einem nativen Windows-X11-Server realisiert werden. Vieleicht überascht der CoFB noch mit einer flotten nativen X-Konsole.

Weitere Informationen

Last update was on Thursday, 17-Nov-2005 by Sven Dickert