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
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
for general use
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Simply boot the stock installed kernel from the GRUB screen
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
Expected Results: Messages pertaining to the bootup should have been displayed.
Ultimately, a login prompt should have been produced on each virtual console.
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
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/