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 (Nobody) <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:	Latest	Flags:	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

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.

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.