Bug 240178

Summary: sysutils/vm-bhyve: No longer works with tmux on FreeBSD CURRENT
Product: Ports & Packages Reporter: Sean Eric Fagan <sef>
Component: Individual Port(s)Assignee: freebsd-ports-bugs mailing list <ports-bugs>
Status: Open ---    
Severity: Affects Some People CC: cgull+l-freebsd-bugzilla, churchers, ebay, meta, olgeni, pi, razzfazz, vas
Priority: --- Keywords: needs-qa, regression
Version: LatestFlags: churchers: maintainer-feedback+
Hardware: Any   
OS: Any   

Description Sean Eric Fagan freebsd_committer 2019-08-28 18:31:26 UTC
On FreeBSD-HEAD, with vm-bhyve-1.3.0 and tmux-2.9a_1, when running FreeBSD itself under bhyve, tmux no longer works as the console.  As soon as the bootloader finishes, and the kernel loads, tmux stops updating.  The VM is still running, but I have no way of connecting to it.  Looking at fstat, it looks like the bhyve process still has the right ctty that tmux is using, but... no updates.

FreeBSD-12 works still.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-29 10:05:12 UTC
@Sean Using category/portname: in Bugzilla issue titles/summaries will ensure that MAINTAINERS are assigned (if they're committers) and/or notified (if they're not) automatically.
Comment 2 Sean Eric Fagan freebsd_committer 2019-10-04 20:10:31 UTC
Does anyone have any idea what's going on here?  I can't get a graphic console to work, so this is a major frustration in my life right now.
Comment 3 Sean Eric Fagan freebsd_committer 2019-10-04 20:33:41 UTC
(It's now happening with 12.1 as well.  That is, 12.1 as both the host and guest; tmux-2.9a_1 and vm-bhyve-1.3.0)
Comment 4 Sean Eric Fagan freebsd_committer 2019-10-05 17:55:52 UTC
Well.  Just doing "vm _run -tf ${VMNAME}" hangs in the same way, no tmux needed.  Run bhyveload manually, and then "tmux bhyve ...." works.
Comment 5 Sean Eric Fagan freebsd_committer 2019-10-05 20:26:23 UTC
And if I put this in a file:
bhyveload -m 4G -e autoboot_delay=3 -d /tank/VMs/FreeBSD-HEAD/disk0.img FreeBSD-HEAD
bhyve -c 1 -m 4G -AHP -g 33333 -U d3ab47db-44ca-11e8-a8cb-d05099c3569a -u -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/tank/VMs/FreeBSD-HEAD/disk0.img -s 4:1,virtio-blk,/tank/VMs/FreeBSD-HEAD/disk1.img -s 4:2,virtio-blk,/tank/VMs/FreeBSD-HEAD/disk2.img -s 5:0,virtio-net,tap0,mac=58:9c:fc:02:96:c1 -l com1,stdio FreeBSD-HEAD
bhyvectl --destroy --vm=FreeBSD-HEAD

and then do "tmux new -s sh /tmp/test.sh", that works.  (No networking, because I didn't bother setting that up, but it does work.)

So "vm start FreeBSD-HEAD" doesn't work, but running those commands does.
Comment 6 Sean Eric Fagan freebsd_committer 2019-10-05 22:26:48 UTC
Right.  So this is the problem:

        # actually run bhyve!                                                   
        # we're already in the background so we just wait for it to exit        
        bhyve ${_opts} \
              ${_devices} \
              ${_iso_dev} \
              ${_comstring} \
              ${_name} >>"${_logpath}" 2>&1

When using a non-graphical console, and tmux, _comstring is "-l com1,stdio".

But stdout and stderr have been redirected to _logpath.  This has no chance of working as intended.
Comment 7 Daniel Becker 2019-11-07 18:08:31 UTC
Upstream bug report on this issue:

Comment 8 Adam McDougall 2019-11-23 17:01:17 UTC
I think this is the cause? https://svnweb.freebsd.org/changeset/base/352720
Comment 9 John Hood 2019-11-29 03:22:16 UTC
I opened the vm-bhyve bug, and I've now opened a pull request with the very simple bugfix: https://github.com/churchers/vm-bhyve/pull/337

I've not tested the bugfix on a wide variety of bhyve versions, though.
Comment 10 churchers 2020-01-14 16:38:22 UTC
Sorry for the delay on attending to this.

This should be fixed in vm-bhyve-1.4.2 which is waiting to be committed to the ports tree.
Comment 11 Koichiro Iwao freebsd_committer 2020-01-29 03:06:43 UTC
*** Bug 243079 has been marked as a duplicate of this bug. ***
Comment 12 Koichiro Iwao freebsd_committer 2020-01-29 03:08:26 UTC
I committed r524530 in bug 243198.