coLinux
Advertisement

Is it possible to run a new kernel under coLinux without applying any coLinux patches you ask. 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 devel-colinux-20070708.tar.gz

Expanding disk space

While it builds make a couple of spare virtual HDs. See here for some tips: http://colinux.wikia.com/wiki/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 coLinux kernel patches - fourth 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.

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 http://colinux.wikia.com/wiki/Network#Introduction and http://colinux.wikia.com/wiki/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 then 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 -fs 12 -geometry 120x32+15+5 \
 -title "coLinux Xterm" -sb -rightbar -sl 10000 +cm +bdc

Building UML

getting newest 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 

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

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 UML kernel

Change to your kernel build directory and type something like (change if needed):

cd /colinux/build/linux-2.6.22-rc2-source
make O=/colinux/build/linux-2.6.22-rc2-build defconfig ARCH=um

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

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-try4 ubda=/UML/FedoraCore5-x86-root_fs.ext3.6GB \
  ubdb=/UML/drive_spare.ext3.2GB mem=256M eth0=tuntap,,,192.168.0.254

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.

Full routed network with UML under coLinux

coLinux agent as "router" in this way and should forward all tcp packets.

Have no pcapBridge or other bridget installed, and no loopback device on windows side, and no ICS. Yust only one TAP-Win32-Device for coLinux, a real Ethernet LAN card for my Windows and SLiRP inside coLinux for internet.

My networks

  • Windows Ethernet LAN: 192.168.0.71
  • Windows default gateway and DNS: 192.168.0.xxx (does no matter here)
  • Windows TAP: 192.168.4.71 (is your 192.168.37.20)
  • coLinux eth1: 192.168.4.20
  • coLinux eth0: 10.0.2.15/255.255.255.0
  • coLinux default gateway: 10.0.2.2 (route over SLiRP)
  • coLinux DNS: 10.0.2.3
  • coLinux tap0: 192.168.10.3 (is your 192.168.0.254)
  • UML eth0: 192.168.10.1 (is your 192.168.0.253)

All comands have copy & paste from working. Would currently no manualy rewrite with your adresses and risk typofixies. - Feel free to replace my numbers with yours.

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.4.71: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.3

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

The routing table inside coLinux was changed by UML, that's now to see:

coLinux# route -n
Kernel IP routing table
Destination   Gateway  Genmask         Flags Metric Ref Use Iface
192.168.10.1  0.0.0.0  255.255.255.255 UH    0      0     0 tap0
192.168.4.0   0.0.0.0  255.255.255.0   U     0      0     0 eth1

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 your coLinux side from tuntap (tap0):

UML# route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.10.3

See the routing inside UML now:

UML# route -n
Kernel IP routing table
Destination   Gateway       Genmask        Flags Metric Ref  Use Iface
192.168.10.0  0.0.0.0       255.255.255.0  U     0      0      0 eth0
0.0.0.0       192.168.10.3  0.0.0.0        UG    0      0      0 eth0

On Windows, set the ipaddress from coLinux side of TAP-coLinux as gateway for that network:

C:\> route add 192.168.10.0 mask 255.255.255.0 192.168.4.20 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.4.20  192.168.4.71      1
...

Now can directly access from windows to UML: [uml-putty-ssh]

C:\> ping 192.168.10.1
C:\> putty.exe 192.168.10.1

This was the private network between Windows - coLinux - UML only. Routing table in coLinux was not changed to this point here:

coLinux:/ # route -n
Kernel IP routing table
Destination   Gateway    Genmask         Flags Metric Ref  Use Iface
192.168.10.1  0.0.0.0    255.255.255.255 UH    0      0      0 tap0
192.168.4.0   0.0.0.0    255.255.255.0   U     0      0      0 eth1

Lets UML going to the world

Now, lets set and view with SLiRP for outgoing internet access. eth0 was configured as "eth0=slirp" under windows. eth0 is 10.0.2.15/255.255.255.0, add the default gateway under coLinux:

coLinux:/ # route add default gw 10.0.2.2
coLinux:/ # route -n
Kernel IP routing table
Destination   Gateway    Genmask         Flags Metric Ref  Use Iface
192.168.10.1  0.0.0.0    255.255.255.255 UH    0      0      0 tap0
192.168.4.0   0.0.0.0    255.255.255.0   U     0      0      0 eth1
10.0.2.0      0.0.0.0    255.255.255.0   U     0      0      0 eth0
0.0.0.0       10.0.2.2   0.0.0.0         UG    0      0      0 eth0

Add the default gateway under UML:

UML# route add default gw 192.168.10.3
UML# route -n
Kernel IP routing table
Destination   Gateway       Genmask       Flags Metric Ref Use Iface
192.168.4.0   192.168.10.3  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.3  0.0.0.0       UG    0      0     0 eth0

In theority can remove the fixed route for network 192.168.4.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.

UML can no access directly to the world:

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.

If you replace SLiRP with pcapBridge for coLinux, then can do more, but need also more setups (more routings...) and IP forwarding under Windows. But this is an other lesson.


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 http://colinux.wikia.com/wiki/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
Advertisement