What happens if I run the package upgrade process of a distribution (say Arch Linux) and it wants to upgrade the kernel?
Since coLinux (0.73) uses 2.6.22, how do distributions deal with this? Can I simply keep upgrading my distro forever or will it break at some point because all packages of the distro will start depending on newer kernel and or kernel headers than the one from coLinux?
Mostly you can upgrade your distro. The distro can not overwrite the coLinux kernel. The kernel is the file "vmlinux" on your Windows host. The distro will perhaps write a file into directory /boot, that is never used by coLinux.
If the distro will perhaps fail from upgrade the boot loader (Grub or LILO), then force to skip this step.
But, some distros does not work with older kernel. So, I suggest: Create a backup of your image file before upgrading the distro. (if you have free disk space for this)
Check the oldest kernel you can use for the upgrade.
Okay, I understand now why the distro cannot overwrite the kernel. But it *can* overwrite kernel headers, and or kernel source.
For example, if I use the standard Arch linux image for colinux, and then do an upgrade, it will automatically pull in kernel headers newer than 2.6.22 (i think 2.6.26 at the moment).
What will happen if I subsequently compile stuff from source code, that is using these new kernel headers, but that will then run on the coLinux kernel. Is this possible, do I have to do something special, or do have just have to try and see? It would be nice if I could somehow predict what is safe and what is likely to go wrong.
For other distros (e.g. Ubuntu), I guess they always stay on the same kernel version within their major release (e.g. Ubuntu 7.10), but instead they just release occasional security updates on that kernel. I guess that also means I will never benefit from those security updates, because coLinux simply runs its own, unupdated kernel, correct?
Yes, you are right for kernel headers. They can giv problems for very rarely cases. But, the basic sets of headers you perhaps needs (for example sys/errno.h) are unchanged between kernel versions. Or you have more in the file, as the kernel would give as return code. Kernel and glibc have also a good working fall back for non existend functions. Only, if you would build the glibc self, then you should give this build the right headers.
Running an other kernel as the distribution was build, are typically for many users. For example the Debian 3.0 and Debian 4.0 was never created for coLinux kernel 2.6.22. It runs very nice.
I suggest DO NOT overwrite kernel headers in the directory /usr/include/linux and /usr/include/asm with the coLinux headers. Your glibc was build with a set of kernel headers, and that headers you should have in this directories. The headers MUST match your glibc binary.
If you would build kernel modules from source, then you need coLinux kernel headers. You have build they from source or get they from some pre-configured archive. But, this is perhaps an other case.
If your distribution does not run with the current coLinux kernel, then you needs to update coLinux kernel or you needs to rebuild glibc. Both are very hardly things.
PS: I have often updated my Kernel and never changed the /usr/include/linux and have no problems. I never changed my distribution glibc - I changed kernel. So, my includes don't match the current kernel. - They still matched the glibc.