From: Matt B. <ma...@zi...> - 2004-01-31 19:39:50
|
Tried to fire up coLinux on my XP Home Edition SP1a + current critical patches installation. (Hey, I wasn't going to plunk down the money for a better version of an OS I wasn't going to use on this laptop.) ;-) TAP-Win32 installed fine, though the procedure appears markedly different under Home. But it is there in the network connections, though it's marked with a red X because it's "down", which I assume is media status. Result: C:\coLinux>colinux-daemon.exe Cooperative Linux daemon Installing kernel driver Error initializing kernel driver Removing kernel driver Stopping driver service Removing driver service Daemon failed: -1 C:\coLinux> Any hints as to increasing verbosity etc. would be much appreciated. All files are as the README asks them to be, and I am a "Computer Administrator" in XP Home's user panel (which is significantly suckier than 2000's, or I gather XP Pro's.) My immediate suspicion is that XP Home isn't gonna fly. I may try to borrow my wife's 2000 laptop later on to test. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Dan A. <da...@gm...> - 2004-01-31 19:53:45
|
On Sat, Jan 31, 2004 at 02:39:36PM -0500, Matt Behrens wrote: > Result: > > C:\coLinux>colinux-daemon.exe > Cooperative Linux daemon > Installing kernel driver > Error initializing kernel driver > Removing kernel driver > Stopping driver service > Removing driver service > Daemon failed: -1 > > C:\coLinux> > > Any hints as to increasing verbosity etc. would be much appreciated. > All files are as the README asks them to be, and I am a "Computer > Administrator" in XP Home's user panel (which is significantly > suckier than 2000's, or I gather XP Pro's.) Can you please send me the output of DebugView http://www.sysinternals.com/files/dbgvnt.zip (Make sure that it captures kernel debug messages) Thanks, -- Dan Aloni da...@gm... |
From: Dan A. <da...@gm...> - 2004-01-31 20:47:07
|
On Sat, Jan 31, 2004 at 03:06:57PM -0500, Matt Behrens wrote: > On Sat, Jan 31, 2004 at 09:58:29PM +0200, Dan Aloni wrote: > > > I attached a slightly modified version of the daemon. > > Okay, this one got me booted. However, now I see: Oh very good, now you can play with it ;) > /dev/cobd0: The filesystem size (according to the superblock) is 262144 blocks > The physical size of the device is 30448 blocks > 262144 sounds much more likely to me, given the gigabyte image I'm > mounting. It occured on my setup as well. I need to see more of these reports to find out whether the 30448 number that fsck prints there is fixed. I also saw this today. While trying to debug it, It sometimes occurs and sometime doesn't, and only with that image. I am going to look inside the fsck source code to get more clue. Perhaps it's a cobd bug, related to the way it answers to ioctl()s. Until it gets fixed, you can hack your way out of it if you edit that init script from inside coLinux. -- Dan Aloni da...@gm... |
From: Matt B. <ma...@zi...> - 2004-01-31 21:05:16
|
On Sat, Jan 31, 2004 at 10:46:56PM +0200, Dan Aloni wrote: > I need to see more of these reports to find out whether the 30448=20 > number that fsck prints there is fixed. I also saw this today. While=20 > trying to debug it, It sometimes occurs and sometime doesn't, and only=20 > with that image.=20 FWIW, I made a smaller image (128M) by loop-mounting both and moving the files over; I got the same message on boot, this time 121793 blocks vs. the correct figure of 131072. Curious -- can I infer that there are disk-style images that do work? --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Matt B. <ma...@zi...> - 2004-01-31 21:56:09
|
Okay, it seems there are worse problems than just misreporting the size in cobd. It seems in e2fslibs that the size is actually determined by an algorithm I can't get my weekend brain around, but it does a lot of seeking and trying to read a byte to get the "real" size. Armed with this idea I tried to dd if=3D/dev/cobd0 of=3D/dev/null bs=3D1k count=3D128k (using my 128M image). I got a stream of I/O errors near the end and DebugView is filled with several messages starting with "block io failed: edbb6000 400 (reason: c0000011)". Goes up to edea6c00. I can't find the above DebugView message anywhere in the 0.5.2 colinux source I pulled today. So I think I'm stuck for the day... hopefully someone smarter than me can pick it up from here. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |
From: Dan A. <da...@gm...> - 2004-01-31 22:26:40
|
On Sat, Jan 31, 2004 at 04:55:57PM -0500, Matt Behrens wrote: > Okay, it seems there are worse problems than just misreporting the > size in cobd. > > It seems in e2fslibs that the size is actually determined by an > algorithm I can't get my weekend brain around, but it does a lot > of seeking and trying to read a byte to get the "real" size. > > Armed with this idea I tried to dd if=/dev/cobd0 of=/dev/null bs=1k > count=128k (using my 128M image). I got a stream of I/O errors > near the end and DebugView is filled with several messages starting > with "block io failed: edbb6000 400 (reason: c0000011)". Goes up > to edea6c00. c0000011 is STATUS_END_OF_FILE. It is possible that reading cobd devices from userspace is broken. Prehaps in that scenario offsets are passed from Linux to Windows wrongly. > I can't find the above DebugView message anywhere in the 0.5.2 > colinux source I pulled today. It's in colinux/os/winnt/kernel/block.c. -- Dan Aloni da...@gm... |
From: Matt B. <ma...@zi...> - 2004-02-01 00:13:39
|
On Sun, Feb 01, 2004 at 12:26:31AM +0200, Dan Aloni wrote: > On Sat, Jan 31, 2004 at 04:55:57PM -0500, Matt Behrens wrote: > > I can't find the above DebugView message anywhere in the 0.5.2 > > colinux source I pulled today. > It's in colinux/os/winnt/kernel/block.c. Well, at this stage I think I'm sunk; my admittedly virgin eyeballs I don't see anything obviously wrong with anything there, and I can't throw in more debug calls to track down the problem because I'm missing a cross-compile environment and a DDK. :-) Sorry. Maybe in the future. --=20 Matt Behrens <ma...@zi...> <http://www.zigg.com/> Life's too short to recompile what you don't hack. <http://www.debian.org/> |