On 08/09/2013 05:38 AM, Federico Giannici wrote:
I don't know how I made it (probably in previous releases of OS), but
now I have a disk with the following disklabel:
# /dev/rsd2c:
type: SCSI
disk: SCSI disk
label: ST1000DM003-9YN1
duid: b0e3fc037df87899
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 121601
total sectors: 1953525168
boundstart: 64
boundend: 1953520065
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 1953519936 64 4.2BSD 8192 65536 1 # /bu
c: 1953525168 0 4.2BSD 2048 16384 1
As you can see the "c" partition is not of type "unused", and some
commands complain of this.
oops. (about your "use" of 'c', not the complaining)
I wasn't able to change this situation. I tried with "disklabel -E sd2",
"disklabel -d sd2", "disklabel -R sd2 proto" (with a proper "proto"
file), but nothing changed.
What is the proper way to handle this?
Please note that "a" partition contains data that must be preserved (I
umounted that partition before all disklabel commands).
that response pretty well indicates "insufficient backups".
Just thought I'd mention that.
The system is a 5.3 amd64, and sd2 is a normal SATA disk.
Thanks.
I'm testing on -current-ish.
Nifty. I was able to create a disk similar to yours (used "disklabel
-e", changed the partition type from "unused" to "4.2BSD", and filled in
the other fields as yours was). I also had trouble "fixing" it.
It appears there is insufficient checking to prevent this from
happening, but too much to fix it. Maybe e"X"pert mode can have this
relaxed so you can edit 'c', both to screw the pooch...and maybe unscrew
it, too.
disklabel -E showed the overlapping partitions, asked me which I wanted
to disable, I disabled 'c', it showed everything exactly as I wanted it,
wrote to disk, reinvoked disklabel and the old c -- 4.2BSD was back.
disklabel -e let me change the type from 4.2BSD to MSDOS to RAID, but
not to "unused". changing it to "unused" or an invalid fstype resulted
in no change being made, with an error message if the fstype was
unknown, but silent failure if fstype was valid.
using disklabel -e to delete the 'c' line also silently failed to change
anything.
using disklabel -E, disabling 'c' (as I had to disable something),
hitting "A" to autoconfigure the drive looked good, but upon saving and
re-loading disklabel, I 'c' was back to (in my case) RAID. My partition
was gone and replaced with the Autoconfig layout.
At this point, for comic relief, I'm going to point out I'm doing this
on my netbook, which has a SD card in it that ends up with a backup of
my believed most important files (at the time I wrote the script) every
time I boot the machine up. I'm doing this on my SD card. So I, too,
am working with insufficient backups now. :)
Here's the good news: disklabel does not hit the partitions themselves.
As long as I put my 'd' partition back when I am done with the exact
same parameters it had before (and don't write anything else to that
part of the disk), my data will still be there. hopefully. :)
Making changes in -E then doing a "disklabel -c" to read from disk ended
up with no productive change.
AH-HAH! Got it! Definitely a "work around", not what I'd call elegant,
and it may scare the hell out of you...
1) Backup your data. you won't need it. probably. :)
2) Go into fdisk, change the starting offset of the partition from 64 to
63 (could be 23, too. anything smaller than 64 and bigger than 2 or
so). That will screw with all the offsets for the existing disklabel,
you will now end up with a completely new disklabel (or so I thought)
3) disklabel the disk. Curiously, this pulled up almost my exact OLD
disklabel, 'cept my 'd' partition (and yes, it was 'd') started at
sector 63, instead of 64. I have no idea where this came from. Last I
saw, I had most of an 'A'uto disklabel in place. I can not explain
this. Finding the current disklabel, I'd have believed. finding no
disklabel, I expected. Finding something too like my original disklabel
to be an accident? no. Your milage may vary.
You have a couple options here.
4a) You could just recreate exactly the disklabel you had before, and
other than the "boundstart" sector being wrong (now 63, was 64), you are
done. Or...
4b) go back in with fdisk and move the start back to 64, and then go
back into disklabel and rebuild things.
5) Verify that your data is intact.
I did 4b, and the big gotcha of the end result is since the disklabel
ended up being rebuilt completely, it now has a new duid. Unlike you, I
didn't jot down my duid. Yours is in the e-mail :)
So...work around. Ugly. I learned something, but I'm not quite sure
what yet. I think there's a bug in there somewhere.
Nick.
