I am trying to construct some custom kernel/ramdisk combinations and
am running into problems that indicate I don't fully understand the
process.  I'm hoping one of the ramdisk wizards here can help out.

First, I can create bootfloppies using the provided tools (e.g., in
/usr/src/distrib/i386/floppies) just fine.  I can also manipulate
those tools either to include a custom kernel on my floppy or to alter
the composition of the ramdisk.  I also understand that the size of
the ramdisk allocated in the kernel by

    options MINIROOTSIZE=...

should match the size of the virtual device used for building the
ramdisk.

From there things get more fuzzy.  When I try to modify kernels, they
load from disk but the transfer of control to the kernel seems to
cause a reset.  I expect there is something misconfigured in the match
between my kernel and the ramdisk, but I don't know where to look.

- The organization of the bootfloppy appears to be the following
  (correct me if I'm wrong):

  block 0:  first stage bootloader
  block 17: second stage bootloader
  block 8k: beginning of bootloader/kernel compressed tar file

  - Why put the second stage bootloader at block 17?  This has no
    relationship to the track size of the disk.  Perhaps it
    shouldn't.

  - How does the first stage bootloader find the second stage one?

  - Why put the bootcode/kernel at an offset of 8k?

  - Why are there 2 copies of the same bootloader, one outside the
    compressed tar file and one inside it?

- Are there any constraints on the geometry or disklabel of the
  ramdisk as long as the total number of sectors equals the space
  allocated within the kernel by MINIROOTSIZE?

- Are there any constraints on the geometry or disklabel of the
  virtual disk used to construct the bootable image?  For example,
  must the disklabel used match the target device (e.g., floppy3 or
  floppy5) to which the image will ultimately be written?  I can
  write, for example, the rescue-tiny image created using the floppy5
  disklabel to a 3.5" disk and successfully boot, so there would seem
  to be no relationship between the target device and the disklabel
  used for the image.

- What principles must be followed in order to create a kernel/ramdisk
  combination that will boot successfully?

  - For example, what are the important elements of the INSTALL_*
    kernels that must be kept when deriving custom ones?

  - What (if anything) constrains the kernel size and the ramdisk
    size?

  - What other issues must be considered?

Thanks for any help you can offer.

Cheers,
Brook