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