Re: 9.1 won't install - GEOM/GRAID issues

2013-01-08 Thread Mike.
On 1/8/2013 at 7:51 AM Warren Block wrote:

|On Tue, 8 Jan 2013, Mike. wrote:
|
|> On 1/2/2013 at 12:11 PM Fbsd8 wrote:
|>
|> I tried to run the dd commands...
|>
|> Using the LiveFS disc for FreeBSD 9.1, I got some manner of
permission
|> error, indicating that something would not let the dd commands
execute.
|> Using the LiveFS disc for FreeBSD 8.3, the dd commands completely
|> successfully.
|>
|> After zero-ing out the sectors, I tried to install FreeBSD 9.1, and
I
|> continued to get the RAID problems trying to mount root.
|>
|> So I punted that drive, and used another drive.   FreeBSD 9.1
installed
|> without an issue, and it is running fine as I type this.
|>
|> So there is something about that other disk drive (something that is
|> not in the last two sectors or the first sector) that the 9.1
install
|> has issues with.
|
|RAID metadata could be larger than the last two blocks.  Even a
leftover 
|GPT backup table is 34 blocks by default.  If the drive is still 
|attached to the controller that put the metadata there, it may hide 
|those blocks from the user.  The RAID BIOS menus or graid(8) may be 
|needed to clear the metadata in that case.  Or move the drive to
another 
|controller that will not recognize the old metadata.
 =

I was also thinking that the RAID meta could be larger than the last
two blocks, but I didn't want to start arbitrarily overwriting blocks
with zeroes.  With the goal of moving along with the install, I
preferred to use a different drive.

I do not think the drive was ever attached to a RAID controller as part
of a RAID array.  As I mentioned earlier, there is a Promise RAID
controller in the box.  That controller was not set up as a RAID
controller, but as a vanilla SATA controller.  And, after checking
inside the box, the drive in question was not plugged into the RAID
controller, but a vanilla SATA port on the motherboard.   It may be
possible that the RAID controller nonetheless did have the opportunity
to put its "mark" on the drive at some point in the distant past.  I
cannot rule that out completely.   It just would have been nice if the
FreeBSD install offered a better way to recover from the problem.

I plan to do a full wipe of the old drive using dd to completely clear
it out.





___
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: 9.1 won't install - GEOM/GRAID issues

2013-01-08 Thread Warren Block

On Tue, 8 Jan 2013, Mike. wrote:


On 1/2/2013 at 12:11 PM Fbsd8 wrote:

I tried to run the dd commands...

Using the LiveFS disc for FreeBSD 9.1, I got some manner of permission
error, indicating that something would not let the dd commands execute.
Using the LiveFS disc for FreeBSD 8.3, the dd commands completely
successfully.

After zero-ing out the sectors, I tried to install FreeBSD 9.1, and I
continued to get the RAID problems trying to mount root.

So I punted that drive, and used another drive.   FreeBSD 9.1 installed
without an issue, and it is running fine as I type this.

So there is something about that other disk drive (something that is
not in the last two sectors or the first sector) that the 9.1 install
has issues with.


RAID metadata could be larger than the last two blocks.  Even a leftover 
GPT backup table is 34 blocks by default.  If the drive is still 
attached to the controller that put the metadata there, it may hide 
those blocks from the user.  The RAID BIOS menus or graid(8) may be 
needed to clear the metadata in that case.  Or move the drive to another 
controller that will not recognize the old metadata.

___
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: 9.1 won't install - GEOM/GRAID issues

2013-01-08 Thread Mike.
On 1/2/2013 at 12:11 PM Fbsd8 wrote:

