8.3-BETA1 installation problem
Michael Powell
nightrecon at hotmail.com
Fri Feb 24 11:35:02 UTC 2012
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
More information about the freebsd-questions
mailing list