*BSD News Article 22584


Return to BSD News archive

Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!library.ucla.edu!europa.eng.gtefsd.com!uunet!nih-csl!postman
From: crtb@helix.nih.gov (Chuck Bacon)
Subject: Disklabel vs. DOS partition table
Message-ID: <1993Oct19.145248.22328@alw.nih.gov>
Sender: postman@alw.nih.gov (AMDS Postmaster)
Organization: National Institutes of Health, Bethesda
Date: Tue, 19 Oct 1993 14:52:48 GMT
Lines: 39

I've seen numerous posts complaining that the DOS or the BSD
filesystem got zapped, either by FDISK or by disklabel.
Having just lost both a DOS and a BSD partition while trying
to get pcfs to mount, I'd like to get straightened out!

Question 1:
What is the relation between the DOS partition table's location
(the very first sector on the disk, I think) and that of the
disklabel?  I.e., where does the disk label get written?

Question 2:
What is the minimum coordination between the DOS partition table
and the disk label which will allow pcfs to mount?

Question 3:
Is the c partition determined by wired-in logic, or does it
depend on pc# and oc# values in disktab?  This appears to be
important, since all the examples in /etc/disktab have defined
c partitions, with oc#0.

Question 4:
Just exactly what does disklabel do?  With -r, it reads from the
disk, and without, it uses an in-core copy.  OK.  But what's
getting edited with -e?  Since -w requires a disk name, apparently
to look up in /etc/disktab, what's the point of editing?  I've
apparently edited successfully by editing /etc/disktab, but not
by use of -e.

Question 5:
I have found that FDISK will place the first DOS partition of the
first disk exactly one track in from the beginning of the disk,
but it will locate the first DOS partition of the second disk one
*cylinder* in.  If I use Norton's diskedit, say, to revise this to
start the second disk's DOS partition in the second track, will
DOS work?  And what's the impact on the disk label?

--
	Chuck Bacon - crtb@helix.nih.gov ( alas, not my 3b1 )-:
		ABHOR SECRECY	-   DEFEND PRIVACY