Re: [coLinux-users] using 2.6 kernels, moving to latest coLinux snapshot, etc.

[gboutwel <gbo...@pr...>]

> Does the 2004-07-10 snapshot fix all of the known problems
with

> microseconds returned by gettimeofday (especially on Windows
XP

> SP1, which I am using)?



In a nutshell..  0.6.1 was 2.4 kernel, just moving to 2.6 kernel
helped tremendously with the gettimeofday problems, but there
where still some.  I believe an patch that went into the 0710
snapshot helped some more.  I still experience clock skew on
XP SP1 on Gentoo when doing make sometimes.  But it's probably
the best it's been in a long time.



> I noticed from an earlier message that there is a build of
the

> 2004-07-19 version from the monotone repository available at

> http://firechief.dyndns.org/colinux/>. Does this version fix

> the problems?



This version doesn't provide any gettimeofday fixes that aren't
in 0710.  It does include an fix for memory allocation that reportedly
speeds-up boot time, and an fix for situations where starting
up sometimes resulted in an cannot connect to pipe errors.  It's
an build of monotone's 07/17/2004 changes (which where what was
there on 07/19/2004) when I built that version to give to an
guy experiencing an odd problem.  Oddly enough the build fixed
his problem, so I left it up and have recommended to several
people experiencing problems to try it.  It's not an OFFICIAL
snapshot/release or otherwise.  It's just the latest sources
on 07/19 compiled, and archived in to an archive.  It doesn't
even have an installer.  You will probalby want to/need to install
0710 as a pre-requisite to running this version if you wish to
try it.  After that, you'd back-up or make an copy of the 0710
install directory, and unarchive this archive over the top of
the existing files.



> Is there any good prediction on when there will be an official

> coLinux 0.6.2 release? If it is in the next 2 weeks, then I
am

> better waiting for it, but otherwise I want to consider using
a

> development snapshot.



I'm not sure when Dan's going to release another snapshot or
release.  I'd say it's a pretty safe bet that it'd be in the
next 2 weeks, but I maybe wrong.  I've been running the 07/17
code with other patches (namely UML's SKAS3 patch) applied since
7/28 with very little issues.  I'd say the 07/17 code is fairly
stable and worth moving to TODAY, if it solves your problems.
 Even if it doesn't solve your all your problems, it will help
us deteremine which ones we have solved and which ones still
need some work.



> * Can I run both the old and new coLinux at the same time so
that I

> don't have to shut down my working coLinux to test out the
new one?

> I think this doesn't work because I can't have both versions
of the

> Windows driver for coLinux installed at the same time. Am I
right?



  Yes and No.  Yes you can have both installed (in different
directories) and run them interchangably, but No you can't leave
your current one running, install the new one and test with it.



  When running interchangably, you'd need to run a sequence of
commands similiar to the following:



1) stop all colinux instances

2) in directory of verison you where just running, run colinux-daemon
--remove-driver

3) cd to directory of version you want to run

4) run colinux-daemon --install-driver

5) start any colinux instance you want to run under this version.



  The main reason for this is that until the coLinux 'API' has
been solidified it's still changing and has changed pretty much
every version/snapshot.  As long as the API changes the Windows
side kernel-mode driver can not be used with different versions,
doing so causes reboots.  The API especially changed in the switch
from 2.4 to 2.6.





> Is this enough? Will the new coLinux with the new kernel just

> simply work?



Pretty much, you'll also want to modify your /etc/fstab to point
to /dev/cobd/0, or create an symbolic link between /dev/cobd0
and /dev/cobd/0



> Why do the new /dev/cobd/X files need to exist? What software

> depends on them being in that location vs. the old location?
As far

> as I can understand, the coLinux-adapted kernel just knows
about the

> major number 117 and couldn't care less what names the devices
have

> in the file system. The only place that I know of that cares
about

> the names is /etc/fstab. So why can't I just continue using
the old

> names? The advice on the wiki does not explain this.



Because the 2.6 flavor has devfs enabled, not sure why the 2.4
didn't or why the behavior under 2.4 was different than 2.6.
 devfs is what causes the change from /dev/cobd0 to /dev/cobd/0
and /etc/fstab is the only thing that needs changed.  Not changing
/etc/fstab results in gentoo not liking the / partition, putting
it into RO mode, and booting into a single/rescue mode (every
time you boot, until you've fixed the /etc/fstab). Gentoo is
pretty much the only distro that had this problem of booting
into single/rescue mode on the switch-over.  The other distros
(namely debian) just worked, so it may be somehting in Gentoo's
handling of 2.6 kernels.  Sorry I didn't make that clearer when
I wrote those instructions on the wiki.  You're welcome to go
fix it. :)



> * What is relationship between the files in /lib/modules/2.4.24-co
in

> the pre-built 2GB Gentoo root partition and the contents of

> vmlinux-modules.tar.gz that comes with coLinux 0.6.1? There
are

> only two .o files with names in common and they differ. Otherwise,

> the modules in vmlinux-modules.tar.gz seem to be a nearly completely

> different set from the modules in /lib/modules/2.4.24-co.



the vmlinux-modules.tar.gz that ships with colinux installs,
are the modules built at the same time the vmlinux is built,
put into an archive, which extracts to an path of /lib/modules/<kernelversion>,
so in your move to 2.6, you should transfer the vmlinux-modules.tar.gz
file from the colinux directory to your image and unarchive it
while in the / directory, that is if you want/need modules which
aren't built into the kernel.  If that's not the case for you
(you don't need anything that's not bult-in to the kernel) then
you can pretty much not care about the modules or the vmlinux-modules.tar.gz.
 The difference between vmlinux-modules.tar.gz in 2.4 and vmlinux-modules.tar.gz
in 2.6 is the difference in the kernel and the kernels handling
of modules in 2.6, which changed pretty dramatically.  There's
an great document called the 2.6 Halloween document that talks
about what's invovled in moving from 2.4 to 2.6, probably well
worth the read (sorry I don't have an URL for you).  BTW, the
changes in the 2.6 kernel module handling, are also there reason
you have to install module-init-tools.



> Are the ones in vmlinux-modules.tar.gz supposed to be loaded
at boot

> time (perhaps via initrd?) and the others are for later? Also,
why

> are the Linux files in /lib/modules/2.4.24-co and not

> /lib/modules/2.4.24-co-0.6.1 (which would seem to be the place
they

> should be based on a page on the wiki).



No, Everything that's need for a typical boot is pretty much
built-in to the kernel.  The vmlinux-modules.tar.gz is provided
to give folks who want/need the additional modules the abililty
to insmod them, without having to d/l the kernel source, patch
it, and build them on their own.



> * When I emerged module-init-tools, it did not create an

> /etc/modprobe.conf file from my existing /etc/modules.conf
file. Am

> I supposed to run generate-modprobe.conf or

> modules.conf2modprobe.conf?



Hmm... Not sure on that. The 2.6 Halloween doc covers the modules.conf
to modprobe.conf changes, but I'm not sure how Gentoo specifically
handles this.



> Do I need to run depmod at some point? Or will this happen

> automatically?



Most distros run depmod automaticlally, pretty sure Gentoo does
too.



I hope that answers most your questions.  Feel free to question
further on any or the repsonse I've given if I didn't make it
clear enough.



Also, the next snapshot and/or release should include an initrd
image which will 'automagically' install the vmlinux-modules.tar.gz
files into the file image.  I just wrapped up working on that
earlier this week.



George



--------------------------------

Looking for that favorite verse?

Search for it in Praize Bible

http://www.praize.com/bible/