Solved MPX3132 SATA controller (mountroot failed)

I just installed FreeBSD 10 on a system with an internal harddisk which I believe identifies as ada0. After the installation was successful and the system rebooted successfully I added another harddisk by using a MPX3132 SATA controller. The controller was already in the system during the installation of FreeBSD but no disks were attached. When the second disk is attached to the first SATA port on the controller, the system does no longer boot and I get a mountroot failed error. When I unplug the second disk again, the system boots fine. I'm new to FreeBSD and think that maybe the fact that the second disk is disk1 on its controller has something to do with it, but I'm not sure.
Anyone has an idea about what's going on here?
 
This should be just a boot order or controller initialization problem, that probably can be fixed in the bios.
The bios thinks the MPX3132 SATA Port is disk0 (ada0), can not boot from it and try booting disk1 (ada1),
where the bootloader want to mount ada0 which is empty, i guess.
 
Thank you for your response User23. I have changed the boot order in the BIOS but this does not seem to help. At the mountroot prompt I typed "?" to get a list of disks and in that list it appears that the disk with FreeBSD installed on it (OCZ) now has partitions called ada1p3 ada1p2 ada1p1 whereas the second disk (Western Digital) has only ada0
I strongly believe the OCZ should be ada0.
Any idea?

WP_20160818_17_48_43_Pro.jpg



WP_20160818_17_40_48_Pro.jpg



Don't know how to make a screenshot in FreeBSD so I went for the phone camera. hahaha
 
The order changed because you added a disk. This has nothing to do with the boot order in the BIOS as the machine correctly boots, it's just stuck at the bootloader stage.

Use ufs:/dev/diskid/DISK-OCZ-MYPQ3FJ79XVPDVFGp2 to boot it. Using the diskid should ensure it keeps booting, even if the disks more around. You may still need to adjust /etc/fstab if it contains references to ada0. The best way is to use the labels instead of specific disks.
 
The suggestion to change the content of /etc/fstab was the key to the solution of this problem. I changed it as per your suggestion and now it boots fine. I still find it odd that the order would change when adding a disk (the first disk never moved), this seems a recipe for strange situation like this. Thanks both for your help!
 
It's based on the order disks are detected. Using labels means it's not a problem, and you can even move disks to a different kind of controller like an external USB enclosure.
 
Back
Top