On 4/29/06, n schembr wrote:
> The road map talks about knoppix/ Frame Buffer device support as a goal. =
What is the status of this work?
It's been prototyped and we have a more or less working (not
necessarily ready for general consumption) proof of concept
implementation. General concensus of early folks using it is that
there where some choices about the impmentation that wheren't
acceptable, especially when using via remote displays. If you'd like
to try it to see if it would work for you can try to get an binary of
nlucas's build of colinux, or build an coLinux build environment and
download from monotone.colinux.org the org.colinux.nlucas branch of
code and compile it.
The implementation decisions that where made that didn't go over
well with the community need to be revisited and done differently.=20
The concepts for the Frame Buffer, need to be generalized and built
into the coLinux API that's used for all devices, as it use a method
that is much better (shared memory between guest and host) than the
current method (passage pages for moving data between guest and host)
and could be used to improve all devices.
> What about a pipe to the local xserver on windows. Pass the requests =
from the dummy interface to the xserver running on windows. Support Xmi=
ng as the Display device? Xming is small and fast?
Just set-up X Server with XDMCP, and set the DISPLAY to a 'remote'
display that points to Xming running on the host... This has all been
covered in the wiki, discussed, and help for others setting it up been
covered in the mailing lists.
> What about the vga.bin from QEMU. Could the qemu project video hardware =
be reused?
Probably not. coLinux and QEMU use different 'architectures' QEMU
(as well as VMWare and VPC) attempt emulate an entire CPU. coLinux
just attempts to 'time share' (so to speak) your existing/real CPU.=20
Besides if we have an implemented proof of concept Frame Buffer
already, then it's probably not worth working on getting QEMU's to
work.
> Booting an Iso image and installing to a cobd device from the text instal=
lers can go a long way.
> Most users do not have the skills required to hack the linuxrc file for =
every distribution.
You CAN boot an iso image now with coLinux. ISO is built-in on the
coLinux kernel, you don't even need an initrd.gz. Maybe the problem
with ISO installers is that they are using modules that aren't
accepted in main-line Linux kernel, like cloop, or squashfs, or
unionfs. Those are all nice and all, but they haven't been accepted
into the linux kernel proper and coLinux doesn't ship with them
(imagine if you would if coLinux's limited developers chased around
all over the internet keeping up with the latest versions of several
popular kernel module add-ons and what it would do to coLinux
development). The biggest problem with distro installers is that the
coLinux cobd device doesn't support partitions, if that where fixed
most installers would more or less work out of the box without a lot
of fiddling (not currently the case, currently you have to
skip/bypass/kill or other-wise the partition step in most installers
and manually mount the target device to the right location). After
that it would be better if the distro installers would recognize
coLinux and know that they are work ing in an limited hardware
environment and not do a lot of hardware probing, and recognize that
the kernel is provided and not to try install one.
--
George

Hello All,
I need to start by thanking everyone involved for producing coLinux. I also need to apologize for not being a system programmer. I will never be able to undertake the task of building or implementing the items I talk about.
The road map talks about knoppix/ Frame Buffer device support as a goal. What is the status of this work?
I'm trying to install stock distributions of Debian, Ubuntu, and FC. I've been starting with small loads and building them up with the stock packages. The Distro wants real hardware to install on.
When the package manager probes or install the X server, the kernel faults cleanly and closes as it should. I'm not trying to have colinux run X windows. I want to satisfy the installer and the X server.
An Xserver that can not display anything sounds like a dumb device but it allows the system to start normally.
What about a Frame buffer device that displays a text file or a 800X600 8 bit logo on VC-F7.
What about a pipe to the local xserver on windows. Pass the requests from the dummy interface to the xserver running on windows. Support Xming as the Display device? Xming is small and fast?
Vncviewer has a different protocol, but the listen option would make an easy install for the user. Start vncviewer in listen mode and startx. When the xserver starts, a connection to 127.0.0.1:5500 would form the display.
What about the vga.bin from QEMU. Could the qemu project video hardware be reused?
Booting an Iso image and installing to a cobd device from the text installers can go a long way.
Most users do not have the skills required to hack the linuxrc file for every distribution.
Thank you for your time, and help,
Nicholas A. Schembri
State College Pa, USA
Produce an Autorun KNOPPIX disc for Windows, that will load coLinux on Windows and also be able to boot a machine natively. Frame buffer device. Let the native XFree86 server be used instead of using a "remote" X server provided by the host OS such as the Cygwin XFree86 server under Windows.

