Description of problem: After installing today's updates my M5 KDE x86_64 client would not boot. The i586 KDE companion client updated and rebooted just fine. I then completely made a new install from the M5 KDE x86_64 Live-DVD. That booted just fine then a complete update resulted in the same error message. I have included a screen shot of the error message.
Created attachment 8019 [details] Vbox client fails to boot
Summary: After today's update M5 x86_64 KDE client would not boot => After today's update M5 x86_64 KDE Vbox client would not boot
I take that back it looks like the i586 client does not work either. :-((
Creating a new client ( M5 x86_64 KDE Live-DVD ) on the updated Host system the new client boots and runs just fine. It appears that the error occurs only if I update it.
I've created an M5 x86_64 KDE Vbox Client using boot.iso. Install was clean but boot up ended with a similar error message. See attachment boot_stop_ci.png
Created attachment 8020 [details] Error message from new boot.iso install
CC: (none) => thierry.vignaudAssignee: bugsquad => tmbSource RPM: (none) => virtualbox
I have executed a from a ground up blank drive install of M5 x86_64 KDE using the boot.iso and that went successful from start to finish. As expected no updates were found and needed. Repeated reboots are successful. So this appears to be at least isolated to M5 Vbox clients. I'm done with this today and will take a look at other distros and M6 clients on the updated Vbox tomorrow. Essentially what I have found is with today's updates any existing M5 clients will be bricked. Any attempt to create/install M5 as a Vbox client will be unsuccessful.
Try removing /etc/X11/xorg.conf, also try updating to 5.0.22 in updates_testing.
(In reply to David Walser from comment #7) > Try removing /etc/X11/xorg.conf, also try updating to 5.0.22 in > updates_testing. OK, Broken M5 x86_64 KDE Vbox client starts the boot process and gets to the error message point and hangs there. How do I at that point, in the Client, get to a terminal/root then remove the /etc/X11/xorg.conf file? [root@localhost wilcal]# rm /etc/X11/xorg.conf I know. Thanks
I have a working, and successfully updating and rebooting, Vbox client of M6 x86_64 Gnome that was installed from the Live-DVD.
William, it's not hung, it's just not able to start X on tty1 and run the Display Manager. Do Right-Ctrl F2 to switch to tty2 and you can log in on the console. I had this bug just magically come back on my system once I updated the host to 5.0.22 (even though it was fine before that, bizarre). Upgrading the VM to 5.0.22 didn't fix it. Removing xorg.conf allowed X to start, but at the wrong resolution (5.0.16 regression IIRC), but restoring xorg.conf and removing the ModeLine entries from the Monitor section fixed it. We'll need to make sure our installer/drakxtools don't write ModeLines in xorg.conf if you're using a VirtualBox VM.
(In reply to David Walser from comment #10) > We'll need to make sure our installer/drakxtools don't write ModeLines in > xorg.conf if you're using a VirtualBox VM. Well I tried just about everything I know. Remove /etc/X11/xorg.conf Comment out the ModeLines. Delete the ModeLines. I'm using VI to edit xorg.conf And thanks for the "Right-Ctrl F2 to switch to tty2" tip. That works just fine. I just can't get it to repair and start X.
Blocks: (none) => 18727
If you install x11-driver-video-modesetting (and remove xorg.conf) you should be able to get X running again, even if that's not the "correct" fix.
Blocks: 18727 => (none)Depends on: (none) => 18727
(In reply to David Walser from comment #12) > If you install x11-driver-video-modesetting (and remove xorg.conf) you > should be able to get X running again, even if that's not the "correct" fix. Did that in a root terminal and that didn't seem to change anything. I've attached the screen cap.
Created attachment 8049 [details] x11-driver-video-modesetting install
Thomas, something Len just said on the qa-discuss list inspired me to try one more thing. Adding the nomodeset option to the kernel command line fixes my VM at work.
(In reply to David Walser from comment #15) > Thomas, something Len just said on the qa-discuss list inspired me to try > one more thing. > > Adding the nomodeset option to the kernel command line fixes my VM at work. Please tell me exactly how to do that.
Reproduced this issue here with a 32bit client on 64bit host. I've removed the vboxadditions kmods and using dkms-vboxadditions have rolled it back as far as 5.0.14 to test older versions. They all fail to start X. Xorg.0.log shows it is loading VboxVideo and using vt1, falls back to old method for v4l and then fails to find vboxvideo kernel module. lsmod shows that vboxvideo is actually loaded. One oddity maybe is it says.. (II)VBoxVieo: guest driver for VirtualBox: vbox should that perhaps be vboxvideo rather than vbox?
CC: (none) => eeeemail
Rebooting the same system into kernel 4.1.15 allows X to start
s/system/client/
dkms shows no vboxadditions installed in 4.1.15 though. No matching kernel devel so I suppose it didn't build. Will install the kernel devel and try it again.
No, sorry to mislead. It actually fails with kernel 4.1.15 and dkms-vboxadditions-5.0.14 too. After updating, it also fails on kernel 4.1.15 and dkms-vboxadditions 5.0.20. Points a bit to the host being the problem.
One thing else to try, which I neglected to do is to downgrade virtualbox-guest-additions and dkms-vboxadditions together.
also fails with kernel 4.1.15 and virtualbox-guest-additions and dkms-vboxadditions at 5.0.16
Adding nomodeset to kernel command line here doesn't help with additions 5.0.16 but updating again to 5.0.20 and rebooting into kernel 4.1.15 with nomodeset does start X. The same thing with kernel 4.4.13 does too, so it does appear to be virtualbox not liking our X configuration.
Yeah, I will have to review all the changes between 5.0.16 and 5.0.22 to figure out where it breaks... I'm setting up a nVidia and an Amd testsystem to hopefully find the issue as I cant trigger it on my intel skylake system
Thanks for all the work here folks. Seems to be a particularly gnarly problem. Bless good ole M6 for behaving so well. :-))
I just booted my VM at home and it just worked without me having to do anything special (4.4.13 and 5.0.22 guest and host). The only thing I can think is maybe there's some kind of race condition between the kernel modules loading and X trying to start.
This works every time on both my i586 & x86_64 M5 Vbox clients: During the boot process select "Advanced options for Mageia" Type "e" for edit Scroll down to the "linux" line Key End to get to the end of the line add "nomodeset" to the end of the line ctrl-x or F10 will restart the boot process The M5 client will now boot to a working desktop The change is only temporary and "nomodeset" will need to be entered every time. Kudos to David.
*** Bug 18802 has been marked as a duplicate of this bug. ***
CC: (none) => bugzzzz
*** Bug 18256 has been marked as a duplicate of this bug. ***
CC: (none) => ghbdtn
Depends on: 18727 => (none)
Summary: After today's update M5 x86_64 KDE Vbox client would not boot => Mageia virtualbox guest does not start X
*** Bug 18990 has been marked as a duplicate of this bug. ***
CC: (none) => vigenmageia
Ran into this again where X is failing on x86_64, but working on i586. Workaround is to switch to kernel-server-latest (use right ctrl+f2 to switch to a terminal login) Comparing the modules loaded, and the order, I think this may be due to the i586 desktop kernel having CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m CONFIG_FB_SYS_FOPS=m while the x86 desktop kernel has CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_SYS_FOPS=y With the x86 desktop kernel, Xorg.0.log has the message (II) vboxvideo: kernel module found, not loading. followed by the msg (EE) no screens found(EE) This is with the 4.4.16-desktop-1.mga5 kernel on both guests. Just guessing as to the possible cause, as the "found, not loading" msg indicates to me, it's a module load order problem. Why it isn't happening to everyone is not clear to me.
CC: (none) => davidwhodgins
Information on this is somewhat anecdotal, but the root cause seems to be that the VBoxVideo X11 driver now includes support for modesetting, and is therefore incompatible with the old vboxvideo kernel module that also handles modesetting. So if the vboxvideo kernel module is loaded, the X server refuses to load the VBoxVideo driver. Setting the vboxvideo module parameter modeset=0 appears to solve this issue, and from my limited knowledge of VirtualBox, appears to result in no lost functionality (screen resizing still works). I've tried this on both 5.1 and my experimental 6sta2 Live ISOs. Blacklisting vboxvideo would probably also work, although I've not tried it. I don't know what the preferred way of fixing this is, but for the Live ISOs I propose to add a file in /etc/modprobe.d to set the vboxvideo parameter.
CC: (none) => mageia
commit 6f688832ece31330983de447383dc5b54925da92 Author: Martin Whitaker <mageia@...> Date: Sat Nov 12 11:52:49 2016 +0000 Fix for mga#18724 - set vboxvideo.modeset=0 in /etc/modprobe.d. This avoids a conflict between the VBoxVideo X11 driver and the vboxvideo kernel module which prevented X starting. --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=6f688832ece31330983de447383dc5b54925da92
Created attachment 8663 [details] Xorg.0.log from failed attempt to start X However, with latest updates, a freshly created mga6 client won't start X, even with my fix or with the nomodeset option. The error message is different, ending in [ 126.128] (EE) Fatal server error: [ 126.128] (EE) AddScreen/ScreenInit failed for driver 0 (full log attached). This failure appeared after I updated my local mirror of cauldron - previously updated 2-3 weeks ago.
commit 9ed3af28563ff8573221731402122d696195c3a6 Author: Martin Whitaker <mageia@...> Date: Sat Nov 12 11:52:49 2016 +0000 Fix for mga#18724 - set vboxvideo.modeset=0 in /etc/modprobe.d. This avoids a conflict between the VBoxVideo X11 driver and the vboxvideo kernel module which prevented X starting. (cherry picked from commit 6f688832ece31330983de447383dc5b54925da92) --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=9ed3af28563ff8573221731402122d696195c3a6
commit a80fd494f07288b87ad27fd4f670e1bc68b3c486 Author: Martin Whitaker <mageia@...> Date: Sun Dec 4 20:11:11 2016 +0000 Revert "Fix for mga#18724 - set vboxvideo.modeset=0 in /etc/modprobe.d." This reverts commit 9ed3af28563ff8573221731402122d696195c3a6. The kernel vboxvideo driver is now used instead of the X11 one. --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=a80fd494f07288b87ad27fd4f670e1bc68b3c486
Presumed fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 19951 has been marked as a duplicate of this bug. ***
CC: (none) => ch-hanisch
After the last update, it is impossible to start a graphical sessions in virtualbox. In /var/log/Xorg.0.log : (EE) open /dev/dri/card0: no such file or directory
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
The solution is the Installation of GuestAdditions from the Oracle-ISO.
same problem after updating guest additions to : virtualbox-guest-additions-5.1.10-3.mga6
This bug is still valid today, if you install Mageia 5 in a VirtualBox VM with default parameters, boot, do all updates, and reboot, you won't reach the DM as X fails to start. One workaround is to kill /etc/X11/xorg.conf to force a clean config. Increasing priority and severity, as I suspect it affects many users who want to try Mageia 5 and then just give up seeing how quickly it breaks.
Priority: Normal => HighSeverity: normal => major
I've been doing the "nomodeset" kernel option on booting an M5 Vbox client for so long it's become automatic for me.
My system works fine with: /etc/X11/xorg.conf # File generated by XFdrake (rev 262502) # ********************************************************************** # Refer to the xorg.conf man page for details about the format of # this file. # ********************************************************************** Section "ServerFlags" Option "DontZap" "False" # disable <Ctrl><Alt><BS> (server abort) AllowMouseOpenFail # allows the server to start up even if the mouse does not work #DontZoom # disable <Ctrl><Alt><KP_+>/<KP_-> (resolution switching) EndSection Section "Module" Load "v4l" # Video for Linux EndSection Section "ServerLayout" Identifier "layout1" EndSection
Not sure if this is related but I will post it here.. I found that with the dkms-vboxadditions package that vboxvideo driver does not get loaded like the other drivers after being built causing video to fail.. If you look in the post script for the dkms package in the src package virtualbox you will find it missing: 611 %post -n dkms-%{name} 612 set -x 613 /usr/sbin/dkms --rpm_safe_upgrade add -m %{name} -v %{version}-%{release} 614 if [ -z "$DURING_INSTALL" ] ; then 615 /usr/sbin/dkms --rpm_safe_upgrade build -m %{name} -v %{version}-%{release} && 616 /usr/sbin/dkms --rpm_safe_upgrade install -m %{name} -v %{version}-%{release} && 617 /sbin/rmmod vboxpci &>/dev/null 618 /sbin/rmmod vboxnetflt &>/dev/null 619 /sbin/rmmod vboxnetadp &>/dev/null 620 /sbin/rmmod %{kname} &>/dev/null 621 /sbin/modprobe %{kname} &>/dev/null 622 /sbin/modprobe vboxnetflt &>/dev/null 623 /sbin/modprobe vboxnetadp &>/dev/null 624 /sbin/modprobe vboxpci &>/dev/null 625 : 626 fi I am creating my own virtualbox rpm now to fix it.. if you would like a patch for the spec after my confirmation build I can do that.. If this is not related to this issue I can open a new one. Thanks.
CC: (none) => JMiahMan
Oops I posted the wrong section up there It should be... 650 %post -n dkms-vboxadditions 651 set -x 652 /usr/sbin/dkms --rpm_safe_upgrade add -m vboxadditions -v %{version}-%{release} 653 if [ -z "$DURING_INSTALL" ] ; then 654 /usr/sbin/dkms --rpm_safe_upgrade build -m vboxadditions -v %{version}-%{release} && 655 /usr/sbin/dkms --rpm_safe_upgrade install -m vboxadditions -v %{version}-%{release} 656 : 657 fi and there needs to be a similar line added as with dkms-virtualbox (posted above).. /sbin/modprobe vboxvideo &>/dev/null to make sure the module is loaded after build.
I understand this bug was only valid for Mageia 5. Closing as OLD, since Mga5 is no longer supported. Please reopen if it's still valid in a later Mageia version.
Status: REOPENED => RESOLVEDCC: (none) => marja11Resolution: (none) => OLD