Root mount waiting for: CAM

[fireodo]

Hi,

since update from 2.4.5 to 2.5.0 I get in the dmesg for 5 times this message:

Root mount waiting for: CAM

This was with my ancient SSD-Drive and is now under 2.5.1 with new HDD-Drive also.

Is this something I have to worry about or can I ignore it?

Thanks,
fireodo

[jimp]

It's safe. The OS is waiting for devices be detected and settle before attempting to boot the rest of the way. It was done before but didn't print a message.

It's needed for things like booting from USB or certain drive controllers to work properly.

[fireodo]

@jimp

Thats good to hear - thanks a lot!

Kind Regards,
fireodo

[Bismarck]

@jimp

Anyway to disable this, can’t boot anymore just looping of this message

[stephenw10]

You can try removing or commenting out the line kern.cam.boot_delay from /boot/loader.conf(.local)

However the line will not stop a system booting. If it isn't booting that's just a side effect and not the cause. Removing it will likely just make it fail to boot faster or fail with no output.

Steve

[Bismarck]

@stephenw10

Thanks will try that later, could it be that kern.cam.boot_delay is not present in the installer? Because every time this happens I can only do a fresh install and recover my config.xml and as long I do not reboot again all is fine. ** (which is a very awkward way to reboot)
**

I guess it has something to do with ILO and the virtual usb, maybe...

[stephenw10]

It's more likely to be required in the installer because waiting for the USB drive to become active is most of the reason it's there.

When you reboot does it eventually fail or just shows Root mount waiting for: CAM forever?

I agree, that's.... an inconvenient way to reboot.

Steve

[Bismarck]

@stephenw10

Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM 
Root mount waiting for: CAM

Yes it just loops for ever, the first time it was on the update from 2.5.0 to 2.5.1, if I remember right I waited 45 mins. It did not happened with 2.5.0 and prior.

So when I remove kern.cam.boot_delay from /boot/loader.conf, I guess with the next update it will be overwritten and when the update reboots at the end I'm in trouble again.

Things I've tried so far: hw.usb.no_boot_wait=1 in the loader prompt and set hw.clflush_disable=1, with no luck.

[stephenw10]

Hmm, you could try setting it to a different value in loader.conf.local which would not get overwritten. I'm not sure which has precedence there but I expect .local to.

What are you running that failing like that?

Steve

[Bismarck]

@stephenw10

Repurposed HP ProLiant DL360p Gen8 with Smart Array P420i raid controller

Disabling all related to USB or ILO in the Bios didn't make a difference, last time.

I must confess, since I've installed 2.5.0 I did only reroots and no real reboots, I guess it must be something with FreeBSD 12.2.

So booting from the Installer ISO or USB Image works just fine, booting the system afterwards does not.

What would be a "safe" value for kern.cam.boot_delay in loader.conf.local?

Thank you for your support.

[stephenw10]

@bismarck said in Root mount waiting for: CAM:

So booting from the Installer ISO or USB Image works just fine, booting the system afterwards does not.

Except the very first boot after the install though. Which is the weird thing. Might be useful to look at the boot/console log from that to see what is different.

You might also try booting verbose to see if it gives you more error output.

Since it seems to be waiting for something that never happens I would try setting kern.cam.boot_delay to 0. You can probably also set that at the loader prompt to test at boot.

Steve

[Bismarck]

@stephenw10

I will try to schedule a downtime for the next weekend and give it a try.

Comparing the loader.conf from 2.4.5 with 2.5.x

2.4.5

kern.cam.boot_delay=10000
autoboot_delay="3"
kern.ipc.nmbclusters="1000000"
kern.ipc.nmbjumbop="524288"
kern.ipc.nmbjumbo9="524288"
hw.usb.no_pf="1"
boot_serial="NO"

2.5.x

kern.cam.boot_delay=10000
autoboot_delay="3"
kern.ipc.nmbclusters="1000000"
kern.ipc.nmbjumbop="524288"
kern.ipc.nmbjumbo9="524288"
boot_serial="NO"

Could hw.usb.no_pf be a issue here?

[stephenw10]

Hard to imagine it would have any effect there unless some USB device is being incorrectly detected. Even then it wouldn't affect storage. Or I wouldn't expect it to.

[Bismarck]

@stephenw10

Just an idea, I had added

hw.bce.tso_enable=0
hw.pci.enable_msix=0

to /boot/loader.conf.local like mentioned in the pfSense docs for tuning etc.

Now looking at the default values via sysctl of the running system:

# sysctl hw.bce.tso_enable
hw.bce.tso_enable: 1
# sysctl hw.pci.enable_msix
hw.pci.enable_msix: 1

and digging a little deeper, I've read at reddit. FreeBSD Mailinglist and the "other" sense forum that setting:

set hw.pci.enable_msix=0

can make the system fail to boot.

Could this be the root cause for Root mount waiting for: CAM loop?

[Bismarck]

@stephenw10

set hw.pci.enable_msix=0

BINGO! We have a winner!

Just deleted /boot/loader.conf.local and leave /boot/loader.conf untouched, now system is booting smooth and nicely again.

Thank you for your patience, much appreciated!

(Maybe someone should ad a hint at the pfSense docs, using this setting "may" leave you with a unbootable system.)

[stephenw10]

Mmm, disabling MSIX globally for all PCI devices should really be a last resort option anyway.