On Fri, Jun 08, 2007 at 10:41:40PM -0400, Kenneth R Westerback wrote:
> This is very odd on several fronts. First, someone has obviously
> been writing on the MBR for no good reason. I just tested an fdisk
> compiled to day and noticed no oddities on my i386.
> 
> Second, the fact that you find a disklabel. Since we no longer store
> or look for disklabels in FreeBSD partitions it is being
> read from sector 1 if I recall the code correctly. But it should not
> have been writing the disklabel there when there was an OpenBSD
> partition to store it in.
> 
> Do you know if this is exactly the same disklabel you were using
> before? Have you changed anything in the disklabel recently that
> would identify this as an artifact that just happened to be lying in
> sector 1 for a while?

Other than reducing the size of the last partition a couple of months
ago, there has been no (intentional) change to that disklabel since:

> On Wed, Oct 11, 2006 at 08:09:08AM -0700, K WESTERBACK wrote:
> > Darn. A perfectly good theory shot to hell. :-).
> > 
> > It would seem that you have a 'valid' disklabel at
> > sector 1 of that disk.
> > 
> > First, if you could save the first two sectors of the disk
> > with
> > 
> > dd if=/dev/rsd1c of=SaveMySectors bs=512 count=2
> > 
> > and send me that file, and do two experiments, I would
> > appreciate it.
> >
> > If you can run fdisk against the disk and change the partition
> > type to 'A6' (OpenBSD) the correct disklabel should be read
> > in and you should get the 'old' info back again.
> >
> > Second, if you are the risk taking type, change partition type
> > back to 'A5' (FreeBSD) and zero out sector 1 on the disk with
> > something like
> > 
> > dd if=/dev/zero of=/dev/rsd1c bs=512 count=1 seek=1
> > 
> > Then see what disklabel says. You should get a simple
> > spoofed disklabel with 'c' and 'i' partitions.
> >
> > Finally, changing the partition type to 'A6' again should give
> > you access to the data.

That was the last change I'm aware of.

> Can you copy the MBR and send it to me. There might be a clue as to
> what overwrote it. Then I would do "fdisk -i" and see what happens.
> This will move the OpenBSD partition to partition 3, but cover the
> entire disk as your original MBR did. Then see if the disklabel,
> which should be read from the OpenBSD partition says.

I'll send the file attached to the next message, since I assume it would
be stripped from the mailing list.

After running fdisk -i sd1:

# fdisk sd1
Disk: sd1       geometry: 4462/255/63 [71687370 Sectors]
Offset: 0       Signature: 0xAA55
         Starting       Ending       LBA Info:
 #: id    C   H  S -    C   H  S [       start:      size   ]
------------------------------------------------------------------------
 0: 00    0   0  0 -    0   0  0 [           0:           0 ] unused
 1: 00    0   0  0 -    0   0  0 [           0:           0 ] unused
 2: 00    0   0  0 -    0   0  0 [           0:           0 ] unused
*3: A6    0   1  1 - 4461 254 63 [          63:    71681967 ] OpenBSD

It's back as an OpenBSD disklabel, but the c partition still starts at
63 rather than 0:

# disklabel sd1
# Inside MBR partition 3: type A6 start 63 size 71681967
# /dev/rsd1c:
type: SCSI
disk: da0s1
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 4462
total sectors: 71687370
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

15 partitions:
#             size        offset  fstype [fsize bsize  cpg]
  c:      71681967            63  unused      0     0      # Cyl     0*-  4461
  d:       2104452            63  4.2BSD   2048 16384  132 # Cyl     0*-   130
  e:       8385930       2104515  4.2BSD   2048 16384  328 # Cyl   131 -   652
  f:      23294250      48387780  4.2BSD   2048 16384  328 # Cyl  3012 -  4461
  h:       4112640      15936480  4.2BSD   2048 16384  256 # Cyl   992 -  1247
  i:       2104515      40933620  4.2BSD   2048 16384    1 # Cyl  2548 -  2678
  j:      18828180      20049120  4.2BSD   2048 16384  328 # Cyl  1248 -  2419
  k:       5349645      43038135  4.2BSD   2048 16384   16 # Cyl  2679 -  3011
  l:       2056320      38877300  4.2BSD   2048 16384  128 # Cyl  2420 -  2547
  m:       2104515      10490445  4.2BSD   2048 16384  132 # Cyl   653 -   783
  n:       2056320      12594960  4.2BSD   2048 16384    1 # Cyl   784 -   911

Emilio

Reply via email to