Re: GPT Question

2010-11-11 Thread Derek Funk

On 11/10/2010 9:34 PM, 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.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJM22Q5AAoJEB/pNtMYu8Pl8G4P/RyHfn03BxY0tSaii2J1a5gQ
L7q7ZK9mrvpXCv/tGk+ieWwct01cgpf3SRoEbmjpnL4c//g54fChCdOylJDD7wpU
LlxB4CsNMkV9JIT46zkw6ET6ERFYVC0sG+DxJr3JRCkRcTseQjNbNaKJuESMHsu3
OoYrjKjosz5juqkqS0Ty930KCcWRX5DYLsBH0QSHg7q+9ZNnFBuNIB0os4DyZ803
rmxg0bz4YDzTHFe7sJG1/uhN1gUGT3jGUuXUEKnKIrZQaUvdJe3xfNtq/mqHKiZG
il45ljdxESt/Y9p7MyGle439YM/BtFt48+O9vcbd0Oljl+nwlFVHNPMKd91KOv/b
WPd8y1wmO2X7tTUetDqjby3GlRjvpuPrzddfbpj87DqKdvJ3hqGtGRflrMeWLklg
dAS5n3Q8x42vu/5CXlCWtNO2GQMYWTX7VPWmCzymzC60A3YM4UoY3GEF7PV/tChS
etUVcSp3JhpepOjgVyY7SA+dO3sZhLAvulqhy/KX6E1ffkCoRMPYWdu9zYXk1F/i
6tEpEDdU7QAViCSbUnp7ZZrt/QcG5XbD0yOUy1M/bvfkGo3qd+TukTCJ8s0JDZ8x
lPYF+p8pkzm9zfFeA1e90VqkkhNb/gDFzwg3grcO5hEse4OXlsXMmA5kfxjVKbFj
mUO0LYyMmd0QW49J91ts
=w5P4
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org

   
My understanding is, if you are using FreeBSD 8.x, sysinstall / fdisk 
will not write disk partitions.  gpart is used now.


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: GPT Question

2010-11-11 Thread Ian Smith
In freebsd-questions Digest, Vol 336, Issue 9, Message: 23
On Thu, 11 Nov 2010 17:45:19 -0600 Derek Funk dfu...@cox.net wrote:
  On 11/10/2010 9:34 PM, Mark Caudill wrote:
[..]
   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.

  My understanding is, if you are using FreeBSD 8.x, sysinstall / fdisk 
  will not write disk partitions.  gpart is used now.

Your understanding is incorrect.  In 8.x you MAY use gpart now, but 
sysinstall (when running as init from a booted installation medium) 
still slices and partitions disks fine, and sysinstall - or sade(8) - 
(when run as a utility from a working system) will indeed write to the 
boot sectors including MBR, and will happily slice and partition disk/s 
other than the boot slice, if and only if you have previously set sysctl 
kern.geom.debugflags=16 - not called the 'foot-shooting' bit for nothing 
- so don't forget to set it back to 0 when you've finished.

cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


GPT Question

2010-11-10 Thread Mark Caudill
-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.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJM22Q5AAoJEB/pNtMYu8Pl8G4P/RyHfn03BxY0tSaii2J1a5gQ
L7q7ZK9mrvpXCv/tGk+ieWwct01cgpf3SRoEbmjpnL4c//g54fChCdOylJDD7wpU
LlxB4CsNMkV9JIT46zkw6ET6ERFYVC0sG+DxJr3JRCkRcTseQjNbNaKJuESMHsu3
OoYrjKjosz5juqkqS0Ty930KCcWRX5DYLsBH0QSHg7q+9ZNnFBuNIB0os4DyZ803
rmxg0bz4YDzTHFe7sJG1/uhN1gUGT3jGUuXUEKnKIrZQaUvdJe3xfNtq/mqHKiZG
il45ljdxESt/Y9p7MyGle439YM/BtFt48+O9vcbd0Oljl+nwlFVHNPMKd91KOv/b
WPd8y1wmO2X7tTUetDqjby3GlRjvpuPrzddfbpj87DqKdvJ3hqGtGRflrMeWLklg
dAS5n3Q8x42vu/5CXlCWtNO2GQMYWTX7VPWmCzymzC60A3YM4UoY3GEF7PV/tChS
etUVcSp3JhpepOjgVyY7SA+dO3sZhLAvulqhy/KX6E1ffkCoRMPYWdu9zYXk1F/i
6tEpEDdU7QAViCSbUnp7ZZrt/QcG5XbD0yOUy1M/bvfkGo3qd+TukTCJ8s0JDZ8x
lPYF+p8pkzm9zfFeA1e90VqkkhNb/gDFzwg3grcO5hEse4OXlsXMmA5kfxjVKbFj
mUO0LYyMmd0QW49J91ts
=w5P4
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: GPT Question

2010-11-10 Thread 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



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org