# FreeBSD 9.0 RC1 amd64 install problems



## fatsailor (Nov 11, 2011)

I keep getting thrown into mountroot with the error that ufs:/dev/ada0p2 can't be found. The correct partition is really ufs:/dev/da0p2. I can type that in and all is fine.

I've tried with 
	
	



```
ahci_enable="YES"
```
 in loader.conf and without and the result is always the same.


----------



## wblock@ (Nov 11, 2011)

What's in /etc/fstab?


----------



## break19 (Nov 12, 2011)

The correct question is, what is in /boot/loader.conf?

You need:


```
vfs.root.mountfrom="ufs:/dev/da0p2"
```
in it.


----------



## fatsailor (Nov 14, 2011)

break19 said:
			
		

> You need:
> 
> 
> ```
> ...



I've added that loader.conf and I get the same behavior. I'm still thrown into mountroot with it looking for ufs:/dev/ada0p2.

I've gone into the loader prompt, and lsdev lists the devices as:

```
disk0:
   disk0p1: FreeBSD Boot
   disk0p2: FreeBSD UFS
   disk0p3: FreeBSD swap
```
The loader_conf_files has /boot/loader.conf in the list as well as hints and local. Local is empty and hints doesn't have anything unusual in it. vfs.root.mountfrom does NOT show up as a variable though. I've set vfs.root.mountfrom at the loader OK prompt, and the system boots fine.

loader.conf is correct (no typos) as suggested by the previous poster. 

I've tried to [cmd=]fsck -t ufs /dev/da0p1[/cmd] (where /boot resides) and I get sectors could not be read errors.....bad disk?


----------



## wblock@ (Nov 14, 2011)

A freebsd-boot partition does not have a filesystem.  It's where the binary bootcode is kept.  /boot is actually on the UFS partition with the rest of that filesystem.

Still waiting to see what's in /etc/fstab.  Why?  Because the loader tries to read it.


----------



## fatsailor (Nov 15, 2011)

wblock@ said:
			
		

> A freebsd-boot partition does not have a filesystem.  It's where the binary bootcode is kept.  /boot is actually on the UFS partition with the rest of that filesystem.
> 
> Still waiting to see what's in /etc/fstab.  Why?  Because the loader tries to read it.



Thanks for the info about /boot.

The fstab is:


```
/dev/da0p3   none    swap    sw     0    0
/dev/da0p2    /         ufs       rw     1     1
```


----------



## wblock@ (Nov 15, 2011)

If the disk is actually an external USB drive, setting a longer timeout in /boot/loader.conf might help:

```
kern.cam.boot_delay=10000
kern.cam.scsi_delay=10000
```


----------



## fatsailor (Nov 15, 2011)

wblock@ said:
			
		

> If the disk is actually an external USB drive, setting a longer timeout in /boot/loader.conf might help:
> 
> [/code]



The disk is a 15k 6Gbps SAS drive connected to a LSI 2008 controller. I originally configured the controller to do RAID 10, and then learned that RAID isn't supported yet on the mps controllers yet. I modified the controller back to no RAID and installed....problems ever since.


----------



## fatsailor (Nov 15, 2011)

fatsailor said:
			
		

> The disk is a 15k 6Gbps SAS drive connected to a LSI 2008 controller. I originally configured the controller to do RAID 10, and then learned that RAID isn't supported yet on the mps controllers yet. I modified the controller back to no RAID and installed....problems ever since.



OK - I figured out the problem. We've mixed SATA and SAS drives which can be done on the controller. However, it appears that the mpt driver doesn't support that mix yet (or has a bug).

I removed the SATA drives to reduce the clutter in a verbose boot in an attempt to diagnose. Once the SATA drives were removed, the system boots fine.

The moral of the story is don't mix SATA and SAS on the LSI 2008 yet.


----------



## fatsailor (Nov 15, 2011)

fatsailor said:
			
		

> OK - I figured out the problem. We've mixed SATA and SAS drives which can be done on the controller. However, it appears that the mpt driver doesn't support that mix yet (or has a bug).
> 
> I removed the SATA drives to reduce the clutter in a verbose boot in an attempt to diagnose. Once the SATA drives were removed, the system boots fine.
> 
> The moral of the story is don't mix SATA and SAS on the LSI 2008 yet.



Further debugging identified that the problem was the order in which the controller was assigning the drives. So the real moral is to use disk labels. Also, the controller driver is mps not mpt.


----------

