Bug 21553 - Cauldron doesn't boot in VirtualBox when selecting kernel 4.12+ and having several CPUs dedicated for the VM
Summary: Cauldron doesn't boot in VirtualBox when selecting kernel 4.12+ and having se...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 22863 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-17 15:11 CEST by Frédéric "LpSolit" Buclin
Modified: 2022-06-18 15:15 CEST (History)
12 users (show)

See Also:
Source RPM: kernel-4.12, virtualbox
CVE:
Status comment:


Attachments
newer dracut 046 (6.96 KB, text/plain)
2017-10-23 22:32 CEST, Giuseppe Ghibò
Details
.vbox configuration file (2.99 KB, text/plain)
2018-08-07 22:26 CEST, Frédéric "LpSolit" Buclin
Details
VBox.log file (83.31 KB, text/plain)
2018-08-07 22:26 CEST, Frédéric "LpSolit" Buclin
Details
Mga6 in a MV booting with kernel 4.14.70-2.1 (48.29 KB, image/png)
2018-09-30 08:39 CEST, Sébastien Morin
Details

Description Frédéric "LpSolit" Buclin 2017-08-17 15:11:19 CEST
My host machine is Mageia 6 running VirtualBox 5.1.26-1. My guest virtual machine is cauldron. When I boot cauldron using kernel 4.12.x, nothing happens. The screen remains black and the VM shows no activity. Pressing ESC doesn't help; the screen remains black. If I boot using kernel 4.9.40, then cauldron boots without any problem. I tried 10+ times, and the problem is 100% reproducible.
Comment 1 James Kerr 2017-08-17 16:28:22 CEST
I had to reduce the number of CPU's to one in order to get the VM to boot.

CC: (none) => jim

