Description of problem: With AMD A75 chipset, when installing from DVD, Fedora 17 recognizes USB mouse, ditto OK with Live CD, but when network update from Repo during install is selected then Firstboot signup cannot be completed as USB mouse is not recognized (but mouse support is required by Firstboot). Maybe this problem is due to a regression in (AMD A75 chipset) hardware support in kernel network updates. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install from DVD but enable Fedora Update repo for network updates 2. Mouse required but not recognized on Firstboot user entry screen 3. Actual results: USB mouse not recognized on Firstboot user entry screen (entry not possible) Expected results: * Surely should be able to use tab or Alt-char to navigate Firstboot. * USB mouse should still be recognized after network updates -- H/W support regression? Additional info: Located in Japan, so not sure which mirror the updates are coming from. Would be desirable to be able to specify "only local mirrors" (i.e. in Japan) to eliminate the possibility of rogue mirrors, like in China, installing malware. (I'm a bit paranoid about security). When Update repo is enabled then sometimes two versions with same release number but different size are displayed.
Under "Additional info": > When Update repo is enabled then sometimes two versions (of the same package) with same release number but different size are displayed. This refers to Yumex
PS: The Fedora 18 LiveCD won't even boot on an AMD A75 chipset PC. The A75 chipset is probably the most widely-used chipset for AMD FM1 and FM2 socket CPUs.
Re. my comment: <quote> Additional info: > Located in Japan, so not sure which mirror the updates are coming from. > Would be desirable to be able to specify "only local mirrors" (i.e. in Japan) > to eliminate the possibility of rogue mirrors, like in China, installing > malware. (I'm a bit paranoid about security). When Update repo is enabled then > sometimes two versions with same release number but different size are > displayed. <unquote> When I update, I'm asked to accept the signature 1ACA3465 for the F17 Update repo. I'm not sure where this comes from. When I attempt to log into the KDE desktop, the computer freezes. Also the names under the program icons on the Gnome desktop now all have the small letter "a" missing (replaced by a space).
Can you please attach some log files? - anaconda.log and yum.log will show us what repository was used - Xorg log files will give us information about input devices You should be able to find those in /var/log directory. Thanks.
Hope these attached files help. Please let me know if you need more. The problem with "a" missing from program names in Gnome seems to have fixed itself. I'm thinking of setting up local F17 update and F18 update repos, synched with a trustworthy local repo, and trying a reinstall to see if it fixes the problems (can't use KDE desktop etc). If F17 doesn't send my attachment I'll try again from Windows. file:///home/keith/Documents/F17logs.tar.gz
Created attachment 687564 [details] Requested logfiles
Created attachment 687589 [details] Some DEBUG errors in anaconda.yum.log, possible bad install DVD? Some DEBUG errors in anaconda.yum.log, possible bad install DVD?
Had no problem this time, using local repo. for F17update. However <separate bug> F17 installer gives an error like "Can't read floppy disk in drive" and freezes for what feels like several minutes before continuing installation. Some previous distros had problems if IDE floppy was left enabled (it used to be enabled by default) but no floppy drive was connected. Current BIOS doesn't even show floppy. Will try F17 -> F18 upgrade next.
An attempt to run fedup for the F17->F18 upgrade ended as follows: ... fedupiso/filelists_db | 3.4 MB 00:00 ... Traceback (most recent call last): File "/bin/fedup", line 330, in <module> main(args) File "/bin/fedup", line 275, in main pkgs = download_packages(f) File "/bin/fedup", line 57, in download_packages updates = f.build_update_transaction(callback=output.DepsolveCallback(f)) File "/usr/lib/python2.7/site-packages/fedup/download.py", line 185, in build_update_transaction (rv, msgs) = self.buildTransaction(unfinished_transactions_check=False) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1124, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 897, in resolveDeps (checkdep, errormsgs) = self._processConflict(*conflict) File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 759, in _processConflict self._dscb_procConflict(po, niceformatneed) File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 745, in _dscb_procConflict self.dsCallback.procConflictPo(po, niceformatneed) File "/usr/lib/python2.7/site-packages/fedup/callback.py", line 142, in procConflictPo self.log.debug('CONFLICT: %s → %s', po, formatted_conflict) NameError: global name 'po' is not defined
*Security alert* I noticed this article: http://blog.sucuri.net/2013/01/server-side-iframe-injections-via-apache-modules-and-sshd-backdoor.html and ran the rpm checks mentioned in the article on my PC: (Fedora 17 updated from Fedora 17 update repo) file /lib64/libtranslit is not owned by any package file /lib64/mission-control-plugins.0 is not owned by any package file /lib64/packagekit-plugins is not owned by any package file /lib64/rados-classes is not owned by any package file /lib64/sssd is not owned by any package file /usr/lib64/libtranslit is not owned by any package file /usr/lib64/mission-control-plugins.0 file /lib64/packagekit-plugins is not owned by any package file /usr/lib64/rados-classes is not owned by any package file /usr/lib64/sssd is not owned by any package The PC is triple-boot Windows / CENTOS 6.3 / Fedora 17 A check of CENTOS 6.3 gives: file /lib64/ld-lsb-x86-64.so is not owned by any package file /usr/lib64/crash is not owned by any package file /usr/lib64/gnome-bluetooth is not owned by any package file /usr/lib64/hal is not owned by any package file /usr/lib64/ipa is not owned by any package file /usr/lib64/java is not owned by any package file /usr/lib64/jss is not owned by any package file /usr/lib64/udev is not owned by any package file /usr/lib64/liblber-2.4.so.2 is not owned by any package file /usr/lib64/libldap-2.4.so.2 is not owned by any package file /usr/lib64/libldap_r-2.4.so.2 is not owned by any package file /usr/lib64/libldif-2.4.so.2 is not owned by any package file /usr/lib64/libnfsidmap is not owned by any package file /usr/lib64/librevocation.so.1 is not owned by any package file /usr/lib64/udev is not owned by any package I have another PC that is also triple boot but Fedora 17 was successfully upgraded to Fedora 18. I will run the same checks on that PC.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.