VBoxLinuxAdditions 5.0.30 kill host's touchpad when Linux guest crashes

[rsktuxedo]

I updated my install today to 5.0.30, and updated the guests' tools. On my RHEL 7 guest, I messed some things up due to /boot space issues, and dracut couldn't rebuild the initramfs files. I thought I'd gotten it cleaned up properly, but apparently not, as the guest crashed early in boot-up.

I then noticed that my touchpad wasn't working (no mouse pointer movement, and clicks were ignored). Oddly, when I did Windows-L to lock up, the touchpad was working again, but it failed as soon as I unlocked.

This seems like a "leak" in the sandboxing of the guest, as the tools shouldn't be able to cause problems on the host, should they? What logs do I need to supply for investigating this?

Thanks, Rick

[socratis]

This seems like a "leak" in the sandboxing of the guest, as the tools shouldn't be able to cause problems on the host, should they?

No they shouldn't and this is the first I've heard of it. There is no "leak" nor "sandboxing" as you refer to it, because your guest does not see the hardware on the host, so it can't affect it. Something else is affecting its behavior. Actually did it happen more than once? Is there a trackpad driver loaded? An add-on? Maybe that got somehow involved?

[rsktuxedo]

It's 100% repeatable. There is a touchpad driver that handles both the touchpad and trackpoint.

Since the original post, I've found that I can regain use of the touchpad, at least most of the time, by pressing CAD (at which point the pointer can be moved), and then clicking Cancel. I don't recall this working the first couple times this problem manifested. Admittedly this is rather bizarre behavior...

[rsktuxedo]

I have booted the rescue kernel, and have rebuilt the faulty initramfs files. The guest now boots successfully with the VBoxAdditions loaded.

I saved the bad initramfs images, though, in case there's anything you want for debugging.