Bug 240178 - sysutils/vm-bhyve: No longer works with tmux on FreeBSD CURRENT
Summary: sysutils/vm-bhyve: No longer works with tmux on FreeBSD CURRENT
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2019-08-28 18:31 UTC by Sean Eric Fagan
Modified: 2019-11-29 03:22 UTC (History)
6 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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:

https://github.com/churchers/vm-bhyve/issues/332
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.