[WorksForMe] Xubuntu VM on Win host fails to boot after every VB release

[mrzenwiz]

This is the third or fourth time in a row where a new VB release for Windows has come out and required several changes before I could boot my Xubuntu VM where I do 90% of my work.

The failure was something like VBox Hardening error (which has been documented as a knee-jerk response to scare media - how sad is that?).

I upgraded to VB 5.2.20, installed the extension pack, restarted VB, and my Xubuntu 18.04 VM failed to boot. I rebooted Windows (as suggested by the error notice) and that did not help. I rebooted a second time, still no help.

After googling around for about five minutes, I finally found an article that said I had to execute (install) the VBoxDrv.Inf file, which I have never even had to look at before, then restart Windows again. Finally, my VM booted up.

This issue (of it not rebooting after upgrading VB and rebooting, last time it was 2x, this time 4x) is extremely disruptive to a smooth work environment and, although I have seen this so many times on Windows boxes I lost count years ago, it is pathetic. I NEVER have this problem with VB on Linux running my Windows 7 VM at home. Never.

There is no excuse for why changes like these aren't automated in the upgrade process. The change logs should clearly identify needs for this type of modification before a new upgrade will run the existing VMs. Users should never have to be concerned about this kind of change, and it is one of the biggest reasons why these products are only used by those of us who actually work in computers. That is a good way to restrict your user base, but it also offends the base.

I realize this is part of the whole Windows crap environment, and I really appreciate being able to use VB to escape from being stuck with said Windows garbage. However, this kind of annoyance with every single upgrade almost makes me want to go back to VMware.

Yes, it's free software. That is absolutely no excuse for crappy quality.

[socratis]

Yes, it's free software. That is absolutely no excuse for crappy quality.

Or crappy reporting/ranting/misunderstanding of the fundamentals of the problem (Hint: it's the MS installer engine).

And since you're in the less than 0.1% of the users that face an issue with this, I strongly suspect that it's your host that's botched and not VirtualBox, because at this point, VirtualBox is not even involved! It's the Windows installer that's screwed up, and a quick search around the internet will convince even the most doubting Thomas.

Marking as [WorksForMe].

PS. BTW, your Xubuntu VM has nothing to do with what you're facing/describing. It could have been any VM...