Subject: RE: NetBSD Hang after disklabel, xsm crash
To: None <gunnar@bitcon.no>
From: None <Havard.Eidnes@runit.sintef.no>
List: port-i386
Date: 07/29/1998 16:59:20
> > This is your first big problem.. While you might be able to
> > use partition c and d on an i386, it's use is considered a
> > bad idea, and might break on occasion. The right thing to do
> > is to make a new partition, a, and make it the same size as
> > the c or d partition.
>
> OK, now I'm confused. I thought that using partition d was a
> bad idea but using partition c was OK, at least if c is offset
> 63 sectors from the beginning of the disk.
>
> Please tell me it's so, most of the disks on our FTP server are
> set up like this... :-| (they are working fine so far (NetBSD
> 1.3), but you've got me worried that something might break in
> the future if I upgrade...)
For what it's worth, here's my current understanding of these
things as they appear on the i386 platform:
If you are going to use the entire disk for NetBSD, and use the area
from sector 0 to the end as a single file system, it really does not
matter whether you use partition "a", "c" or "d" for the file system
partition. The caveat is that if you use the "d" partition, you
cannot re-label the disk without first unmounting the file system on
the same partition, because the disklabel is written using RAW_PART
which is partition "d" on the i386, and NetBSD doesn't much like
multiple "open"s on a partition. (But then again, this is probably
not a serious limitation, since you'd have to dump(8) the file
system contents, unmount the partition, relabel, newfs and
restore(8) anyway to resize the partition to make room for another
one.)
Some BIOSes may dislike you using the first area on the disk for
your own purposes, I presume that is why some have mentioned "63" as
a (presumably) safe starting point for the NetBSD portion, and as
far as I can tell sysinst defaults to that method as well.
Both the NetBSD disklabel and the first-stage boot loader (or
"master boot record", if you will) can live within a "live" file
system, because the file system code has been taught not to touch
the areas used for these functions, as witnessed by the definition
of SBOFF and BBOFF in the file system code and in newfs. (Not so
with the swap code, though, so it is a really dumb idea to use the
first part of the disk as part of a swap partition, as I had the
dubious pleasure of experiencing first-hand on SunOS a long time
ago.)
Regards,
- H=E5vard