Hi, On 10-1-2 下午3:06, olafbuddenha...@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