Re: Making a partition bootable (SS10)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am performing a fresh install NetBSD 4 (*) [...] SS10 [...], I
> thought of making a small boot partition.

Reasonable enough.  I routinely do that.

> I have thus a root partition and a small 20MB root partition which I
> put at the beginning of the disk.

I assume at least one of those "root"s should be "boot".  That's what I
do; for example, one of my machines has a mount table showing

Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
/dev/sd0d      33900347 29922214  2283115    92%    /
/dev/sd0a         63471    14814    45483    24%    /kernels
kernfs                1        1        0   100%    /kern
procfs                4        4        0   100%    /proc

/kernels holds boot, netbsd, and a handful of old versions of netbsd;
the old versions are of no use in routine operation, but are very
useful when I'm booting new kernels (which I do semi-regularly) which
don't always work right.

> What is the "boot" file?  at first, I was about to mount my boot
> partition into /boot as used on linux, but that would have been a
> problem.

/boot is the second-stage bootloader.

SPARC booting works in four stages.  The first stage (which I'll call
the 0th stage here, so that "first stage" aligns with most other uses
of the term) is the PROM code (the "ok " prompt).  This reads the next,
"first", stage read off the disk (off the beginning of the boot
partition) and jumps to it.  This uses ROM callbacks to load the second
stage from fixed block numbers, block numbers which are set by
installboot and which normally are the blocks making up /boot.  The
second stage presents the user-interaction prompts and, eventually,
loads and jumps to the kernel (the third stage).

As for putting your boot partition on /boot, that's workable if you do
it right, which admittedly is difficult if you don't quite have your
head entirely around the paradigm.  See below.

The second-stage bootloader, normally kept in /boot, has to be in the
portion of the disk accessible to the ROM.  Depending on the ROM code
your machine has, this may or may not be a significant restriction;
some versions can't access beyond the first gig of the disk (the
portion addressable by 6-byte CDBs, which have 21-bit block numbers).
Other versions can use 10-byte CDBs, good for, IIRC, 2T - but some of
those use 10-byte CDBs but then use 32-bit byte offsets internally,
leading to issues at 2G or 4G (depending on whether they're signed).
If you want to be safe, it needs to be below the 1G mark.

The second-stage bootloader does not, strictly, even need to be in a
file, but if it's not then you'll need to make your own arrangements
for getting its block numbers installed into the first-stage
bootloader.  (You can even rm the file afterwards and it will continue
to work until something happens to reallocate one of the relevant
blocks and write into it.)  That's normally done by installboot, and
installboot is built around the assumption that the second-stage
bootloader is in a file.  The file, assuming of course that there is
one, does not have to be called anything in particular, but you do need
to tell installboot where to find it so as to get the correct block
numbers to stick into the first-stage bootloader.

> I tried to copy "netbsd" and "boot" into the other partition and boot
> from it, but it doesn't work.

This should work _provided_ the partition containing them is all within
the first gig of the disk, and you (re)run installboot to set the
correct block numbers in the first-stage bootstrap, and you either (a)
build a kernel "config root on" your actual root partition, (b) boot
with -a so you can manually supply the root device, or (c) set up an
autoconfigured-as-root RAIDframe unit to steal root away from what it
would otherwise default to.

> Fdisk writes the boot sectors on a "whole disk".

Fdisk?  fdisk?  On NetBSD/sparc, I wouldn't expect there to even _be_
an fdisk.  (My own NetBSD/sparc machines are at 1.4T, which is what I
use on anything not needing something newer for hardware support
reasons; they have no fdisk.)  Unless it does something totally unlike
what it does on (eg) i386, I would not expect it to be useful in any
way here.  SPARC machines of the SS10 era - pretty much, anything
before Sun drank the PCI koolaid - have no use for MBR-style
partitioning.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B