From owner-freebsd-questions@FreeBSD.ORG Fri Feb 24 11:35:02 2012 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 C4F3B1065674 for ; Fri, 24 Feb 2012 11:35:02 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 77FB88FC13 for ; Fri, 24 Feb 2012 11:35:02 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S0tQS-0003N3-KE for freebsd-questions@freebsd.org; Fri, 24 Feb 2012 12:35:00 +0100 Received: from pool-173-79-99-96.washdc.fios.verizon.net ([173.79.99.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 12:35:00 +0100 Received: from nightrecon by pool-173-79-99-96.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Feb 2012 12:35:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Date: Fri, 24 Feb 2012 06:34:35 -0500 Lines: 87 Message-ID: References: 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-99-96.washdc.fios.verizon.net Subject: Re: 8.3-BETA1 installation problem X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nightrecon@hotmail.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:35:02 -0000 Omer Faruk SEN wrote: [edited to relocate top post] [snip] >> >> If you need to clear the old MBR the "old way", use a LiveFS or Fixit >> shell and do this (as root): >> >> sysctl kern.geom.debugflags=16 and: >> >> dd if=/dev/zero of=/dev/adx oseek=1 bs=512 count=1 >> >> where x equals your drive number. This will zero out any old MBR. >> >> A time or two when I've seen this error this fixed it up and the install >> proceeds as normal. As Warren said before, don't use the "W", just Q and >> sysinstall will queue and issue all the commands at a later point. > Already done that but still habe the same issue. I can dd and sysctl but > after installing without using W at disk label screen still no luck. I > have also done > sysctl kern.geom.debugflags=16 on fixit and restarted installation but > still getting the same error. > I apologize over minor language difficulties, as I'm as guilty as anyone. But I do find the above slightly confusing, as I cannot tell for certain whether you have executed the commands correctly, or not. I can easily assume that you did and the problem indeed is somewhere else. The purpose of the sysctl command is to make it so that the subsequent dd can actually complete it's write to zero the MBR. If you were to examine this sector in a hex editor you would see all zeroes if the dd was successful. If it's anything other than all zeroes the write did not happen. If the write didn't happen then the problem would remain. Historically, I had this problem when I pulled an old backup disk off the shelf to swap into a box with a failed drive. The old disk still had the previous install of version 6.2 on it. I'm not certain exactly what changed, but some fuzzy glint of memory seems to make me think it was some kind of change in partition labeling between 6.2 and 7.x which rendered 7.x unable to properly read and modify the disk. Trying to install 7.x over the old 6.2 continually failed with exactly the same error as you describe until I booted from a LiveFS CD and did the above 2 commands. Another difference is that I have _not_ done this procedure in a FIXIT shell; I'm just assuming here that it would work the same way but could be wrong. There are several other things that jump out at me that I will include for ideas. A RAID controller sometimes will store it's metadata on the last sector of a disk. I doubt that this would cause a problem until or unless you were trying to use a GEOM class like gmirror which does the same thing and would clash. If so, you'd need to zero this sector as well. I doubt that this is the situation. You could also play around with BIOS controller configurations as well. For example, you would not want to be using Intel MatrixRAID. So "NO" to setting the controller to any kind of RAID setting in BIOS - and for an SSD you really want to select AHCI. The only other choice is Legacy support. I'm also a little apprehensive of installing to ad6 - you might try as an experiment unplugging any/all other drives you don't want to take chances with and plug up the SSD as ad0 to see if this changes anything. I have FBSD 9 installed in a VM for testing, and I believe it has switched to the new ATA_CAM layer as default now. I have also configured my 8.2 machines the same way so the drives are now ada0 instead of the old ad0 naming scheme. I do not know if this change has gone into the 8.3 Beta you are having trouble with. Examine your dmesg output and you can determine this. If your drive(s) are showing up as ada0 then possibly sysinstall doesn't know how to deal with this. I thought this was supposed to start with 9, and do not really know anything about 8.3 Beta. One thing I'd try is to see if installing 8.2 RELEASE would work. If it did, then the devs probably need some kind of PR filed so they will be aware. I won't see 8.3 until it becomes RELEASE, as I run production machines and I just am not interested in any potential upgrade until 8.3 achieves RELEASE status. But if attempting to install 8.2 RELEASE does the same thing it would circle me back to believing the crux of the problem is whatever was on the drive previously - and that needs to be successfully erased before your install will proceed. You should also reboot the box after doing these 2 commands, don't just try and continue on with sysinstall - reboot first. -Mike