coLinux
Register
No edit summary
(fix link to source)
 
(45 intermediate revisions by 11 users not shown)
Line 1: Line 1:
Is it possible to run a new kernel under coLinux without applying any coLinux patches you ask. Take a look at this picture<ref>[[Talk:NewKernel|talk about faked screen]] - coLinux dosn't run without coLinux patches</ref> ! Read '''carefully''' before you say it doesn't work.
+
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%.
   
[[Image:CoLinux-2.6.23-rc2.gif|http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.23-rc1.bz2]]
+
[[Image:CoLinux-2.6.23-rc2.gif|http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.23-rc2.tar.bz2]]<br>
   
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]]
+
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.
   
  +
==Build coLinux from source==
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.
 
  +
===Try newest coLinux version===
 
  +
The first step (optional), is to get the newest coLinux available.
 
1. The first step (optional), is to get the newest coLinux available:
 
   
 
Try here:
 
Try here:
http://www.henrynestler.com/colinux/testing/devel-0.8.0/20070412-gcc412/
+
http://www.colinux.org/snapshots/ - You ''can'' try '''newest''' version, devel-colinux-20070412-gcc412 works without problems.
   
Get devel-colinux-20070412-gcc412.tar.gz (or newer) and build it (read the DOCs).
+
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 [http://downloads.sourceforge.net/colinux/coLinux-0.7.2-src.tar.gz coLinux-0.7.2-src.tar.gz]''
   
  +
===Expanding disk space===
2. While it builds make a couple of spare virtual HDs. See here for some tips:
 
  +
While it builds make a couple of spare virtual HDs. See here for some tips: [[ExpandingRoot]]
http://colinux.wikia.com/wiki/ExpandingRoot
 
   
 
You will want one drive to be 2GB and the second around 6GB the third maybe 8-12GB.
 
You will want one drive to be 2GB and the second around 6GB the third maybe 8-12GB.
Line 29: Line 29:
 
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).
 
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).<br>
3. While you are building coLinux 0.8.0 (step 1) and making some more 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).
 
  +
'''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.
 
Choose a new version (but NOT _the_ newest - since you don't want too many bugs).
 
   
 
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
 
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.
+
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)===
4. While the drives are copying (and 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.
 
  +
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 one or keep your current one if it is your preference. Thier example executable and root_filesystem has no modules so you will need the source code from kernel.org in any event.
+
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 your current root_filesystem you will need a tiny copy of it. 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 file 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) as a file in your /UML
 
  +
