FreeBSD 9.0 RC1 amd64 install problems

F

fatsailor

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
Code: 
ahci_enable="YES"
in loader.conf and without and the result is always the same.
 
The correct question is, what is in /boot/loader.conf?

You need:

Code: 
vfs.root.mountfrom="ufs:/dev/da0p2"
in it.
 
break19 said:
You need:

Code: 
vfs.root.mountfrom="ufs:/dev/da0p2"
in it.
Click to expand...

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:
Code: 
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?
 
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.
 
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.
Click to expand...

Thanks for the info about /boot.

The fstab is:

Code: 
/dev/da0p3   none    swap    sw     0    0
/dev/da0p2    /         ufs       rw     1     1
 
If the disk is actually an external USB drive, setting a longer timeout in /boot/loader.conf might help:
Code: 
kern.cam.boot_delay=10000
kern.cam.scsi_delay=10000
 
wblock@ said:
If the disk is actually an external USB drive, setting a longer timeout in /boot/loader.conf might help:

[/code]
Click to expand...

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 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.
Click to expand...

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 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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top