Bug 243576 - sysutils/vm-bhyve: module vmm.ko not loading in FreeBSD 13 on AMD64
Summary: sysutils/vm-bhyve: module vmm.ko not loading in FreeBSD 13 on AMD64
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2020-01-24 23:50 UTC by gdinolt
Modified: 2023-11-20 10:53 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (churchers)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gdinolt 2020-01-24 23:50:37 UTC
The VM command fails with error:

/usr/local/sbin/vm: ERROR: unable to load vmm.ko!

The error occurs because (at least in FreeBSD 13)

kldstat -qm vmm.ko

returns a value of 1, even if vmm.ko is already loaded.

The error is in /usr/local/lib/vm-bhyve/vm-util

-- vm-util	2020-01-24 15:43:46.495030000 -0800
+++ vm-util-new	2020-01-24 15:44:07.662656000 -0800
@@ -46,7 +46,7 @@
 #
 util::load_module(){
     local _mod="$1"
-    kldstat -qm ${_mod} >/dev/null 2>&1
+    kldstat -qn ${_mod} >/dev/null 2>&1
     if [ $? -ne 0 ]; then
         kldload ${_mod} >/dev/null 2>&1
         [ $? -eq 0 ] || util::err "unable to load ${_mod}.ko!"

I replaced the -qm with -qn, which seems to work at least as far as getting vm to start.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-25 03:43:25 UTC
Thank you for the report and patch. Could you include your proposed patch as an attachment please
Comment 2 Greg 2023-07-24 14:54:39 UTC
I recently upgraded from 13.1 to 13.2-RELEASE. I was using bhyve without issue prior to the upgrade. Since finishing the upgrade to 13.2-RELEASE, I have been unable to run VMs.

The error is as noted in the original bug report:

/usr/local/sbin/vm: ERROR: unable to load vmm.ko!


I have checked my copy of /usr/local/lib/vm-bhyve/vm-util and it is using the -qm flag as noted below, not the -qn flag. Changing the relevant line to use -qn resolves the issue.
Comment 3 Dries Michiels freebsd_committer freebsd_triage 2023-07-28 11:18:49 UTC
What doees "kldstat -qm vmm" return? Probably not 1, its called as such in vm-bhyve not "kldstat -qm vmm.ko". I'm running 13.2 stable and I do not observe this issue at all.
Comment 4 Dries Michiels freebsd_committer freebsd_triage 2023-07-28 11:20:44 UTC
https://github.com/churchers/vm-bhyve/blob/master/lib/vm-util

See line 79, where the function is called with "vmm" not "vmm.ko".
Comment 5 Greg 2023-07-28 22:48:18 UTC
The machine that was exhibiting this behavior is sadly no more. The motherboard turned out to be on the fritz and had to be replaced.

I did not have a chance to do much troubleshooting beyond identifying the mobo as at issue. (One RAM rendered the system unbootable if populated; half the onboard USB simply disappeared after several hardware swaps as par of diagnosis, and some other gremlinish behavor). I chalk my issues up to the failing hardware.

Nonetheless, with new hardware the -qn version remains functional. I've reverted back to -qm as that also works.

To answer the specific question, of the binary combinations between '-n'/'-m' and 'vmm'/'vmm.ko', only '-m vmm.ko' fails, as expected.

$ kldstat -n vmm
Id Refs Address                Size Name
 4    1 0xffffffff82167000   579de0 vmm.ko
$ kldstat -n vmm.ko
Id Refs Address                Size Name
 4    1 0xffffffff82167000   579de0 vmm.ko
$ kldstat -m vmm
Id  Refs Name
  3    1 vmm
$ kldstat -m vmm.ko
kldstat: can't find module vmm.ko: No such file or directory
Comment 6 Dries Michiels freebsd_committer freebsd_triage 2023-11-20 10:53:04 UTC
gdinolt@pacbell.net is this still relevant?