So after posting in another forum, I have managed to solve one of my problems and an able to boot. The solution to that first problem can be found here:
How does one add a file to the RDB of a Hard Disk? So now the system performs a long constant read of the hard disk on boot (the hard disk light is on steady). I presume this is reading the kernel. However, once this completes, I get the following:
s5mountroot VOP_OPEN error 6
WARNING: nfs_mountroot called
PANIC: vfs_mountroot: cannot mount root: errno 89
4.0 2.1c 0800430 Backtrace:
40001F44: 103EEF4… (and a bunch of hexadecimal loveliness).
Previously I had tried to make boot floppies with the modified GVP kernel. Thinking that while I might not be able to boot off of the hard disk, perhaps I could make a boot disk from the drive and then I could do things like add support for my Ariadne network card. Unfortunately, the disk did the same thing. Given I was working with a new, second hard disk (I had started the install process over just in case something else was wrong), I booted with my GVP boot floppy and created a new boot floppy. I tried booting from it to get exactly what I had gotten booting off of the hard disk, including the same hexadecimal values.
So, I wondered, I have a boot floppy that works - can I take that kernel and put it in the boot partition. Looking at how the kernel is made - it goes through an elf2brel process and then compressed and then catted to boot1 and boot2 files and written to the floppy with some padding. Only the elf2brel and compression is different. For a bit I thought about trying to extract the original kernel from the floppy, but that would be a rather involved task - after further thought, it seemed possible that just writing the floppy to the boot partition would work. So I dd'd the floppy to a file on the hard disk, and then dd'd that to the boot partition.
Shutdown, rebooted, and it worked. It's a little slow because it has to decompress the kernel, but it does boot.
So the new problem seems to be with the kernel itself.
I've extracted the patch files and made sure that the patches have been appropriately applied. One is to kernel.c and the other is to sd.c. They are very simple. An address and some function definitions / calls. Otherwise, the only other file is an object file: gvp_11.o. Of course this is a problem because it's not the source.
I find it weird that of the install package given via the Gateway CD, the GVP boot disk works, but the patch code doesn't. But that doesn't mean it can't happen.
So here are what I see as possibilities:
The address that was added to sd.c of the gvp_11 queue is wrong - or there is something in the gvp_11.o code that isn't working.
Things I can personally do:
1) See if the new GVP-M corporation has a copy of that gvp_11.c file. Though I wouldn't be surprised if they didn't.
2) Decompile the gvp_11.o file and see what the values are in there.
3) Try to recover (separate the boot and kernel files from the boot disk image and uncompress the kernel) and look at the differences between it and the kernel that my system makes. In theory, given there are no other extra drivers in the kernel and the kernels are the same level, the only differences I should see are the necessary ones. And perhaps I can use this to back engineer the gvp_11.o file, and make changes on the binary level.
So unless anyone else has any ideas, or the gvp_11.c file. I'm stuck booting with a very basic kernel.
Mack