| [ Wie kriegt man Linux unter Windows zum fliegen? ] | activities | address | index | podcast | remote | hacks | working |
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
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.
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.
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
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\Floppy0In der /etc/fstab im Linux-Gast finden sich dann beispielsweise
/dev/hda6 / ext3 defaults 1 1 /dev/fd0 /floppy auto user,noauto 0 0Die hier verwendeten Pfade sind Windows-Pfade zum Dateisystem. Das ist bei den runtergeladenen, angepaßten Distributions-Dateisystemen der Pfad zu der entsprechenden Datei.
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.
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
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
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.txtIst 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.
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
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
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
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
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:
eth0=slirp,"",tcp:22:22/tcp:80:80Angesprochen werden die Dienste über die IP-Adresse des Windows-Host Systemes.
# Die Netzwerkkarten eth0=slirp eth1=tuntap,"TAP"
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.
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.
Last update was on Thursday, 17-Nov-2005 by Sven Dickert