Created attachment 690491 [details]
kickstart script

Created attachment 690492 [details]
screenshot of anaconda.log

We've also got bug 887223 tracking this in RHEL7.  I do not believe this is anything specific about your kickstart file.  The other bug report indicates it's a transient error, but you indicate it is reproducible every time.

Yes, I tried it twice times yesterday and once again this morning.  Exactly the same failure every time.  This is my virt-install line if that helps:

virt-install --quiet --connect qemu:///system --virt-type kvm --name f18k --network bridge=virtbr,mac=52:54:00:96:ce:be --ram 1000 --os-type linux --os-variant fedora18 --disk path=/var/lib/libvirt/images/f18k.img,size=15 --noautoconsole --location http://myhost/mirror/fedora/releases/18/Fedora/x86_64/os/ --extra-args 'ks=http://myhost/~jorton/ks.php?host=myguest&url=fedora/releases/18/Fedora/x86_64/os/'

*** Bug 950437 has been marked as a duplicate of this bug. ***

Description of problem:
Installing MATE Desktop using TC6 alpha netinstaller

Version-Release number of selected component:
anaconda-19.18-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Alpha-TC6\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.1.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha-TC6

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

Dan, could you please provide rationale for this being nominated as an Alpha blocker? Thanks.

(In reply to comment #7)
> Dan, could you please provide rationale for this being nominated as an Alpha
> blocker? Thanks.

Under criterion of a failed install.

Description of problem:
Tried to install TC6. Crashed after setting the root password (not sure it's related to that however).

- workstation profile with a few additional options
- English (US) language, German (nodeadkeys) layout
- btrfs

Version-Release number of selected component:
anaconda-19.18-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   method=http://dl.fedoraproject.org/pub/alt/stage/19-Alpha-TC6/Fedora/x86_64/os/
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.1.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha-TC6

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

Discussed at 2013-04-15 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-15/f19alpha-blocker-review-7.2013-04-15-16.00.log.txt . This is obviously a show-stopper bug, but it seems to be transient for most reporters, and the initial reporter is using a kickstart (which is outside of Alpha criteria). There really isn't much consistency between reports, so it's hard to pin down the cause here.

Overall we felt there are obviously many more cases where this doesn't happen than where it does, or else there wouldn't be so many check marks in the Alpha validation test matrices. So for now, it is rejected as a blocker on the basis it's just not affecting enough installs. If more details emerge that pin down the cause of this more precisely and they seem to indicate it is a blocker after all, please re-propose.

Joe, if you can reproduce this reliably, can you please attach the full set of anaconda log files from /tmp after the failure?

That applies to all reporters - please, if you're able to reproduce this, attach your logs. Thanks!

I'm not sure I can reproduce this any more.  My environment has changed slightly: I was using an f17 kvm host.  

I've just installed three f18 vms in a row, using exactly the same kickstart file as above, and it worked perfectly.  I'll check with f19 and That Other Distro as well.

Description of problem:
I don't know what caused this problem. I was performing normal installation and a while after my clicking on "begin installation", traceback was showed. I'm not able to reproduce it. Maybe some race condition.

Version-Release number of selected component:
anaconda-19.19-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Alpha\x20x86_64 rd.live.check quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

Created attachment 736260 [details]
anaconda-tb

Created attachment 736261 [details]
anaconda.log

Created attachment 736262 [details]
program.log

Created attachment 736263 [details]
packaging.log

Created attachment 736264 [details]
syslog

Created attachment 736266 [details]
storage.log

Created attachment 736267 [details]
ifcfg.log

I can reproduce this issue reliably using the netinst ISO image -- using the complete DVD image seems to work (it's installing package ATM).

Here's what/how I tried to install:

- No kickstart

- English language, German keyboard layout

- VM with leftover partitioning, or empty virtual disk image. Choose the single virtual disk (15GB), then "Done", BTRFS scheme and custom partitioning. In the case with existing partitions, delete them first of course. Then choose the suggested partitioning and reduce swap from 4GB to 1GB, extend root (and home) volumes by the gained 3GB, then "Done":

  Manual Partitioning (BTRFS):
    DATA
        /home [home] 13.859GB (BTRFS, btrfs, Single)
    SYSTEM
        /boot [vda1] 500MB (Standard Partition, ext4)
        /root [root] 13.859GB (BTRFS, btrfs, Single)
        Swap [vda2] 1GB (Standard Partition, swap)

- Software Selection:
    Environment:
        Development and Creative Workstation
    Add-ons:
        Administration Tools
        C Development Tools and Libraries
        Design Suite
        Development Tools
        Engineering and Scientific
        PostgreSQL Database
        RPM Development Tools
        Security Lab
        System Tools

- "Begin Installation"

- Set root password

The crash happens at this point usually. If I'm especially quick, I can enter the "user creation" spoke first.

I'll attach a tarball with all log files I found in /tmp.

Adam: As kickstart is not involved and I can reliably reproduce this, would you consider this a blocker?

Created attachment 736295 [details]
Tarball containing anaconda logs from failed F19 Alpha RC3 installation

Nils: can you reproduce it without installing a giant ton of add-ons?

Description of problem:
Random error during installation

Version-Release number of selected component:
anaconda-19.18-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Alpha-TC6\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.1.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha-TC6

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

That traceback has:

Local variables in innermost frame:
e: [Errno 12] Timeout on file:///tmp/anaconda-yum.conf: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 300 seconds')

Which makes me think this is a virt problem.

(In reply to comment #25)
> That traceback has:
> 
> Local variables in innermost frame:
> e: [Errno 12] Timeout on file:///tmp/anaconda-yum.conf: (28, 'Operation too
> slow. Less than 1000 bytes/sec transferred the last 300 seconds')
> 
> Which makes me think this is a virt problem.

I installed on dual striped sata 3 ssd on a quad core AMD.

Can you please increase the timeout value?

For blocker consideration purposes - by my count we have 6 people who have hit this bug with F19:

Dan
Nils
Ľuboš
Stefano
Tao Wu (#950437)
Jens (#950954)

A thought: for anyone who experiences this bug regularly or 100% of the time, does passing "slub_debug=-" on the kernel command line help? I'm wondering if this bug is somewhat performance-related, which would explain it happening apparently more often with F19 Alpha, as the debug kernel makes performance rather worse.

I have a Core 2 Duo P8600 with 4GB of RAM, 128GB SSD and I'm using Virtualbox, and the install crashed 3/3 attempts during different parts of the install.

Adam, I just got the issue also with "slub_debug=-".

Same issue with RC3

We should re-consider this one in the go/no-go meeting, I think. Re-proposing.

Thanks. +1

(In reply to comment #23)
> Nils: can you reproduce it without installing a giant ton of add-ons?

Hmpf. It seems whatever I do today, I can't reproduce the problem -- leaving everything (under my control) the same, even to the point of running a second VM in parallel as I did yesterday, running an installation of F19 RC3 from a DVD ISO image (both to images in the same folder).

That kind of leaves changes in the tree (? -- is the RC3 anaconda tied to the RC3 tree or will it pick newer stuff?), or even which mirror was chosen, or it was that I have much fewer browser windows/tabs open, ... which all isn't exactly helpful in figuring out what went wrong then.

(In reply to comment #25)
> That traceback has:
> 
> Local variables in innermost frame:
> e: [Errno 12] Timeout on file:///tmp/anaconda-yum.conf: (28, 'Operation too
> slow. Less than 1000 bytes/sec transferred the last 300 seconds')
> 
> Which makes me think this is a virt problem.

I'm not sure about that number of 300 seconds -- I think I got through the whole process in less than 5 minutes but it's a close call.

Discussed (again) at 2013-04-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-17/f19alpha-blocker-review-8.2013-04-17-16.00.log.txt . The increasing number of people hitting this concerns us somewhat. However, this seems to be something of a heisenbug - it's very hard to pin down - and the information available indicates it's not actually a showstopper for anyone (all reporters seem to have found that it starts working if they wait a while, or use the DVD, or something).

So right now we're working on the basis that this only affects netinstalls and is something to do with the mirror used or the repository contents, it affects a minority of install attempts, and it will usually work if the user waits a while and tries again. Using the DVD image is also a workaround. On that basis, we decided to once again reject the bug as a blocker. If we're able to find information that contradicts the above, this may change things.

Stefano, it'd be handy if you could try today and see if it's cleared up for you - you're the only reporter so far who hasn't reported back that a later attempt was successful, but it seems that so far, you've only hit the bug on one day. It'd be good to know if today it's started working for you (as for Nils).

I'm running livemedia-creator on an F19 ARM system (Calxeda HighBank), and also see the folling in a dump:

--------
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 473, in updateBaseRepo
    self._yumCacheDirHack()
  File "/usr/lib/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 195, in setup
    self.updateBaseRepo(fallback=not flags.automatedInstall)
  File "/usr/lib/python2.7/site-packages/pyanaconda/packaging/__init__.py", line 656, in payloadInitialize
    payload.setup(storage)
  File "/usr/lib/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

Local variables in innermost frame:
e: [Errno 12] Timeout on file:///tmp/anaconda-yum.conf: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 300 seconds')
url: file:///tmp/anaconda-yum.conf
includetuple: ('file:///tmp/anaconda-yum.conf', None)
self: <yum.parser.ConfigPreProcessor instance at 0x1600080>
absurl: file:///tmp/anaconda-yum.conf
fo: None
--------

The command line used is:

  livemedia-creator \
   --no-virt --make-disk \
   --armplatform=tegra \
   --ks=./F19-trimslice-test.ks

running:

  anaconda-19.19-1.fc19.armv7hl
  lorax-19.2-1.fc19.armv7hl
  python-blivet-0.10-1.fc19.noarch
  kernel-highbank-3.6.10-8.fc18


Note: we are using an F18 kernel, the same one we successfully used for running lmc on F18.

Still hitting this on RC4

Description of problem:
After failed UEFI attempts, switched my BIOS to legacy mode (Lenovo x120e) and attempted an install.

My LAN connection to the internt failed for a period of time, so for about two hours the installer waited for me to set up the LAN connection again, after which I was able to set a mirror and choose a set of software packages (GNOME 3).

As this is the first time this happened, I'm not sure if it is repeatable. Will try again.

Version-Release number of selected component:
anaconda-19.20-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:UUID=bf3dd9e9-d3b1-4259-afa2-c42c943b97fc rd.live.check quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

dan: see the commonbugs note - give it a while and try again, or use the DVD or live.

Thanks Adam. My report was automatically filed as a duplicate; I have already read the common bugs note and am trying again. This time seems to be working, adding weight to the "possibly an issue with the selected repo" theory.

yeah, it's a weird issue - if you read back through the comments, for some people just retrying right away works, for some it works the next day, for the other Dan it never seems to work...it's odd.

(In reply to comment #41)
> yeah, it's a weird issue - if you read back through the comments, for some
> people just retrying right away works, for some it works the next day, for
> the other Dan it never seems to work...it's odd.

No it works. But it crashes more than it works.

I have hit this on baremetal now with TC6 on a UEFI install.

I think this is related to partitioning somehow. 

I don't know if others are hitting this with automatic partitioning enabled but after 2nd try and choosing reclaim space and letting anaconda create the partitions instead of creating them by hand the install *seems* to be running. 

But I would say we can rule out physical/virtual/uefi/non-uefi to from this bug as I have tested them all.

Description of problem:
Installing F19 RC4. 

Version-Release number of selected component:
anaconda-19.20-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Alpha\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

I am seeing this while working on some new code, it is frequently failing to read file:///run/install/DD-1/x86_64/repodata/repomd.xml so it isn't limited to just the config file.

Currently I am hitting it 9/10 tries on a KVM PXE setup.

I'm going to jump to conclusions and speculate that there is something funky going on in urlgrabber which is what yum uses to read file:// URI's.

Adding Zdenek Pavlas to the CC to get his thoughts.

I've got such bug when try to build Fedora iso-image with enabled updates-testing repo:

---
Pungi:INFO: Adding repo ourtree
Pungi:INFO: URL for repo ourtree is ['file:///builddir/19/x86_64/os']
hfsplus-tools-540.1.linux3-3.fc19.x86_64
checking for root privileges
checking the selinux mode
checking yum base object
setting up build architecture
setting up build parameters
installing runtime packages
got release: fedora-release
running runtime-install.tmpl
Looking for extra fedup-dracut packages...
installpkg *-fedup-dracut failed: No package(s) available to install
template command error in runtime-install.tmpl:
  run_pkg_transaction
  NoMoreMirrorsRepoError: failure: repodata/repomd.xml from ourtree: [Errno 256] No more mirrors to try.
file:///builddir/19/x86_64/os/repodata/repomd.xml: [Errno 12] Timeout on file:///builddir/19/x86_64/os/repodata/repomd.xml: (28, 'Operation too slow. 
Less than 1000 bytes/sec transferred the last 30 seconds')
Warning: Reusing existing destination directory.
Could not find valid repo at: /builddir/19/x86_64/os
Spawning worker 0 with 4377 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete
Traceback (most recent call last):
  File "/usr/bin/pungi", line 256, in <module>
    main()
  File "/usr/bin/pungi", line 146, in main
    mypungi.doBuildinstall()
  File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 937, in doBuildinstall
    workdir=workdir, outputdir=outputdir)
  File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 243, in run
    rb.install()
  File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line 104, in install
    self._runner.run("runtime-install.tmpl")
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 180, in run
    self._run(commands)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 199, in _run
    f(*args)
  File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 485, in run_pkg_transaction
    self.yum.buildTransaction()
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1263, in buildTransaction
    self.save_ts(auto=True)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6513, in save_ts
    msg += "%s:%s:%s\n" % (r.id, len(r.sack), r.repoXML.revision)
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1661, in <lambda>
    repoXML = property(fget=lambda self: self._getRepoXML(),
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1657, in _getRepoXML
    self._loadRepoXML(text=self.ui_id)
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1648, in _loadRepoXML
    return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes())
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1622, in _groupLoadRepoXML
    if self._commonLoadRepoXML(text):
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1447, in _commonLoadRepoXML
    result = self._getFileRepoXML(local, text)
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1225, in _getFileRepoXML
    size=102400) # setting max size as 100K
  File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1021, in _getFile
    raise Errors.NoMoreMirrorsRepoError(errstr, errors)
yum.Errors.NoMoreMirrorsRepoError: failure: repodata/repomd.xml from ourtree: [Errno 256] No more mirrors to try.
file:///builddir/19/x86_64/os/repodata/repomd.xml: [Errno 12] Timeout on file:///builddir/19/x86_64/os/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')
---

Description of problem:
Problem happened during new user creation.

Version-Release number of selected component:
anaconda-19.20-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Alpha\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

This error comes from curl's Curl_speedcheck function so I think there is something going wrong with its calculation on file:// transfers.

I changed the urlgrabber setting for LOW_SPEED_LIMIT to 1 instead of 1000 and I am still consistently seeing this error in my tests.

Any additional advice for debugging would be appreciated. I can reproduce this in my setup 9/10 tries.

It appears that curl isn't resetting itself correctly when a new request is made. Something about the starting state causes it to mis-calculate the transfer time for the file.

If I add the following before making the calls to add the local repos the install works fine, no timeout errors:

+        with _yum_lock:
+            from urlgrabber import grabber
+            grabber.reset_curl_obj()

What version of python-urlgrabber is being used?  There was a rather nasty bug that could be related (BZ 923951), but that has been fixed in python-urlgrabber-3.9.1-26.fc19 almost month ago, and urlgrabber is resetting the curl object before each request.  The relevant commit is here: http://yum.baseurl.org/gitweb?p=urlgrabber.git;a=commitdiff;h=129e0e98

I've just checked that the curl object is being reset for file:// urls, too.

Why is this assigned to curl?  Do we have any (py)curl-based reproducer of the issue?

Sorry, I don't have a simple reproducer for this. But I am consistently hitting it with my boot.iso setup. The reason I re-assigned it to curl is that:

1 - the error is generated by the speedcheck function in curl.
2 - It works if I increase the timeout to some insane level, like 300000
3 - It works if I reset the curl object right before adding repos (without increasing the timeout).
4 - It appears to abort the file grab immediately. There is no 300 second delay from when it tries to when it gets the error, indicating a timing problem.

curl should be resetting its timers on each file grab, we shouldn't need to reset the object outside of curl.

The version of urlgrabber I am using has the fix for bug 923953 (that was the first thing I checked), but I am not sure of the exact version. I think I used Alpha TC6 as the base for this PXE setup, but I'll have to see if I can find a version number somewhere.

Also note that we are seeing this across a number of different setups, not just KVM, but also bare metal installs as well as pungi runs.

curl --version reports 7.29.0 and urlgrabber is 3.9.1 with the _do_open reset() call in place. The image doesn't have any more exact version numbers than that in it.

Probably found the root cause of this..

data->state.keeps_speed is not being reset between requests.  curl_easy_reset() zeroes out data->set and data->progress, but the keeps_speed variable is stored in data->state instead (should be in progress, probably).

There's Curl_speedinit() function to zero it out, called from do_init().  But alas, create_conn() skips do_init() for connections that don't require network.

3.9.1-26 went stable a long time ago, on 03-27. The builds people have been hitting this with definitely had 3.9.1-26 in them.

I haven't been able to net install F19 Alpha yet because of this...

Removing the RejectedBlocker for Alpha from the Whiteboard
so this gets attention as a Beta blocker.

Thanks for the analysis.  I will try to create a libcurl-based reproducer on my own.

I've patched curl, so the keeps_speed timestamp is reset also before each file:// request.  Should fix #4 (immediate abort).

scratch build is available there:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5304060

However, I didn't manage to reproduce this, and am not sure why additional reset() did help.  To trigger the 'Operation too slow' error, progress code has to calculate low enough speed && it has to be low for 30 seconds.  Mabye the extra reset() helped with the first part(?)

diff -up curl-7.29.0/lib/url.c.orig curl-7.29.0/lib/url.c
--- curl-7.29.0/lib/url.c.orig	2013-02-06 10:47:19.000000000 +0100
+++ curl-7.29.0/lib/url.c	2013-04-26 10:51:29.361598999 +0200
@@ -4895,6 +4895,9 @@ static CURLcode create_conn(struct Sessi
                           -1, NULL); /* no upload */
     }
 
+    /* since we skip do_init() */
+    Curl_speedinit(data);
+
     return result;
   }
 #endif

There seems to be a similar bug for the FTP protocol, which is fixed already:

    bug 679709

I will try to reuse the reproducer from there:

    attachment #503481 [details]

Created attachment 740383 [details]
libcurl-based reproducer

git-bisect points to the following upstream commit:

https://github.com/bagder/curl/commit/9dd85bce

(In reply to comment #60)
> diff -up curl-7.29.0/lib/url.c.orig curl-7.29.0/lib/url.c
> --- curl-7.29.0/lib/url.c.orig	2013-02-06 10:47:19.000000000 +0100
> +++ curl-7.29.0/lib/url.c	2013-04-26 10:51:29.361598999 +0200
> @@ -4895,6 +4895,9 @@ static CURLcode create_conn(struct Sessi
>                            -1, NULL); /* no upload */
>      }
>  
> +    /* since we skip do_init() */
> +    Curl_speedinit(data);
> +
>      return result;
>    }
>  #endif

This seems like the correct way to fix the bug, will commit it on your behalf.

upstream commit:

https://github.com/bagder/curl/commit/b37b5233

fixed in curl-7.30.0-2.fc20

curl-7.27.0-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/curl-7.27.0-9.fc18

curl-7.29.0-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/curl-7.29.0-6.fc19

curl-7.24.0-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/curl-7.24.0-8.fc17

*** Bug 920764 has been marked as a duplicate of this bug. ***

Package curl-7.24.0-8.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing curl-7.24.0-8.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6720/curl-7.24.0-8.fc17
then log in and leave karma (feedback).

Thanks.

*** Bug 953667 has been marked as a duplicate of this bug. ***

Description of problem:
Trying to install F-19 alpha

Version-Release number of selected component:
anaconda-19.20-1

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   method=ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/releases/test/19-Alpha/Fedora/x86_64/os/
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Alpha

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 141, in run
    threading.Thread.run(self, *args, **kwargs)
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 129, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1398, in preInstall
    self._writeInstallConfig()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 352, in _writeInstallConfig
    self._yumCacheDirHack()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 279, in _yumCacheDirHack
    if not self._yum.conf.cachedir.startswith(self._yum.conf.installroot):
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1001, in <lambda>
    conf = property(fget=lambda self: self._getConfig(),
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 338, in _getConfig
    startupconf = config.readStartupConfig(fn, root, releasever)
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1000, in readStartupConfig
    confpp_obj = ConfigPreProcessor(configfile)
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 91, in __init__
    fo = self._pushfile( url )
  File "/usr/lib/python2.7/site-packages/yum/parser.py", line 205, in _pushfile
    'Error accessing file for config %s' % (absurl)
ConfigError: Error accessing file for config file:///tmp/anaconda-yum.conf

(In reply to comment #73)
> Trying to install F-19 alpha

Could you please try it with libcurl-7.29.0-6.fc19 in use?

curl-7.29.0-6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note: the fix for this was pulled into F19 Beta TC2, so if you want to verify it and you have a reliable reproducer, please test with that. Similarly, if anyone hits this with TC2 or later, then we apparently still have a problem.

curl-7.27.0-9.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

curl-7.24.0-9.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/curl-7.24.0-9.fc17

curl-7.27.0-10.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/curl-7.27.0-10.fc18

curl-7.27.0-10.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

curl-7.24.0-9.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

I still have this problem (sometimes) on F18 with all updates applied (curl-7.27.0-10.fc18).  I'm creating custom install media with pungi, including all non-testing updates, I include a kickstart file in the image etc., and some work, some don't work, sometimes the same image does work one time and fails the other time.

Any help is appreciated.