Is it possible to run a new kernel under coLinux without applying any coLinux patches, you ask? It is, using User-mode Linux. Take a look at this picture! It was created by hitting [Print Scr] and resizing to 75%.
Here is my .config file. Rename this download to ".config" and move it to your linux-2.6.23-rc2-build directory. Media:linux-2.6.23-rc2.config.xcf. I'm not a kernel / Linux / net / everything Guru so if someone else wants to fix up this page with some comments - be my guest.
- 1 Build coLinux from source
- 1.1 Try newest coLinux version
- 1.2 Expanding disk space
- 1.3 Get a newer Linux kernel (any version) to run under coLinux
- 1.4 To use UML you must expand your root_filesystem (or create another drive)
- 1.5 Install new coLinux-patched vmlinux and coLinux-patched kernel modules
- 1.6 Get newer Linux kernel patches - fourteenth version number
- 1.7 Build colinux kernel
- 1.8 Basic networking, tuntap for X11
- 2 Building UML
- 3 Start UML
- 4 Full routed network with UML under coLinux
- 5 conclusions
Try newest coLinux version
The first step (optional), is to get the newest coLinux available.
Try here: http://www.colinux.org/snapshots/ - You can try newest version, devel-colinux-20070412-gcc412 works without problems.
Get devel-colinux-*.tar.gz and build it (read the "building" DOCs included with it).
The day as this text was written, it was devel-colinux-20070412-gcc412.tar.gz. Same kernel and same gcc exist now as coLinux-0.7.2-src.tar.gz
Expanding disk space
While it builds make a couple of spare virtual HDs. See here for some tips: ExpandingRoot
You will want one drive to be 2GB and the second around 6GB the third maybe 8-12GB.
The first drive will be used to mount under coLinux with kernel version 2.6.17.x (I'll call this Linux_1) to copy the 2.6.22 (or whichever version) modules (and source) over to so it can be "loop mounted" in the new Linux and the modules installed (then re-boot).
The second will be used to expand the root_filesystem image you choose since the one from the UML site is on a 1.5GB drive (that is too small).
The third will be the coLinux mounted HD (but you move it inside your coLinux virtual HD and then add it directly to the new kernel's command line (ubdX) and mount it there) that holds the higher version of the kernel and the root_filesystem that you will be running (the NEW Linux (Debian, Fedora, etc) can be the same as you are running now or different.
Basically you need the 2GB for the modules and source, 6GB to expand to new root_filesystem (if it is less than 2GB) and the 8-12GB drive to hold everything without eating up space on your coLinux virtual HD. Once the modules are installed you can delete the 2GB drive (if you will never need a tmp drive again and are short on space on your WinXP drive).
Get a newer Linux kernel (any version) to run under coLinux
While you are building coLinux 0.8.0 (step 1) and making some more virtual HDs (step 2) you can download a newer version of the Linux kernel from http://www.kernel.org/pub/linux/kernel/v2.6/ (I'll call this Linux_2).
Choose a new version (but NOT _the_ newest - since you don't want too many bugs).
Added Comment - Aug 7, 2007 - I have linux-2.6.23-rc2 running (it is the newest at the moment) and it does not seem to be buggy. It only adds a few features to the 2.6.22 series so you might want to get the newest .22 series for stability sake - it's your computer, your choice.
Something from 2.6.22 is likely going to be better than a bleeding edge kernel - but get what you want ! If you want the same version as the UML page at sourceforge is using (to make thier instructions easier the first time you try this) then get this file: http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.22-rc2.tar.bz2
The newest kernels have more features. Get a 4 digit kernel with the last number the highest possible and the second to last number one less than the highest number possible. If you want a high end Firewall get the newest kernel.
To use UML you must expand your root_filesystem (or create another drive)
While the drives are copying (an hour, at least) and the kernel building open and read these web pages: http://user-mode-linux.sourceforge.net/ and http://user-mode-linux.sourceforge.net/source.html . You can Google other sites for help too.
You can get the example root_filesystem from there (Fedora 5) that you can use instead of your current Linux OS or keep your current one if it is your preference. Thier example executable and root_filesystem have no modules so you will need the source code from kernel.org in any event if you want to boot without a lot of warnings.
It is likely better to simply get the kernel version you prefer from kernel.org (since you will need to build the kernel anyway) and either use their Fedora image or the image you are using now.
To use the root_filesystem image you are using now (your current Linux OS) you will need to either trim it's size and/or make a new larger virtual HD. The root_filesystem that you run as your second Linux version must be small enough to be copied into your coLinux virtual HD, or your coLinux vitual HD must be big enough (by expanding the root_filesystem) to hold a smaller copy of your current Linux OS's root_filesystem. This is because you are running Linux inside (under) coLinux (not from the DOS command line) so one needs to fit inside the drive of the other.
Take the small root_filesystem and copy it into a much bigger virtual HD containing your current root_filesystem. If you have a 2GB Debian root file_system then make a copy of it and create an 8GB virtual drive. Copy the copy into the virtual drive and make sure it boots. Next shutdown and copy the 2GB file into the 8-12GB file (cofs mount it) and move it into your /UML directory. Like a big fish swallowing a small fish. This "file in the file" won't run when you start coLinux, it is for when you start the new kernel, it needs a file system to read for it to boot.
If someone know a simpler way to try to explain that, go ahead. I made the explanation long so it would be clearer (hopefully).
If you don't get all the virtual HD's created (step 2) and have finished studying those web pages by this time then just go on to the next step and come back to finish what is left to do later. Try to at least get the 2GB virtual HD created first since you need it first. If you are using the DOS command line to copy swap files together (copy /b swap+swap+swap newdrive.ext3.6GB) you can hit CTRL-C to stop the copy (if it is not ready when you wish to re-boot) and later use trunc or resize to fix the size. It takes a long time to copy together swap files to make a bigger virtual HD (of a few gigs in size) but don't let it stop you from re-booting when you wish to, just do it and come back and fix things.
Install new coLinux-patched vmlinux and coLinux-patched kernel modules
After everything above is done install the fresh vmlinux (on WinXP by copying it through cofs0) and the modules go into /lib/modules (on coLinux virtual HD - just let "make modules_install" do it). Be certain to compile with module versioning on so you don't overwrite your old modules. Now type "shutdown -h now" to exit and then start coLinux again in the usual manner.
At this point in the directions when you start coLinux and type "dmesg | gcc" you will see that you are running coLinux version 2.6.17-co-0.8.0 (built with gcc 4.2.1) You have not yet patched coLinux with the newest Linux patches (coLinux patches are the only ones installed at this point).
Get newer Linux kernel patches - fourteenth version number
You now have kernel 2.7.17(.0)-co-0.8.0 running. Go to site: http://www.kernel.org/pub/linux/kernel/v2.6/ to check for the newest patches - if it is still .14 then change to your download directory and type this to get it:
Change to your linux-2.6.17-source directory and type something like this:
bunzip2 -d -k -c /downloads/patch-22.214.171.124.bz2 | patch -p1 2>&1 \ | tee ../p-126.96.36.199_log.txt grep -v patching ../p-188.8.131.52_log.txt
There should be only a couple of small rejects - fix them. The reason you will have rejects is because these are Linux patches for Linux - they are not supposed to be used for for coLinux. I have tested version .14 and it does work with coLinux, newer versions might not.
Lets be clear about this.
- The coLinux patches are applied to Linux to make it coLinux.
- The Linux patches are applied to Linux.
- You are not supposed to apply Linux patches to coLinux.
- I'm telling you that the Linux version 184.108.40.206 patches can be applied to coLinux.
- Higher versions of Linux patches might break coLinux and screw your data.
- You do NOT need to do this to use UML, but it makes sense that .14 is better than .0 !
If that is too hard then go no further - time for more reading / learning.
Build colinux kernel
Build, install, re-boot to get coLinux with kernel 220.127.116.11-co-0.8.0 . Change to the build directory beneath your linux-2.6.17-source and you can either rename it linux-18.104.22.168-source so your not confused or leave it as-is (so if you ever try the 'official' coLinux build routine the scripts will see that you have a kernel build and will not rebuild it).
The upgrade of coLinux is optional as far as running the newest kernel is concerned since this method will allow you to run a new kernel on an old one (though some features may not work). It makes sense to use the newest coLinux possible and patching up to .14 from .0 is very easy (though not officially supported by the authours of this website).
I've used the above version for a while now - it works well but don't complain if it breaks since the authors of coLinux don't want to fix this hack - they only support official versions. So if you leave it at .0 and don't change it to .14 then you can make bug reports to the authors. If you patch above what is supported then you need to Google for help, check the forums, or post a question at the bottom (if you must).
Alter your colinux.conf file to mount all the new virtual drives you created. Later, the 6GB drive can be copied through your /mnt/windows drive to coLinux's new 8GB drive once you've expanded the Fedora (or whicher version of Linux OS you like). You might do this by adding these sort of lines to your coLinux.conf:
cobd2=c:\colinux\drive_2.ext3.2GB cobd3=c:\colinux\drive_1.ext3.6GB # http://uml.nagafix.co.uk/FedoraCore5/FedoraCore5-x86-root_fs.bz2 (1.5GB (90M)) cobd5=c:\colinux\FedoraCore5-x86-root_fs cofs0=c:\ # Setup fast X11 networking too eth0=tuntap eth1=pcap-bridge eth2=slirp
Basic networking, tuntap for X11
For help with the networking see pages Network Introduction and CoLinux on Linux. You may need to tunnel into your second Linux with ssh, that is what I am doing at the moment. I can also run it on Cygwin's X11. I'm still working on "perfect" network scripts which I will post here when I get them perfected (instead of needing to tunnel) - help here would be appreciated (post your tips after you get it running, please).
The MS loopback driver should be at 10Mbps and the TAP-Win32 Adapter should run at 100Mbps. Connect coLinux to Cygwin's X11 on the fast link. You should be able to play DVDs at 1/4 screen size reasonably, but not perfectly (with a newer, fast computer) or you don't have your system setup correctly.
If you run a "Network Bandwidth Monitor" program you will see that playing DVDs uses about 18 Mbits / second so you don't want to use the 10Mbps link for XWindows or X11 will be slower than it should be.
The prior paragraph does not mean that you should play DVDs on coLinux - they play poorly. It is simply a good way to make the system processor very busy and try to push as much data through your X11 connection as possible.
If a 1/4 screen size DVD looks awful (and you have a fast computer), then something is wrong - fix it. If a 1/4 screen size DVD looks reasonably good (but not perfect) then you have X11 networking setup OK and are getting as much performance as you can hope for. If someone has a better test, post it.
A fast X11 network is essential to your enjoyment of coLinux and not impossible to acheive.
Create a shell script to start Xterm and enjoy a large screen instead of coLinux's small console.
#!/bin/sh echo Starting Xterm export DISPLAY=192.168.37.20:0 xterm -bg black -fg white -fa Arial_bold -fs 12 -geometry 120x32+15+5 \ -title "coLinux Xterm" -sb -rightbar -sl 10000 +cm +bdc
Un-tar your new Linux kernel sources
Untar your new kernel source in your /colinux/build directory (don't overwrite your old /colinux/build/linux-2.6.17.x-build !) with a command like this:
tar --bzip -xf /download/linux-2.6.22-rc2.tar.bz2
Do NOT apply any coLinux patches to this Linux kernel.
Now you have a directory which might be /colinux/build/linux-2.6.22-rc2 (depending on where you have your coLinux directories). Rename it and create a seperate build directory for the new kernel (Linux_2). The reason I use the word "might" is because you may have set things up differently and would have to type something different. If you set things up exactly the same then change might to should (or must, it's your system; do what you like).
cd /colinux/build mv linux-2.6.22-rc2 linux-2.6.22-rc2-source mkdir /colinux/build/linux-2.6.22-rc2-build
Now you might type this: "ls -l /colinux/" and see something like this:
drwxr-xr-x 14 root root 10240 Aug 4 21:13 build drwxr-xr-x 7 1000 users 1024 Jul 3 11:25 devel-colinux-20070412-gcc412 -rw-r--r-- 1 root root 3256320 Jun 22 20:10 devel-colinux-20070412-gcc412.tar drwxr-xr-x 7 1000 users 1024 Jun 22 20:41 devel-colinux-20070511 drwxr-xr-x 2 root root 1024 Apr 23 17:11 dist drwxr-xr-x 2 root root 1024 Jul 18 07:53 download drwxr-xr-x 2 root root 1024 Jul 24 02:46 log drwxr-xr-x 9 root root 1024 Jun 23 13:18 mingw32
Now you might type this: "ls -l /colinux/build" and see something like this:
drwxrwxrwx 15 400 401 1024 Jan 22 2006 binutils-2.16.91-20060119-1 drwxr-xr-x 19 root root 1024 Jul 26 21:43 linux-2.6.17-build drwxrwxrwx 19 root root 1024 Jul 23 00:49 linux-2.6.17-source drwxr-xr-x 20 root root 3072 Aug 2 17:55 linux-2.6.22-rc2-build drwxr-xr-x 19 root root 1024 Aug 2 09:22 linux-2.6.22-rc2-source -rw-r--r-- 1 root root 188 Jul 22 13:25 p-22.214.171.124_log.txt
Get the UML patches from sourceforge - they might be here:
ONLY patch ONE file (don't bother with all the patches, read them to see why).
Patch file linux-2.6.22-rc2-source/arch/um/os-Linux/user_syms.c so you can compile without errors. It is a tiny patch that is necessary to build, most of the other patches do not apply to x86 or break something else. Kernel version linux-2.6.23-rc2 seems to build fine without this one patch so you can run .23-rc2 UML without any patches whatsoever. The .22-rc2 version needs the patch.
Build the UML kernel
Change to your kernel build directory and type something like (change to suit your directories):
cd /colinux/build/linux-2.6.22-rc2-build make -C /colinux/build/linux-2.6.22-rc2-source O=/colinux/build/linux-2.6.22-rc2-build defconfig ARCH=um
Now (in your build directory) type:
make ARCH=um vmlinux modules modules_install
This will install the new kernel's modules (Linux_2 modules) in your present coLinux root_filesystem image (where they won't be used by linux-126.96.36.199), you have them copied there as a backup and they will work when copied over to the new kernel's root_filesystem.
Follow the advice at ExpandingRoot to make your root_filesystem image (FedoraCore5-x86-root_fs ? ) bigger since at 1.5 GB it won't hold the modules and much else. Next rename it to something like FedoraCore5-x86-root_fs.ext3.6GB so you know the filetype and size.
You can copy (or move) the 8GB drive through your windows mount (cofs0) to your coLinux virtual drive (to hide it from windows) and mount it inside coLinux as /UML --OR-- you can leave it on your windows drive and colinux-mount it with cobdx and then again mount it inside coLinux to /UML .
Into this /UML drive (in coLinux's virtual HD) copy your newly built vmlinux to /UML/UML-linux-2.6.22-rc2 and the new OS root_filesystem image (Linux_2) to /UML/FedoraCore5-x86-root_fs.ext3.6GB .
installing modules for UML
Copy the modules from the coLinux /lib/modules/?? directory to the cobdx drive that is 2GB in size after mounting it like this:
mount -t ext3 /UML/drive_spare.ext3.2GB /tmp/newfs -o loop cp --preserve=all /lib/modules/2.6.22-rc2/* /tmp/newfs/lib/modules/2.6.22-rc2/ cp -r --preserve=all /lib/modules/2.6.22-rc2/kernel/* \ /tmp/newfs/lib/modules/2.6.22-rc2/kernel/ umount /tmp/newfs
That copies all the modules - you might want the source but not the build links (if HD space is an issue).
Run UML from coLinux prompt
Now you can run it like it was any other linux program. In coLinux type this:
./UML-linux-2.6.22-rc2 ubda=/UML/FedoraCore5-x86-root_fs.ext3.6GB \ ubdb=/UML/drive_spare.ext3.2GB mem=256M eth0=tuntap,,,192.168.0.254
Note: UML-linux-2.6.22-rc2 is what you renamed vmlinux to after compiling it UML.
Do NOT try typing that from the DOS command line. Linux executables don't run under DOS but do run under coLinux.
That runs the new Linux kernel inside the old kernel version hosted on coLinux - which runs on WinXP and is accessed via XWindows running on Cygwin X11 (could use VNC? have not tried).
Login (without a password) as root (if using the sourceforge root_filesystem for FC5) and type "passwd root" to set a password (so you can login using ssh (which requires a passworded account) you might make the password 'root' for testing use).
Now mount the drive with the modules you just copied and copy them to the 6GB expanded OS root. (Later, when you reboot the NEW OS (run it inside coLinux), you can remove the 2GB drive and keep the 8-12GB one).
mkdir /mnt/newfs mount -t ext3 /dev/ubdb /mnt/newfs cp -r --preserve=all /mnt/newfs/lib/modules/* /lib/modules/ cp -r --preserve=all /mnt/newfs/opt/colinux/build/linux-2.6.22-rc2-source/* \ /opt/colinux/build/linux-2.6.22-rc2-source/
Login into UML
Login to FC5 2.6.22-rc2 (Linux_2) from Linux_1 (188.8.131.52):
ssh -Y -l root 192.168.0.253
Type the 'root' password and you should see the screen-shot at the top of this posting.
Now you can configure the Linux kernel with many more options than before and you don't need to use coLinux patches on the new kernel. More software is compatable, though the networking is a bit tricky.
You can also use the new kernel to run a firewall for the old kernel in a chroot jail and have all the fancy new kernel security features work for the old kernel! Keep the new kernel hidden or keep the old kernel hidden and use one to protect the other. There are lots of things you can do now.
This next section was kindly added by someone else.
coLinux acts as a "router" and should forward all tcp and udp packets.
You don't need pcapBridge or other bridges, no loopback device on windows side, and no ICS. Its just the TAP-Win32-Device for coLinux, a real Ethernet LAN card for Windows and SLiRP inside coLinux for internet.
network basics for routing
For routing we need 2 separate networks. For routing to the internet, we need 3 networks. Between every PC (virtual or real) there is one private network. All the networks must be different in the first 3 numbers (assume, that we use 255.255.255.0 a typical class C network). In one network all the virtual network cards must start with the same 3 numbers. A network has two or more end points.
- Network 192.168.0.x - Windows Network to the world. Be sure, that no other networks (coLinux, UML) starts with this numbers. ipconfig
- Windows Ethernet LAN: 192.168.0.71
- Windows default gateway and DNS: 192.168.0.xxx (does no matter here)
- Network 192.168.37.x - private between coLinux and Windows (TAP-Win32)
- Windows TAP: 192.168.37.20
- coLinux eth0: 192.168.37.222 (I'm not known yours, and use .222 here)
- Network 10.0.2.x - private network inside coLinux for outgoings (NAT, Firewall to the world)
- coLinux eth1: 10.0.2.15/255.255.255.0
- coLinux default gateway: 10.0.2.2 (route over SLiRP)
- coLinux DNS: 10.0.2.3
- Network 192.168.10.x - private Network between coLinux and UML
- coLinux tap0: 192.168.10.254
- UML eth0: 192.168.10.253
For understanding static routings you should know, that network connections works automatically only in the same network. Tat is, a network card with 192.168.37.222 can only directly talk with cards in the same network 192.168.37.x (x is 1 - 254). To talk with other addresses (for example from Windows 192.168.37.20 to 192.168.10.253), the caller must know the Router what works on both networks (192.168.37.x and 192.168.10.x) - this is coLinux. To solve this problem, you set static routes. Which says to windows, that the network 192.168.10.0 is available behind the network card 192.168.37.222. The way to the 192.168.37.222 Windows knows. This is in the one network with the TAP-Win32 192.168.37.222. Windows will send the packet to TAP-Win32 adapter. coLinux receives this packet, knows the network 192.168.10.0 (or single address from uml_net) on the interface tap0 and forwards this packet to tap0 - to UML. To send packets back from UML to Windows an other static route must be set inside UML with the way back.
Disable your Windows firewall, if you are configuring this for the first time. After it is working, you can enable the firewall and allow open some ports step by step. - For the first steps it is better that the firewall doesn't block your settings. ;-)
Reply: Question: *Windows TAP: 192.168.4.71 ''(is your 192.168.37.20)'' Answer: I call XTerm with a script that sets DISPLAY=192.168.37.20:0 . A Henry: OK. Changed. Question: *coLinux tap0: 192.168.10.3 ''(is your 192.168.0.254)'' Answer: I started UML_Linux with "eth0=tuntap,,,192.168.0.254" . A Henry: OK. Changed. Question: *UML eth0: 192.168.10.1 ''(is your 192.168.0.253)'' Answer: I read http://xfree86.cygwin.com/docs/ug/using-remote-apps.html and typed "ifconfig". I used "eth0=tuntap,,,192.168.0.254" to start UML but the ifconfig program says my interface is at 192.168.0.253 so that is the number I used to 'ssh' into UML. I don't know why it is one number off but I can connect. A Henry: Yes, it's some automatic sets there. The 192.168.0.253 is a big problem for me. This blocks me from using 192.168.0.x under Windows for the Ethernet card. 192.168.0.x is very often used for private routers (WLAN, DSL). We can use any free network here, but not the 192.168.0.x, not the 192.168.37.x and not 10.0.2.x I'm use 192.168.10.x for UML now. Usable for you to? Q Henry: What's the address for TAP-Win32 on coLinux side? (I used 192.168.37.222) Q Henry: What's the network for real Ethernet? (I used 192.168.0.x) I will try your suggestions and fix for my setup. It would be great to have FULL network connectivity so you can simply start coLinux and use a script to start UML then use UML as if it was regular Linux system (only no direct hardware access, just like coLinux).
I have a new networking page at Cellphone Internet connection that I have been busy with and I am going to install the new kernel from http://www.colinux.org/snapshots/ and have been busy with other things too. I appreciate your efforts to put out the new version and type some info here to get the networking going for UML. I'll be back to this page to add some more.
Run UML with net
On coLinux run UML with tuntap, set the path to UML helper programs (uml_net), set the DISPLAY to your Xming (or CygwinX):
export PATH=umlbin:$PATH export DISPLAY=192.168.37.20:0.0 sudo ./vmlinux-2.6.22-rc1-um1 umid=id1 ubd0=umlrootfs.img con=xterm \ con0=fd:0,fd:1 eth0=tuntap,,,192.168.10.254
uml_net must run as root. If you not have the programm uml_net working, needs to setup many of things by hand after start of UML (see kernel docs UserModeLinux-HOWTO.txt).
This should popup multipe Xterm with login prompts. One Xterm for every login console inside the umlrootfs.img uml-xconsole
Set IP-Adress inside UML:
UML# ifconfig eth0 192.168.10.253
The routing table inside coLinux was changed by UML, that's now what you see:
coLinux# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.10.253 0.0.0.0 255.255.255.255 UH 0 0 0 tap0 192.168.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
The current ifconfig inside coLinux is now:
coLinux# ifconfig eth0; ifconfig tap0 eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55 inet addr:192.168.37.222 Bcast:192.168.37.255 Mask:255.255.255.0 ... tap0 Link encap:Ethernet HWaddr 00:FF:69:DB:76:CE inet addr:192.168.10.254 Bcast:192.168.10.255 Mask:255.255.255.255 ...
Enable ip forwarding inside coLinux (mostly done by the UML automaticly):
coLinux# echo "1" > /proc/sys/net/ipv4/ip_forward
Inside UML must set as gateway the coLinux side (192.168.10.254) from tuntap (tap0) for the TAP-Win32 network (192.168.37.0):
UML# route add -net 192.168.37.0 netmask 255.255.255.0 gw 192.168.10.254
See the routing inside UML now:
UML# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.37.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
On Windows, set the ipaddress from coLinux side of TAP-coLinux (192.168.37.222) as gateway for UML network (192.168.10.0):
C:\> route add 192.168.10.0 mask 255.255.255.0 192.168.37.222 metric 1
See the output from windows route (free translated from german): uml-winxp-side
C:\> route print =============================================================== Device list 0x1 ........................... MS TCP Loopback interface 0x2 ...00 ff 08 2b 97 78 ...... TAP-Win32 Adapter V8 (coLinux) 0x10004 ...00 a0 cc d5 07 a0 .. SiS 900 PCI Fast Ethernet Adapt =============================================================== Current routes: Destination Netzmask Gateway Interface Count ... 192.168.10.0 255.255.255.0 192.168.37.222 192.168.37.20 1 ...
Can directly access from windows to UML and the way back now:
C:\>ping 192.168.10.253 Ping runs for 192.168.10.253 with 32 Bytes Data: Answer from 192.168.10.253: Bytes=32 Time=8ms TTL=63 Answer from 192.168.10.253: Bytes=32 Time=2ms TTL=63 Answer from 192.168.10.253: Bytes=32 Time=1ms TTL=63 ...
C:\>tracert 192.168.10.253 Tracerroute to 192.168.10.253 over max 30 Hops 1 <1 ms 1 ms <1 ms 192.168.37.222 2 1 ms 1 ms 5 ms 192.168.10.253
C:\> putty.exe 192.168.10.253
This was the private network between Windows - over coLinux - to UML. Routing table in coLinux was not changed at this point here. CoLinux works as router and forwards all packets from one to the other network.
Lets UML going to the world
Now, lets set and view with SLiRP for outgoing internet access. eth1 was configured as "eth1=slirp" under windows.
eth1 is 10.0.2.15/255.255.255.0 inside coLinux. You can permanently configure it with your distributions tools, or for this session by hand on command line:
coLinux:/ # ifconfig eth1 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
Add the default gateway under coLinux. To avoud problems with double default gateways, it's a good idea to clear the oldy first:
coLinux:/ # route del default coLinux:/ # route add default gw 10.0.2.2
Lets compair the routing now: uml-colinux-routes
coLinux:/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.10.253 0.0.0.0 255.255.255.255 UH 0 0 0 tap0 192.168.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth1
Add the default gateway under UML. The adress (192.168.10.254) is the tap0 on coLinux side: uml-route-default
UML# route del default UML# route add default gw 192.168.10.254 UML# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.37.0 192.168.10.254 255.255.255.0 UG 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth0
In theority can remove the fixed route for network 192.168.37.0 now. This is double here. But, is better. If any programms would remove the default route, then the static route from UML to the windows would not broke.
Set 10.0.2.3 as DNS inside UML:
UML# echo "nameserver 10.0.2.3" > /etc/resolv.conf
The 10.0.2.3 is a virtual DNS-Server inside coLinux. Be remember, that you can't ping this address. But, you can ping from UML to the Windows side of SLiRP router:
UML# ping 10.0.2.2 -c 3 PING 10.0.2.2 (10.0.2.2): 56 data bytes 64 bytes from 10.0.2.2: icmp_seq=0 ttl=254 time=0.0 ms 64 bytes from 10.0.2.2: icmp_seq=1 ttl=254 time=0.0 ms 64 bytes from 10.0.2.2: icmp_seq=2 ttl=254 time=0.0 ms ...
UML can access directly to the world now:
UML# wget www.google.com
Be remember: SLiRP dosn't support IMCP pings. So you can not ping to any sites.
On the windows side needs nothing to change. SLiRP is hidden from out side of your Windows.
Picture with login from Windows putty directly to UML: uml-putty-ssh
For all the commands ifconfig and route you need to find the right place inside your distribution to have this config on every boot. If you can't find the right setup files, then add a new script under the startups (inside init.d/rc5.d or so) and write all the single commands from this chapter in such file.
If you replace SLiRP with pcapBridge for coLinux, then can do more with ping, but need also more setups (more routings...), IP forwarding under Windows and has problems with WLAN non duplicatable MACs (promisc). - This can be an other lesson.
Optimising the static addresses
If you logging in via ssh the sshd would try to check your host address an would resolve into the name. This is typicaly to see as delay on logins. For faster login set all the known ipaddresses in the file /etc/hosts:
# Windows Ethernet 192.168.0.71 WinXP.domain WinXP
# TAP-Win32 192.168.37.20 coWin.colinux coWin 192.168.37.222 coLinux.colinux coLinux
# TAP-UML 192.168.10.254 coLinux.colinux coLinux 192.168.10.253 umlLinux.colinux umlLinux
# SLiRP 10.0.2.2 slirp-router.colinux slirp-router 10.0.2.3 slirp-dns.colinux slirp-dns 10.0.2.15 slirp-client.colinux slirp-client
Set the adresses in coLinux and also in UML (in UML without the SLiRP).
That may be tough to follow, can someone else explain better ?
How things are 'exactly' depends on what kernel you decide to build and what you decide to name your directories (etc.), if you do the same as above before you alter everything it will be easier to follow the instructions.
AFTER you are able to get a screen-shot like at the top then do your own thing.
After you are finished you might have a (PARTIAL) directory structure on coLinux (depending on what you did) something like this:
/colinux/build/... /colinux/build/linux-2.6.17-build/... /colinux/build/linux-2.6.17-source/... /colinux/build/linux-2.6.22-rc2-build/... /colinux/build/linux-2.6.22-rc2-source/... /UML/... /UML/FedoraCore5-x86-root_fs.ext3.6GB /UML/drive_spare.ext3.2GB
After you are finished you might have a (PARTIAL) directory structure on WinXP (depending on what you did) something like this:
C:\colinux\netdriver\ C:\colinux\coLinux.conf C:\colinux\*.exe C:\colinux\*.txt C:\colinux\Debian-3.0r2.ext3-mit-backports.14gb (make this drive huge) C:\colinux\drive_spare.ext3.8GB (optional, could all be on one drive)
network flow graph
The data flow network model is like this:
100 100 10 or 100 |-----| Mbps |---------| Mbps |---------| Mbps |----------| | UML |-------| coLinux |-------| WinXP |-----------| Internet | |-----| |---------| |- - - - -| |----------| \____________| CygwinX |_ 100 |---------| \_|---------| Mbps | WinXP's | | Video | | Monitor | |---------|
The best X11 performance will be obtained if you ensure that you do NOT use 10Mbps data-flow paths for X11 since it needs almost 20Mbps (this may vary with different computer setups - test as explained above).
The executable model is like this:
|-------------------------| | Your Computer | | | | |-------------------| | | | Windows XP | | | | | | UML runs on coLinux and connects to coLinux | | |-------------| | | (and nothing else, not even the hardware). | | | coLinux | | | | | | | | | | | | |-------| | | | coLinux runs on WinXP and connects to | | | | UML | | | | UML and WinXP (and not the hardware). | | | |-------| | | | | | | | | | | | |-------------| | | WinXP run on your computer and connects to | | | | coLinux (and your hardware, directly). | |-------------------| | | | |-------------------------|
There are pages on this site that will help you out. That is how I figured this out.
There is a similar idea on page CoLinux on Linux - that page is about "coLinux on Linux". This page is about "Linux on coLinux".
Read Dan's article at http://www.colinux.org/publications/Reprint-Aloni-OLS2004.pdf . See page 10, section 5.2 says that we need someone to do what is described on this page.
Comment From Henry 
- talk about UML screen - coLinux kernel self is hidden in background