From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (Win95; I) Description of problem: Virgin installation (no other OS on machine) proceeds normally, including all setup dialogs and internal probings of hardware. Both Monitor (AOC Spectrum Dlr7a) and video card (generic AOpen GeForce 2 MX 64M AGP) are detected and Xwindows is configured. Bootup option is set to runlevel 3 on an ASUS A7M266D dual Athlon 1800+ MOBO with the 760MPX chipset. However, after installation is completed, booting either SMP or UP kernel results in a blank console screen and no ability to login (even if typing in the dark). Ctl-Alt-Del DOES cause reboot, and using rescue-kernel from installation media works correctly allowing verification from log files that bootup DID actually occur. Issue was reported to installatiion support channel (service report #228953), but after a week of email ping-pong where the following was attempted: 1. combinations of boot options nousb,noathlon,apm=off,mem=nopentium 2. BIOS shutdown of DPMS services 3. Attempts to reconfigure XFree86 to a lower resolution (which I did despite questioning why Xwindows would make any difference) 4. Disabling DMA for the harddisk, and alterring the initscripts to not start apmd in runlevels 345 NONE of which made any difference to the problem. 5 Using my own discretion I also tried using the vga=ask boot option which at least produced the mode menu onscreen - which resulted in the first time I had seen ANYTHING beyond the GRUB bootscreen. On my own, google turned up an article from the Linux Gazette describing EXACTLY the same problem, but alas their solution led to a bad BIOS setting (PCI .vs. AGP as primary VGA card) - which is untrue in my case. However it alluded to perhaps needing to compare kernel configs as the next logical step to solve the problem. Based on that, I attempted to rebuild the kernel using the SMP config that was supplied in the kernel source package (2.4.7-10SMP). This also failed -- HOWEVER I noticed that there was also a (2.4.7-10BOOT) config present and tried a rebuild with that (based on the notion that the rescue kernel had always worked). This WORKED correctly, allowing me to view the bootup and subsequently login. However I am now unsure of just what is actually configured into my machine. Notably, my parallel port is not functioning, nor is my new kernel SMP-aware; but it is at least a start. Is there something inherently different in accessing the video card in a kernel configured for installation versus one that is configured for general use Version-Release number of selected component (if applicable): 2.4.7-10 How reproducible: Always Steps to Reproduce: 1. Simply boot the stock installed kernel from the GRUB screen 2. 3. Actual Results: Grub boot screen is cleared, and remains dark. However, monitor remains 'on' (i.e. not standby, nor loss of signal). Console fails to show any acknowledgement of switching between virtual consoles, nor does it accept blind keyboard entry of valid login sequences. Expected Results: Messages pertaining to the bootup should have been displayed. Ultimately, a login prompt should have been produced on each virtual console. Additional info: Due to the relative ages of the 7.2 release and the newness of the 760MPX chipset many of the onboard devices are reported in the log as "unknown" including bridges and IO chips. However given that BOTH the rescue and stock kernels agree on how little they "know" about the devices I tend to think of this as somewhat inconsequential to the problem at hand; but I am no kernel hacker (yet) so my opinion may not count for much on this point.
Created attachment 90498 [details] Contents of log messages for rescue and stock kernels and also lspci of machine
760MPX is known to work but you require - BIOS > = 1007 (or 1004 with MP set to MP 1.1), and a PS/2 mouse installed if the system is the ASUS.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/