Changing Kernel Configurations

Ross Oliver rosso at sco.COM
Fri Jul 20 07:26:05 AEST 1990


In article <1990Jul16.125419.1283 at bbt.se> pgd at bbt.se (P.Garbha) writes:
>In article <KAMBIZ.90Jul13114306 at mrspoc.Transact.COM> kambiz at mrspoc.Transact.COM (Kambiz Aghaiepour) writes:
>>
>>I am having problems changing the kernel configurations on one of our
>>systems here at Transact.  We are running SCO xenix on a 386 machine.
>>After changing the number of buffers (NBUF) and max. buffer heads
>>(MAXBUF), relinking xenix, and running hdinstall, I can no longer boot
>>from the new kernel.  Upon boot, I get the message :
>>
>>bn void <number>
>>bn void <number>
>>bn void <number>
>
>I get the same error message when i install the new irwin tape drivers
>from sosco. But I only get one "bn void 2", and then the system boots
>normally. (But the tape does not work).
>
>What does "bn void <number>" mean anyway?


Well, this is an ugly one.  The following explanation applies only if your
hard disk has more than 1024 cylinders.  During the boot sequence, the
boot program uses the computer's BIOS to load the XENIX kernel from the
hard disk.  However, the BIOS understands only disks of 1024 cylinders
or smaller.  If any of the disk blocks used to store the kernel reside
beyond the 1024th cylinder, the BIOS will not be able to read them, and
the boot program cannot finish loading the operating system.  Since
both of you started having this problem after building a new kernel, it
sounds like your disks have filled up past the 1024th cylinder, and your
new kernel resides (at least partially) on disk blocks past that point.

There is only one sure-fire way to fix the problem and prevent it from
happening again: rebuild your root filesystem so that it is completely
within the first 1024 cylinders.  This means reinstalling your operating
system and everything else on your root filesystem.

There is a less drastic fix you can try that MIGHT fix the problem
for now, but it will most likely happen again should you relink your
kernel again.  First, go into system maintenance mode to make sure there
is no other disk activity.  Then, remove some files that are sure to
be near the beginning of your disk (such as some operating system files).
Remove enough files to equal the size of your new kernel.  Then copy
(not move) your new kernel to another file.  The new file will be created
using the disk blocks freed by removing the other files.  You now should
be able to boot from the copied kernel.  This is only a temporary fix;
eventually, you should rebuild your root filesystem.

Ross Oliver
Technical Support
The Santa Cruz Operation, Inc.



More information about the Comp.unix.xenix mailing list