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):
Steps to Reproduce:
1.Boot CD 1, select graphical install
2.Watch it hang
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.
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
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.