>>
>>the new wiki server is under full load.
>>Many robots are currently scanning files.
>>That's why mostly users have no response from server.
>>
>>If you need only any information, please use the backup:
>>
>>
>
>I hope this problem will solve soon natually because robots
>get all pages.
>
> --- Okajima, Jun. Tokyo, Japan.
>
>
I 0confirmed the status and, Yes, you are right, Henry ---
Current problem we can notice is a short term one, hopefully.
--- Okajima, Jun. Tokyo, Japan.

>
>the new wiki server is under full load.
>Many robots are currently scanning files.
>That's why mostly users have no response from server.
>
>If you need only any information, please use the backup:
>
>
I hope this problem will solve soon natually because robots
get all pages.
--- Okajima, Jun. Tokyo, Japan.

Henry:
First of all, I appriciate your effort. Thank you, Henry!.
One notice is, possibly there is some update which has not
still been transferred to the new server.
I mean, the data you tansferred must not be the newest one,
so if someone have updated pages before you transfered,
there would be confliction about the status of the wiki.
Yeah, I dont think this is so serious, so dont have to care
this issue, if you dont have interested in.
--- Okajima, Jun. Tokyo, Japan.

Hello,
the new wiki server is under full load.
Many robots are currently scanning files.
That's why mostly users have no response from server.
If you need only any information, please use the backup:
http://www.henrynestler.com/colinux/oldwiki/htm/
--
Henry Nestler

Hello,
the new server is complete.
1. Wiki
- Please update your bookmarks for the wiki.
http://wiki.colinux.org/mediawiki/
- All pages are translated into MediaWiki format.
Please read the MediaWikiMigrationReportStatus.
- Users pages are copied under Namespace "User:"
- Accounts are not moved and should be create new.
2. Source
- The Public Monotone Source Control Repostory was moved.
- You can connect with Monotone version 0.23 up to 0.25.2
Please download it from http://www.venge.net/monotone/downloads/
Monotone Version 0.26+ is currently not usable.
- Monotone has a detection for changed servers key and will report as
"man in the middle attack", if you work with your current repostery.
Follow the help of Monotone and use commands unset known-servers. This
is servers new fingerprint: d4e679a6d0a1a4bafd9ab6865737bb99ff5527f6
- This are minmal commands to gets the complete source code:
$ monotone --db=colinux.db db init
$ monotone --db=colinux.db pull monotone.colinux.org '*'
- Mostly basic commands for Monotone you find on coLinux home page:
http://www.colinux.org/?section=scs
--
Henry Nestler

On 4/21/06, Eirik Bakke <ebakke@...> wrote:
> would reboot when coLinux had allocated 128Mb RAM, but not when allocated
> 768Mb RAM. Maybe a tighter physical memory space might make certain bugs
Where you running with initrd.gz ?
I've found that at certain memory (typically 128) if you run with
initrd.gz it reboots, if you change memory size to something else, or
remove initrd.gz the same kernel/daemons boot and work fine... I
suspect an memory allocation problem of some sort with initrd &
colinux's memory allocation routines.
> At some point coLinux also died gracefully with a message in the windows
> console "BUG in mm.c on line XX" or something like that (I don't have the
> exact message available at the time, but I can dig it up if anyone's
> interested). But that was with the VServer patch applied, so it might not
> apply to the clean coLinux kernel.
I'd be interested in the BUG in mm.c on line XX that you had. It
might be worth looking into, and it might turn up what's the problem
with memory allocation... Worth looking at, especially if the line in
question turns out to lead back more to coLinux code thatn VServer
code.
So you've got an VServer and PlanetLab patched coLinux that works?
--
George

