bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cannot boot subhurd


From: Da Zheng
Subject: Re: cannot boot subhurd
Date: Sat, 02 Jan 2010 22:46:20 +0800
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

Hi,

On 10-1-2 下午3:06, olafBuddenhagen@gmx.net wrote:
> But then you still have a boot sector and probably a few empty sectors
> before the start of the actual partition -- I don't see how ext2fs could
> ever have mounted this...
> 
> Unless you actually did "mke2fs /dev/hd1" after partitioning -- which
> *overwrote* the partition table you created with fdisk, and instead put
> the filesystem directly on the unpartitioned disk.
> 
>> I tried to create /dev/hd1s1, but it doesn't work.
> 
> Err... What do you mean? You can't mke2fs /dev/hd1s1? Well, if indeed
> you overwrote the partition table as described above, that's no wonder
> :-)
Yes, I did "mke2fs /dev/hd1". After partitioning, I tried to create hd1s1 device
file with MAKEDEV, but got the error "Unknown code P 6 while trying to determine
filesystem size" after I ran "mke2fs /dev/hd1s1".

In fdisk, I printed the information of all partitions, and see the device name
is called hd1p1, but I couldn't create a device file called hd1p1 with MAKEDEV.
> 
>> I finally got a working subhurd
> 
> Let us know what the problem was, and how you got around it :-)
I simply created another disk and copied all files in the main Hurd to that disk
with a little adjustment (I created device files and servers manually). It works
pretty well now.

I tried crosshurd. It doesn't work. Anyone maintains crosshurd?
>> I wonder if it's because the proc server in subhurd cannot run in a
>> higher priority.
> 
> Doesn't seem too likely to me... If some protocol relies on proc being
> scheduled before other processes, that would be *extremely* fragile.
> 
> Of course you could still test what happens if you set the higher
> priority with some backdoor or a debugger or something. Perhaps the
> lower priority indeed uncovers some kind of race condition... Though I
> must say that other race conditions (like the auth one) seem more
> likely.
I agree that lower priority isn't the direct cause of hangs, but if raising the
priority can solve the problem, we should do it.

Zheng Da




reply via email to

[Prev in Thread] Current Thread [Next in Thread]