Subject: Re: hosed partition table
To: None <netbsd-users@netbsd.org>
From: None <tlaronde@polynum.com>
List: netbsd-users
Date: 10/24/2006 13:31:25
On Mon, Oct 23, 2006 at 05:51:19PM -0400, George Georgalis wrote:
> >>>>fdisk: DIOCGDEFLABEL: Inappropriate ioctl for device
> >>>>fdisk: DIOCGDINFO: Inappropriate ioctl for device
> >>>> $ disklabel wd1                                                        
> >>>>
> >>>>disklabel: Invalid signature in mbr record 0
> >>>>disklabel: ioctl DIOCGDINFO: Inappropriate ioctl for device
[..]
> 
> I can use to "disklabel -i -I wd1" to add or remove partitions c
> or d; but there is a special property of d being 63 sectors larger
> then the largest c ("entire disk") which I cannot reproduce...
> that's where I'm stuck.

It seems that there is a mess with the MBR.

From what I have read in the sources (take with care; other more
knowledgeable please correct if I'm wrong).

You have two choices. Whether using traditionnal i386 MBR (4 primary
slices called partitions), or don't use the traditionnal MBR and
dedicate the whole disk to NetBSD: in this case there is no MBR.

The differences are:

1) If there is a MBR, a slice (partition) has to be flagged NetBSD (169)
so that subr_disk_mbr.c can find a disklabel (the first valid one
searched in the flagged NetBSD slices, searched in order).
	Secondly, traditionnally, the first 64 sectors are skipped (the
	difference between c and d is, in your case, there: if you had a 64
	shift between c and d before, this means that you had a MBR. You
	seem to have one no more?)

2) If there is no MBR, the disklabel is found in the second sector of
the whole disk.

Here, you have a mix between the two solutions: an empty MBR but with a
disklabel probably in the second sector of the whole disk as is the case
for a whole dedication.

You should have first resurrected the MBR from the info saved in
var/backups, and it could have just "magically" restored everything if
the disklabel in the slice dedicated to NetBSD happened to be correct.

Hope this helps (and that there is not too much errors ;)
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C