Support Requests item #1476423, was opened at 2006-04-25 23:58
Message generated for change (Comment added) made by henryn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1476423&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win XP Home Edition
Initial Comment:
Does colinux work under Win XP Home?
I dont get my network working with the debian-edition,
now im trying to get it to work with gentoo.
Has anybody get it?
Thanks for answering my question!
----------------------------------------------------------------------
Comment By: Henry N. (henryn)
Date: 2006-04-26 00:16
Message:
Logged In: YES
user_id=579204
Yes, it is running under XP-Home.
The networking on Debian and Gentoo will be the same.
think, this would not help you. Only if you know more from
native gentoo, then gentoo could be better for you.
Mostly all networking problems are on the Windows side
and/or with understanding the difference between the
various types (TAP/SLiRP/Pcap-Bridged/Windows-Bridging/ICS).
Wiki: "SLiRP with fixed address"
If you install one of the latest version, for sample 0.6.3,
then search the network type SLIRP in the wiki help. This
is not fast, but very easy to install inside the coLinux.
On the windows side give only "eth0=slirp" as command line,
or type="slirp" in the older XML config. Inside coLinux
type this ony linux root command prompt, and your network
is running:
ifconfig eth0 10.0.2.15 netmask 255.255.255.0 broadcast
10.0.2.255
route add default gw 10.0.2.2
echo "nameserver 10.0.2.3" > /etc/resolv.conf
And last:
Have you installed it complete, exist files colinux-net-
daemon.exe and colinux-slirp-net-daemon.exe?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1476423&group_id=98788

Support Requests item #1476423, was opened at 2006-04-25 14:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1476423&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win XP Home Edition
Initial Comment:
Does colinux work under Win XP Home?
I dont get my network working with the debian-edition,
now im trying to get it to work with gentoo.
Has anybody get it?
Thanks for answering my question!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1476423&group_id=98788

Eirik Bakke wrote:
> Could someone tell me what happens exactly when the coLinux kernel needs to
> make a Windows system call? For instance, from what I have learned, the
> Linux function gettimeofday() will trigger a system call to the Linux
> kernel, which in turn makes a Windows system call to get the time of the
> day. This would immediately(?) trigger a context switch from coLinux to
> Windows.
>
> 1) Is it the user-mode coLinux daemon or the kernel-mode linux.sys that
> actually performs such calls in the end?
It is linux.sys
> 2) When the Windows system call returns, is a context switch back to coLinux
> again performed immediately, or does the coLinux daemon again have to wait
> for Windows to give it a timeslice first?
Goes back immediately, so windows allowed it.
The waiting for next "timeslice" for is only if linux is idle.
The problem is, that only one Windows System call is performd in at the
same time. A call from Linux to Windows is not "reentrant".
This all is more complex as only the single call for current time. In
normal case Linux put one requests into a command/data fifo and call
linux.sys to work on it. Linux.sys get the comands and move this data
to the daemons pipe (Network, Console). For the "gettimeofday" function
and for the "read/write image file" the linux.sys call a windows
function and must wait to return from it, then put the response (answer)
back into answer buffer. Then linux.sys goes back to the Linux. But
Windows can catch cPU time, if windows has an other system device, that
needs time. For sample you move the mouse, or other pointing device.
Linux is cooperative and allow to break in all cases. coLinux is the
*guest* and can generaly not get the full CPU time.
http://www.henrynestler.com/colinux/screenshoots/suse90-build-colinux.png
This is a state, in that coLinux builds them self, this is running since
10 minutes and needs all CPU time, see the Windows task manager. But
inside Linux it is also 0% Idle. In comparsion with native linux it
needs many more system time. That's because linux often waits for
read/write on block device.
http://home.arcor.de/henryn/colinux/screenshoots/colinux-4runs.png
here is an other scenario. This runs 4x coLinux, al lare idle, the best
sitiation for coLinux: The host is also idle with 2% CPU usage. If you
would try this under VMware, then your Host would not accessable longer
for more things. :-)
You should risk a view into source. All in linux.sys handled function
are under the directory src/colinux/os/winnt/kernel. There you will
find the KeQuerySystemTime(). This function will call, if Linux wish to
know the current time.
Now back to your question 2) again. Yes, it goes back directly from
Windows to Linux *after* the windows system call. But the system call
need some longer time. For sample ZwReadFile() blocks the Linux, until
it is ready to gets data from file (blocked read). In this example the
time is very long. *And* your speed-test can not start without reading
from a windows file. Any starts of a program inside linux need to read
a file, the syslog is mostly running and writing to a file. If you read
a file, mostly Linux configurations will accurate set the accessing time
(atime). That needs a write to file on windows side (your image file).
You are losing some processing time for coLinux VM again.
If you need a speed testing, then make a differ:
What would you do with coLinux?
If you need maximal speed, then create a RAM-Disk, disable atime and
runs only in this device.
If you wand build Linux Kernels or other developments under coLinux,
then create a tmpfs for directory /tmp, disable swap device and give
coLinux enough memory. You would impres with the speed. Compaired with
other virtual systems.
You can not directly compair it with benchmark tests directly.
--
Henry Nestler

