Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!lanl!unm-la!unmvax!turing.unm.edu!mike
From: mike@turing.unm.edu (Michael I. Bushnell)
Newsgroups: comp.unix.wizards
Subject: Re: A few problems with BSD
Message-ID: <2036@unmvax.unm.edu>
Date: 10 Oct 88 09:50:24 GMT
References: <10194@eddie.MIT.EDU>
Sender: news@unmvax.unm.edu
Reply-To: mike@turing.unm.edu (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Lines: 53

In article <10194@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
~The following are a few problems I've had with 4.3BSD on a uVax II in
~dealing with disk subsystems that I've put together myself.  I'm
~wondering whether I'm doing something wrong, or whether these are
~known bugs, and whether or not there is a work-around:

We did this quite a lot (we are going to stop now that we have the
disklabeling drivers...)

~   (1) If you accidentally attempt to boot a system on a disk drive
~       for which there is no partition table in the kernal, BSD kindly
~       trashes the filesystem for you.  This is of more than academic
~       concern, because it has happened to me.  This happened when I
~       built a new kernal, but the distributed version of uda.c got
~       accidentally used, rather than our modified version.  Is there
~       any work-around for this problem?  (Other than being perfect
~       and never accidentally booting the wrong kernal.)

It is probably trashing the filesystem because it is swapping on it.
A pain, yes, but this is fixed in tahoe by the use of a disklabel on
the disk.  The kernel will use the label on the disk and not an
internal hard-coded partition table.  

~   (2) It appears that the BSD bootblocks will not boot a kernal that
~       is bigger than a certain size.  This happened to me, and it was
~       very frustrating to figure out what the problem was.  I finally
~       replaced the BSD bootblocks with the Ultrix bootstrap system,
~       and this fixed things.

This happened to me too when I made a significantly larger generic
kernel.  The problem is that boot is not relocating itself high enough
for the kernel to fit in underneath.  Change RELOC in
/sys/stand/Makefile to something larger.

~   (3) In the partition table for a disk drive, a "-1" for the size of
~       a partition is supposed to mean that the partition contains
~       everything up to the end of the disk.  It seems, however, that
~       this only works if the disk is less than a certain size.  Is
~       this indeed the case, or am I doing something wrong?  If I
~       could get this to work for any sized disk drive, then I could
~       make just one partition table for all drives and use the disk
~       partitioning features of our disk controller to make logical
~       disk drives in place of the normal BSD Unix disk partition
~       notion.

That is exactly what we do.  I don't know why it doesn't work for you.

                N u m q u a m   G l o r i a   D e o 

       \                Michael I. Bushnell
        \               HASA - "A" division
        /\              mike@turing.unm.edu
       /  \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike