From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218 Description of problem: While still in text-mode, the machine hangs when the installer asks the "verify CDROM media (yes) (no)" question if the graphical install has been selected. No keyboard reaction, no nothing. I assume that this is the phase where the install is probing the graphics hardware for the first time or similar. When doing a text install, install continues normally. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Boot CD 1, select graphical install 2.Watch it hang 3.Profit! Actual Results: Total hang, no way out except rebooting the machine Expected Results: I would have expected to be able to select the "don't check media" option and started the install. Additional info: HP Pavilion ze5155 P4 notebook computer, 512MB RAM, ATI Mobility M6 graphics card.
That's odd. We've gotten a few of these - could be a kudzu/keyboard init interaction problem. I don't know if we have this model handy.
Do you have a USB keyboard handy that you could try attaching to the laptop to get through the install? I'm curious to know if the keyboard works properly post-install.
could be a dup of #81243
I probably didn't read your report correctly. The first try locked up at the media check option, but then cold starting the machine let you continue with a text mode installation. This could be a warmboot problem - did you boot into the installer cold or warm?
Happens both cold and warm, as far as I can tell. I think I tried both. However, I'll double-check once the text-mode install has completely finished, just to verify that it _does_ finish. Btw, not being able to use email to update bug stuff sucks.
Btw, no USB keyboards around tonight, and I probably won't have time to snarf one before leaving on vacation Friday. Will try.
I was wrong, you were right - it does _not_ happen on a cold boot. So the gaphics vs text mode installation is apparently a red herring, and the real issue is cold boot vs warm boot. It turns out graphics mode install doesn't work that well anyway, but that's a separate problem: XFree86 has trouble synching on the TFT-screen on this machine. Doing a console switch back to text mode and then back to graphics mode sometimes fixes that. And sometimes not.
(on the email bit - we're doing testing for the bugzilla email gateway - so that should be coming in the not-too-distant future) Interesting that things aren't working on the warm boot. Is it hanging at the media check screen or just after you select "don't check"? On the X problem - is this a 1024x768 15" display?
The keyboard goes away _before_ I can do the "don't check" thing. Which is the first thing that asks for keyboard input. In fact, by pressing the caps-lock key and looking at the caps-lock LED, I can tell that the keyboard is dead already when the kernel is booting (but it worked in the BIOS), so it's definitely a RH kernel problem, and has nothing to do with any later probing of hardware by the install sequence. Btw, both SuSE 8.1 and current 2.5.x work fine on this same machine, so the keyboard problem is very much RH-specific. (The xfree86 problem is something generic). And yes, that is a 1024x768 15" display.
We're going to revert some userland ps/2 probing code. You're probably right that it won't fix your case though. Don't know what might be wrong in the kernel, though. Arjan?
Doing more testing (at least 25 reboots) shows that it's not repeatable after all. I had at least 10 consecutive successful soft reboots when I was pressing caps-lock while the kernel was booting. And then several failures, including at least one with the installed kernel (ie the one loaded from harddisk, not the CD-ROM installation kernel). I'm pretty sure one of them was from a cold boot too. In short, no real patterns after all. Sometimes it works, sometimes it doesn't. Sometimes it seems to stop working within the same boot (ie caps-lock worked for a while, then stopped), and sometimes it seems to not have worked at all during a boot (but maybe it worked for a window I just didn't notice).
I don't have patches against keyboard stuff; the patches Alan had in his tree I backed out because those were indeed broken.. so why it fails... does the loader probe the ps/2 ports that early ?
loader doesn't probe ps/2 ports directly. The mouse probe begins in stage 2 of the installer (once you've mounted the media, etc). It could be that our modified ps/2 probe code places things in an odd state, and if you warm reboot after the install things go wrong.
I'm going to point my finger at the kudzu ps/2 probe code, which did some very dubious things (disable port, fail probe, didn't re-enable port). The next beta will not use the newer (broken) code.
Oh, another note - on the laptop and screen not working properly - it may work better if you run at the native lcd resolution. Boot into the installation program with "linux resolution=1024x768"
Please try again with Pheobe beta2 (now on ftp.redhat.com)
I'm going through Bugzilla closing some bugs that have been marked as Modified for some period of time. I believe that most of these issues have been fixed, so I'm resolving these bugs as Rawhide. If the bug you are seeing still exists, please reopen this report and mark it as Reopened.