I tested upgrading a Mageia 2 VM to Cauldron with current Cauldron as of Friday (the 12th), so the kernel version was 3.8.5. The host is also Mageia 2. The VM is using the desktop kernels. When booting with the Cauldron kernel, I hit Esc on the splash to see the boot messages, and the last message I see is it trying to bring up networking (using the LSB network service), and then the display stops updating after that. Sending an ACPI shutdown does shut the machine down. Booting with the Mageia 2 kernel works fine. Checking the logs, it appears that it did boot successfully with the 3.8 kernel and it believes X started OK as well. It appears that what's happening is that once X tries to start, it stops updating the display. Booting the 3.8 kernel to multi-user.target works just fine. I put the kernel in the RPM field, since it does work with the Mageia 2 kernel, but I suspect the issue may be a bit more complicated than that. I had previously tested updating this VM to Cauldron right before the version freeze in January. The Cauldron kernel at the time was 3.7.1, which worked just fine. However, I checked out the 3.7.1 kernel from SVN (revision 332447), and applied a few of the spec changes that have been made since then (revisions 379541, 379614, 392742, and 409426), and built it using --without desktop586 --without doc --without source --without debug --without perf --without cpupower. This kernel has the same problem as the 3.8.5 kernel. So, I'm not sure if the issue is with the kernel, something in the build chain (like the compiler), or if it's with the virtualbox code (like the vboxvideo X module or vboxadditions kernel modules). The last one seems a strange one to suspect, as it does work with the Mageia 2 kernel, but not perfectly. The "Automatic" resolution setting in drakx11 doesn't work and you have to set it manually to match the monitor, and it has been reported (Bug 8810) that you also can't dynamically resize the resolution by changing the VM window size (confirmed still valid this weekend by Shlomi Fish), so there are certainly some problems with the vboxvideo module. Reproducible: Steps to Reproduce:
*** Bug 9749 has been marked as a duplicate of this bug. ***
CC: (none) => eeeemail
Setting release blocker. 3RC Live ISOs all affected. Classic ISOs not yet tested in vbox. More info on this bug so I've closed bug 9749
Priority: Normal => release_blockerCC: (none) => ennael1, tmbWhiteboard: (none) => 3RC
Classic beta 4 iso install correctly last sunday, even with all updates
CC: (none) => makowski.mageia
confirmed here. vboxvideo driver seems to be the pb. Using XFdrake to switch to vesa driver fixes the pb and boot is going smoothly
See also https://forums.mageia.org/en/viewtopic.php?t=4713&p=33064
(In reply to Anne Nicolas from comment #4) > confirmed here. vboxvideo driver seems to be the pb. Using XFdrake to switch > to vesa driver fixes the pb and boot is going smoothly I'm not sure that vboxvideo driver is the only issue, although it is a factor. I started the thread at https://forums.mageia.org/en/viewtopic.php?t=4713&p=33064 and have done further tests. To begin with, I installed the 3.8.7-desktop586-1.mga3 kernel and uninstalled all others. I also uninstalled all vbox, virtualbox and dkms packages, then rebooted. From the Mageia Control Center, I selected Set up the graphical server > Graphic Card > Other > VESA driver (generic) and saved the changes. Did a reboot and all was fine. This time, I bypassed all Mageia vbox and virtualbox packages by installing guest additions from the VM window menu (Devices > Install Guest Additions). The installation failed the first time due to not finding kernel headers. After installing the dkms, dkms-minimal, kernel-desktop586-devel-latest and kernel-desktop586-devel-3.8.7-1.mga3 packages, I ran the guest additions installation again. This time guest additions were installed. On reboot, X display would not start. Rebooted to safe mode, changed to /opt/VBoxGuestAdditions-4.2.10/ directory and ran ./uninstall.sh. On next reboot, X display started successfully. Started Mageia Control Center again and selected Set up the graphical server > Graphic Card. My previous choice of Other > VESA driver (generic) had reverted to VirtualBox virtual video card. I changed it, once again, to VESA driver (generic). Rebooted and X display started correctly. Ran the guest additions installation again (not the Mageia package installation) from the VBox VM's window menu. After completing the guest additions installation, I checked the video driver from Mageia Control Center. At program startup, I got the error message "Your Xorg configuration is broken. We will ignore it." I continued with the setup and it chose the VirtualBox virtual video card by default. I changed that to VESA driver (generic), tested and saved the changes. Next reboot was successful with the (non-Mageia) guest additions installed and the VESA driver installed. However, throughout this exercise, whenever ALL guest additions were completely removed and the VM had been rebooted, I would check the status of VBox shared folders group with: cat /etc/group | grep vbox It would ALWAYS return the value "vboxsf:x:488:darrel", showing that the vboxsf group still existed and I was still a member of that group. This should not be, if there are no VirtualBox components installed. Now that I have the guest additions still installed and am able to boot normally, the folder I share between the host and the guest is not available to the guest, although it is set up to permanently automount. That, too, is a new wrinkle. The vboxsf group is specifically for the purpose of using shared folders. This whole thing has me scratching my head as to what, exactly, the culprit is here.
CC: (none) => darreljohnston
I have Cauldron upgraded with newest packages and it would not start so I have made new fresh install in VirtualBox and upgrade all packages except : x11 virtualbox vbox 1.After upgrading vbox, virtualbox everything works fine 2.After upgrading x11 Cauldron would not start 3.Changing driver to VESA - it is starting normally. kernel-3.8.8-2 virtualbox-4.2.12 x11-1.13.4 I am going to work so I have no time to downgrade x11 and test it so, maybe later.
CC: (none) => minkob
so this bug affect also clean install ? I don't see why we have released isos then
duplicate in fact *** This bug has been marked as a duplicate of bug 9716 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE
*** Bug 9813 has been marked as a duplicate of this bug. ***
CC: (none) => bozonius
After today's update of x11-server and virtualbox packages, all issues have been resolved. It wasn't as easy as just updating and rebooting. I had to uninstall all dkms and virtualbox packages and remove xorg.conf. After doing so and rebooting, I reinstalled virtualbox guest additions, then rebooted. Everything is now working normally again. Thanks, gentlemen.
'Changing driver to VESA - it is starting normally.' How and where? If I have a boot fail system with only a single CLI.
CC: (none) => timpul
*** Bug 9847 has been marked as a duplicate of this bug. ***
I'm using the VirtualBox virtual video card driver and did not need to switch to the VESA driver. My solution to get Mageia 3 to work properly in VBox 4.2.12 is here: https://forums.mageia.org/en/viewtopic.php?f=8&t=4838 I agree that there are bugs that need to be squashed but at least I figured out a way that works for me with my ATI 6880 in Windows 7 Pro 64-bit host.
CC: (none) => markb
(In reply to Mark Brandon from comment #14) > I'm using the VirtualBox virtual video card driver and did not need to > switch to the VESA driver. My solution to get Mageia 3 to work properly in > VBox 4.2.12 is here: > > https://forums.mageia.org/en/viewtopic.php?f=8&t=4838 None of those steps should be needed anymore, as this has been fixed (make sure you've installed the updates from Cauldron). Furthermore, dkms-virtualbox is for host machines, not guests. dkms-vboxadditions is for guests, and if you have that installed, you don't need to manually install guest additions, we have a virtualbox-guest-additions package for that.