Bug 584696 - F13 beta installer hangs while installing dracut
F13 beta installer hangs while installing dracut
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2010-04-22 04:26 EDT by David Paschal
Modified: 2011-06-06 13:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-06 13:25:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Paschal 2010-04-22 04:26:15 EDT
Description of problem:

Did a boot.fedoraproject.org-based network install of F13 beta.  Mostly default install options, except changed system profile type from desktop to software development, and added "KDE" and "KDE software development" package groups.  Installer hung while installing the "dracut" package.  I suspect this is an intermittent problem not specific to the "dracut" package, and if it happens again it might hang on a different package.  System is otherwise responsive; I can move the mouse pointer around, and I can switch to other VTs and issue shell commands, but no installer progress or network activity has been observed in 30+ minutes.

Version-Release number of selected component (if applicable):

Fedora 13 beta

How reproducible:

It happened on the first (and so far only) try.

Steps to Reproduce:
1. See above for description.
Actual results:

Installer hangs while installing the "dracut" package.

Expected results:

Installer should successfully install all packages without hanging.

Additional info:
Comment 1 Chris Lumens 2010-04-22 08:27:16 EDT
What're the results of ps -ef?  Can you attach /tmp/anaconda.log and /tmp/syslog?
Comment 2 David Paschal 2010-05-02 19:18:30 EDT
Sorry, unfortunately I had powered down the system after the failed install, and it appeared that /tmp/anaconda.log and /tmp/syslog weren't saved on the disk either.  I tried to reinstall several times but wasn't able to reproduce the issue again.  However, here's some additional information and thoughts that may still prove useful.

During the failed install, I got numerous errors about failures to download packages along with the "reboot or retry" prompt, but each time after I selected "retry" it continued successfully, presumably by trying a different mirror server, at least for a while until another error on a subsequent package.  In contrast, I experienced few or no such errors on the subsequent reinstalls that completed successfully.  This first (failed) install attempt happened shortly after F13-beta had been released, so the mirrors were probably much busier and more prone to failure at that time than with the later installs after things had settled down a bit.

Yesterday while running "yum -y update" on a different machine with Fedora 12, it hung indefinitely while downloading one of the updated package files.  When I came back to it after it had been in that state for about an hour, I aborted it with ^C, and it completed successfully when I retried the update operation.  And then just today while running "yum -y update" for the first time on the F13-beta system that was the original subject of this bug report, it got into a similar state, but while trying to download one of the package database files (I forget which one) rather than a specific updated package file.  In this latter case, yum was displaying extremely large estimated-completion times suggesting to me that the download was completely stalled, and it continued successfully after I pressed ^C once, causing it to try a different mirror server.

The common thread here, which I suspect is also the culprit with the original installation failure, is that there seem to be cases where a download operation from a mirror server begins successfully but stalls part-way through, and the installation utility (be it anaconda or yum) waits indefinitely to finish what it started.

My suggestion would be to augment the various download routines to have a reasonable timeout on data transfers during the download of a given file, in addition to whatever timeouts apply when making the initial TCP/IP connection attempt.  Furthermore, I think it would be a good idea whenever a download fails (whether due to initial-connection or during-transfer timeout or prematurely-closed connection) to automatically try failing over to other mirrors before giving up and displaying an error message.  yum usually seems to be pretty good about failing over to another mirror server when it actually decides that a download has failed, but I have my doubts about anaconda given my experience described above, where it would error out but continue successfully after I immediately selected "retry".
Comment 3 Manuel Faux 2010-08-19 17:29:54 EDT
David, can you reproduce the bug on current F13?

Fedora Bugzappers volunteer triage team
Comment 4 David Paschal 2010-10-07 16:27:52 EDT
I think I was able to reproduce it once on released-F13, using boot.fedoraproject.org, but it hung on a different package than dracut.  When I tried it again more recently, I got so many error messages about failure to download various packages (which would succeed after clicking Retry), that I gave up on BFO and downloaded the DVD instead.  If nothing else, there's definitely still an robustness/usability issue with package download operations.  The installer should do better about retrying (perhaps trying other mirrors if available) instead of just waiting for user intervention, and the default selection (if the user just presses Enter) should be Retry instead of Abort.  If possible, it would be good if the installer could continue to retry periodically in the background even when the Retry/Abort dialog is displayed, and if it succeeds later, it could automatically dismiss the dialog and continue on with the installation.  That would allow for unattended installations.
Comment 5 Bug Zapper 2011-06-02 11:00:21 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
Comment 6 David Paschal 2011-06-02 14:44:05 EDT
OK to close it.  I was able to install F15-beta recently using BFO without experiencing any of these issues.  In general, however, to be on the safe side I usually burn a DVD image and install from that, then install updates after booting into the newly-installed system.

Note You need to log in before you can comment on or make changes to this bug.