Version-Release number of selected component (if applicable): xorg-x11-server-common-1.7.99.901-2.20100215.fc13.i686.rpm xorg-x11-server-utils-7.4-15.fc13.i686.rpm xorg-x11-server-Xorg-1.7.99.901-2.20100215.fc13.i686.rpm Steps to Reproduce: 1. boot a rawhide compose (e.g. 20100218) 2. go through the stage1 to get X on the screen Actual results: I can't move the mouse cursor or use keyboard. Expected results: Not that. Additional info: This problem has been on rawhide for months. It disappeared briefly before f13 was branched but is back now.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Hi, how can I get the X server log when the computer doesn't react to any input after X starts? Thanks. Ales
I also tried adding the two new files in /etc/xorg.conf.d/ into the install image but there's still no input possible.
(In reply to comment #2) > how can I get the X server log when the computer doesn't react to any input > after X starts? boot into runlevel 3, that doesn't start X. when the grub menu comes up, edit the boot line and append the number 3 to the end of the line. then boot as normal, it will drop you into the console where you can then log in and get the log files. attaching them to here might be more difficult unless you're familiar with the links browser. maybe best to email them to yourself and use a working GUI to attach them.
Created attachment 395045 [details] Xorg.0.log.old
I have a same problem. I attached Xorg.0.log.old. revision of xserver xorg-x11-server-common-1.7.99.901-6.20100215.fc13.i686.rpm xorg-x11-server-Xorg-1.7.99.901-6.20100215.fc13.i686.rpm
Created attachment 395086 [details] X.log from anaconda And here's mine. The system where this happens *has got* files in /etc/xorg.conf.d: -bash-4.1# ls /etc/xorg.conf.d/ 00-evdev.conf 10-quirks.conf The X server is started under a root, for what it's worth.
weird. very weird. in both cases, the server doesn't see the list of devices, which suggests that it can't talk to udev. not sure why this is the case, I can assume the udev service is running? what's the output of udevadm info --export-db?
Created attachment 395408 [details] udevadm --export-db output
weird, you're missing the ID_INPUT labels that we need in the server. what version of udev do you have installed? is there an update available for you?
I have updated udev to 151-3.fc13.i686. And there are ID_INPUT labels in the udeadm output. But the problem is shown. I attach another udevadm output.
Created attachment 395418 [details] another output of udevadm
have you rebooted after installing udev? i think that's still necessary (just restarting the service may not be enough). also, can you provide the new xorg.log as well please? I want to see if it's now the server that's going wrong.
Offcourse, I have rebooted.
I have tested xorg-x11-server as follows. xorg-x11-server-1.7.99.901-7.20100215.fc13 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13 and xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.i686 xorg-x11-server works fine. My problem is solved by 1 matching ABI version between the server and drivers 2 updating udev. Regards
Anaconda adds the /etc/xorg.conf.d/* with 49f12d62f5d9c5cf213a983023000be988ffffc1. To appear with anaconda-13.29.
(In reply to comment #16) > Anaconda adds the /etc/xorg.conf.d/* with > 49f12d62f5d9c5cf213a983023000be988ffffc1. To appear with anaconda-13.29. Is more needed to properly address this bug other than the fix to anaconda from bug#566948?
James: once you package /etc/xorg.conf.d then you should be set to go. Masao - did you get ABI warnings in the log? If so, then it was an update related issue (stale packages, similar to udev), so if it works for you now, the bug can be closed.
anaconda-13.29-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.29-1.fc13
(In reply to comment #18) > James: > once you package /etc/xorg.conf.d then you should be set to go. > > Masao - did you get ABI warnings in the log? If so, then it was an update Yes, I get ABI warnings in the Xorg.0.log. > related issue (stale packages, similar to udev), so if it works for you now, > the bug can be closed. I think so for my case.
xorg-x11-server-1.7.99.901-8.20100223.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/xorg-x11-server-1.7.99.901-8.20100223.fc13
just for info - the package here simply requires the required version of udev so that other users that may have the same update status don't run into this issue. A user with a fully updated system should not experience this bug anyway. I'll leave this bug open, once the package goes into stable it will close the bug automatically. Thanks for your patience in tracking this down.
Adding to F13Alpha, xorg-x11-server-1.7.99.901-8.20100223.fc13 is required to address the no input during install problem present in F-13-Alpha. Bug#566948 concerns the anaconda portion of this fix.
Created attachment 395719 [details] logs F13 Alpha RC2 Hi Peter, the problem still exists during installation of F13 Alpha RC2, attaching udev and X.org logs. At the moment of the X.org startup, there are the two files in /etc/xorg.conf.d. Ales
python-urlgrabber-3.9.1-5.fc13,anaconda-13.29-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-5.fc13,anaconda-13.29-1.fc13
Created attachment 395734 [details] log-files.tgz - using boot.iso with correct anaconda+xorg-x11-server packages I'm testing with a boot.iso (http://serverbeach1.fedoraproject.org/pub/alt/stage/boot.iso) that uses anaconda-13.29 and xorg-x11-server-1.7.99.901-8.20100223.fc13 and I'm still experiencing this problem.
anaconda-13.29-1.fc13, python-urlgrabber-3.9.1-5.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda python-urlgrabber'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2688
xorg-x11-server-1.7.99.901-8.20100223.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2700
Moving back to ASSIGNED based on comment#26
(In reply to comment #26) > Created an attachment (id=395734) [details] > log-files.tgz - using boot.iso with correct anaconda+xorg-x11-server packages > > I'm testing with a boot.iso > (http://serverbeach1.fedoraproject.org/pub/alt/stage/boot.iso) that uses > anaconda-13.29 and xorg-x11-server-1.7.99.901-8.20100223.fc13 and I'm still > experiencing this problem. looking at the udevadm output, the ID_INPUT is missing again. which suggests a broken udev setup or an old version of udev. I think this might be fixed by anaconda-13.30-1.
This appears to be fixed in newer builds of anaconda. Fixed builds will be in the Alpha, hopefully we can test and get karma pushed through too.
multiple reports that this works with 13.30+ (rc3+). let's close.
python-urlgrabber-3.9.1-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2688
xorg-x11-server-1.7.99.901-8.20100223.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.