Wow! That was far more of a detailed response than I was ever expecting.

On Fri, 21 May 2004, der Mouse wrote:

> > I've got a SPARCstation LX which in a previous life had RedHat 5.2
> > for SPARC installed on it.
> 
> > Alas, fool that I am, I also installed SILO on the MBR of the first
> > SCSI drive.
> 
> Um, Sun disks - at least on Suns of that era - don't have MBRs.  They
> don't even have anything very much like peecee MBRs (though for all I
> know sparclinux may try to pretend they do).
> 
> Where SILO is hiding is a question I can't easily answer.  But I can
> explain the boot process of a Sun (of that era), and you may be able to
> figure out where SILO is hiding from that.
> 
> When you tell the machine to boot (perhaps implicitly), you must tell
> it which partition to boot from (though this is often defaulted).  The
> ROM code in the machine reads the first sector of the disk.  This is
> the pack's label, and in particular it contains a partition table.  The
> ROM code then reads sectors 1 through 15 of the partition you're
> booting from (skipping sector 0, presumably in case the partition
> begins at offset 0, since in that case sector 0 is the label sector).
> The 7½K of data read from the disk is dumped into memory and called.
> It is then responsible for loading anything further.  Under NetBSD,
> this code loads the next stage boot program out of the root partition,
> either by walking the filesystem to find it or by loading block numbers
> hardwired at bootblock installation time, depending on the OS version.
> Under NetBSD, this next-stage boot program is the first part that
> normally prints anything; it loads the kernel and invokes it, and away
> you go.
> 
> My guess would be that your boot blocks (sectors 1-15 of your boot
> drive) are untouched from the sparclinux install, and either they
> contain SILO themselves or they're loading SILO from elsewhere, some
> "elsewhere" that didn't get overwritten during the NetBSD install.

This sounds spot on, although exactly _where_ the SILO was installed I 
haven't been able to find out. The "official" SILO site 
(www.sparc-boot.org) doesn't have that information and I've posted a 
question on this topic to their mailing list, but as of yet, I've not 
received any response - and it has to be said that it's not the highest 
volume mailing list I've ever seen, though that's probably doing them a 
disservice. But I digress.

From what you've said, it seems to imply that the process of formatting 
and partition creation that the installer does, doesn't revamp all of the 
disk.

If that's the case, would dd'ing from /dev/zero to the entirety of the 
disk do the trick? It may be a sledge hammer to crack a nut (to coin a 
cliche) but I'm assuming that if I drop down to a shell from the 
installer, _prior_ to actually performing the install and do something 
along the lines of

# dd if=/dev/zero of=/dev/sd0c bs=1024k count=whatever

this would zap the entire disk contents?

 > 
> I have a hazy memory that the installer didn't install bootblocks at
> some revision about that time; that would very neatly explain the
> symptoms you're seeing.  I'd suggest you boot to the installer, break
> out of sysinst, and installboot the bootblocks by hand.  (I'd give
> specific commands except that I don't know them for 1.6.2.  Once you're
> up under the installer, you can mount your installed root filesystem
> and chroot to it, and then use things like man(8) to read docs.)

I did try this but with no luck but I didn't chroot so I'll probably try 
this tonight.

Cheers

Gary

-- 
"There are two major products that came out of Berkeley; LSD and UNIX.
We don't believe this to be a coincidence."

BOFH Excuse #76: Unoptimised hard drive.

Linux, because eventually, you grow up enough to be trusted with a fork()