Support Requests item #1475862, was opened at 2006-04-24 23:58
Message generated for change (Comment added) made by juergenh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1475862&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: v1.0 (example)
Status: Open
Priority: 5
Submitted By: Joe Example (theschles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple problems during install and initial config
Initial Comment:
Windows 2000 Server 1.5GB RAM fully patched
New install of coLinux
Using Debian-3.0r2.ext3-mit-backports.1gb.bz2
Following GettingStartedLong off of Wiki site
Attempting to set up a bridged network connection
1) I'm a complete *nix noob - should I even be using
Debian-3.0r2.ext3-mit-backports.1gb.bz2 - or should I
be using Debian-20040605-mit.ext3.1610mb.bz2 ???
2) I'm getting "eth0: duplicate address detected!" all
over the place.
Attached you'll find my default.colinux.xml file. I've
left the TAP TCP/IP settings in Windows as DHCP. I've
tried putting in various MAC addresses in to no effect.
I am also getting "IPv6 over IPv4 tunneling driver". I
searched and found something on IPv6, but as a noob I
have no idea what was being said.
I can ping from coLinux to Windows and back. (coLinux
does get a LAN IP address) But I cannot SSH or VNC
into coLinux.
Help!!!!!!!!!!
----------------------------------------------------------------------
Comment By: Juergen Hennerich (juergenh)
Date: 2006-04-25 08:35
Message:
Logged In: YES
user_id=13380
I guess you have the win-pcap driver installed
(http://www.winpcap.org/install/default.htm) and 'Local Area
Connection' is actually the name of your external physical
network adapter. This has nothing to do with the TAP, so you
could remove (or ignore) it.
If this is the case, try the following line:
<network index='0' name='Local Area Connection'
type='bridged' mac='11:22:33:44:55:66' />
If you have a dhcp server in your network coLinux should get
an IP-Address, if you have the following lines in your
/etc/network/interfaces:
auto eth0
iface eth0 inet dhcp
What do you get, when you type in (as root) ifconfig?
Is your sshd running? (type "ps auxw | grep sshd")
If your sshd is running you could try to set a static IP in
/etc/network/interfaces:
auto eth0
iface eth0 inet static
address free IP-address in your external network
(e.g.:address 192.168.2.20)
netmask 255.255.255.0
gateway IP-Address of your router
In this case you should also edit /etc/resolv.conf and set a
nameserver manually: nameserver IP-Address of your nameserver.
Juergen
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1475862&group_id=98788

> Could someone tell me what happens exactly when the coLinux=20
> kernel needs to
> make a Windows system call? For instance, from what I have=20
> learned, the
> Linux function gettimeofday() will trigger a system call to the Linux
> kernel, which in turn makes a Windows system call to get the=20
> time of the
> day. This would immediately(?) trigger a context switch from=20
> coLinux to
> Windows.
>=20
> 1) Is it the user-mode coLinux daemon or the kernel-mode=20
> linux.sys that
> actually performs such calls in the end?
>=20
> 2) When the Windows system call returns, is a context switch=20
> back to coLinux
> again performed immediately, or does the coLinux daemon again=20
> have to wait
> for Windows to give it a timeslice first?
>=20
Good question. I haven't a clue. I'm currently trying to get=20
a grip on the memory handling (trying a 2.6.16 port). If I find
anyting useful, I'll let you know.
/A

Could someone tell me what happens exactly when the coLinux kernel needs to
make a Windows system call? For instance, from what I have learned, the
Linux function gettimeofday() will trigger a system call to the Linux
kernel, which in turn makes a Windows system call to get the time of the
day. This would immediately(?) trigger a context switch from coLinux to
Windows.
1) Is it the user-mode coLinux daemon or the kernel-mode linux.sys that
actually performs such calls in the end?
2) When the Windows system call returns, is a context switch back to coLinux
again performed immediately, or does the coLinux daemon again have to wait
for Windows to give it a timeslice first?
Thanks,
-- Eirik B.

