[Workaround] System hangs after updates this morning

[mrambo3501]

The notifier on the taskbar indicated there were updates this morning which I let it install. I think were there a couple dozen of them including cpupower, a bunch of mariadb pkgs, and notably, a new kernel 3.12.13 and nvidia driver packages. Upon reboot immediately after the update I saw a plymouth error and no graphical desktop. Since then, with full poweroff/poweron reboots the system (actually just ctrl-alt-f1) hangs trying to start Avahi with the message...

[** ] A start job is running for Avahi mDNS/DNS-SD stack (the two asterisks are in varying shades of red)

Although it hangs ctrl-alt-f1 at this point I can log in ctrl-alt-f2. I tried to find the exact list of pkgs it installed this morning but if the list exists I couldn't find it.

Rebooting using the old 3.12.9-1 kernel pauses briefly at the Avahi startup but then goes on all the way to "[OK] Reached target Graphical Interface" - except that there is no graphical interface present. ctrl-alt-f2 does still work.

I suspect something with the nvidia driver with or without contribution by the new kernel but I don't really know what to do about it.

Suggestions are appreciated. Thanks.

[mrambo3501]

I have found that changing from the nvidia to the nouveau driver via XFdrake will boot to the graphical desktop. Apparently the hang at avahi was only when I hit the tab button to watch boot messages for some reason. I still see warnings about possible conflicts with a kernel driver but it does boot to the desktop. It isn't right yet though. I should be able to use the nvidia driver as I was before this mornings package updates.

Still open to suggestions .

[doktor5000]

Can you please show the output of

Code: Select all

rpm -qa | grep -e kernel -e nvidia | sort

[mrambo3501]

Here it is.

Code: Select all

dkms-nvidia-current-331.49-1.mga4.nonfree
kernel-desktop-3.12.13-2.mga4-1-1.mga4
kernel-desktop-3.12.9-1.mga4-1-1.mga4
kernel-desktop-devel-3.12.13-2.mga4-1-1.mga4
kernel-desktop-devel-3.12.9-1.mga4-1-1.mga4
kernel-desktop-devel-latest-3.12.13-2.mga4
kernel-desktop-latest-3.12.13-2.mga4
kernel-firmware-20131013-2.mga4
kernel-firmware-nonfree-20140119-1.mga4.nonfree
kernel-userspace-headers-3.12.13-2.mga4
nvidia-current-doc-html-331.49-1.mga4.nonfree
nvidia-current-kernel-3.12.13-desktop-2.mga4-331.49-2.mga4.nonfree
nvidia-current-kernel-3.12.9-desktop-1.mga4-325.15-7.mga4.nonfree
nvidia-current-kernel-desktop-latest-331.49-2.mga4.nonfree
x11-driver-video-nvidia-current-331.49-1.mga4.nonfree


Thanks.

[doktor5000]

Looks ok. Can you please do the following - boot into kernel 3.12.13-2.mga4 with nvidia driver selected via drakx11 (XFdrake) and when it hangs then login via ctrl-alt-f2 and copy away /var/log/Xorg.0.log and afterwards please attach that file here.

[mrambo3501]

Here is the log file. This is with kernel 3.12.13 and the GeForce 8100 to GeForce 360 driver loaded. This is the driver XFdrake auto selects.

In case it helps here is the graphics card related part of lspci -vv.