|Michael Powell wrote:
|> Mike. wrote:
|> [snip]
|>> Thanks for the reply.   The disk in question has never been used
for
|>> RAID, so if there is RAID metadata on the disk, I do not know how
it
|>> got there.  The disk is (I believe --- it's been a while since I
have
|>> been inside that box) on a Promise SATA RAID controller, but RAID
is
|>> not used and has never been used (I have a 3Ware controller for
RAID on
|>> that box).
|>>
|>> When things settle down, I'll try to figure out how to sanitize the
|>> disk and try to install 9.1 again.
|>>
|> 
|> If somehow some RAID controller ever wrote out metadata to the disk
it
|will 
|> be the last sector or two at the very end. Sometimes some GPT
|partitioning 
|> schemes corrupt this too. If some alien form of GPT partitioning or
some 
|> form of RAID has written anything to this area it will throw an
error
|when 
|> GEOM 'tastes' the disk. 
|> 
|> You can zero both these areas with dd if=/dev/zero plus disk plus
some 
|> arithmetic. Another way, and I do sometimes when I go to reuse a
disk
|that's 
|> been used for a while, is to use the mfr's diagnostic utility. I
know
|the WD 
|> diag utility has an option to write 0's to the entire drive.
Sometimes I
|do 
|> this and then run the extended diags just to get a 'feel good'
factor on
|the 
|> media. Trouble with this is the larger the disk gets the longer it
|takes. I 
|> just like media scans on old disks before I recycle them to a new
|project.
|> 
|> -Mike
|> 
|>
|
|Here is a little script named gpart.nuke that may help you
|
|#! /bin/sh
|echo "What disk do you want"
|echo "to wipe? For example - da1 :"
|read disk
|echo "OK, in 10 seconds I will destroy all data on $disk!"
|echo "Press CTRL+C to abort!"
|sleep 10
|diskinfo ${disk} | while read disk sectorsize size sectors other
|do
|  # Delete MBR and partition table.
|  dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
|  # Delete GEOM metadata.
|  dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr
$sectors 
|- 2` count=2
|done
 =


A follow-up to this issue.

I tried to run the dd commands...

Using the LiveFS disc for FreeBSD 9.1, I got some manner of permission
error, indicating that something would not let the dd commands execute.
 Using the LiveFS disc for FreeBSD 8.3, the dd commands completely
successfully.

After zero-ing out the sectors, I tried to install FreeBSD 9.1, and I
continued to get the RAID problems trying to mount root.

So I punted that drive, and used another drive.   FreeBSD 9.1 installed
without an issue, and it is running fine as I type this.

So there is something about that other disk drive (something that is
not in the last two sectors or the first sector) that the 9.1 install
has issues with.




Thanks for the assist.



___
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: 9.1 won't install - GEOM/GRAID issues

2013-01-02 Thread Fbsd8

Michael Powell wrote:

Mike. wrote:
[snip]

Thanks for the reply.   The disk in question has never been used for
RAID, so if there is RAID metadata on the disk, I do not know how it
got there.  The disk is (I believe --- it's been a while since I have
been inside that box) on a Promise SATA RAID controller, but RAID is
not used and has never been used (I have a 3Ware controller for RAID on
that box).

When things settle down, I'll try to figure out how to sanitize the
disk and try to install 9.1 again.



If somehow some RAID controller ever wrote out metadata to the disk it will 
be the last sector or two at the very end. Sometimes some GPT partitioning 
schemes corrupt this too. If some alien form of GPT partitioning or some 
form of RAID has written anything to this area it will throw an error when 
GEOM 'tastes' the disk. 

You can zero both these areas with dd if=/dev/zero plus disk plus some 
arithmetic. Another way, and I do sometimes when I go to reuse a disk that's 
been used for a while, is to use the mfr's diagnostic utility. I know the WD 
diag utility has an option to write 0's to the entire drive. Sometimes I do 
this and then run the extended diags just to get a 'feel good' factor on the 
media. Trouble with this is the larger the disk gets the longer it takes. I 
just like media scans on old disks before I recycle them to a new project.


-Mike




Here is a little script named gpart.nuke that may help you

#! /bin/sh
echo "What disk do you want"
echo "to wipe? For example - da1 :"
read disk
echo "OK, in 10 seconds I will destroy all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
 # Delete MBR and partition table.
 dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
 # Delete GEOM metadata.
 dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors 
- 2` count=2

done



___
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: 9.1 won't install - GEOM/GRAID issues

2013-01-02 Thread Michael Powell
Mike. wrote:
[snip]
> 
> Thanks for the reply.   The disk in question has never been used for
> RAID, so if there is RAID metadata on the disk, I do not know how it
> got there.  The disk is (I believe --- it's been a while since I have
> been inside that box) on a Promise SATA RAID controller, but RAID is
> not used and has never been used (I have a 3Ware controller for RAID on
> that box).
> 
> When things settle down, I'll try to figure out how to sanitize the
> disk and try to install 9.1 again.
> 

