virtualbox.org

The errors are of the form:
Payload error - DNF installation has ended up abrubtly: Transaction check error

Further details of a bad SHA1 digests are then given. I wasn't able to cut and paste the errors but they relate to packages libni_config-1.3.1-39.el8.x86_64 and kernel-core-4.18.0-147.8.1.el8_1.x86_64

I tried the following all with a similar problem:
- CentOS-8.1.1911-x86_64-dvd1.iso
- CentOS-8.1.1911-x86_64-boot.iso
- CentOS-Stream-8-x86_64-20191219-boot.iso

I then tried 7x and successfully installed a minimal image:
- CentOS-7-x86_64-Minimal-2003

Perhaps not an issue with the ISOs themselves but a problem with the rpms being used?
I'm just going to use my 7.x system.

For all involved, please check if Hyper-V is enabled on your Windows 10 host.

Look for these lines in the guest vbox.log:

{timestamp} HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
{timestamp} NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...

VT-x may be called AMD-V in the log, for AMD hosts.

Or post the log: Start the guest from full power off, not save-state. Run until you see the problem happen, then shut down the guest from within the guest OS if possible. If not possible, close the Virtualbox window for the guest with the Power Off option set. Right-click the guest in the main Virtualbox window's guest list, choose Show Log. Save the far left tab's log, zip the log file, and post the zip file, using the forum's Upload Attachment tab.

same issue

It seems that CentOS release team do not do intensive and proper testing of their software before releasing to the public. It's a bit sad, but that's how it feels.

So many people use Virtualization technologies and it's really important for OS developers to test the major ones like VMWare and others like Virtualbox, Hyper-V etc.

They simply do not run the tests and publish software.

XTJ wrote:It seems that CentOS release team do not do intensive and proper testing

I strongly believe this is not the case. There is no doubt that CentOS does excellent testing on their releases, and I'm quite certain they test their ISOs. They wouldn't have got this popular with shoddy testing.

Several different sources of ISO have suffered the same problem. The problem is having Hyper-V enabled. It interferes in some way with the hashing that the guest OS tries when running in a Virtualbox guest. Turn off Hyper-V and the problem goes away.

I ran into this exact same issue and it had me scratching my head for days. I even tried an Ubuntu image, just to see if it was Centos. It wasn't Centos.

After I read through a few other forums, I finally figured out that Hyper-V still had some active components, even after I disabled the feature from Programs and Features and rebooted my computer. What really tipped me off was when I read through the vbox.log file as suggested by scottgus1

scottgus1 wrote: Look for these lines in the guest vbox.log:

{timestamp} HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
{timestamp} NEM: WHvCapabilityCodeHypervisorPresent is TRUE, so this might work...

When I did this, I noticed that I had the exact same errors in the log.

Here's what I did to figure out that Hyper-V was still running:

1. Open System Information. On my Windows 10 host, the application was located under C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools.
2. From the System Summary tab scroll down to the bottom of the pane on the right.

If Hyper-V is not enabled what you should see should look like this: If Hyper-V is enabled, you will see a message stating "a hypervisor has been detected. features required for hyper-v will not be displayed"

In order to completely disable Hyper-V after disabling it from the features list, I still had to do the following:
1. Go into Services.msc, right click on each service associated with Hyper-V, select Properties, and set the Startup Ttype: to "Disabled".
2. I had to disable the Hyper-V network adapter under Control Panel\Network and Internet\Network Connections. The adapter in my case was labeled "vEthernet (Default Swtich)"
3. I then had to reboot my computer.

After that, I was in business. I hope this helps!

Thanks, ScottyC, for your experience and the breakdown of your fix!

I believe it is time to lock this one, as an anecdotal line of evidence and a fix have developed, please see the first post.

For further posters with this issue, please try the info in the first post, then make a new topic with an attached vbox.log if you cannot proceed.