SOLVED TrueNAS Installer Won't Boot on Dell PowerEdge R310: "Root mount waiting for: CAM" Problem

[Pax Romana]

It's a Dell PowerEdge R310 in perfect operating condition, RAM has been thoroughly tested, the boot USB is a genuine quality Sandisk 32GB, and the system runs other systems just fine: UNRAID and Windows 10 Enterprise.

I get the blasted "Root mount waiting for: CAM" issue and the installer USB just loops over and over for at least 15 minutes, never timing out.

The RAM is Dell-issued ECC server RAM at 12 GB. The PERC card has been pulled and I'm running just off the integrated motherboard SATA ports to three 1 TB drives that work fine with UNRAID. The boot mode is BIOS and the drive mode set in BIOS is ATA (not RAID). All other fancy stuff in the BIOS has been disabled to keep the system simple for troubleshooting. The BIOS sees all the hard drives and the USB installation drive just fine. There are no other add-in cards in the MB slots.

The system as it is will boot and run an UNRAID system without issue with 3 btrfs data drives. Absolutely no problems. The system also boots the FreeBSD installer from the same USB on the same USB port without a hiccup. FreeBSD 13.0-Release will install to one of the blanked hard drives with ZFS on root and boot from that hard drive just fine. Windows 10 Enterprise also ran fine on the system for 73 days.

The problem is, I want the data integrity that ZFS provides without the creation and administration hassles of using OpenZFS on Unbuntu. UNRAID works fine using btrfs on the data drives but btrfs is not the preferred file system according to the UNRAID admins, and encrypted btrfs on UNRAID is just asking for trouble. That leaves TrueNAS. XigmaNAS and OMV aren't contenders. I don't trust ZFS on XigmaNAS, and OMV doesn't have ZFS.

So my question is, what's the problem with the "Root mount waiting for: CAM" that's seems to have been plaguing both FreeNAS and now TrueNAS for some time, according to my Google searches? If UNRAID, Windows 10, and FreeBSD 13 all run fine on the machine, well that suggests something got booger'd-up in TrueNAS.

I'm flashing a USB drive now to test if Ubuntu Server will install to an SSD on the R310 system and then if OpenZFS can pool the three hard drives without issues.

 

[Samuel Tai]

Try booting in UEFI mode. The bootloader now expects UEFI boot.

 

[Pax Romana]

I tried that last night, but will try it again, can't hurt to repeat the finding. Thanks.

 

[Pax Romana]

BIOS vs UEFI boot isn't the problem but I did manage to accidentally get the system to boot the installer. The problem only occurs when one specific spinning drive of three identical drives is in the last of four front drive bays. Weird. Two of the three Seagate drives have the same firmware, the troublemaker has a different firmware revision, but if I swap the oddball into a different drive bay, the problem doesn't manifest. If it was a failing drive, or the fault of the drive's firmware, it shouldn't matter which bay it is in, but the system only "CAM" boot-loops when the drive with firmware different than the other two is in the fourth bay. Geesh.

I haven't replicated and resolved the problem enough times to rule out a SATA connector problem. I will do that.


I'm going to blank all three data drives again with DBAN, run a factory re-certification diagnostic on the suspect drive, and go from there.


> Try booting in UEFI mode. The bootloader now expects UEFI boot.
The TrueNAS installer says for enterprise systems to use BIOS mode instead of UEFI boot. This could be a legacy statement from the FreeNAS days that just hasn't been changed yet. Is the best-practice recommendation to prefer UEFI for TrueNAS come from the developers? In other words, is it official?


At this point, the problem seems to be on my hardware platform, not TrueNAS, so consider this thread resolved, but I'll keep it open for a day or two and post what the final resolution to my problem was.

 

[Pax Romana]

After the data drives were zeroed again with DBAN there were no further problems. Am sure I wiped the drives prior to the trouble. Have no idea why wiping them again solved the problem.

There does not seem to be a connector issue. I fiddled around with the SATA connector on the troublesome bay enough to try to cause a failure.

Now booting the system under UEFI per Samuel Tai's recommendation.

If others pass this way on their way to getting an old PowerEdge server running again, be sure all the motherboard firmware is updated. Dell servers take several firmware updates. It's not just the BIOS like in a desktop, but multiple subsystems, even the redundant power supplies sometimes need a firmware update. It's not a trivial task like flashing a BIOS on a desktop.

 

[Pax Romana]

This thread can be marked "SOLVED" by a mod.