Code: Select all

        01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 310] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: NVIDIA Corporation Device 0733
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at b0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at ce000000 (64-bit, prefetchable) [size=32M]
        Region 5: I/O ports at cc00 [size=128]
        [virtual] Expansion ROM at c0000000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [78] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <4us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [b4] Vendor Specific Information: Len=14 <?>
        Capabilities: [100 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
        Capabilities: [128 v1] Power Budgeting <?>
        Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Kernel driver in use: nouveau
        Kernel modules: nvidiafb, nouveau, nvidia_current


Thanks.

[doktor5000]

Just what I thought, there's an issue loading the nvidia kernel module:

[ 38.878] (II) NVIDIA(0): Creating default Display subsection in Screen section
"screen1" for depth/fbbpp 24/32
[ 38.878] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
[ 38.878] (==) NVIDIA(0): RGB weight 888
[ 38.878] (==) NVIDIA(0): Default visual is TrueColor
[ 38.878] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[ 38.879] (**) NVIDIA(0): Option "AddARGBGLXVisuals"
[ 38.879] (**) NVIDIA(0): Enabling 2D acceleration
[ 38.885] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the
[ 38.885] (EE) NVIDIA(0): system's kernel log for additional error messages and
[ 38.885] (EE) NVIDIA(0): consult the NVIDIA README for details.
[ 38.885] (EE) NVIDIA(0): *** Aborting ***
[ 38.885] (EE) NVIDIA(0): Failing initialization of X screen 0
[ 38.885] (II) UnloadModule: "nvidia"
[ 38.885] (II) UnloadSubModule: "wfb"
[ 38.885] (II) UnloadSubModule: "fb"
[ 38.885] (EE) Screen(s) found, but none have a usable configuration.
[ 38.885] (EE)
Fatal server error:
[ 38.885] (EE) no screens found(EE)
[ 38.885] (EE)
Please consult the The X.Org Foundation support
at http://bugs.mageia.org
for help.
[ 38.886] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 38.886] (EE)
[ 38.919] (EE) Server terminated with error (1). Closing log file.

Please repeat the process, but attach the following log here. As root run

Code: Select all

journalctl -axb > boot.txt

Also attach your /etc/X11/xorg.conf and the output of the following command

Code: Select all

cat /proc/cmdline

[jiml8]

I would bet this system has been using the nvidia driver from their website. In this event, it needs to be reinstalled using the nvidia installer.

[Trex78]

Hello,

