Critical error on kernel boot since 4.14.11

[user20180115]

Guest: Fedora 27 i686
Virtualbox: v5.2.4, v5.2.5-120181(latest test build)

Everything is fine with kernel 4.14.8.
4.14.11 and 4.14.13 will crash.

[socratis]

00:00:02.869590 HM: HMR3Init: Falling back to raw-mode: VT-x is not available

You should enable VT-x in your BIOS, see ticket #12254. However, your Core2 Quad Q8200 does *not* support VT-x, so that's going to be a problem for you.

[user20180115]

00:00:02.869590 HM: HMR3Init: Falling back to raw-mode: VT-x is not available

However, your Core2 Quad Q8200 does *not* support VT-x, so that's going to be a problem for you.

Yes I know that my processor does not have VT-x, but it has never been a problem before. Does this mean that non-VT-x-enabled processors are suddenly not supported for Linux guests anymore?

[socratis]

Maybe, it really depends on the guest, that's not a generalized statement. Some Linux guests still work, just like in your case.

But it definitely means that if you want to have supported N years back hardware, it may be wise to not expect it to work with the latest patches/updates/fixes. Especially virtualization software or virtual guests!

[user20180115]

The very same kernel boots fine on bare hardware dated 2002.
Should I also report it to Linux kernel guys? Will they regard it as a regression in their code, what do you think?

[socratis]

All things being equal, if the only difference between the two systems is the kernel, I'm not sure that reporting it will do anything. The dates are not relevant. There may be something in the revisions that have a problem, that requires the VT-x part to be enabled. I really don't know...

[Perryg]

Code: Select all

00:00:02.693050 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Snapshots' (snapshots) is ntfs
00:00:02.693067 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Fedora-root.vdi' is ntfs
00:00:02.694460 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Fedora-usr.vdi' is ntfs
00:00:02.695650 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Fedora-var.vdi' is ntfs
00:00:02.696834 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Fedora-swap.vdi' is ntfs
00:00:02.697984 File system of 'D:\LIB\VirtualBox\Machines\Fedora\Fedora-opt.vdi' is ntfs

I though I was unique in that I setup separate partitions for most of the OS system locations but you are on a completely different level using separate drives for each. Bet that was a tussle to setup.

Anyway to the problem you are having. Updating the kernel seems to be where you lost it, and if you boot to the previous kernel it works properly. I would say that it might not really be a VBox issue since most popular distros these days are trying to phase out i686 kernels.

Have you checked the guest settings and is VT-x/AMD-v disabled? You could post the following ( as an attachment )

• From the hosts terminal/command window type VBoxManage showvminfo <VM Name> --details and post here. Replace <VM Name> with the actual name of the VM. Use " " if the name has a space in it.
  
  Note if the host is Windows you need to be in the directory that has VBoxManage.exe for the command to work.

[user20180115]

Bet that was a tussle to setup.

That was pretty easy actually. In real env I can't afford having separate custom-sized disks for different mounts. And it helped me a lot when I substituted "var" and "opt" mounts couple of times.

Have you checked the guest settings and is VT-x/AMD-v disabled? You could post the following ( as an attachment )

Something like that is on. Should I turn anything off with modifyvm?

[Perryg]

Something like that is on. Should I turn anything off with modifyvm?

That would be my first thought. I seem to remember this being the case some time ago and that took care of the issue. IIRC the DEVs even stated that supporting non-VT-x/AMD-v was going lower in their priority, only dealing with it on a case by case issue.

[user20180115]

Turned everything off in the VM configuration - nothing helped.

[Perryg]

These kinds of problems that are reproducible should be reported to bugtracker.
It would also help if you can post the ticket number here so other can see the progress, add information, or see the final results.