Well, I did some good old empirical research on this serverboot mystery and by changing
this: -T typed ${root} $(task-create) $(task-resume) to this: -T typed ${root-device} $(task-create) $(task-resume)
I can then get kernel to boot up to where it hangs at ext2fs.static with the following text preceeding...
task loaded: /hurd/ext2fs.static --multiboot-command-line=/boot/kernel root=hd0s1 --host-priv-port=2 --device-master-port=3 --exec-server-task=4 -T typed hd0s1
task loaded: /lib/ld.so.1 /hurd/exec
start /hurd/ext2fs.static: _
And there it remains until I hit the reset button. I couldn't debug this because it trapped out before getting this far with the debugger running.
Using serverboot.gz gives me the old mysterious insto-reboot. Didn't mess with it any more yet, but it does boot gnumach.gz just fine.
This may be a problem on my side now, as I built this kernel today with a slightly modified };)> oskit source: basically I hacked about 60% of the code out of the tree leaving an "oskit-tiny" which still compiled. Yeah, I know this was probably an evil thing to do, but I was bored. ( Got it down to 3MB bzip2'ed )
I'll recompile and reinstall "regular" oskit tomorrow and see if it makes a difference.
- Doug