Mageia forum

The latest update to kernel 3.12.21 appears to result in a broken X server, apparently due to a problem with Nvidia driver -- at least on the one machine on which I have applied the update. The boot process throws up an error

Failed to start Wait for Plymouth Boot Screen to Quit

And after a some more messages just hangs at "Reached target Graphical Interface". Logging in in tty2 and starting the X server results in

modprobe: ERROR: could not insert 'nvidia_current': Unknown symbol in module, or unknown parameter (see dmesg)

Is anybody else having the same problem? And what's the simplest way of fixing this?

Applied the indicated updates (Kernel, NVidia, Virtualbox, etc.) this morning. Unfortuately encountered the same "BROKEN" boot/initiation result, where NO system activation occurs; just hangs until reboot.

Had to regress to last Kernel install and everything booted/initiated AOK. This latest set of updates did BREAK things...!

Yes, just re-pointing the symbolic links in /boot to 3.12.20 does the trick.

x86-64 desktop

from journal

Code: Select all

Jun 18 19:29:21 Williams kernel: Kernel command line: BOOT_IMAGE=linux_Mageia4 root=UUID=ef1306a0-6e2b-497f-b27c-d7aad62e1c86 nokmsboot splash quiet  resume=UUID=1ad37ac4-2e28-46d8-8153-33f60e72c43f vga=788
...
Jun 18 19:29:21 Williams kernel: Linux version 3.12.21-desktop-2.mga4 (iurt@ecosse.mageia.org) (gcc version 4.8.2 (GCC) ) #1 SMP Thu Jun 5 21:33:44 UTC 2014
...
Jun 18 19:29:42 Williams kdm[1905]: X server died during startup


x11-driver-video-nvidia-current 331.79
nvidia-current-kernel-desktop-latest 331.79
dkms-nvidia-current 331.79

have tried XFdrake

have reverted to kernel 3.12.20

normally boot with acpi=off. Makes no difference with this problem.

Cheers

Is anybody else having the same problem?

Yes. I have.

And what's the simplest way of fixing this?

Simplest way is to use 3.12.20 while troubles with 3.12.21 are not fixed =)

Please report problem to bug-tracker. You can comment already created bug https://bugs.mageia.org/show_bug.cgi?id=13547 or create new and it will be marked as duplicate (or #13547 will be marked as duplicate of yours )

xxblx

Thank you for the link. That is the problem I am seeing.

edit doktor5000: merged into existing forum thread

Have added my bit to the bug report -- thanks.

