Root mount waiting for: CAM
-
Thanks will try that later, could it be that
kern.cam.boot_delayis 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...
-
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: CAMforever?I agree, that's.... an inconvenient way to reboot.
Steve
-
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: CAMYes 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_delayfrom /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=1in the loader prompt and sethw.clflush_disable=1, with no luck. -
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
-
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_delayin loader.conf.local?Thank you for your support.
-
@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
-
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_pfbe a issue here? -
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.
-
Just an idea, I had added
hw.bce.tso_enable=0 hw.pci.enable_msix=0to /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: 1and digging a little deeper, I've read at reddit. FreeBSD Mailinglist and the "other" sense forum that setting:
set hw.pci.enable_msix=0can make the system fail to boot.
Could this be the root cause for
Root mount waiting for: CAMloop? -
set hw.pci.enable_msix=0BINGO! 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.)
-
Mmm, disabling MSIX globally for all PCI devices should really be a last resort option anyway.
