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]
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 …
> A screen recording of 13.0-RC3 not responding to keyboard input:
> 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
Created attachment 223658 [details]
An export of a bugged appliance. OVF version: 2.0.
For me, the bug was easily reproducible with
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
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
11. reboot in normal mode
12. observe automated growth of the UFS filesystem
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.
> … Please, can anyone tell whether the bug is reproducible with a RELEASE or release candidate of FreeBSD as the host? …
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