From owner-freebsd-questions@FreeBSD.ORG Thu Nov 11 05:01:35 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41DC5106564A for ; Thu, 11 Nov 2010 05:01:35 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B7B988FC12 for ; Thu, 11 Nov 2010 05:01:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PGPHw-0002Si-Vj for freebsd-questions@freebsd.org; Thu, 11 Nov 2010 06:01:32 +0100 Received: from pool-173-79-85-36.washdc.fios.verizon.net ([173.79.85.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Nov 2010 06:01:32 +0100 Received: from nightrecon by pool-173-79-85-36.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Nov 2010 06:01:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Followup-To: gmane.os.freebsd.questions Date: Thu, 11 Nov 2010 00:02:21 -0500 Lines: 52 Message-ID: References: <4CDB643A.4090308@me.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-173-79-85-36.washdc.fios.verizon.net Subject: Re: GPT Question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 05:01:35 -0000 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