Bug 860022

Created attachment 616622 [details]
File: ifcfg.log

Created attachment 616623 [details]
File: version

Created attachment 616624 [details]
File: product

Created attachment 616625 [details]
File: type

Created attachment 616626 [details]
File: environ

Created attachment 616627 [details]
File: storage.log

Created attachment 616628 [details]
File: program.log

Created attachment 616629 [details]
File: release

Created attachment 616630 [details]
File: anaconda.log

Created attachment 616631 [details]
File: syslog

Created attachment 616632 [details]
File: hashmarkername

Created attachment 616634 [details]
File: ks.cfg

Created attachment 616635 [details]
File: packaging.log

Created attachment 616636 [details]
File: cmdline_file

Created attachment 616637 [details]
File: anaconda-tb

Created attachment 616638 [details]
File: description

This is a traceback out of the yum module.  Are we doing something wrong here yum folks?

yum/__init__:
@313:        uuid = self.preconf.uuid
@385:        del self.preconf

I'd bet that somewhere between these two lines _getConfig() is called recursively, so the "inner" function deletes self.preconf, and the "outer" one tracebacks.  There's likely some self.conf reference between lines 313 and 385.  doPluginSetup, maybe?

 What Zdeněk says is true, but because of that possibility we try to limit what we do a _lot_ between those two lines. Here is a mostly complete list:

1. Take values from preconf

2. Setup arch. data.

3. config.readStartupConfig()

4. config._getsysver() manual call for releasever=/

5. doLoggingSetup()

6. doPluginSetup()

7. config.readMainConfig()

...and at that point self._conf is set, at which point we can't recurse into this code path.
 My guess is that #6 is the problem, at that point we do a couple of things that might be triggering something:

6.1: import each plugin module (runs any top level code) in the module.

6.2: runs the "config_hook" of each enabled plugin.

...and here the problem is likely #6.2 (you should be able to run this outside of anaconda though).

 If you don't have any weird plugins, it probably means you are overridding one of the stages above ... which will be harder to debug :(.

Created attachment 665671 [details]
Screenshot of crash

I've been seeing this off and on for a while on my vm installs.  Just got it with 18.37.3 from F18-TC3.  In text mode install the traceback does not appear to be logged anywhere (a separate bug?), but the screen shot does show another traceback along with the reported one.

Created attachment 665809 [details]
screenshot of crash

Tried a second time.  Got a different yet similar crash.  Something does seem racy.  I've got a lot of repos configured - I wonder if that helps trigger it.

Created attachment 665811 [details]
screenshot - pycurl.error: cannot invoke setopt() - perform() is currently running

Third try, yet a different traceback.

The traceback from c#22 suggests two threads are using the same curl_obj instance in urlgrabber module.  This module is not thread-safe.

Seems that most methods in YumPayload class use yum_lock to synchronize access to Yum internal state, but at yumpayload.py:487, self._yum.repos is touched directly.  This triggers opening *.repo files with urlgrabber.grabber.urlopen().

AIUI, Anaconda touches self._yum.repos from >1 thread.  It's a property that mostly just returns self._yum._repos (so it's thread-safe).  But on first run, the getter also parses repositories from yum.conf and (possibly remote) *.repo files (this uses urlgrabber and is not thread-safe).

The "1st run" check in Yum is racy.  http://lists.baseurl.org/pipermail/yum-devel/2012-December/009843.html kind of "fixes" this, but IMO Anaconda should make sure YumBase object is instantiated and initialized from 1 thread only.

I've added _yum_lock to everyplace I can see us using self._yum, give this updates.img a try (against smoke8)

http://bcl.fedorapeople.org/updates/860022.img

Works for me with TC3, thanks!

Discussed at 2012-12-19 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . We are delaying the decision on blocker status as we're not sure how likely this is to hit people - it seems to be related to having a large number of repos, Orion, exactly how many do you have? - but we're at least agreed that it is NTH.

base url + 8 additional repos

Discussed at 2012-12-21 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-21/f18final-blocker-review-7.2012-12-21-18.33.log.txt . Agreed this doesn't seem to happen often enough to consider a blocker, but it's already accepted as NTH, and will be in next anaconda build.

dracut-024-17.git20121220.fc18, anaconda-18.37.7-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.7-1.fc18

Package dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-17.git20121220.fc18 anaconda-18.37.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.8-1.fc18
then log in and leave karma (feedback).

dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.