GPT Question

[Michael Powell]

Mark Caudill wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Firstly, hello list. This is my first post here and while I'm a long
> time Linux user, I'm a recent FreeBSD convert so please bear with me.
> Yesterday I installed an extra hard drive that used to be in a Windows 7
> box. In sysinstall I ran fdisk then label to try to get the disk ready.
> The problem was that even though after I hit 'w' and it didn't give any
> errors, when I did a `ls /dev/ad*` it was still showing the old
> partitions, even after a reboot. I tried running fdisk manually and a
> few other things I found on Google but they all seemed to just be
> silently failing since they never showed an error but the changes never
> really went into effect. When I was first building out this box I had an
> issue partitioning the disks but the behavior was different in that it
> errored with messages about not being able to commit or write the
> changes to disk. That issue turned out to be with some GPTs on the drive
> which I was able to remove in Linux with parted. Anyway, I figured that
> there was a chance that this might be a GPT issue since this drive came
> form the same machine as the other. I couldn't remember what command I
> had run and didn't feel like pulling the drive into another machine so I
> just ran `dd if=/dev/zero of=/dev/ad12 bs=512` and let it run. That must
> have done the trick because I was then able to partition the disk in
> sysinstall and all is well. What I'm wondering is what really went on
> here? I'm not clear at all as to why FreeBSD (or some mechanism within
> this installation) isn't able to handle this. Or was this a GPT issue at
> all? I'd like to find out what was going on so that I don't chase my
> tail again on issues like this in the future. Thanks.

I don't know if this may, or may not, be strictly a GPT issue. I had a drive 
fail and the one I pulled out of the junk box for temporary use had FreeBSD 
6.2 on it. Somewhere between 7 and 8,1 there was some kind of change where 
the old mbr or partition table was invisible to the new system, and hence 
you couldn't write out to it because as far as the new system was concerned 
it wasn't there. I suspect that other format incompatibilities such as what 
I experienced can be caused by other forms of previous mbr/partitioning data 
as well, and your experience would fall in this category.

For me the magic incantation was to boot a LiveFS 'fixit' (the fixit shell 
in sysinstall works the same) and zero out the mbr. This first command gives 
you dangerous, mighty, and all-powerful write access:

sysctl kern.geom.debugflags=16      and next zero the mbr with this:

dd if=/dev/zero of=/dev/adx oseek=1 bs=512 count=1  where (x) is your drive 
number. If my theory is correct and you have seen a similar situation, these 
two things are the quickest and easiest way to get around it.

-Mike