As for backing out... I don't think it is entirely obvious that just reverting the symbolic links in /boot would be sufficient. It wasn't obvious to me, anyway. Reason being that (a) it was nvidia-current that was blowing up, which was presumably 3.12.21 specific, so backstepping to the previous version seemed also indicated (I don't know how nvidia-current works); (b) in my case the update involved considerably more than just the kernel, so there may have been dependencies. My initial response was not to risk making things worse.

Which really brings up a more general issue. Say an automatic update is applied and things get seriously broken in some way. Is there a simple way of backing out of that last automatic update?

I've had to roll back more than once. This mechanism makes it simple and quick.

viewtopic.php?f=41&t=5957

Sure. I used to run rsnapshot, though I've replaced it now with a combination of btrfs snapshots and a daily rsync. But rolling back the whole of / on a running system seems a bit excessive (as well as a bit rash ). I was hoping for something like urpmi -- backout.

I have the same problem on my new workstation - Glad I found this support page.

Problem not solved yet – I am new to Linux.

mla wrote:Yes, just re-pointing the symbolic links in /boot to 3.12.20 does the trick.

But .. How .. step by step please - for newcomers.

I, too, am experiencing this issue.

Just selecting the previous kernel at the grub screen worked for me. I didn't have to modify /boot. My links in /boot are all still pointing to the 3.12.21 kernel.

kaj1jensen wrote:I have the same problem on my new workstation - Glad I found this support page.

Problem not solved yet – I am new to Linux.

mla wrote:Yes, just re-pointing the symbolic links in /boot to 3.12.20 does the trick.

But .. How .. step by step please - for newcomers.

First of all. Try to load Mageia with 3.12.20. On boot menu choose "desktop 3.12.20-1.mga4" or "server 3.12.20-1.mga4" (server if you use kernel-server).
If Ok you may just to use that menu item for system loading.

If you want to use "Boot Mageia 4" for loading with kernel 3.12.20 then you need to modify symlinks in /boot. But I don't recommend to you it.

If you want to do anyway (whatever you do - do at your own risk).
Do

Code: Select all

ls /boot

Output will look like

Code: Select all

[xxblx@localhost ~]$ ls /boot
boot.backup.sda                   symvers-3.12.18-server-1.mga4.xz
config-3.12.13-server-2.mga4      symvers-3.12.20-server-1.mga4.xz
config-3.12.18-server-1.mga4      symvers-3.12.21-server-2.mga4.xz
config-3.12.20-server-1.mga4      symvers-3.12.8-server-2.mga4.xz
config-3.12.21-server-2.mga4      symvers-3.12.9-server-1.mga4.xz
config-3.12.8-server-2.mga4       System.map-3.12.13-server-2.mga4
config-3.12.9-server-1.mga4       System.map-3.12.18-server-1.mga4
dracut/                           System.map-3.12.20-server-1.mga4
gfxmenu*                          System.map-3.12.21-server-2.mga4
grub/                             System.map-3.12.8-server-2.mga4
initrd-3.12.13-server-2.mga4.img  System.map-3.12.9-server-1.mga4
initrd-3.12.18-server-1.mga4.img  vmlinuz@
initrd-3.12.20-server-1.mga4.img  vmlinuz-3.12.13-server-2.mga4
initrd-3.12.21-server-2.mga4.img  vmlinuz-3.12.18-server-1.mga4
initrd-3.12.8-server-2.mga4.img   vmlinuz-3.12.20-server-1.mga4
initrd-3.12.9-server-1.mga4.img   vmlinuz-3.12.21-server-2.mga4
initrd.img@                       vmlinuz-3.12.8-server-2.mga4
initrd-server.img@                vmlinuz-3.12.9-server-1.mga4
symvers-3.12.13-server-2.mga4.xz  vmlinuz-server@

Attention to vmlinuz@, vmlinuz-server@ and initrd.img@, initrd-server.img@. Symbol "@" mean that they are symbolic links.
I have vmlinuz-server@ and initrd-server.img@ because using kernel-server. You may have vmlinuz-desktop@ and initrd-desktop.img@. Check it. It's important.

What you need:
- backup /boot
- remove old symlinks
- create new symlinks

1. Be a superman Be a superuser

Code: Select all

su
<enter root-password>

2. Backup /boot (backup will be saved in your user's /home)

Code: Select all

cp -r /boot /home/<your_username>

Note: Use absolute path for user's home dir like /home/user, /home/john, /home/vasya, etc. Don't use ~/ or $HOME/ in this command! You are root! Root's home dir (~/ or $HOME) is a /root.
3. Go to /boot

Code: Select all

cd /boot

4. Remove symlinks

Code: Select all

rm -rf vmlinuz vmlinuz-server initrd.img initrd-server.img

Note: you may have not "-server", you may have "-desktop" for example.
5. Create new symlinks

Code: Select all

ln -s initrd-3.12.20-server-1.mga4.img initrd.img
ln -s initrd-3.12.20-server-1.mga4.img initrd-server.img
ln -s vmlinuz-3.12.20-server-1.mga4 vmlinuz
ln -s vmlinuz-3.12.20-server-1.mga4 vmlinuz-server

6. Reboot. Try to load by "Boot Mageia 4" item from boot menu.
If all broken - move boot dir from backup (/home/your_user/boot) to /boot.

Kernel/nvidia driver testing is one of those complex areas where the QA team, of which I am a member, does not have
enough people participating to verify workability everywhere. We are reaching out to the Mageia users to partcipate in the
QA updates testing. Even more complex to this is a platform such as mine which is 64-bit kernel / nvidia / Virtualbox.
All of these are moving parts and when an update comes alone to any one of these I usually have to put aside the better
part of a weekend to process the testing. Please do consider participating in the QA team even if it's just to work on
specific parts like nvidia. Thanks.

Note my test platform:

Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
Mageia 4 64-bit, Nvidia driver
virtualbox-4.3.10-1.1.mga4.x86_64
virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64

works just fine with the latest Kernel/nvidia/Vbox updates

Looking at GNU GRUB version 2.00 I can only select Mageia or Advanced options for Mageia - no version 3.12.20.

xxblx wrote:

kaj1jensen wrote:I have the same problem on my new workstation - Glad I found this support page.

Problem not solved yet – I am new to Linux.

mla wrote:Yes, just re-pointing the symbolic links in /boot to 3.12.20 does the trick.

But .. How .. step by step please - for newcomers.

First of all. Try to load Mageia with 3.12.20. On boot menu choose "desktop 3.12.20-1.mga4" or "server 3.12.20-1.mga4" (server if you use kernel-server).
If Ok you may just to use that menu item for system loading.

If you want to use "Boot Mageia 4" for loading with kernel 3.12.20 then you need to modify symlinks in /boot. But I don't recommend to you it.

In addition I can select Manjaro but it did break down the same way last year - updating the Kernel.
Gnu Grub is from the Manjaro installation last year and functioned fine with both Manjaro and mageia until Manjaro died.

I continued with only Mageia without problems so far - even the major upgrade from version 3 to 4 were without problems.
The editor in GNU GRUB shows no trace of 3.12.20 - so I will wait for more advice here and probably try to do modifications on the hard drive - the hard way.
The tool box Parted Magic works fine from a CD disk and the now dead Manjaro on a separate disk can be replaced with a second Linux.

As a Newcomer to Linux I do not yet know the filenames and locations of my e-mails and browser links - so a lot of work ahead to move them "the hard way".

kaj1jensen wrote:The editor in GNU GRUB shows no trace of 3.12.20 - so I will wait for more advice here and probably try to do modifications on the hard drive - the hard way.

I think that the reason is boot loader from manjaro. AFAIK, Manjaro use Grub2.
Mageia 4 default boot loader is a Grub Legacy. When new kernels installed, new items with it automatically adding to /boot/grub/menu.lst by default. If your system don't add new items to menu.lst then look like it's because you use third party boot loader.

kaj1jensen wrote:Looking at GNU GRUB version 2.00 I can only select Mageia or Advanced options for Mageia - no version 3.12.20.

If you select Advanced Options are you not presented with a second menu that includes other installed kernels? I don't use Grub2 but IIRC that is what happened when I tested it some time ago.

Jim

French users had success with :

Code: Select all

urpme -a nvidia
 urpmi nvidia

and MrsB indicates that it is probably a problem with dkms which doesn't detect that a new kernel is present and doesn't build the new driver. She recommands to install
nvidia-current-kernel-{desktop586,desktop,server}-latest
according to which kernel you have.

No option for version 3.12.20 as the GNU Grub 2.00 is from Manjaro (bad luck) but a door do open.

jkerr82508 wrote:

kaj1jensen wrote:Looking at GNU GRUB version 2.00 I can only select Mageia or Advanced options for Mageia - no version 3.12.20.

If you select Advanced Options are you not presented with a second menu that includes other installed kernels? I don't use Grub2 but IIRC that is what happened when I tested it some time ago.

Jim

Advanced options has 1. linux - 2. linux-nonfb - 3. failsafe
1. OK for 2 seconds. The blue screen with Mageia logo shows up. Then boot lines as below under 2.
2. Boot lines over the screen but hangs at "Reached target Graphical Interface"
ctrl+alt+delete to get back to start.
3. Boot lines as in 2 but the system ask for a: control-D to continue or b: root password.
a: control-D The system hangs as in 2.
b: Password opens a new line: [root@localhoast~]# _
This may be the way to instruct the system - so I am reading your suggestions before I go further into "the minefield" as I am new to Linux.

papoteur wrote:French users had success with :

Code: Select all

urpme -a nvidia
 urpmi nvidia

and MrsB indicates that it is probably a problem with dkms which doesn't detect that a new kernel is present and doesn't build the new driver. She recommands to install
nvidia-current-kernel-{desktop586,desktop,server}-latest
according to which kernel you have.

Typing urpme -a nvidia
gave the answer: To satisfy dependences the following 12 packages will be removed (173MB)
- - - nvidia-current-kernel-3.10.24-server - - - - -
Remove 12 packages ? (y/N) - - - do I dare to "pull the trigger".

In the bugzilla thread https://bugs.mageia.org/show_bug.cgi?id=13547 rexy gives a simple and effective work-around which does not involve going back to 3.12.20. Having now successfully used it on all my machines, I can confirm that it is fully effective:

Boot to 3.12.21 and wait for it to hang.
Open a tty console (e.g. Ctrl-Alt-F2) and login as root and issue these commands:
urpme dkms-nvidia-current
urpmi dkms-nvidia-current
reboot

Тhe urpmi command will take a while rebuilding the module -- just wait for it to complete. Essentially, the update process fails to build the module, and the above sequence forces it to be built.

It would appear that the problem is only experienced on machines which have VirtualBox installed. If it is not istalled, the module builds automatically as it should.

I have had troubles like this for earlier kernel upgrades as well. After some expert guidance from doktor5000 I do the following for all nvidia machines.
It is a bit drastic because it removes one of the leaves on the dkms tree so reverting to an earlier kernel might be a problem (?)

Logout and reboot...
When the "reached graphical target interface" message appears AltCtrlF2 to a console login. Login as root or self and then su root.

Code: Select all

$ urpme dkms-nvidia-current


to remove the driver built on the earlier kernel...
Then invoke XFdrake (drakx11) and select the appropriate driver and reply "yes" to use latest proprietary driver. This starts the process of downloading the needed RPMs and the rebuilding of the nvidia driver against the current kernel.
Reboot again and all should be well. Note that I do not use VirtualBox.

Darn. I have just noticed that mia posted the same solution, albeit even simpler.
However, I would point out that the fault (dkms not swinging into action at reboot after new kernel upgrade) affected several previous upgrades going back to kernel 3.12.8.

Thanks Mia, I can confirm that this worked for me and is probably the best workaround in this situation. I also have VirtualBox Installed.

Code: Select all

Boot to 3.12.21 and wait for it to hang.
Open a tty console (e.g. Ctrl-Alt-F2) and login as root and issue these commands:
urpme dkms-nvidia-current
urpmi dkms-nvidia-current
reboot

Тhe urpmi command will take a while rebuilding the module -- just wait for it to complete. Essentially, the update process fails to build the module, and the above sequence forces it to be built.

I have just installed mga4 on a new machine via a USB stick and have lost nvidia after the upgrade from kernel 3.12.8 to 3.12.25 so am stuck with 3.12.8. The former neat solution at console level during the boot sequence cannot be followed because Ctrl/Alt/F2 no longer works on this machine and maybe never did. That really is a deal-breaker. What could prevent the key sequence from working? Maybe this would be better in another thread but the nvidia problem is what needs solving.