Subject: Finally - end of my kernel woes - sort of
To: None <current-users@NetBSD.ORG>
From: David Jones <dej@inode.org>
List: current-users
Date: 04/13/1997 14:20:44
Just an update to my earlier post on difficulties compiling the kernel.

I was unable to use a kernel that I compiled myself to compile the
sources again.  The result was unbootable.

In addition (and this was obvious if I stopped to think about it), whatever
problem that stopped me from compiling a kernel ALSO caused corruption
when I tried to copy a known good kernel (KGK) to the boot drive.

The solution was clear: get the KCADP-1.2.1 floppy, boot from it, and use
the kernel copy procedure to copy the 1.2.1 generic kernel to the boot
drive.  Note that I am booting from a KGK, and using the KGK to copy
a KGK to the boot drive.

After that, I was OK.  I updated sources, and built a kernel using that,
which booted.  And everyone lived happily ever after... NOT!!!


I still have the problem:

- I can boot the KGK and use it to compile a kernel.  Call the new kernel
  F95.
- I can boot F95, and use it to filter/route packets (which is what the
  machine is for).  So far so good.  BUT:
- I ***CANNOT*** boot F95 and use it to compile an updated F95 (call it
  F95B).  F95B will not boot.  Instead, immediately after printing
  "entry point 0x100020", the machine reboots, as if I had hit the reset
  button.
- If I halt the machine and reboot from the KGK, I can compile F95B,
  and have it work.

All sources are updated from yesterday.

Now this is not a show-stopper, since the work-around is easy: reboot from
KGK every time I need to recompile F95.  But I wonder why this is the case?


On to another subject: you can't print quads in the kernel.  The system
simply does not grok %qd.  Should I send-pr this (or better, re-work the
*printf functions in subr_prf the way I think they should be, and
send-pr the diffs)?