Created attachment 516566 [details]
anaconda log of traceback
Description of problem:
traceback after specifying boot loader location
Version-Release number of selected component (if applicable):
16.14 with updates
Steps to Reproduce:
1. boot tc1 and use updates.img from http://clumens.fedorapeople.org/723167.img
2. select custom layout
3. specify boot loader location, click next
continue on to installation
This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=723167
Can you grab /tmp/anaconda-tb-* and attach to this bug report? Thanks.
Created attachment 516747 [details]
anaconda-tb-* as requested
Deleted original, reran install attempt and got same error, so hope this file serves your purpose.
By chance is "Cannot connect to Gnome Keyring Daemon" related?
That should only be a problem with saving bugs automatically. It shouldn't be causing the traceback.
problem persists in 16.14.2 and 16.14.3
hi, shouldn't this bz be an alpha blocker?
Still not fixed in 16.14-1
anaconda sets up releasever before _getConfig is called specifically because there's not going to be a system-release package installed to be read. See around line 776 in yuminstall.py (doConfigSetup). I don't know why yum would be trying to set it anyway.
> anaconda sets up releasever before _getConfig is called specifically because
> there's not going to be a system-release package installed to be read. See
> around line 776 in yuminstall.py (doConfigSetup). I don't know why yum would
> be trying to set it anyway.
AFAIK we've always done that ... we always look for the system releasever, and then override it with the preconf/etc. one. We can fix that, I guess, it will mean adding a parameter to readStartupConfig() ... which I think will be fine.
Normally this just meant that no package was found, and releasever='$releasever', maybe rpm has started complaining in cases were it didn't before?
(In reply to comment #9)
> Normally this just meant that no package was found, and
> releasever='$releasever', maybe rpm has started complaining in cases were it
> didn't before?
Could this be due to the trailing slash bug of rpm-4.9.1?
AFAIK that was an rpmbuild bug only.
It was rpmbuild-only bug that affected some directories, nothing else. So it would be possible to fail looking for a provider of /some/directory where a buggy rpm contains /some/directory/ but that's not the case with releasever lookup AFAIK.