Summary: I am running with a Matrox mga450 dual headed monitor card with two monitors. (I normally run with Xinerama) A recent emerge --deep --update installed sys-fs/udev-103. On reboot, when udev starts, things go horribly south. The system says it is starting udev, and just after the message "letting udev process events" (or something similar to that), * the console goes blank, * then displays a random colored pattern, and * and in some case the boot freezes. * In other cases, the pattern changes to a second pattern one or two seconds later, and * the boot continues, but the console displays nothing more, and is useless. Since this is workstation the system is rendered useless. This was discussed and a work-around provided (mask >=sys-fs/udev-087-r1 in /etc/portage/package.mask) in the following thread on gentoo-forums: http://forums.gentoo.org/viewtopic-p-3799419.html I am willing will to test a fixed version of this package. But, I would appreciate a description what was determined to be wrong, and the fix, before I do. I would NOT update the live CD or the stage3 tar ball with this version of udev, or there will be problems for folks doing installations. (there already are, if they follow the instructions installation instructions doing: emerge --sync && emerge --update At least, with the current stage3 tar ball, the system will boot. Output of emerge --info, dmesg, and kernel config will be attached.
Created attachment 104605 [details] emerge --info output
*** Bug 158862 has been marked as a duplicate of this bug. ***
Created attachment 104606 [details] dmesg output (describes hardware) (after down grading to udev-087
Created attachment 104607 [details] kernel configuration
I think your only problem is having the matrox-framebuffer-module in your kernel-config and not loading it. Newer udev-versions with enabled coldplug (/etc/conf.d/rc:RC_COLDPLUG=yes) try to load that module and *bang*. Just delete that module or blacklist it, or disable COLDPLUG. Then please add a comment on this bug.
This bug could be related: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195761#c9
I think this bug is rather a kernel, and no udev issue. Reading the Redhat-Bug, this adding this to a file in /etc/modules.d/... could solve it: install matrox_w1 /bin/true Please comment if this works.
I had this exact problem on a machine with a Matrox G450 card running a single monitor. The solution by Matthias Schwarzott in comment #5 works for me. Fortunately, although the screen was completely scrambled, the boot completed, so I was able to ssh in to the system to change /etc/conf.d/rc, then reboot with the screen intact. Of course, one finds this bug when rebooting, in this case after updating both udev to udev-103 and the kernel to vanilla-sources 2.6.17.13. Not too helpful in finding the source of the bug - sorry.
After applying the above workaround, does running "modprobe --ignore-install matrox_w1" cause the bug to appear during standard system operation?
This bug report indicates that there is a bug in matroxfb which causes the problems you have seen here. You didn't notice this before, because the driver wasn't loaded before, but newer udev loads it automatically. While there are workarounds above to prevent udev from loading the driver which avoid this problem, if you're interested in solving the actual matroxfb bug then please reopen this with the information requested in comment #9
