FreeBSD-current, GENERIC kernel using vt(4) reports on boot: > module_register_init: MOD_LOAD (vesa, 0xffffffff80dc3400, 0) error 1 And a panic if vesa is loaded from the loader: > OK load vesa > /boot/kernel/vesa.ko size 0xb2a8 at 0x1bf2000 ... panic: module_register_init: module named vesa not found cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff81c04ad0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffffff81c04b80 vpanic() at vpanic+0x189/frame 0xffffffff81c04c00 panic() at panic+0x43/frame 0xffffffff81c04c60 module_register_init() at module_register_init+0x22d/frame 0xffffffff81c04c90 mi_startup() at mi_startup+0x108/frame 0xffffffff81c04cb0 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why
Cut and paste issue, the errno was wrong -- it should be: > module_register_init: MOD_LOAD (vesa, 0xffffffff80dc3400, 0) error 19 vesa failing to attach if sc(4) is not available is not too surprising, although we ought to have a better user-facing way to handle it. The panic looks like a module infrastructure issue that we should solve though.
See https://reviews.freebsd.org/D3613.