From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 Description of problem: I'm trying to install RHEL 4 U1 WS via NFS on a Dell Dimension 9100. After a short period of time (usually after anaconda switches to graphical mode) the system completely freezes - mouse and keyboard (both attached via USB) are dead. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot from boot-CD 2. Select language and keyboard mapping 3. Fill in Network info and NFS server Actual Results: Anaconda switches to graphical mode and the system freezes shortly thereafter (once we got as far as disk druid) Expected Results: Installation proceeds Additional info:
Created attachment 117908 [details] Output of lspci
Created attachment 117909 [details] contents of /proc/cpuinfo
Created attachment 117910 [details] output of dmesg
Does booting with 'linux nofb' help? Are your keyboard leds blinking at this point?
When booting with 'linux nofb' my LC Display goes blank stating "no signal" as soon as anaconda is supposed to start the graphical mode (after entering network info and info on the NFS server) . Keyboard leds don't flash. I just installed RHEL 3 U5 and the installation went without a hitch (but with the Vesa video driver)
I just installed RHEL 4 U1 WS with "linux nofb text" and the install went through smoothly. I'll test tomorrow with the proprietary display drivers from ATI, to see if X works.
Ok, after a bit of tweaking, the install of WS4 seems to work. Here's what I needed to do to get through the installation (including firstboot) without locking up the system: * boot from the install CD with "linux nofb text" * after the install, when the system is rebooted, remove "rhgb quiet" from grub and add "nofb" * remove the radeon driver from /etc/X11/xorg.conf and replace it with the vesa driver (or install the driver from ATI)
I just tried the beta for WS4 Update 2 - it locks up at the screen asking wether I want to test the installation media
Bug also applies to RHEL 4 U3 - see Support requests 873768, 873766, 873764 and 849096
Created attachment 128899 [details] xorg.conf as requested
Created attachment 128900 [details] Xorg.0.log
(In reply to comment #25) > In RHEL 4 U3 > > Internal Status set to 'Resolved' > Status set to: Closed by Client > > This event sent from IssueTracker by Charles_Rose > issue 84778 > Closing bugzilla bug to match issue tracker status. Assuming the problem is no longer reproduceable. If the problem recurs, please reopen and respond to previous engineering inquiry in comment #22 above.
I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I see is #19 and #26), so it's hard to respond to it. But the bug surely still applies. The service requests 873768, 873766, 873764 and 849096 are still open, in status "Waiting on Red Hat"
I'd love to reopen the bug, but when I try to, all I get is this: "You tried to change the Status field from CLOSED to NEW, but only the owner or submitter of the bug, or a sufficiently empowered user, may change that field."
(In reply to comment #27) > I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I > see is #19 and #26), so it's hard to respond to it. This bug was originally filed directly in bugzilla instead of coming in via Red Hat support services. Since then, it has had numerous issue-tracker requests attached to it. The bug contains a number of comments which are private communication between engineering and support, which are flagged private. Any time you see missing comment numbers in a bug, it indicates there are private comments present intended for internal communication, etc. I have made private requests for more information, which should have gotten passed along to all customers who have issue-tracker requests linked to this issue, however there have not been any responses to the request. Since then some of the linked issues were closed as Resolved, so under the assumption that the issue was no longer a problem for some of the people who reported it, and the lack of any type of response to inquiries, must indicate the issue is no longer relevant. I don't know if you have filed an official Red Hat support request for this issue via http://www.redhat.com/support or not, however now that you have confirmed the issue is still occuring, I'm reopening it. > But the bug surely still applies. The service requests 873768, 873766, > 873764 and 849096 are still open, in status "Waiting on Red Hat" Thanks for confirming the issue. To get everyone on the same page, I'll reiterate the current status in public comment, so that everyone sees the same thing: So far, Red Hat has been unable to reproduce the reported problem internally. In order to diagnose the problem and potentially fix it, we first need a way to reproduce the issue in our labs. Since it seems to be affecting a lot of people, we need _everyone_ who is experiencing the issue to attach there information directly into this bug report so that engineering has all of the details from _all_ of the systems the problem is occuring on. Once that information is available, we can review it and try to determine what commonality the problematic systems may share, and can hopefully get a test system to reproduce the issue. If we can not reproduce the issue, then we will require a system be sent to our Westford lab which is known to reproduce the issue, so that we can directly investigate it. If everyone can attach their info now, that would be very useful. To Red Hat support services: Please ensure that this above engineering request has been passed on to _all_ customers experiencing this problem, and that any information that is returned to Red Hat via issue-tracker and/or CRM, is directly copied into this bugzilla report so that engineering has the data to work with.
(In reply to comment #27) > I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I > see is #19 and #26), so it's hard to respond to it. But the bug surely still > applies. The service requests 873768, 873766, 873764 and 849096 are still open, > in status "Waiting on Red Hat" Only bugzilla is visible to Red Hat engineering, so any information present in issues filed in CRM or issue-tracker which are relevant to engineering, need to be copied through to the bugzilla report tracking the issue by support folk, or engineering never sees it, as we do not use CRM or issue-tracker directly. Basically it works like this: - Customer reports issue to Red Hat support services - Support services work with customer to try and resolve the issue and to gather information. - If support can not resolve the issue directly, they gather information, and it gets escalated to RHAT engineering via bugzilla, and all details of the issue are copied through to bugzilla. - Red Hat engineering works directly with bugzilla. Any requests made, go back to support services, who work with the customer to obtain the information requested by engineering, which then gets copied back into bugzilla. customer <-> support <-> engineering This bug is a bit confusing because it was originally a direct-filed bugzilla bug, which flows as: user <-> engineering - which is outside of the Red Hat support organization. Later, official issues got attached, but Red Hat support appears to have not attached themselves to the bug report, so the flowchart appears to be: user -> engineering and customer -> RH support -> bugzilla -> engineering -> bugzilla -> STOP I'm trying to reconnect things so that it becomes: customer <-> RH support <-> bugzilla -> engineering -> bugzilla -> RH support -> customer Hopefully this helps explain any confusion, and we can get the required info now. Thanks again for reopening.
Created attachment 133063 [details] sysreport of affected system
Created attachment 133064 [details] Sysreport of another affected system This sysreport should be identical to the sysreport Martin just added. Both machines are Dell Dimension 9100 machines. We ordered them via the same order. The main difference to the sysreport Martin added, is, this machine is currently running the ATI proprietary drivers. Maybe there's some additional information in the logs which might help you. Please contact us if more details / information is needed.
Created attachment 133077 [details] Another sysreport of an affected machine This is a sysreport of a Dell Dimension 9150 which is also facing the issue. Currently running with the ATI proprietary drivers.
Just an FYI: Update 4 didn't resolve the issue.
Installed RHEL5 Beta2. Worked like a charm. Dekstop effects are working, too. So no issues with RHEL5 Beta so far.
Looks like this one fell through the cracks.
Closing as per comment #46. If you still want this issue considered for RHEL4, please reopen, and explain the nature of the modifications mentioned in comment #42.