directory. Like a big fish swallowing a small fish. The 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.
 
  +
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 [[ExpandingRoot|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 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 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 ===
   
5. 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.
+
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===
6. 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:
 
  +
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:
   
 
wget -nv http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.14.bz2
 
wget -nv http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.14.bz2
Line 66: Line 74:
 
</pre>
 
</pre>
   
  +
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.
There should be only a couple of small rejects - fix them.
 
  +
  +
<br>
  +
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 2.6.17.14 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.'''
 
   
  +
'''If that is too hard then go no further - time for more reading / learning.'''
   
  +
===Build colinux kernel===
7. Build, install, re-boot to get coLinux with kernel 2.6.17.14-co-0.8.0 . Change to the build directory beneath your linux-2.6.17-source and you can either rename it linux-2.6.17.14-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).
 
  +
Build, install, re-boot to get coLinux with kernel 2.6.17.14-co-0.8.0 . Change to the build directory beneath your linux-2.6.17-source and you can either rename it linux-2.6.17.14-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).
 
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 Henry will appreciate any bug reports you might wish to send.
+
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:
 
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:
Line 91: Line 109:
 
</pre>
 
</pre>
   
  +
===Basic networking, tuntap for X11===
See http://colinux.wikia.com/wiki/Network#Introduction for info on setting up networking.
 
  +
For help with the networking see pages [[Network#Introduction|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.
 
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.
Fast X11 is essential to your enjoyment of coLinux and not impossible to have. Create
 
  +
a shell script to start Xterm and enjoy a large screen instead of coLinux's small console.
 
  +
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.
   
 
<pre>
 
<pre>
Line 102: Line 128:
 
echo Starting Xterm
 
echo Starting Xterm
 
export DISPLAY=192.168.37.20:0
 
export DISPLAY=192.168.37.20:0
xterm -bg black -fg white -fa Arial -fs 12 -geometry 120x32+15+5 \
+
xterm -bg black -fg white -fa Arial_bold -fs 12 -geometry 120x32+15+5 \
 
-title "coLinux Xterm" -sb -rightbar -sl 10000 +cm +bdc
 
-title "coLinux Xterm" -sb -rightbar -sl 10000 +cm +bdc
 
</pre>
 
</pre>
   
  +
==Building UML==
 
  +
===Un-tar your new Linux kernel sources===
8. Untar your new kernel source in your /colinux/build directory (not /colinux/build/linux-2.6.17.x-build !) with a command like this:
 
  +
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:
 
<pre>
 
<pre>
 
tar --bzip -xf /download/linux-2.6.22-rc2.tar.bz2
 
tar --bzip -xf /download/linux-2.6.22-rc2.tar.bz2
 
</pre>
 
</pre>
   
  +
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).
 
  +
  +
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).
   
 
<pre>
 
<pre>
Line 132: Line 162:
 
drwxr-xr-x 2 root root 1024 Jul 24 02:46 log
 
drwxr-xr-x 2 root root 1024 Jul 24 02:46 log
 
drwxr-xr-x 9 root root 1024 Jun 23 13:18 mingw32
 
drwxr-xr-x 9 root root 1024 Jun 23 13:18 mingw32
<pre>
+
</pre>
   
   
Line 144: Line 174:
 
drwxr-xr-x 19 root root 1024 Aug 2 09:22 linux-2.6.22-rc2-source
 
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-2.6.17.14_log.txt
 
-rw-r--r-- 1 root root 188 Jul 22 13:25 p-2.6.17.14_log.txt
<pre>
+
</pre>
   
   
Line 152: Line 182:
 
ONLY patch '''ONE''' file (don't bother with all the patches, read them to see why).
 
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.
+
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 ===
   
9. Change to your kernel build directory and type something like (change if needed):
+
Change to your kernel build directory and type something like (change to suit your directories):
   
  +
cd /colinux/build/linux-2.6.22-rc2-build
<pre>
 
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 -C /colinux/build/linux-2.6.22-rc2-source \
 
O=/colinux/build/linux-2.6.22-rc2-build defconfig ARCH=um
 
</pre>
 
   
Now type "'''make vmlinux modules modules_install'''".
+
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-'''2.6.17.14'''), you have them copied there as a backup and '''they will work''' when copied over to the '''new''' kernel's root_filesystem.
 
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-'''2.6.17.14'''), 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 http://colinux.wikia.com/wiki/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.
+
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 .
 
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 .
Line 174: Line 203:
 
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 .
 
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===
 
10. Copy the modules from the coLinux /lib/modules/?? directory to the cobdx drive that is 2GB in size after mounting it like this:
+
Copy the modules from the coLinux /lib/modules/?? directory to the cobdx drive that is 2GB in size after mounting it like this:
   
 
<pre>
 
<pre>
 
mount -t ext3 /UML/drive_spare.ext3.2GB /tmp/newfs -o loop
 
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 --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/
+
cp -r --preserve=all /lib/modules/2.6.22-rc2/kernel/* \
  +
/tmp/newfs/lib/modules/2.6.22-rc2/kernel/
 
umount /tmp/newfs
 
umount /tmp/newfs
 
</pre>
 
</pre>
   
That copies all the modules - you might want the source but not the build links if HD space is an issue.
+
That copies all the modules - you might want the source but not the build links (if HD space is an issue).
   
  +
==Start UML==
11. Now you can run it like it was any other linux program. In coLinux type this:
 
  +
===Run UML from coLinux prompt===
  +
Now you can run it like it was any other linux program. '''In coLinux''' type this:
   
 
<pre>
 
<pre>
./UML-linux-2.6.22-rc2-try4 ubda=/UML/FedoraCore5-x86-root_fs.ext3.6GB \
+
./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
 
ubdb=/UML/drive_spare.ext3.2GB mem=256M eth0=tuntap,,,192.168.0.254
 
</pre>
 
</pre>
   
  +
Note: UML-linux-2.6.22-rc2 is what you renamed vmlinux to after compiling it UML.
That runs the new Linux kernel inside the older kernel version hosted on coLinux which runs on WinXP and is accessed via XWindows running on Cygwin X11 (could use VNC).
 
   
  +
Do '''NOT''' try typing that from the '''DOS''' command line. Linux executables don't run under DOS but do run under coLinux.
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).
 
   
  +
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).
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, you can remove the 2GB drive and keep the 8-12GB one).
 
  +
  +
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).
   
 
<pre>
 
<pre>
Line 204: Line 240:
   
 
cp -r --preserve=all /mnt/newfs/lib/modules/* /lib/modules/
 
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/
+
cp -r --preserve=all /mnt/newfs/opt/colinux/build/linux-2.6.22-rc2-source/* \
  +
/opt/colinux/build/linux-2.6.22-rc2-source/
 
</pre>
 
</pre>
   
  +
===Login into UML===
12. Login to FC5 2.6.22-rc2 (Linux_2) from Linux_1 (2.6.17.14):
 
  +
Login to FC5 2.6.22-rc2 (Linux_2) from Linux_1 (2.6.17.14):
 
<pre>
 
<pre>
 
ssh -Y -l root 192.168.0.253
 
ssh -Y -l root 192.168.0.253
Line 216: Line 254:
 
<hr>
 
<hr>
   
Now you can configure the Linux kernel with many more options than before and
+
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.
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
+
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.
 
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.
---
 
  +
  +
==Full routed network with UML under coLinux==
  +
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. [http://www.henrynestler.com/colinux/screenshoots/uml-winxp-ipconfig2.png 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 <!-- Henry: 192.168.4.71 -->
  +
**coLinux eth0: 192.168.37.222 ''(I'm not known yours, and use .222 here)'' <!-- Henry: 192.168.4.20 -->
  +
*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 <!-- Henry: 192.168.10.3 -->
  +
**UML eth0: 192.168.10.253 <!-- Henry: 192.168.10.1 -->
  +
  +
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. ;-)
  +
  +
<!-- Rob: Please mail me private! -->
  +
<pre>
  +
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).
  +
</pre>
  +
  +
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 [http://www.henrynestler.com/colinux/screenshoots/uml-xconsole2.png 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): [http://www.henrynestler.com/colinux/screenshoots/uml-winxp-side2.png 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:
  +
[http://www.henrynestler.com/colinux/screenshoots/uml-colinux-routes2.png 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:
  +
[http://www.henrynestler.com/colinux/screenshoots/uml-route-default2.png 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: [http://www.henrynestler.com/colinux/screenshoots/uml-putty-ssh2.png 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).
  +
  +
----
   
  +
==conclusions==
 
That may be tough to follow, can someone else explain better ?
 
That may be tough to follow, can someone else explain better ?
   
Line 231: Line 491:
 
AFTER you are able to get a screen-shot like at the top '''then''' do your own thing.
 
AFTER you are able to get a screen-shot like at the top '''then''' do your own thing.
   
  +
===Notes===
 
  +
After you are finished you ''might'' have a (PARTIAL) directory structure on '''coLinux''' (depending on what you did) something like this:
Notes:
 
 
After you are finished you ''might'' have a (PARTIAL) directory structure on coLinux (depending on what you did) something like this:
 
   
 
<pre>
 
<pre>
Line 247: Line 505:
 
</pre>
 
</pre>
   
After you are finished you ''might'' have a (PARTIAL) directory structure on WinXP (depending on what you did) something like this:
+
After you are finished you ''might'' have a (PARTIAL) directory structure on '''WinXP''' (depending on what you did) something like this:
  +
   
 
<pre>
 
<pre>
\colinux\...
+
C:\colinux\netdriver\
\colinux\drive_spare.ext3.8GB
+
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)
 
</pre>
 
</pre>
   
The network is like this:
+
===network flow graph===
  +
The data flow network model is like this:
 
<pre>
 
<pre>
  +
100 100 10 or 100
|-----| |---------| |---------| |----------|
 
| UML |---| coLinux |---| WinXP |---| Internet |
+
|-----| Mbps |---------| Mbps |---------| Mbps |----------|
|-----| |---------| | | |----------|
+
| UML |-------| coLinux |-------| WinXP |-----------| Internet |
\________| CygwinX |_
+
|-----| |---------| |- - - - -| |----------|
|---------| \_|---------|
+
\____________| CygwinX |_
| WinXP's |
+
100 |---------| \_|---------|
| Video |
+
Mbps | WinXP's |
| Monitor |
+
| Video |
|---------|
+
| Monitor |
  +
|---------|
  +
</pre>
  +
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:
  +
<pre>
  +
|-------------------------|
  +
| 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).
  +
| |-------------------| |
  +
| |
  +
|-------------------------|
 
</pre>
 
</pre>
   
 
There are pages on '''this''' site that will help you out. That is how I figured this out.<br>
 
There are pages on '''this''' site that will help you out. That is how I figured this out.<br>
   
There is a similar idea on this page http://colinux.wikia.com/wiki/CoLinux_on_Linux
+
There is a similar idea on page [[CoLinux on Linux]] - that page is about "coLinux on Linux". This page is about "Linux on coLinux".
   
 
Rob
 
Rob
 
<hr>
 
<hr>
   
Comments ?
+
===Comments ?===
  +
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.
  +
  +
<hr>
  +
  +
Comment From Henry <ref>[[Talk:NewKernel|talk about UML screen]] - coLinux kernel self is hidden in background</ref>
   
 
<div class="references-small">
 
<div class="references-small">

Latest revision as of 07:52, 8 June 2008

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%.

http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.23-rc2.tar

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.

Build coLinux from source[]

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:

wget -nv http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.14.bz2

Change to your linux-2.6.17-source directory and type something like this:

bunzip2 -d -k -c /downloads/patch-2.6.17.14.bz2 | patch -p1 2>&1 \ 
| tee ../p-2.6.17.14_log.txt

grep -v patching ../p-2.6.17.14_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 2.6.17.14 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 2.6.17.14-co-0.8.0 . Change to the build directory beneath your linux-2.6.17-source and you can either rename it linux-2.6.17.14-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

Building UML[]

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-2.6.17.14_log.txt


Get the UML patches from sourceforge - they might be here:
http://user-mode-linux.sourceforge.net/old/work/current/2.6/2.6.22/patches.tar

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-2.6.17.14), 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).

Start UML[]

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 (2.6.17.14):

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.

Full routed network with UML under coLinux[]

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).


conclusions[]

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.

Notes[]

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".

Rob


Comments ?[]

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 [1]

  1. talk about UML screen - coLinux kernel self is hidden in background