Support Requests item #1475862, was opened at 2006-04-24 16:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1475862&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Install Problem (example)
Group: v1.0 (example)
Status: Open
Priority: 5
Submitted By: Joe Example (theschles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple problems during install and initial config
Initial Comment:
Windows 2000 Server 1.5GB RAM fully patched
New install of coLinux
Using Debian-3.0r2.ext3-mit-backports.1gb.bz2
Following GettingStartedLong off of Wiki site
Attempting to set up a bridged network connection
1) I'm a complete *nix noob - should I even be using
Debian-3.0r2.ext3-mit-backports.1gb.bz2 - or should I
be using Debian-20040605-mit.ext3.1610mb.bz2 ???
2) I'm getting "eth0: duplicate address detected!" all
over the place.
Attached you'll find my default.colinux.xml file. I've
left the TAP TCP/IP settings in Windows as DHCP. I've
tried putting in various MAC addresses in to no effect.
I am also getting "IPv6 over IPv4 tunneling driver". I
searched and found something on IPv6, but as a noob I
have no idea what was being said.
I can ping from coLinux to Windows and back. (coLinux
does get a LAN IP address) But I cannot SSH or VNC
into coLinux.
Help!!!!!!!!!!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1475862&group_id=98788

Bugs item #1473410, was opened at 2006-04-20 00:42
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.7.1-hnXX Series Won't Boot
Initial Comment:
I can't seem to get any of the 0.7.1-hnXX series of
development installers to boot. Doing so just reboot
my system before I get a chance to see any error
messages. I have tried 0.7.1hn(13,12,11) versions.
All cause my system to reboot.
I thought it may be the /noexecute=OptIn issue, but I
have changed this to /noexecute=AlwaysOff (which is
what I need to do on my Notebook at home), but this
does not fix the problem.
I currently have the devel-coLinux-20050813 version
installed and working fine, (which I believe is what
all the 0.7.1-hnXX series are based on). The
configuration files seem to have the same syntax
between devel-coLinux-20050813 and the 0.7.1-hnXX
series (i.e. no XML).
Any suggestions on how I might debug this problem?
Have Fun !!
Shane
(Shane.Hill@...)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-23 18:17
Message:
Logged In: NO
Problem seems to occur when argument mem>=256.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_id=98788

Hi,
I had the same problem with 0.7.1-hn12 while trying to build both the
Windows daemons and the coLinux kernel myself, with certain modifications to
the latter (VServer patch and also PlanetLab Kernel+coLinux). After cleaning
up my build directory and kernel configuration and doing a new clean build
it worked fine, but I do not know why, or why the reboots happened in the
first place. I made some observations, though: (1) In one case the machine
would reboot when coLinux had allocated 128Mb RAM, but not when allocated
768Mb RAM. Maybe a tighter physical memory space might make certain bugs
more likely to show up? (2) In another case, a kernel with the VServer patch
applied would reboot the mahchine, but not an unmodified coLinux one (or was
it the other way around?). (3) In a third case, any one of three kernels I
built (plain hn12, +VServer, +PlanetLab) would either work or reboot
depending on various unknown conditions (the amount of RAM allocated being
one of them).
My main theory is that the reboots happened whenever I used a version of the
coLinux kernel that was not exactly the same as that of the kernel (e.g. I
might have been using a version of the daemons that I downloaded, together
with a kernel I built myself). Unfortunately I would not be able to
reproduce these errors at the time as I haven't been keeping track of old
non-working builds. My build environment is basically Fedora Core 3 (gcc
3.4?, I think).
At some point coLinux also died gracefully with a message in the windows
console "BUG in mm.c on line XX" or something like that (I don't have the
exact message available at the time, but I can dig it up if anyone's
interested). But that was with the VServer patch applied, so it might not
apply to the clean coLinux kernel.
-- Eirik
-----Original Message-----
From: colinux-devel-admin@...
[mailto:colinux-devel-admin@...] On Behalf Of
colinux-devel-request@...
Sent: 20. april 2006 23:17
To: colinux-devel@...
Subject: coLinux-devel digest, Vol 1 #789 - 1 msg
Send coLinux-devel mailing list submissions to
colinux-devel@...
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/colinux-devel
or, via email, send a message with subject or body 'help' to
colinux-devel-request@...
You can reach the person managing the list at
colinux-devel-admin@...
When replying, please edit your Subject line so it is more specific than
"Re: Contents of coLinux-devel digest..."
Today's Topics:
1. [ colinux-Bugs-1473410 ] 0.7.1-hnXX Series Won't Boot
(SourceForge.net)
--__--__--
Message: 1
To: noreply@...
From: "SourceForge.net" <noreply@...>
Date: Thu, 20 Apr 2006 00:42:51 -0700
Subject: [coLinux-devel] [ colinux-Bugs-1473410 ] 0.7.1-hnXX Series Won't
Boot
Bugs item #1473410, was opened at 2006-04-20 00:42 Message generated for
change (Tracker Item Submitted) made by Item Submitter You can respond by
visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_i
d=98788
Please note that this message will contain a full copy of the comment
thread, including the initial issue submission, for this request, not just
the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.7.1-hnXX Series Won't Boot
Initial Comment:
I can't seem to get any of the 0.7.1-hnXX series of development installers
to boot. Doing so just reboot my system before I get a chance to see any
error messages. I have tried 0.7.1hn(13,12,11) versions.
All cause my system to reboot.
I thought it may be the /noexecute=OptIn issue, but I have changed this to
/noexecute=AlwaysOff (which is what I need to do on my Notebook at home),
but this does not fix the problem.
I currently have the devel-coLinux-20050813 version installed and working
fine, (which I believe is what all the 0.7.1-hnXX series are based on). The
configuration files seem to have the same syntax between
devel-coLinux-20050813 and the 0.7.1-hnXX series (i.e. no XML).
Any suggestions on how I might debug this problem?
Have Fun !!
Shane
(Shane.Hill@...)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_i
d=98788
--__--__--
_______________________________________________
coLinux-devel mailing list
coLinux-devel@...
https://lists.sourceforge.net/lists/listinfo/colinux-devel
End of coLinux-devel Digest

