Virtualbox 5.2.6 on 18.03. I’ve excluded other possible causes.
A guest does NOT need to be running, though a guest seems to possibly change the failure mode.
Without a guest, resume gave console output mentioning io errors during zfs pool access; shortly after dropping to debug, it reboots. With a guest, it mentions (iirc different) io errors, drops to db and [input] keystrokes and a minority of character outputs seem to be doubled.
The attached is from wake with virtualbox running but no guest.
Wireless was deactivated, and I did
before running virtualbox in all cases.
[Edit:] Looking at the picture I realized I should add that I had /dev/mdX devices configured and attached to by virtualbox and the picture is cut off; later learned to read guid’s with “zdb tank|more” to cofirm that’s my (encrypted) root partition and not a loopdevice.
In virtualbox guests in fullscreen but not windowed display, keyboard input is largely lost. “Largely” because even though everything including the host-key doesn’t do anything, ctrl-alt-F? does switch to consoles (and the keyboard works fine there). Also “largely” because the keyboard did start working at one point in a linux-4.16 guest in fullscreen after not working, but was lost on return to fullscreen.
Of course, this is an issue unto itself. (Note that the same machine with EL7 as the host-OS had none of these problems…)
It was possible to suspend & resume with virtualbox running both without & with a guest running.
I think it would be reasonable for the virtualbox install to at least add users who are sudoers to these groups since there’s no loss of security…they could do that themselves…[unless anyone can think of attack vectors/surface this would create…]
BUT: the although the guest could get keyboard input back (or at least hostkey), I couldn’t find any way to get mouse (tablet) input working after resume (hence only can say for hostkey, although once I found the trick in my other thread I noticed that hostkey function came and went with other keyboard input to the guest). [I did check the recent thread on mouse integration; that pertains to TrueOS as a guest on an unspecified host; this was with a linux guest…]
[Edit:] May have spoken too soon, again: unexplained reboot while post-resume, non-working mouse input, linux guest was running. Investgating…
[Edit:] Worse still with a different guest [linux-4.16] running: resumed but even though guest was in the background an (by definition) keyboard/mouse were not captured at suspend, keyboard and mouse totally unresponsive, iirc after screensaver accepted a password.
Also: even though I set vm_enable=“NO” in rc.conf, it gets set to “YES” by something. From logs I surmise this is rerun on resume; if so, kldload vmm would conflict with vboxdrv. On investigation I found vm was enabled in rc-update (presumably from using bhyve/vm-bhyve/iohyve/aquemu), so deleted that and iohyve. On the next reboot it did not get set. Now, with the linux-4.16 guest running, resume from suspend flashes the screensaver but (faster than ever yet) yields a reboot.
[Edit] And with a different linux guest running it resumes to the screensaver and takes no io at all, remaining unresponsive. I daresay the last “proper” rc-update changes made matters worse.
[Edit:] Experimentation shows that wpa_supplicant is getting reenabled on resume despite
rc-update delete wpa_supplicant
…rc-status lists it as started manually after each resume–WHY?; it seems to not be causing problems with resume by now but I want to eliminate this variable.
[thought I posted this a couple of days ago but it was hiding in a browser tab; since then I started the ZFS breaking resume thread. Posting this because it contains a couple of changes that seem pertinent…over a few tries, the machine hasn’t hung while trying to suspend.]
So it appears that something different is broken. Without earlier identified/hypothesized factors, my system now hangs either before suspend completes (indicator lights on) or panics on resume due to ZFS timing out. It seems worse now & I suspect that the various things I’ve disabled along the way were delaying suspend/resume long enough for something in ZFS to complete.
I’ve increased hw.acpi.sleep_delay 1 -> 8, though it’s only a guess that this falls after any zfs suspend activity starts (tested once, suspend-resume worked though little was running at the time) and set vfs.zfs.deadman_checktime 5000 -> 10000 in /boot/loader.conf. On reboot, there were still the early zfs load failed messages I sort-of hoped this would remedy.