Subject: port-i386/2729: Fake i386 disklabel can be confusing
To: None <gnats-bugs@NetBSD.ORG>
From: Scott Reynolds <>
List: netbsd-bugs
Date: 09/03/1996 14:41:47
>Number:         2729
>Category:       port-i386
>Synopsis:       Fake i386 disklabel can be confusing
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Sep  3 16:05:04 1996
>Originator:     Scott Reynolds
>Release:        NetBSD >= 1.1
System: NetBSD bonzai 1.2_BETA NetBSD 1.2_BETA (TGI) #7: Thu Aug 1 16:57:07 CDT 1996 scottr@beech:/a/src/sys/arch/hp300/compile/TGI hp300

	The default faked-up disklabel for the i386 port can cause
	inexperienced NetBSD admins pain when they try to add a "new"
	NetBSD partition to their system.  When a disk's MBR partition
	table has a single partition marked as type 165, the fake
	label generated correctly identifies it, but as partition
	`a' instead of partition `c'.  When the unsuspecting admin then
	edits the label to their liking, but (mistakenly) omits the
	proper size and offset for the `c' partition, they are met with
	the following message when they try to put the label on the

		Erase the previous contents of the disk?

	Undoubtably some folks will answer in the affirmative to this,
	thereby wiping out the MBR.  (This is especially true when
	nothing has been installed in other partitions on the disk.)
	When they later go to install D*S and find that the MBR partition
	table is missing, they run FDISK and recreate it -- only to later
	find that the NetBSD label has been wiped out.

	It's easiest to demonstrate like this, using wd1 as an example:

		disklabel wd1 >the_label
		#edit the_label as appropriate, sans the `c' partition
		disklabel -R -r wd1 the_label

	You'll be asked if you want to erase the previous contents of
	the disk.

	Education can go a long way, but by faking up the `c' partitions
	appropriately we can avoid much confusion.  I'm not sure whether
	it's better to simply change the current behavior, moving `a' to
	`c', or to define them concurrently.  I'd tend towards the former,