Bugs item #1473410, was opened at 2006-04-20 00:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_id=98788
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.7.1-hnXX Series Won't Boot
Initial Comment:
I can't seem to get any of the 0.7.1-hnXX series of
development installers to boot. Doing so just reboot
my system before I get a chance to see any error
messages. I have tried 0.7.1hn(13,12,11) versions.
All cause my system to reboot.
I thought it may be the /noexecute=OptIn issue, but I
have changed this to /noexecute=AlwaysOff (which is
what I need to do on my Notebook at home), but this
does not fix the problem.
I currently have the devel-coLinux-20050813 version
installed and working fine, (which I believe is what
all the 0.7.1-hnXX series are based on). The
configuration files seem to have the same syntax
between devel-coLinux-20050813 and the 0.7.1-hnXX
series (i.e. no XML).
Any suggestions on how I might debug this problem?
Have Fun !!
Shane
(Shane.Hill@...)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1473410&group_id=98788

On 4/18/06, Anders Eriksson C (KI/EAB) wrote:
> Thanks for the encouragement! A bit of learning curve ahead as I
> have to read up on how colinux does things under the hood. Is the
> 2005-10-13 version and Henry's -hn13 vorking on the same protocol
> version? (Just trying to rule out some sources for confusion...)
I'd say that stable and devel are running different protocols... I
can't say for hn's except that they are probably essentially the same
only with enhancements/fixes.
> Oh, and additionally:
> Has there been any plans on getting parts of the kernel patch in shape
> for inclusion in the kernel? Or alignment with e.g. UML/XEN/... in
> the way things are done? I guess what I'm wondering is if it's
> considered
> a good thing to get things pushed upstream, or if you'd like to keep
> things close to home for the time being.
Well.... Last it was brought up I think it was stated it would be
pretty doubtful that it would ever be excepted... Outside of that,
coLinux is in it's infancy. We have a LOT to work out before it's
really anything close to something that should be considered main-line
kernel ready. Aligning stuff with UML/XEN/etc isn't a bad idea by any
means. Any aligning we can do that allows us to share/use
features/code from those others is a good thing... I would think.
--
George

>>> For Monotone, that must not be no problem totally.
>>
>> -> it must be NO problem totally.
>
>Monotone installation on a new server is no problem, we can easy install
>a current version.
>
>Sources are backed up and also on many harddisk of users.
>I see no problem.
>
Okay, Then, this should be the last problem:
ALONI: YOU ARE OKAY?
Of course, I know that he is not a guy like making mistake on computer issues,
but, I have to confirm this before formatting the HDD.
Henry:
How about the new server?
You have got logged in already?
--- Okajima, Jun. Tokyo, Japan.