8.3-BETA1 installation problem

[Michael Powell]

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