From owner-freebsd-hackers  Thu Jan  9 18:17:50 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id SAA06986
          for hackers-outgoing; Thu, 9 Jan 1997 18:17:50 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA06978
          for <hackers@FreeBSD.org>; Thu, 9 Jan 1997 18:17:44 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA19116; Thu, 9 Jan 1997 19:05:45 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199701100205.TAA19116@phaeton.artisoft.com>
Subject: Re: 2.2-BETA install report, minor problems.
To: mrcpu@cdsnet.net (Jaye Mathisen)
Date: Thu, 9 Jan 1997 19:05:44 -0700 (MST)
Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.org
In-Reply-To: <Pine.NEB.3.95.970109165119.11087K-100000@mail.cdsnet.net> from "Jaye Mathisen" at Jan 9, 97 04:54:07 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > BSD/OS uses a totally `weird' bootstrap if used in dedicated mode
> > (withouth an fdisk table).  This is something like our `dangerously
> > dedicated' mode, and BSDi should probably warn about its dangers as
> > well.  You just felt it...
> 
> 
> I submit that if I'm selecting that FreeBSD use the entire disk, and I
> insiste that it use the entire disk this way, and "Yes, I don't want to be 
> compatible with any type of OS co-existence", that then the exhibited 
> behaviour is a bug.
> 
> Maybe freebsd needs to zero the disklabel or something itself.  I know
> Alpha's under Digital UNIX had a -z option to disklabel to zero it out.  
> There should be a way to zero out the partition table as well.
> 
> BSD/OS does warn about the dangers, but since I'm not co-existing, I'm
> replacing, then I think our stuff should be able to handle it.

The question is not whether we can handle it.

The question is whether the Copmaq DeskPro/E can handle it, since its
POST code bootstrap checks the boot sector for "validity" (in the
DOS'est sense of the word).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.