Two days ago, I got and installed an update for the kernel-server package (3.14.27 instead of the installed 3.14.24). Now my machine can no longer boot. It fails with: [FAILED] Failed to start Wait for Plymouth Boot Screen to Quit. See 'systemctl status plymouth-quit-wait.service' for details. I restarted my machine to boot using 3.14.24 and it works. So this is a regression in 3.14.27. The command above says nothing useful, because in order to run it, I have to reboot my machine using the older kernel, and so the old error message is gone.
can you attach the part of the "journalctl -a" output (as root) from the time when you were booting with kernel-server-3.14.27 ?
CC: (none) => marja11, tmb
Created attachment 5797 [details] output of journalctl
are you using nvidia304 or nvidia-current drivers ?
# rpm -q -a | grep nvidia nvidia-current-kernel-3.14.24-server-1.mga4-331.79-12.mga4.nonfree nvidia-current-doc-html-331.113-1.mga4.nonfree nvidia-current-kernel-3.14.27-server-1.mga4-331.113-1.mga4.nonfree x11-driver-video-nvidia-current-331.113-1.mga4.nonfree dkms-nvidia-current-331.113-1.mga4.nonfree nvidia-current-kernel-server-latest-331.113-1.mga4.nonfree
Ok, so you are possibly hitting a nvidia update timing issue... 1. Boot into the working kernel 2. open console 3. su - root 4. depmod -a 3.14.27-server-1.mga4 5. reboot. does it work now ?
I had exactly the same problem. The depmod thing fixed it. Thanks for that. Here's my nvidia rpm info: rpm -q -a | grep nvidia nvidia304-kernel-server-latest-304.125-1.mga4.nonfree nvidia304-kernel-3.14.27-server-1.mga4-304.125-1.mga4.nonfree dkms-nvidia304-304.125-1.mga4.nonfree nvidia304-doc-html-304.125-1.mga4.nonfree nvidia304-kernel-3.12.21-server-2.mga4-304.119-12.mga4.nonfree x11-driver-video-nvidia304-304.125-1.mga4.nonfree nvidia304-kernel-3.14.18-server-3.mga4-304.121-3.mga4.nonfree nvidia304-kernel-3.12.25-server-3.mga4-304.119-15.mga4.nonfree nvidia304-kernel-3.14.24-server-1.mga4-304.121-7.mga4.nonfree
CC: (none) => aja
*** Bug 14998 has been marked as a duplicate of this bug. ***
CC: (none) => mageia.bugzilla
(In reply to Thomas Backlund from comment #5) > 4. depmod -a 3.14.27-server-1.mga4 > 5. reboot. > > does it work now ? Yes, now it works. Thanks!
*** Bug 15047 has been marked as a duplicate of this bug. ***
CC: (none) => ole.reier
Exact same symptoms as bug 15047 and 14990 RPM loading Kernel dkms-nvidia-current - NVIDIA kernel module for GeForce 8xxx and later cardsâ nvidia-current-kernel-desktop-latest - Virtual rpm for latest nvidia-current-kernel-desktop driverâ nvidia-current-kernel-3.14.27-desktop-1.mga4 - nvidia-current driver for kernel-desktop-3.14.27-1.mga4â  x11-driver-video-nvidia-current - NVIDIA proprietary X.org driver and libraries for GeForce 8xxx and later cardsâ  [root@localhost fred]# rpm -q -a | grep nvidia dkms-nvidia-current-331.113-1.mga4.nonfree nvidia-current-kernel-desktop-latest-331.113-1.mga4.nonfree x11-driver-video-nvidia-current-331.113-1.mga4.nonfree nvidia-current-doc-html-331.113-1.mga4.nonfree nvidia-current-kernel-3.14.23-desktop-1.mga4-331.79-11.mga4.nonfree nvidia-current-kernel-3.14.27-desktop-1.mga4-331.113-1.mga4.nonfree nvidia-current-kernel-3.14.24-desktop-1.mga4-331.79-12.mga4.nonfree [root@localhost fred]# Videocard is detected as Identification Vendor: âNVIDIA Corporation Description: âGF106 [GeForce GTS 450] Media class: âVGA compatible controller Connection Bus: âPCI Express PCI domain: â0 Bus PCI #: â1 PCI device #: â0 PCI function #: â0 PCI revision: â0xa1 Vendor ID: â0x10de Device ID: â0x0dc4 Sub vendor ID: â0x1043 Sub device ID: â0x8366 Misc Module: âCard:NVIDIA GeForce 400 series and later Apply proposed solution for hitting a nvidia update timing issue... 1. Boot into the working kernel 2. open console 3. su - root 4. depmod -a 3.14.27-desktop-1.mga4 5. reboot. Used console command shutdown now -r Result success Then without repeating the console command Used normal dektop shutdown and then did a cold startup, using the grub default kernel (which is 3.14.27-desktop-1.mga4) booted to the logon screen. Result Success. Does the depmod command need to be run only once following the installation of kernal 27 to fix the timing issue?
CC: (none) => fred.saalbach
(In reply to Fred Saalbach from comment #10) > Does the depmod command need to be run only once following the installation > of kernal 27 to fix the timing issue? Yes! @tmb: is an updated kernel going to be released to fix this issue?
There is currently an update to the 3.14.29 kernel version in Testing. I guess the problem is fixed in that version. You should try these packages to see if the problem is fixed.
CC: (none) => olivier.delaune
It's not a kernel issue. It's when dkms installs the prebuilt kmods the depmod sometimes fails... I have changed the "dkms install" commands in the prebuilt mods to be called later by switching the calls from %post to %posttrans to hopefully fix this
Question from Comment 10: "1. Boot into the working kernel" That means in my cases the 3.14.24 kernel, is that what you mean? In that case, the problem is not solved by this procedure, the boot of desktop 3.14.27 keeps failing.
CC: (none) => herman.viaene
Did the depmod command again on the problem machine. Found out there was a problem with the remote control of the machine (different language set) and in this way the command was corrupt. With the correct command the problem is now solved.
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
I never saw this problem again since 3.14.27 so I guess tmb's fix from comment 13 did the trick.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME