I was recently affected by an incident during upgrading my main 14-STABLE machine that looked initially very much like some sort of regression but turned out to be a pretty simple root cause. Since ZFS support needs a separate kernel module even the default GENERIC kernel cannot handle root on ZFS without access to such. In my case a faulty "make installkernel" (lack of certain kmods inc. zfs.ko) caused the machine boot to fail at root mounting. Failure to load modules listed in loader.conf hid the actual root cause for a long time, as boot posted errors vanish too quickly, turning operator attention towards other theories. Currently on fast modern systems errors posted by loader on boot are gone quickly. It would be helpful if loader stopped for a second, when it cannot locate a module configured in loader.conf to let operator acknowledge the problem. I see if mostly as a usability issue.
Hello, have you tried the kern.vt.slow_down sysctl?
(In reply to Alexander Ziaee from comment #1) Thank you for the suggestion, I was not aware of it. There would be caveats to using it though. 1. at this point it is only on CURRENT. 2. even if it were on 14-STABLE and I was aware, I would be unable to set this, since the system was unbootable. I am sure it is a great measure to facilitate porting efforts from which it stemmed from, I believe. Perhaps it would be worth to auto enable it if some keyboard control is down during boot? For that matter, I have fixed the problem myself by dissecting and understanding the 2 problems I observed, unbootable ZFS root and ENOENT when trying to mount the affected zroot from a system booted with a laptop disk (NB, laptop boot setup had also been affect by the same broken kernel, but the laptop OS was unaffected as thankfully it is UFS based, yet it was unable to hook desktop zroot exiting with ENOENT). A lesson learned is perhaps to record a boot environment before doing installworld/installkernel.