It seems I have a similar problem : after updating kernel and nvidia stuff yesterday (I didn't use this computer sice about two weeks), X server fails to start.
Back to "nouveau" in xorg.conf, all is normal again.
Worked well before this update (and no, I didn't use driver from nvidia website, only official rpms).

Mageia 4 64 bits on Samsung R530 laptop.

I join a zip file with all elements already asked to the original poster. (I can open a new thread if it's better than joining this one).

Thanks.

[mrambo3501]

Attached are the three items requested. There was a question about the source of the nvidia driver being used. The kernel and drivers are all obtained directly from the mageia repositories using urpmi and related tools.

Here is the output of cat /proc/cmdline...

Code: Select all

BOOT_IMAGE=linux root=UUID=7f279179-e61a-4607-8702-275b20da5c3e splash quiet nokmsboot resume=UUID=5de6f806-ba33-4660-8967-5a1dee2d2c55 vga=788


Hope this means more to you than to me. I didn't see much there.

Thanks.

[doktor5000]

@mrambo3501

Also attach your /etc/X11/xorg.conf

[Trex78]

Looks like it's bug 12893 :
https://bugs.mageia.org/show_bug.cgi?id=12893

I tried the bypass given in th thread: remove all nvidia packages, then reselect proprietary driver.
MCC reinstalls all nvidia stuff, and everything works again.

Certainly something missing during the kernel updates.

[mrambo3501]

So sorry. I misread your request. xorg.conf is attached.

I saw the note from trex but will wait awhile before I try whatever is in the bug just in case there is something still on my system that could help with resolution.

Thanks.

[doktor5000]

xorg.conf looks normal.
Best bet is what Trex78 proposed, remove all nvidia packages and reinstall nvidia driver. I've seen that issue before,
usually the conflict was between the nvidia-*-kernel packages which contains the prebuilt binary kernel modules,
and the installed dkms-nvidia packages which compile the driver once a new kernel is detected.

As a result, I usually only install the dkms-nvidia package.

drakx11 will install both, so when you only want to use dkms-nvidia, remember when you run drakx11 it will install the nvidia-*-kernel packages which may not be wanted.

This is what I've currently installed:

Code: Select all

[doktor5000@Mageia4 ~]$ rpm -qa | grep nvidia
x11-driver-video-nvidia-current-331.49-1.mga4.nonfree
dkms-nvidia-current-331.49-1.mga4.nonfree

[mrambo3501]

Well, I have gotten it to work on the nvidia driver. But it isn't very pretty. I removed all the nvidia-*-kernel-* packages but as soon as you try to use XFdrake to set up the proprietary driver it just reinstalls them all over again to the same end as before. The way I used to work around the problem was to set up the nvidia driver with XFdrake but don't reboot until you manually go in and uninstall the nvidia-*-kernel-* packages again. After that you can reboot and all is well. But I do wonder if this will be revisited every time there is a package update in this area. It looks to me like something... perhaps XFdrake... has some incorrect dependencies or something - but heck if I know.

In any case, I know how to work around this now but I do wonder about the folks who will be turned off to mageia since this bug will definitely kill their system.

[doktor5000]

That is what I just described previously.

It's not a bug, it works as designed, there are only really rare cases where it doesn't work as it should. And not, XFdrake doesn't have incorrect dependencies, and no the packages won't come back with an update.

[mrambo3501]

As a result, I usually only install the dkms-nvidia package.

drakx11 will install both, so when you only want to use dkms-nvidia, remember when you run drakx11 it will install the nvidia-*-kernel packages which may not be wanted.

It's not a bug, it works as designed, there are only really rare cases where it doesn't work as it should. And not, XFdrake doesn't have incorrect dependencies, and no the packages won't come back with an update.

Yes, I saw the description and it is as you described. The hard part is that it is intended that way. You're talking about something that breaks working systems. This system started with mga3 and upgraded to mga4 without difficulty. Then, a couple of weeks after the upgrade, a *normal* *system* *update* comes along which leaves it with a dead X configuration - and it is supposed to be this way? Moreover it is then "not a bug" when it "only rarely " doesn't work as it should. Geez, you have two people who hit this in this forum thread and a third one in the referenced bug 12893. I am glad to know, or have reason to hope, that a future update will not trigger this again but I also know for certain that, barring changes, if I ever use XFdrake to change around the driver for any reason it most certainly WILL come back to this situation again should I forget to remove the three packages that XFdrake automatically installs, I have no option to avoid installing, and which result in a broken system if I forget to remove then after installation.

You mentioned in the first quote that I may not want both. How was I supposed to know that? How was I supposed to choose otherwise when the updater automatically installed the update? I didn't make a choice in this regard or have any idea that it "may not be wanted" at all. I had a working system and applied an update. There was no choice offered to me. Update, reboot, broke.

I do not agree with your characterization of the situation - but hey - you guys build it. We either use it or not.

That said, I thank you and Trex78 for the time you each spent looking for a resolution.

Thanks.

[doktor5000]

Then, a couple of weeks after the upgrade, a *normal* *system* *update* comes along which leaves it with a dead X configuration - and it is supposed to be this way? Moreover it is then "not a bug" when it "only rarely " doesn't work as it should. Geez, you have two people who hit this in this forum thread and a third one in the referenced bug 12893. I am glad to know, or have reason to hope, that a future update will not trigger this again but I also know for certain that, barring changes, if I ever use XFdrake to change around the driver for any reason it most certainly WILL come back to this situation again should I forget to remove the three packages that XFdrake automatically installs, I have no option to avoid installing, and which result in a broken system if I forget to remove then after installation.

You mentioned in the first quote that I may not want both. How was I supposed to know that? How was I supposed to choose otherwise when the updater automatically installed the update? I didn't make a choice in this regard or have any idea that it "may not be wanted" at all. I had a working system and applied an update. There was no choice offered to me. Update, reboot, broke.

I do not agree with your characterization of the situation - but hey - you guys build it. We either use it or not.

You're totally correct. You should not need to know about the differences between the two packages, and you're not supposed to know about them in the first place.
AND they should simply "just work" ™ and don't break on updates.

Feel free to comment on the bug report. It did break only for really few users, and most users workarounded the issue instead of trying to get it fixed. Addditionally the problem is that this is not easily reproducable, which is an issue as that way the packagers cannot fix it properly.

So as much as I'd like to fix it, I don't really know what to fix

[mrambo3501]

Feel free to comment on the bug report. It did break only for really few users, and most users workarounded the issue instead of trying to get it fixed. Addditionally the problem is that this is not easily reproducable, which is an issue as that way the packagers cannot fix it properly.

Done on the bug report.

And FWIW, my system at present can reproduce this every time. I even have two more of this exact same system/video card combination that my kids use and which I have not updated yet. If you have something to you want to test I'd be willing give it a shot.

[doktor5000]

I'll try to discuss this with the maintainer of the nvidia packages and will ping you back if I've got something.