If somehow some RAID controller ever wrote out metadata to the disk it will 
be the last sector or two at the very end. Sometimes some GPT partitioning 
schemes corrupt this too. If some alien form of GPT partitioning or some 
form of RAID has written anything to this area it will throw an error when 
GEOM 'tastes' the disk. 

You can zero both these areas with dd if=/dev/zero plus disk plus some 
arithmetic. Another way, and I do sometimes when I go to reuse a disk that's 
been used for a while, is to use the mfr's diagnostic utility. I know the WD 
diag utility has an option to write 0's to the entire drive. Sometimes I do 
this and then run the extended diags just to get a 'feel good' factor on the 
media. Trouble with this is the larger the disk gets the longer it takes. I 
just like media scans on old disks before I recycle them to a new project.

-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"


Re: 9.1 won't install - GEOM/GRAID issues

2013-01-02 Thread Mike.
On 1/2/2013 at 2:38 PM Fabian Keil wrote:

|"Mike."  wrote:
|
|> My FreeBSD server had been running fine, no issues.   This evening I
|> tried to update it to 9.1.  I don't "update in place", I update by
|> wiping the prior version and letting the new version have its way
with
|> the disk.
|> 
|> Well, 9.1 has issues with my system (dmesg is at the end of this
|> message).
|> 
|> When I boot from the install DVD, I see a lot of messages along the
|> lines of ~Root mount waiting for GRAID~, then eventually that times
out
|> and I am allowed to select the Install option.   However, when I get
to
|> the partitioning (btw, it's another issue, but the new set of
screens
|> to partition the drive really suck.  I've never been so confused by
a
|> FreeBSD install.   But I digress...)   I eventually selected "auto"
|> partitioning.  Then I am greeted with a pop up that informs me that
|> ada0 is not valid for some unmentioned reason.   (did I mention that
|> the new partitioning screens suck?).
|> 
|> At this point I give up, and I am now in the process of
re-installing
|> 9.0.
|> 
|> I'm not a long-time user of FreeBSD, I've only been using it since
|> 2005, with installs to keep it up to date through the varied and
sundry
|> versions.   But this is The First Time that a FreeBSD install has
|> failed.  
|> 
|> What's goin' on?  
|
|Probably there's corrupt raid metadata (or something that can be
|confused with raid metadata) on the disk(s).
|
|You could try booting with kern.geom.raid.enable set to 0 or
|without the module loaded. Sanitising the disk(s) should work
|as well.
|
|Fabian
 =


Thanks for the reply.   The disk in question has never been used for
RAID, so if there is RAID metadata on the disk, I do not know how it
got there.  The disk is (I believe --- it's been a while since I have
been inside that box) on a Promise SATA RAID controller, but RAID is
not used and has never been used (I have a 3Ware controller for RAID on
that box).

When things settle down, I'll try to figure out how to sanitize the
disk and try to install 9.1 again.

Thanks again for your quick reply.

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"


Re: 9.1 won't install - GEOM/GRAID issues

2013-01-02 Thread Fabian Keil
"Mike."  wrote:

> My FreeBSD server had been running fine, no issues.   This evening I
> tried to update it to 9.1.  I don't "update in place", I update by
> wiping the prior version and letting the new version have its way with
> the disk.
> 
> Well, 9.1 has issues with my system (dmesg is at the end of this
> message).
> 
> When I boot from the install DVD, I see a lot of messages along the
> lines of ~Root mount waiting for GRAID~, then eventually that times out
> and I am allowed to select the Install option.   However, when I get to
> the partitioning (btw, it's another issue, but the new set of screens
> to partition the drive really suck.  I've never been so confused by a
> FreeBSD install.   But I digress...)   I eventually selected "auto"
> partitioning.  Then I am greeted with a pop up that informs me that
> ada0 is not valid for some unmentioned reason.   (did I mention that
> the new partitioning screens suck?).
> 
> At this point I give up, and I am now in the process of re-installing
> 9.0.
> 
> I'm not a long-time user of FreeBSD, I've only been using it since
> 2005, with installs to keep it up to date through the varied and sundry
> versions.   But this is The First Time that a FreeBSD install has
> failed.  
> 
> What's goin' on?  

Probably there's corrupt raid metadata (or something that can be
confused with raid metadata) on the disk(s).

You could try booting with kern.geom.raid.enable set to 0 or
without the module loaded. Sanitising the disk(s) should work
as well.

Fabian


signature.asc
Description: PGP signature