VT-x status in BIOS is a red herring. Turns out modern Virtualbox won't even start VM's without VT-x.
A true cause turned out to be "Windows Sandbox" feature (although I imagine for some other users the problem might be triggered by "Windows Subsystem for Linux" or anti-virus software). Here is how to reproduce it in Windows 10: 1. Enable "Windows Sandbox" (Control panel -> Programs and Features -> Turn Windows features on or off) 2. After restart run Ubuntu live ISO in virtualbox and notice that a) VM slows to a crawl, some apps (firefox) start crashing randomly, etc b) Virtualbox shows "green turtle" icon (third from the right on the lower panel) which lists Execution engine as "native API" instead of "VT-x" c) Running "apt update" produces error mentioning "hash mismatch" d) Running workaround (mkdir -p /etc/gcrypt; echo intel-ssse3 > /etc/gcrypt/hwf.deny) fixes the apt error 3. Disable "Windows Sandbox" feature 4. After Windows restart run Ubuntu in Virtualbox and be surprised by green turtle still being there, all mentioned problems still present 5. Restart Windows second time, run Ubuntu in Virtualbox again, this time there is a blue chip instead of green turtle and apt works without workarounds Clearly it seems that gcrypt isnt at fault here and the true culprits are Windows Sandbox (possibly some other mechanism that Windows Sandbox enables) and/or Virtualbox. However the result is that new users are getting wrong impression about GNU/Linux and Ubuntu in particular (it appears slow and lags during "live" phase, fails to update after install). So I'd say Ubuntu should detect that it's being run in this broken virtualization mode, show the informative explanation to user (that their current experience isn't representative && how they can fix that) or at least enable the workaround for gcrypt (although if SSSE3 is buggy in this mode, I imagine more things are stealthily broken). Surprisingly Ubuntu still finishes installation, even with default "update from internet" option enabled. After installation, "apt update" still produces the same "hash mismatch" errors though. Enabling workaround and rerunning "apt update" predictably finds many more (292 right now) packages that are to be upgraded. This fail-open behavior (installer and updater ignoring the errors) will no doubt lead to subtle bug down the road for the users as well (I'd argue that it's a security issue as well - users not being informed about security patches they're missing). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890006 Title: Hash mismatch on "apt update" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1890006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs