Bug 893

Summary:	nouveau suddenly loading by default during boot - so nv can't load.
Product:	Mageia	Reporter:	Barry Jackson <zen25000>
Component:	RPM Packages	Assignee:	Anssi Hannula <anssi.hannula>
Status:	RESOLVED FIXED	QA Contact:
Severity:	critical
Priority:	High
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	drakx-kbd-mouse-x11	CVE:
Status comment:
Attachments:	Xorg.0.log Xorg.0.log /var/log/messages

Description Barry Jackson 2011-04-19 15:06:28 CEST

Description of problem:

Until today I was using nv because of bug 610, however now on a fully updated system the nouveau driver appears to be loaded during boot irrespective of what is in xorg.conf.
Nouveau also fails, so only vesa will now boot to a graphical desktop.

Attaching /var/log/Xorg.0.log

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Comment 1 Barry Jackson 2011-04-19 15:10:17 CEST

Created attachment 245 [details]
Xorg.0.log

Comment 2 Barry Jackson 2011-04-19 15:18:08 CEST

Created attachment 246 [details]
Xorg.0.log

Arrhhggg! - as a text file this time !

Barry Jackson 2011-04-19 15:18:55 CEST

Attachment 245 is obsolete: 0 => 1

Comment 3 Manuel Hiebel 2011-04-19 15:40:09 CEST

you can edit the mime type her: https://bugs.mageia.org/attachment.cgi?id=245&action=edit :)

Comment 4 Barry Jackson 2011-04-19 15:45:47 CEST

Created attachment 247 [details]
/var/log/messages

tail of messages for last session.
System has not been re-booted - this was taken from the drive using another system. (same for Xorg.0.log)
Both of these logs were during a reboot after setting driver to nv in drakx11.

Thanks - I didn't realize that field was editable!

Ahmad Samir 2011-04-20 02:15:04 CEST

Priority: Normal => High
Assignee: bugsquad => anssi.hannula
Source RPM: (none) => drakx-kbd-mouse-x11

Comment 5 Anssi Hannula 2011-04-20 02:26:41 CEST

Can you attach
/etc/X11/xorg.conf
/boot/grub/menu.lst
And the output of "display_driver_helper --is-kms-allowed; echo $?",
when the "nv" driver is configured?

Comment 6 Anssi Hannula 2011-04-20 02:28:30 CEST

Those are not needed after all, I've reproduced the issue.

Comment 7 Anssi Hannula 2011-04-20 02:36:11 CEST

Actually those are wanted after all,

I'm just so tired I misinterpreted the script output on my system :)

Comment 8 Barry Jackson 2011-04-20 02:47:35 CEST

Anssi - I must go to bed now but I have just put xorg.0.log and the full messages output of the last session on bug 596 when this still occurred after an update of 173 driver.
I will try to get the other info tomorrow - must sleep! :-/

Comment 9 Barry Jackson 2011-04-20 10:42:23 CEST

Anssi,
Short on time, but a quick heads-up.
On noticing your request for menu.lst it dawned on me that I don't use it normally, as I either boot directly from a separate grub2 boot partition, using vmlinuz and initrd.img, or use grub2 which is installed alongside grub legacy for testing.
On looking at menu.lst it does have nokmsboot set now in each command line which I assume is a new requirement for my hardware?
If I chainload into grub legacy and boot using menu.lst all is well and the new nvidia is working.

Barry

Comment 10 Barry Jackson 2011-04-20 12:12:32 CEST

Just for the record, after adding nokmsboot to /etc/defaults/grub and rebuilding grub2 grub.cfg, grub2 is booting again as normal.

Anssi I reckon it's resolved/invalid and my fault for booting abnormally. ;-)

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 11 Anssi Hannula 2011-04-20 13:12:45 CEST

Thanks for the heads-up.

I'm actually reopening this, as I think I can detect this situation (i.e. nokmsboot set in menu.lst but boot didn't happen with it anyway) and have a dialog appear about having to use nokmsboot :)

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Comment 12 Barry Jackson 2011-04-20 16:27:51 CEST

That would be good - as I'm sure I won't be the last. ;)

Comment 13 Anssi Hannula 2011-04-21 01:57:11 CEST

Fixed in harddrake 13.49 by showing a warning dialog during boot (with a 60s timeout) in this case.

Thanks for the report :)

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED