Created attachment 223470 [details] Screenshot, shortly after attempting ACPI shutdown FreeBSD 14.0-CURRENT host with virtualbox-ose 6.1.18. FreeBSD 13.0-RC3 guest with virtualbox-ose-additions 6.1.18. Other guests are similarly affected, I'm not yet sure of the scope. If the guest runs (is not stopped) at the time of a snapshot, then after starting from the snapshot: * there's no visible response to keyboard input * in response to input from a Kensington Orbit Trackball, the on-screen pointer moves as expected, window decorations and other aspects appear OK (twm) * if I'm lucky, Control-F2 will switch to a tty however there's blackness, no text, no visible response to keyboard input and Control-F9 might not switch back to the window manager * ACPI shutdown does not shutdown the machine, the screen shrinks and there remains blackness with a rapidly blinking underline cursor at top left.
Created attachment 223471 [details] Log Around seventeen minutes after attempting ACPI shutdown, I closed the window to the guest and chose to not save.
Not reproducible with a Windows 10 guest that was running when I saved its state on 2021-03-09.
Tentatively changing this to a FreBSD base system bug …
From <https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079272.html>: > A screen recording of 13.0-RC3 not responding to keyboard input: > > <https://photos.app.goo.gl/zbmcL7B7k5v1UR1x8> > > At 01:40 on the timeline, keyboard input > (visible with x11/screenkey in the host) has > no effect on the FreeBSD guest. … (When I posted to the list, I forgot that this bug report existed. Sorry. Attempting to refine the bug, on my own, has been quite mind-bending.) > … To anyone who's interested: find me in Matrix or IRC for #freebsd > and I'll let you have a copy of the file below, which can be used with > FreeBSD-13.0-RC3-amd64.vhd.xz > > FreeBSD-13.0-RC3-amd64.vhd.ova > > Thanks
Created attachment 223658 [details] An export of a bugged appliance. OVF version: 2.0. For me, the bug was easily reproducible with FreeBSD-13.0-RC3-amd64.vhd.xz from: <https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC3/amd64/Latest/> From what I recall, these steps should make the bug reproducible: 01. FreeBSD 14.0-CURRENT host 02. import the appliance 03. extract FreeBSD-13.0-RC3-amd64.vhd from FreeBSD-13.0-RC3-amd64.vhd.xz 04. attach the .vhd to the virtual machine 05. increase the capacity of the virtual hard disk to 32 GB 06. boot the VM in single user mode 07. <https://docs-dev.freebsd.org/en/books/handbook/disks/#disks-growing> 08. _ignore_ FreeBSD Handbook directions to disable the swap partition and delete the third partition (FreeBSD no longer defaults to this layout) 09. resize the _fourth_ partition, maybe gpart resize -i 4 -s 27G -a 4k ada0 10. _ignore_ the Handbook direction to use growfs (it does not work in this context) 11. reboot in normal mode 12. observe automated growth of the UFS filesystem 13. Control-F2 14. login as root, no password 15. save the state of the running VM 16. ACPI shutdown 17. save the state of the stopped VM 18. start the saved state of the stopped VM 19. df -h 20. close, and restore the state from which you started 21. restore then start from the saved state of the running VM 22. key 'df -h' (or anything) – no response to keyboard input 23. ACPI shutdown – the VM does not stop.
If this is a base system bug, it'll need a change of assignee; I can't make the change (sorry).
(In reply to Graham Perrin from comment #5) A few hours ago in IRC, someone kindly tested with: * Windows 7 in lieu of FreeBSD-CURRENT as the host at step (01) * their own guest appliance in lieu of the import at step (02). I paraphrased an outcome: >> … Do I understand correctly, that you could not (secondarily) >> save a snapshot of a stopped FreeBSD guest after (firstly) >> saving a snapshot of its running state? > correct, with an ACPI shutdown in between.
> … do not work, if started from a snapshot that was > saved whilst the working FreeBSD guest ran Not reproducible with FreeBSD-13.0-RC5-amd64.vhd in VirtualBox 6.1.18 on a Windows 10 host. Reproducible with FreeBSD-13.0-RC5-amd64.vhd in VirtualBox 6.1.18 on FreeBSD 14.0-CURRENT.
From <https://forums.freebsd.org/threads/254458-freebsd-with-virtualbox-on-freebsd-saved-states-of-running-machines-are-unusable.79668/>: > … Please, can anyone tell whether the bug is reproducible with a RELEASE or release candidate of FreeBSD as the host? …
Hello, i cannot reproduce this problem with FreeBSD 13 RC 5 amd64 as host. Tested using an empty VHD and installed with the FreeBSD-13.0-RC5-amd64-disc1.iso.
(In reply to Alexander Vereeken from comment #10) Thanks; and (confirmed in chat) that was with VirtualBox 6.1.18 as the host
This sounds similar to a PR for desktop-installer from a user who figured out that guest additions have a problem with members of the wheel group: https://github.com/outpaddling/desktop-installer/issues/8 In short, if a user in the FreeBSD guest is a member of wheel and vbox-guest* are enabled, the FreeBSD desktop environment is unresponsive. Confirmed for XFCE and Lumina. Removing the user from wheel or disabling vbox guest via /etc/rc.conf alleviates the problem.
In nearly all affected cases: * the guest seems to be _completely_ non-responsive to mouse and keyboard input after starting from the saved state. ---- <https://photos.app.goo.gl/rLTF4nrueco8wTGR7> is a rare example of a guest that _did_ briefly respond (soon after the start from the saved state) to Control-F1 or Control-F2 (equivalent to Control-Alt-F1 or Control-Alt-F2 with real hardware): * I got a TTY, but then * no further response to Control-F1, Control-F2 or Control-F9 * ACPI shutdown failed. Guest: * clean installation of GhostBSD * based on FreeBSD 13.0-STABLE * guest additions 6.1.18 integral to the installation * recently released GhostBSD-21.04.27.iso from <https://www.ghostbsd.org/download>. Host: % pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod emulators/virtualbox-ose 6.1.20 FreeBSD emulators/virtualbox-ose-kmod 6.1.20 FreeBSD % uname -v FreeBSD 14.0-CURRENT #93 main-n246330-5eb9c93a20d: Tue Apr 27 05:14:26 BST 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG % ---- To Guido Falsi: my apologies, this bug report is somewhat messy. The 'kern' assumption was misguided, and so on. If, for a moment, we _ignore_ the long steps to reproduce at comment 5 … … is there enough for this to be recognisably an (emulators/virtualbox-ose) issue with VirtualBox 6.⋯ on some FreeBSD hosts? ---- I have no comparable problem with a FreeBSD 13.0-RELEASE guest on a Windows 10 20H2 host. I can not recall anything like this bug with 5.2.44_4 as the host on -CURRENT. I'm now installing emulators/virtualbox-ose 6.1.20 and emulators/virtualbox-ose-kmod 6.1.20 on a FreeBSD 13.0-RELEASE host, to tell whether the bug is reproducible (for me) without 14.0-CURRENT.
I don't know how much I can help with this issue. For the record I'm using FreeBSD 14 as host, with various guests, one of which if FreeBSD 13.0 release. In it my user is member of the wheel group and I'm using XFCE with no problems. In that guest at present I have additions 6.1.20 or 6.1.18 (I use it on two different hosts) and don't see nay of the described issue. Having just tested the update the host virtualbox is 6.1.22. During testing I also installed additions 6.1.22 in a FreeBSD VM. I have never used saved states though. One thing to note is that using mismatched additions is not really supported by the upstream. It works 99% of the time, but could cause issues. Apart from this I'm sorry I really have no clue what is going on here.
(In reply comment #13) > I'm now installing emulators/virtualbox-ose 6.1.20 and > emulators/virtualbox-ose-kmod 6.1.20 on a FreeBSD 13.0-RELEASE host, > to tell whether the bug is reproducible (for me) without 14.0-CURRENT. As things turned out, that machine was unsuitable for testing. Centrino, around thirteen years old.
(In reply to Guido Falsi from comment #14) > I have never used saved states though. Like, you always shut down the guest before closing its window?
(In reply to Graham Perrin from comment #16) > Like, you always shut down the guest before closing its window? I use snapshots. I keep a clean state snapshot and just revert to it every time I close the machine. When I install updates or do some configuration I want to keep I remove the snapshot, shutdown cleanly and create a new clean state. BTW with one exception (guess which!) OSes nowadays are fast at shutting down most of the time.
Finally, the bug seems to be consistently: * not reproducible with audio input disabled * reproducible with audio input enabled. Tested, with four new machines, .vhd files extracted from FreeBSD-provided archives: FreeBSD-11.4-RELEASE-amd64.vhd.xz FreeBSD-12.1-RELEASE-amd64.vhd.xz FreeBSD-12.2-RELEASE-amd64.vhd.xz FreeBSD-13.0-RELEASE-amd64.vhd.xz Host ==== % uname -v FreeBSD 14.0-CURRENT #95 main-n246689-91f251b2ab3: Sat May 15 12:34:23 BST 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG % pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod emulators/virtualbox-ose 6.1.22 FreeBSD emulators/virtualbox-ose-kmod 6.1.22 FreeBSD % ---- To anyone with a host running 12.2-RELEASE-p6 or 13.0-RELEASE: * can you reproduce the bug with any FreeBSD or FreeBSD-based guest? 1. Gracefully shut down the guest 2. enable audio input 3. start the guest 4. close the window 5. save the machine state 6. start the guest 7. attempt keyboard input, or an ACPI shutdown …
CFT <https://old.reddit.com/r/freebsd/comments/ntki7u/-/> * to determine whether my findings, with audio input, can be reproduced in a FreeBSD guest with any FreeBSD host _other_ than 14.0-CURRENT …
From <https://www.virtualbox.org/wiki/Changelog-6.1#v24>: > Audio: Multiple fixes and enhancements I wonder …
(In reply to Graham Perrin from comment #20) BTW I submitted the patch I'm testing for the upgrade here: https://reviews.freebsd.org/D31264 I can't commit it at present to the tree because there is a significant regression with pulseaudio support.
Updated to 6.1.26 on the host: virtualbox-ose virtualbox-ose-kmod Not yet updated to the corresponding version in any guest: virtualbox-ose-additions ---- % pkg info -x virtualbox virtualbox-ose-6.1.26 virtualbox-ose-kmod-6.1.26 % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #105 main-n248685-c9f833abf1d: Fri Aug 13 20:24:43 BST 2021 root@mowa219-gjp4-zbook-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400030 1400030 % ---- So far, I can no longer reproduce symptoms of this bug with any FreeBSD or GhostBSD guest. Let's assume that it was either: a) fixed by <https://cgit.freebsd.org/ports/commit/?id=416b34d584e26823e403618b02419dbad40e50eb>, which included audio-related changes; or b) overcome by events. (Around six weeks ago, I set autospawn = no in /usr/local/etc/pulse/client.conf – <https://forums.FreeBSD.org/threads/80412/post-519408> … and so on.) ---- If symptoms recur, I should open a new bug (not reopen this; it was messy).