Description of problem: After the last update (~1200 packages), system fails to restart. It loops on messages : audit: type=1100 (or 1001) audit(...): pid=... uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_permit acct="sddm" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' I am running mga6 sta1 in a Virtualbox VM How reproducible: Every time I reboot Steps to Reproduce: 1. 2. 3.
Please add a "3" (without "") to the kernel options line in the grub boot menu, login as root, run updates again with urpmi --auto-update If there are errors about dependencies, then try again later until updating completes succesfully. After that, try whether you can then correctly restart your system again. If it still fails, then start it in runlevel 3 again (with the "3" at the end of the kernel options line) and then run, as root: journalctl -ab-1 > journal.txt and attach journal.txt to this bug report
Keywords: (none) => NEEDINFOCC: (none) => marja11
Created attachment 8958 [details] journalctl -ab-1 > journal.txt After urpmi --auto-update with success, start process still fails. Here is the result of journalctl -ab-1 > journal.txt
The audit messages are not related to the failure to boot. Those messages can be suppressed from the log by adding the kernel option audit=0. The bug appears to be the X server failing to start in the x86_64 virtualbox guest, causing sddm to fail. Try renaming the /etc/X11/xorg.conf to xorg.conf.old, in that guest. While it's not a nice workaround, it has worked in most cases. (press right ctrl key to get the guest to release the mouse, as without the xorg.conf the mouse integration does not work. There are a number of bugs open both for X failing to start in some situations, including under virtualbox. This is likely a duplicate of one of them, though I'm not sure which one. See https://bugs.mageia.org/show_bug.cgi?id=18724 for one of them, and as noted there, ensure the guest additions installed in the vb guest matches the vb version being used on the host.
CC: (none) => davidwhodgins
Created attachment 8960 [details] /var/log/Xorg.0.log I have tried renaming /etc/X11/xorg.conf to xorg.conf.old without success. So I add /var/log/Xorg.0.log. It seems that the module vboxvideo is required but not present. Where can I find it ?
Attachment 8960 mime type: application/x-trash => text/plain
From a Mageia 6 sta2 (qa version) Live x86_64 Plasma iso ... vboxadditions-kernel-4.9.4-desktop-2.mga6 The kernel version has to match. # urpmi vboxadditions-kernel-desktop-latest should pull in the correct version, assuming all updates have been installed.
I could not find Mageia 6 sta2 on the repositories. My configuration : # rpm -qa|grep kernel kernel-firmware-nonfree-20170113-2.mga6.nonfree vboxadditions-kernel-4.9.9-desktop-2.mga6-5.1.12-19.mga6 vboxadditions-kernel-4.9.8-desktop-2.mga6-5.1.12-17.mga6 kernel-desktop-4.9.9-2.mga6-1-1.mga6 vboxadditions-kernel-4.7.0-desktop-0.rc7.4.mga6-5.1.0-3.mga6 kernel-firmware-20170113-1.mga6 kernel-desktop-4.6.3-1.mga6-1-1.mga6 kernel-desktop-4.9.8-2.mga6-1-1.mga6 vboxadditions-kernel-desktop-latest-5.1.12-19.mga6 kernel-desktop-latest-4.9.9-2.mga6 kernel-desktop-4.7.0-0.rc7.4.mga6-1-1.mga6
Sorry I haven't been back to this one sooner. The only other thing I can think of, is to try installing kernel-desktop-devel-latest and the latest updates, and then rebooting.
Summary: System loops with messages "audit: type=1100 or 1001..." at start up => X fails to start in Mageia 6 x86_64 virtualbox guest
Thanks, Dave, for your help! Assigning this bug to the kernel and drivers maintainers, even if the problem might be in virtualbox itself :-/ However, tmb (virtualbox maintainer) will now see it, too.
Assignee: bugsquad => kernel
I installed the last updates but it doesn't work. I think that there is something wrong in the updates of the last months because I have a snapshot before these updates that works perfectly
Hi, thanks for reporting this bug. We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to RESOLVED:OLD
Resolution: (none) => OLDStatus: NEW => RESOLVED