Comment 2 Frédéric "LpSolit" Buclin 2017-08-17 16:35:12 CEST
(In reply to James Kerr from comment #1)
> I had to reduce the number of CPU's to one in order to get the VM to boot.

Also when using kernel 4.9.40, or only with 4.12?
Comment 3 James Kerr 2017-08-17 18:11:24 CEST
IIRC only with 4.12
Comment 4 Frédéric "LpSolit" Buclin 2017-08-17 18:24:02 CEST
I can confirm what James said in comment 1. If I decrease the number of CPUs dedicated for the VM from 2 to 1, then cauldron boots.

CC: (none) => tmb
Summary: Cauldron doesn't boot in VirtualBox when using kernel 4.12 => Cauldron doesn't boot in VirtualBox when selecting kernel 4.12 and having several CPUs dedicated for the VM

Marja Van Waes 2017-08-17 19:17:34 CEST

CC: (none) => marja11
Assignee: bugsquad => kernel

Comment 5 Frédéric "LpSolit" Buclin 2017-09-18 01:02:09 CEST
This was working fine with kernel 4.12.9, but is broken again with 4.12.13.
Comment 6 Giuseppe Ghibò 2017-10-18 23:04:21 CEST
You can drop the number of CPUs on the fly by passing maxcpus=1 at grub boot command line. The same problems occurs also using latest Virtualbox 5.1.30.

BTW, if you want to try a newer than 4.9.40 series kernel with cauldron, there is kernel-joeghi-desktop-4.9.56 in updates_testing.

CC: (none) => ghibomgx

Comment 7 Giuseppe Ghibò 2017-10-18 23:14:26 CEST
Of course I got the same problem with either 4.12.x, 4.13.x. The hangs happens just after printing the line:

[0.023619] x86: Booting SMP configuration:
Comment 8 Giuseppe Ghibò 2017-10-20 19:58:16 CEST
Still happening also on 4.13.8-desktop-1.mga7 (64bit).
Comment 9 Thomas Backlund 2017-10-20 20:07:52 CEST
I cant reproduce...

I just installed a mga6 vm, and upgraded it to cauldron, and it still works...

Could it be hw specific ? What hw?

Do you have virtualization options disabled/enabled in bios/uefi?

Can you attach /var/log/dmesg from failing systems
Comment 10 Frédéric "LpSolit" Buclin 2017-10-21 13:47:07 CEST
(In reply to Thomas Backlund from comment #9)
> Could it be hw specific ? What hw?

Skylake i5-6500 @ 3.20 GHz, 4 cores, 16 GB RAM, 512 GB SSD.


> Can you attach /var/log/dmesg from failing systems

I cannot, because my system doesn't boot at all. If I reboot using kernel 4.12.9, then dmesg only contains the successful boot.
Comment 11 Giuseppe Ghibò 2017-10-23 22:32:14 CEST
Created attachment 9750 [details]
newer dracut 046
Comment 12 Giuseppe Ghibò 2017-10-23 22:36:56 CEST
In my case it's skylake i7 6700. But I think I found the culprit, seems the image generated by current dracut 044. With the newer dracut 046 the boot in SMP mode complete successfully. I attach here the newer dracut for testing. Note that it's disable all the patches merged upstream, as well as the mageia patch customizations, that indeed need to be regenerated.
Comment 13 Thomas Backlund 2017-10-24 07:20:39 CEST
(In reply to Giuseppe Ghibò from comment #12)
> In my case it's skylake i7 6700. But I think I found the culprit, seems the
> image generated by current dracut 044. With the newer dracut 046 the boot in
> SMP mode complete successfully. I attach here the newer dracut for testing.
> Note that it's disable all the patches merged upstream, as well as the
> mageia patch customizations, that indeed need to be regenerated.

So we are missing some module on your hw...

Can you try to diff lsinitrd between non-working and working initrd
Comment 14 Giuseppe Ghibò 2017-10-24 07:49:31 CEST
Apparently is not what is missing but what is present to be harmful, i.e. the presence of the file kernel/x86/microcode/GenuineIntel.bin (maybe outdate?) in the non-working initrd, regenerating the initrd with the command option:

dracut --no-early-microcode ...

will produce a bootable smp initrd image
Comment 15 Thomas Backlund 2017-10-24 08:48:38 CEST
Hm,
ok, so both are on skylake...

weird... early microcode loading should simply bail out when it cant update microcode (which it cant in a vm, only the host has real hw access for loading...)

How long did you wait when it stalls on "x86: Booting SMP configuration"

Do you have microcode installed on the host ?
If not, install it, recreate initrd and reboot the host...
Does the vm boot properly then ?
Comment 16 Frédéric "LpSolit" Buclin 2017-10-24 15:45:27 CEST
(In reply to Giuseppe Ghibò from comment #12)
> In my case it's skylake i7 6700. But I think I found the culprit, seems the
> image generated by current dracut 044. With the newer dracut 046 the boot in
> SMP mode complete successfully. I attach here the newer dracut for testing.

Could dracut 046 be built and pushed to updates_testing to see if it fixes the problem for me too?
Comment 17 Giuseppe Ghibò 2017-10-24 17:40:19 CEST
microcode is already installed in the host (which is mga6), and detected as:

[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09

and it's:

microcode-0.20170707-1.mga6.nonfree

while in the guest is:

microcode-0.20170707-2.mga7.nonfree

which seems the same version and seems also the latest version available here: http://cdn-fastly.deb.debian.org/debian/pool/non-free/i/intel-microcode/

The stalls on the guest VM happens quite immediately, a few hundreds of seconds after the boot (0.026762 prints the counter).

As dracut for Frédéric, you can try with old (i.e. current 044), booting with maxcpus=1 then running dracut to rebuild the initrd using:

mv /boot/initrd-4.13.8-desktop-1.mga7.img /boot/initrd-4.13.8-desktop-1.mga7.img.bak

dracut --no-early-microcode -f /boot/initrd-4.13.8-desktop-1.mga7.img 4.13.8-desktop-1
Comment 18 Frédéric "LpSolit" Buclin 2017-10-24 19:02:50 CEST
Rebuilding initrd did the job. But 4.13.8 takes a huge time to start:

[    0.981594] dracut: rd.md.ddf=0: no MD RAID for SNIA ddf raids
[    1.596314] tsc: Refined TSC clocksource calibration: 3192.043 MHz
[    1.596343] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2e02ed75efa, max_idle_ns: 440795268343 ns
[    2.600304] clocksource: Switched to clocksource tsc
[  139.259956] dracut: Scanning for all btrfs devices

Note the gab between the last 2 lines. More than 2 minutes! If I reboot my VM, this 2 minutes gab is still there.

If I reboot with 4.12.9, there is no entry in /var/log/dmesg about dracut.
Comment 19 Thomas Backlund 2017-10-24 21:14:59 CEST
Ok, so for now it could be an ERRATA stating "for those affected, boot with "maxcpus=1 && urpme microcode && dracut -f" for virtualbox installs...
Comment 20 Giuseppe Ghibò 2018-01-18 12:56:08 CET
FYI, Thomas added a workaround to current dracut 038 to disable early microcode, adding

early_microcode="no"

to /etc/dracut.conf
Comment 21 Thomas Backlund 2018-01-21 00:44:12 CET

Have you enabled hw virtualization in bios ?


Have you enabled i/o apic in vm config (under System) ?

I still cant reproduce this
William Kenney 2018-01-21 00:56:56 CET

CC: (none) => wilcal.int

Comment 22 William Kenney 2018-01-21 01:05:21 CET
See:

https://bugs.mageia.org/show_bug.cgi?id=22408

My comments: 10, 11, 12, 13, 18, 19, 20, 21, 23
Comment 23 Frédéric "LpSolit" Buclin 2018-01-21 01:41:53 CET
(In reply to Thomas Backlund from comment #21)
> 
> Have you enabled hw virtualization in bios ?
> 
> 
> Have you enabled i/o apic in vm config (under System) ?


Yes. Still doesn't work with 4.14.13-desktop-1.mga6.

Summary: Cauldron doesn't boot in VirtualBox when selecting kernel 4.12 and having several CPUs dedicated for the VM => Cauldron doesn't boot in VirtualBox when selecting kernel 4.12+ and having several CPUs dedicated for the VM

Comment 24 William Kenney 2018-01-21 02:49:10 CET
Just guessing here. I've always assigned two cpus to a Vbox client.
Seems this issue started for me about two kernel upgrades ago.
Comment 25 Martin Whitaker 2018-01-24 01:17:55 CET
Another data point. I'm seeing this on a non-Skylake host (i5-3550) with Mageia 6 64-bit host and 64-bit guest, both fully updated. No problem with the originally installed 4.9.35-desktop-1 kernel. Hangs immediately after

Decompressing Linux...
Booting the kernel...

messages with the 4.14.13-desktop-1 kernel. VirtualBox is using 200% CPU on the host system when it hangs. 'dracut --no-early-microcode' fixes it.

With a 32-bit guest and the 4.14.13-desktop586-1 kernel, there is a short delay after the "Booting the kernel..." message, then the message

smpboot: do_boot_cpu failed(-1) to wakeup CPU#1

after which the guest system boots with just one CPU enabled.

CC: (none) => mageia

Comment 26 Mauricio Andrés Bustamante Viveros 2018-02-08 16:14:13 CET
Giving a test to this issue, I found that the maxcpus=1 value does not do anything, always gets guru meditation after the freeing SMP alternatives)

Updating to vbox 5.1.32 and trying again is the same issue
I am will not use the vbox 5.2.6 because fails trying to add a second SATA disk to the configuration

My vbox configuration only has 1 cpu and 100% usage permission

Attached screenshots to drive

https://drive.google.com/file/d/1g7Et19p96dUiMsUN07cWX2gjJPO1fK6l/view?usp=sharing
https://drive.google.com/file/d/1DGAShf3mvFK01atYPd0CUfrhDQm3W94m/view?usp=sharing
https://drive.google.com/file/d/1TSQ6qIybHwszg_W902IfiJJEWZC7H8WE/view?usp=sharing

Hardware: Virtual Box VM 5.1.12r112440 and 5.1.32r120294
RAM: 1024 Mb
Disk: SATA Vbox drive 20 Gb
Sound: Intel HD

Host: Windows 7 SP1 x86
RAM: 4096 Mb
DISK: 1024 Gb
Processor: Pentium Dual COre E5200 2.5 Ghz

CC: (none) => neoser10

D M 2018-02-11 19:20:54 CET

CC: (none) => axonefr

egc 2018-02-22 20:37:53 CET

CC: (none) => egc

Comment 27 Angelo Naselli 2018-04-02 12:13:07 CEST
*** Bug 22863 has been marked as a duplicate of this bug. ***

CC: (none) => anaselli

Comment 28 Thierry Vignaud 2018-04-02 15:29:49 CEST
(In reply to Martin Whitaker from comment #25)
> Another data point. I'm seeing this on a non-Skylake host (i5-3550) with
> Mageia 6 64-bit host and 64-bit guest, both fully updated. No problem with
> the originally installed 4.9.35-desktop-1 kernel. Hangs immediately after
> 
> Decompressing Linux...
> Booting the kernel...
> 
> messages with the 4.14.13-desktop-1 kernel. VirtualBox is using 200% CPU on
> the host system when it hangs. 'dracut --no-early-microcode' fixes it.
> 
> With a 32-bit guest and the 4.14.13-desktop586-1 kernel, there is a short
> delay after the "Booting the kernel..." message, then the message
> 
> smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> 
> after which the guest system boots with just one CPU enabled.

You can remove "splash quiet" from kernel options before actually booting in order to see more verbose messages

CC: (none) => thierry.vignaud

Comment 29 Martin Whitaker 2018-04-02 15:45:50 CEST
(In reply to Thierry Vignaud from comment #28)
> You can remove "splash quiet" from kernel options before actually booting in
> order to see more verbose messages

I know.

After it's hung, there are no more messages ;-)
Comment 30 Frédéric "LpSolit" Buclin 2018-08-06 16:10:45 CEST
This problem is also present with Mageia-6.1-rc-LiveDVD-Plasma-x86_64-DVD.iso. :(
Comment 31 Frédéric "LpSolit" Buclin 2018-08-06 17:09:57 CEST
FYI, this is not an issue when installing and booting OpenSUSE 15.0 and CentOS 7 in VirtualBox, so this issue is really specific to Mageia.
Comment 32 Martin Whitaker 2018-08-06 21:10:19 CEST
(In reply to Frédéric Buclin from comment #30)
> This problem is also present with
> Mageia-6.1-rc-LiveDVD-Plasma-x86_64-DVD.iso. :(

I know. It significantly increased the time it took me to test the ISOs before releasing them :-( But I don't think I should disable early microcode load on the ISOs.
Comment 33 Frédéric "LpSolit" Buclin 2018-08-07 15:48:24 CEST
(In reply to Martin Whitaker from comment #32)
> I know. It significantly increased the time it took me to test the ISOs
> before releasing them :-( But I don't think I should disable early microcode
> load on the ISOs.

Do you mean OpenSUSE and CentOS do not load microcode?
Comment 34 Martin Whitaker 2018-08-07 21:37:22 CEST
(In reply to Frédéric Buclin from comment #33)
> Do you mean OpenSUSE and CentOS do not load microcode?

No. Just that the workaround Giuseppe describes in comment 20 seems to work, but if I applied that when building the ISOs, then early loading of the microcode would be disabled for all uses of the ISOs, and I think that would be a bad thing.

It's odd that that workaround does work, because a VM guest shouldn't actually be loading any microcode.
Comment 35 Thomas Backlund 2018-08-07 21:54:53 CEST
Can any of you share the .vbox config file for an affected vm, I'd like to see if that helps tracking down what causes the issue..
Comment 36 Thomas Backlund 2018-08-07 21:57:12 CEST
also VBox.log might be interesting... maybe giving some clues...
Comment 37 Frédéric "LpSolit" Buclin 2018-08-07 22:26:15 CEST
Created attachment 10303 [details]
.vbox configuration file
Comment 38 Frédéric "LpSolit" Buclin 2018-08-07 22:26:49 CEST
Created attachment 10304 [details]
VBox.log file
Comment 39 Thomas Backlund 2018-08-16 18:37:36 CEST
I've disabled early microcode loading for live medias (in live mode) to make testing them easier for those affected...
http://gitweb.mageia.org/software/build-system/draklive-config/commit/?h=distro/mga6.1&id=77edab3750595955bf62b8831608ee96ac9a138c

The rest of the issue I still need to check...
egc 2018-09-15 21:39:46 CEST

CC: egc => (none)

Comment 40 Sébastien Morin 2018-09-28 12:32:35 CEST
This bug is still reproducible (I ran into it this morning):

Virtualbox 5.2.18 is installed and running on a fully updated Mageia 6 with kernel 4.14.70-desktop-2.mga6.

Step 1 : I installed a new Mageia 6 in a virtual machine (from Mageia-6-x86_64-DVD.iso) in order to try Mate (and then upgrade the system to Cauldron).

Step 2 : I downloaded and installed all updates available on the VM, then I tried to reboot the system but I only got a black screen.
   - When the sytem is started in failsafe mode (with kernel 4.14.70-desktop-2.mga6) the booting hangs with the line: "x86: Booting SMP Configuration"
   - When booting with the original kernel (4.9.35-1), the virtual mga6 runs smoothly.


Possible workaround: reducing the number of processors of the VM to 1 allows the system to boot with kernel 4.14-70.

CC: (none) => sebsweb

Comment 41 Thomas Backlund 2018-09-28 17:40:52 CEST
If you install kernel-desktop-4.14.70-2.1.mga6

from:
http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/21553/x86_64/

in the vm, does that allow you to boot with more processors ?
Comment 42 Martin Whitaker 2018-09-28 19:08:04 CEST
(In reply to Thomas Backlund from comment #41)
> If you install kernel-desktop-4.14.70-2.1.mga6
> 
> from:
> http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/21553/x86_64/
> 
> in the vm, does that allow you to boot with more processors ?

That works for me.

(need to install dkms-vboxvideo to get a graphical display)
Comment 43 Sébastien Morin 2018-09-29 06:25:46 CEST
(In reply to Thomas Backlund from comment #41)
> If you install kernel-desktop-4.14.70-2.1.mga6
> 
> from:
> http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/21553/x86_64/
> 
> in the vm, does that allow you to boot with more processors ?

Sorry Thomas, this didn't work for me:
Even with 1 processor, the virtual machine didn't boot properly with this kernel: it started in CLI and I was unable to find a screen resolution to make it start in graphical mode again.
Same problem with more CPUs, the system starts in CLI, I am asked to login as root and change the settings in drakx11. None of the settings I try will work.

But I'm just wondering... I also have a vboxadditions-kernel-4.14.70-desktop-2.mga6 RPM and a similar vboxadditions-kernel-4.9.35 RPM for the corresponding kernel installed. Shouldn't I install a similar vboxadditions-* RPM corresponding to your kernel in order to make it work?
Comment 44 Martin Whitaker 2018-09-29 09:30:33 CEST
See my comment Sébastien. If you install kernel-desktop-devel-4.14.70-2.1.mga6 from Thomas's repository and then install dkms-vboxvideo, the vboxvideo driver will get built for the new kernel.
Comment 45 Sébastien Morin 2018-09-29 09:58:57 CEST
I saw your comment Martin and I thank you, but I cannot find dkms-vboxvideo.
Which repository is it in?
Comment 46 Martin Whitaker 2018-09-29 10:02:37 CEST
Sorry, my mistake, that should be dkms-vboxadditions (the driver name is vboxvideo, but the package name is vboxadditions).
Comment 47 Sébastien Morin 2018-09-29 11:04:29 CEST
I've tried another method, but I'm afraid it wasn't successful either:

Instead of downloading the files on my virtual machine, I added Thomas's link as a new repository. I uninstalled kernels 4.14.70-2.1 (and -devel) which I had previously installed, and I reinstalled them from the http repository.

When I rebooted, I saw the vboxadditions being built for the new kernel.
Then I arrived at the login screen (in graphical mode), but I couldn't login, or rather: I couldn't open my DE (Cinnamon).

I logged into a tty as a plain user and typed startx, and this is what I got:

xauth: file /home/sebastien/.serverauth.2401 does not exist
xauth: /home/Sebastien/.Xauthority not writable, changes will be ignored
xauth: timeout in locking authority file /home/sebastien/.Xauthority


It seems this new kernel has deeply affected my virtual machine since I can no longer login using the "old" 4.9.35 kernel... which was working fine before I tried to install kernel 4.14.70-2.1
Comment 48 Martin Whitaker 2018-09-29 12:23:55 CEST
(In reply to Sébastien Morin from comment #47)
> xauth: file /home/sebastien/.serverauth.2401 does not exist
> xauth: /home/Sebastien/.Xauthority not writable, changes will be ignored
> xauth: timeout in locking authority file /home/sebastien/.Xauthority

The mixture of /home/Sebastien and /home/sebastien is a bit odd...

What does

  ls -l /home/?ebastien/.Xauthority

show?
Comment 49 Sébastien Morin 2018-09-30 08:39:18 CEST
Created attachment 10389 [details]
Mga6 in a MV booting with kernel 4.14.70-2.1

Steps to reproduce:

1. Install Mageia6 in a virtualbox with >1 proc from Mageia-6-x86_64-DVD.iso
2. Install all updates available (Sept. 30 2018)

=> VM can now boot with default 4.9.35 kernel, but cannot start (black screen) with the updated kernel (4.14.70-2)

3. Booting with kernel 4.9.35, add http://ftp.free.fr/mirrors/mageia.org/people/tmb/mga6/bugs/21553/x86_64/ as a new HTTP media ("tmb-rpm-testing")
4. In MCC, search for kernel 4.14.70-2.1 and select both kernel and kernel-devel (they need to be selected separately)
5. Reboot and select the new kernel 4.14.70-2.1 : the graphical environment is not starting ; when logging in as a user and typing "startx", see the error message on the attached screenshot.

=> At this stage, booting with any of the 3 installed kernels will fail starting in graphical mode.

It seems installing dkms-vboxadditions at the same time, and **before** rebooting with kernel 4.14.70-2.1 is mandatory. Trying to install it afterwards will not fix anything, and booting with all 3 kernels will fail launching in graphical mode.
Comment 50 Sébastien Morin 2018-09-30 09:06:34 CEST
(In reply to Martin Whitaker from comment #48)
> (In reply to Sébastien Morin from comment #47)
> > xauth: file /home/sebastien/.serverauth.2401 does not exist
> > xauth: /home/Sebastien/.Xauthority not writable, changes will be ignored
> > xauth: timeout in locking authority file /home/sebastien/.Xauthority
> 
> The mixture of /home/Sebastien and /home/sebastien is a bit odd...
> 
> What does
> 
>   ls -l /home/?ebastien/.Xauthority
> 
> show?

Sorry about that Martin, I couldn't copy from the tty, and I didn't realize I could join PNG attachments here (I thought only text files were permitted).

I cannot answer the question (that clone has already been deleted), but I followed the same steps as in my previous message, except I installed dkms-vbocadditions at the same time, **before** rebooting on kernel 4.14.70-2.1 and...

... now it works (tested with 4 proc in the VM)
Thank you for your help (and thank you for the RPMs, Thomas)
Comment 51 Sébastien Morin 2018-10-02 21:35:46 CEST
Seems to be fixed with kernel 4.18.11-desktop-2.mga7 which has just been pushed to Cauldron (VM now starting in graphical mode with 4 processors).
Comment 52 Thomas Backlund 2018-10-02 22:11:40 CEST
(In reply to Sébastien Morin from comment #51)
> Seems to be fixed with kernel 4.18.11-desktop-2.mga7 which has just been
> pushed to Cauldron (VM now starting in graphical mode with 4 processors).

Yep, I merged the same fix in Cauldron as in the test kernel 4.14.70-2.1.mga6
Comment 53 William Kenney 2018-10-03 00:21:22 CEST
Super fix. I can't wait to see it.

Thanks everyone.
Comment 54 Thomas Backlund 2018-10-22 07:09:30 CEST
Unfortunately I had to revert this fix for now as it breaks suspend/resume because it seems to be an issue with the dmi calls :/

I will review the codepaths and figure it out or find another way to fix it, but for now you need to either remove/blacklist microcode package or run with one cpu
Comment 55 Deri James 2018-11-21 15:12:16 CET
Using:

MGA 6 Host (VB Version 5.2.22 r126257, Intel I5-2500,microcode updated early to revision 0x2e, date = 2018-04-10)

Cauldron Guest (Linux localhost 4.19.2-desktop-3.mga7 #1 SMP Fri Nov 16 10:07:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux)

It still fails with more than 1 cpu allocated, BUT boots successfully if you change paravirtualisation to "Hyper-V" from "Default". It then boots successfully with two cpus.

CC: (none) => deri

Comment 56 Frédéric "LpSolit" Buclin 2018-11-21 15:35:16 CET
(In reply to Deri James from comment #55)
> It still fails with more than 1 cpu allocated, BUT boots successfully if you
> change paravirtualisation to "Hyper-V" from "Default". It then boots
> successfully with two cpus.

Yes, I can confirm that. Nice catch! :)
Comment 57 Thierry Vignaud 2018-11-21 16:02:09 CET
...
No comment...
Comment 58 Thierry Vignaud 2018-11-21 16:02:33 CET
Or: it's time for us to use virt-manager rather than vbox...
Comment 59 Giuseppe Ghibò 2018-11-21 22:03:41 CET
(In reply to Frédéric Buclin from comment #56)
> (In reply to Deri James from comment #55)
> > It still fails with more than 1 cpu allocated, BUT boots successfully if you
> > change paravirtualisation to "Hyper-V" from "Default". It then boots
> > successfully with two cpus.
> 
> Yes, I can confirm that. Nice catch! :)

what is weird is that other guests (like FC, etc.) boots in the same conditions without Hyper-V paravirtualization. What I also noticed is that in other distro guests' kernel, the clocksource is generally set to kvm. E.g. if you issue:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

you get:

kvm tsc hpet acpi_pm

and with:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

returns:

kvm

while in mga you get

tsc acpi_pm

as available clocksources, and "tsc" as current clocksource (native mageia host lists also "tsc hpet acpi_pm"). I haven't yet figure out what is the kernel config option that triggers that kvm, I thought CONFIG_PARAVIRT_CLOCK, but it's already set to 'y'.
Comment 60 Thierry Vignaud 2018-11-21 23:27:03 CET
Humm, we might just miss some kernel module in drakx/kernel/list_modules.pm
Comment 61 Thierry Vignaud 2018-11-21 23:36:19 CET
Or our vbox patch adding support for Mageia is lacking some option that is autoselected for FC/... ?
Comment 62 Thierry Vignaud 2018-11-22 00:53:29 CET
Should be fixed in next VirtualBox build
Comment 63 Thierry Vignaud 2018-11-22 02:48:28 CET
Though Vbox fails to compile (same error before & after the change)

Source RPM: kernel-4.12 => kernel-4.12, virtualbox

Comment 64 Thomas Backlund 2018-11-22 08:33:52 CET
Thierry, Thanks for spotting the kvm bit, but please dont mess with my packages before checking that I'm ok with the Changes...
Comment 65 Thierry Vignaud 2018-11-24 13:54:50 CET
@Tmb: Ack but note that this an obvious one liner change:
http://svnweb.mageia.org/packages/cauldron/virtualbox/current/SOURCES/VirtualBox-5.2.22-add-Mageia-support.patch?r1=1333125&r2=1333124&pathrev=1333125
I wonder if shouldn't simplify our patch to display Mageia/Mandriva instead of Mandriva?
That would prevent similar issues in the future.

@all: please test virtualbox-5.2.22-2.mga7
Comment 66 Martin Whitaker 2018-11-25 22:44:01 CET
Still with virtualbox-5.2.22-1.mga6, changing Paravirtualization Interface from Default to KVM also fixes the issue for me. This was with a freshly created VM and a Mageia 7 guest with 4.19.4-desktop-1.mga7. So it seems Default != KVM.
Comment 67 Thomas Backlund 2018-11-25 23:00:06 CET
(In reply to Martin Whitaker from comment #66)
> Still with virtualbox-5.2.22-1.mga6, changing Paravirtualization Interface
> from Default to KVM also fixes the issue for me. This was with a freshly
> created VM and a Mageia 7 guest with 4.19.4-desktop-1.mga7. So it seems
> Default != KVM.

Please try with 5.2.22-1.1 currently in mga6 updates testing...

That one has the matching fixes for mga6
Comment 68 Martin Whitaker 2018-11-25 23:35:06 CET
5.2.22-1.1 fixes Default. Now it only fails if you select None or Legacy.
Comment 69 Giuseppe Ghibò 2018-11-26 17:15:57 CET
Once fixed, it is worthwhile to try to submit to virtualbox upstream the mageia patch, so to not have to redo it at any new virtualbox release.
Comment 70 sturmvogel 2022-06-12 20:40:14 CEST
Is this bug still valid with MGA8/Cauldron MGA9 or can this be closed as FIXED?
Comment 71 Martin Whitaker 2022-06-18 10:17:56 CEST
I can no longer reproduce the fault in Mageia 8, so I would say it is fixed.
Comment 72 sturmvogel 2022-06-18 15:15:05 CEST
I also can't reproduce this bug under a MGA8 host and different MGA8/MGA9 cauldron/Fedora guests. I always assign the maximum amount of cores available and use different guest BIOS settings (legacy/UEFI).

So based on comment 71 it makes sense to close this bug as FIXED.

Feel free to reopen if still valid with actual hosts/guests (this bug was originaly filed against MGA 6 which is EOL since Sep 2019).

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.