Description of problem: During a Fedora 20 network install, Anaconda will take a long time to complete "setting up installation source..." when using a slow Internet connection. During this time, Anaconda does not provide any indication that something is happening. As a result, the user might think the process has hung. Version-Release number of selected component (if applicable): Fedora 20 How reproducible: Every time Steps to Reproduce: Perform a network install using Fedora-20-x86_64-netinst.iso over a slow network connection. Actual results: Within the "INSTALLATION SUMMARY" screen, Anaconda displays: INSTALLATION SOURCE: Setting up installation source... Expected results: It would be nice if a progress bar provided reassurance that something is happening. Additional info:
Well, it is either doing something (Setting up installation source...) or fails if for example your Internet connectivity fails/times out. Also I am not sure we can get any repository setup progress from Yum, but I have added this to our DNF wishlist[1], just in case. [1] https://fedoraproject.org/wiki/Anaconda/DNFWishlist
Well… I can certainly understand "slow" connections could take a moment but I wouldn't consider 100Mb fiber being one. I was just experiencing a stuck install to VirtualBox and it reoccurred on the second try as well. So yeah, this is not a problem just on a slow connection as it took minutes to find a source on a wired high bandwidth connection.
There's definitely room for some improvement. I tried a network CD installation twice. I waited about 10-15 minutes each time, without any feedback besides the "setting up installation source..." message. FWIW, I have a 70mbit connection (.no). It turns out to be faster to just download the 4.7GB installation DVD...
I am a user, and I would confirm that this behavior also bothers me and I'd like to see more fine-grained progress reporting. And not just on the display, but also in log files. Thanks!
*** Bug 865437 has been marked as a duplicate of this bug. ***
copied from closed duplicate bug: https://bugzilla.redhat.com/show_bug.cgi?id=865437#c7f21-workstation -Beta-RC4 Boxes hangs at "Preparing to install" 2014-11-02 16:17:29 EST seen 2x 1-)Boot.iso in Boxes 1.2 GB memory (waited 15 minutes) also seen in: 2-)Booted L-i-td USB of Workstation DVD Beta RC-4 (waited 35 minutes) But Boxes: SoaS-f21-Beta-RC4 gets past this problem -and boots a liveinst install This may be related to the size of the .iso being used. (SoaS is much smaller)
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Setting up Fedora 23 inside a VM on a rather slow (5mb ADLS2) connection and it just hangs 'setting up network source'. Been waiting 10 minutes for this to complete. I checked the anaconda log file / console output. Nothing indicating this is going to proceed. Need to give the user more feedback about this process. At least make it clear if it fails.
*** Bug 1257767 has been marked as a duplicate of this bug. ***
Same behaviour on a F23 network installation.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Seeing this with Fedora 26 (rawhide) as well, using "Fedora-Workstation-netinst-aarch64-Rawhide-20161013.n.0.iso". Installer is stuck at "Setting up installation source...", eating 100% of one VCPU, and producing zero network traffic.
I see this on Fedora 24 net installs. https://www.centos.org/forums/viewtopic.php?t=46994 is helpful for me in working around this bug by only having one USB device plugged in. However, this does make it impossible to install from one USB device to another.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 EOL if it remains open with a Fedora 'version' of '23'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 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 this bug is closed as described in the policy above. 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.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Hello. Fedora 26 was released. I see the same issue in Fedora 26. Installation hangs on the "Setting up installation source..." for some time (about 1 hours). I use Fedora 26 Server from here: https://download.fedoraproject.org/pub/fedora/linux/releases/26/Server/x86_64/iso/Fedora-Server-dvd-x86_64-26-1.5.iso I tried net install and i seen the same issue. I tried installation from dvd and seen the same issue. I don't understand what the system does for so long... This issue spend a lot of Business time. Please fix it. Is there workaround? Regards, Vlad.
Yeah, it is really annoying having only the dots. I sshed to the anaconda, tried to look at the logs in /tmp - no clues what is going on. 'top' does not reveal any activity. I also cannot see any interesting process in 'ps axjf'. It cannot be downlowding - I use fast mirrors. I see /mnt/sysimage is not mounted during the dots... How do I possibly find out what is causing the installation delay? Any help at least in terms of clues and hints where do I look?
Artem, as I mentioned last October, try only having one USB drive plugged in (or none, but obviously only if installing from optical media). That seems to speed things up tremendously.
Thanks for the hint, I do not have USBs. I guess I wanted to understand how do I diagnose the situation without going into full debugging (watching the souurce, adding few prints, re-run, and repeat).
OK, with tcpdump I can see anaconda trying to contact 209.132.181.15.https (https://apps.fedoraproject.org/)... Even though only local network repositories are specified in KS. And anaconda just keeps printing dots at least for 20 minutes.
PR: https://github.com/rpm-software-management/dnf/pull/870
The progressbar support for metadata loading (i.e. base.fill_sack()) is already implemented in dnf, it is only needed for anaconda to use it. Could be used in following manner: b = dnf.base.Base() b.read_all_repos() b.repos.all().set_progress_bar(dnf.cli.progress.MultiFileProgressMeter(fo=sys.stdout)) b.fill_sack() Where set_progress_bar's argument may be implementation of dnf.callback.DownloadProgress. Next thing is hang without any message, when dnf is waiting for mirrors to answer, currently there is a timeout 30 seconds after which it tries next mirror and repeats the process, this can result in very long waiting without any message. Next step will be to provide this information.
Would be great to never have the dots for anything. E.g., trying different mirrors should also be properly logged. The dots are as good as not printing anything, in my opinion. Thank you!
Pull requests for addition of so named connection_initiation callback (to signalize that dnf is starting a connection to the mirror for metadata to download): https://github.com/rpm-software-management/dnf/pull/906 https://github.com/rpm-software-management/librepo/pull/113/files
I'm seeing a "dots forever" behavior in F26 (but not F25). Like in comment 21, I strace'd the the anaconda python process and saw connections to https on 209.132.181.15. As I continued to monitor though, I saw port 443 connections to other IPs as well. From what I've been able to deduce, all of the IPs are part of the DNS round robin for geoip.fedoraproject.org. If I wait ~30minutes, this geoip lookup appears to giveup and the install continues as normal. My environment consists of a Foreman server where I'm PXE booting my installs. Our corporate network does not allow direct http/https to the Internet (only through a proxy). I have rsync mirrors of the Fedora repos on our local LAN. I've pointed everything in kickstart and the installed system at our internal mirror. Foreman is setting up the kickstart for a text-based anaconda install. Although I'm successfully pulling a kickstart file, geoip lookup appears to be happening (docs say geoip lookup should be disabled for ks installs). I've also tried explicitly passing inst.geoip=0 as part of the PXE/kernel options and seems to have no effect. -Shawn
Hello Shawn The progress information dnf will provide in this case consists of two parts. First (PRs in comment 25) will provide information about initiating of connection to the mirror before any download starts, this is probably where it stuck in your case. After merging those PRs and anaconda adaption, you will see meaningful information instead of dots. Second is progress of metadata download itself, this should already be used by anaconda.
Are there any workarounds or suggestions to debug the issue in F26? Today, I'm updating our internally managed vagrant images. I'm adding F26 and running into the same issue as when PXE installing from Foreman (dots printing for 30+ minutes and then whatever is stuck gives up and install completes normally). It's frustrating to be able to build my other 5 vagrant box images in less time than it takes for only F26 since it's sitting stuck on something. Thanks, -Shawn
(In reply to Shawn K. O'Shea from comment #26) > I'm seeing a "dots forever" behavior in F26 (but not F25). Like in comment > 21, I strace'd the the anaconda python process and saw connections to https > on 209.132.181.15. As I continued to monitor though, I saw port 443 > connections to other IPs as well. From what I've been able to deduce, all of > the IPs are part of the DNS round robin for geoip.fedoraproject.org. If I > wait ~30minutes, this geoip lookup appears to giveup and the install > continues as normal. > > My environment consists of a Foreman server where I'm PXE booting my > installs. Our corporate network does not allow direct http/https to the > Internet (only through a proxy). I have rsync mirrors of the Fedora repos on > our local LAN. I've pointed everything in kickstart and the installed system > at our internal mirror. Foreman is setting up the kickstart for a text-based > anaconda install. > > Although I'm successfully pulling a kickstart file, geoip lookup appears to > be happening (docs say geoip lookup should be disabled for ks installs). > I've also tried explicitly passing inst.geoip=0 as part of the PXE/kernel > options and seems to have no effect. > > -Shawn Hi Shawn, I don't think that your problem is related to this bug. If there is a problem with geolocation, then it needs to be fixed in anaconda. Please, open a new bug for anaconda and add there logs from /tmp. Thank you! Vendy
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 EOL if it remains open with a Fedora 'version' of '26'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 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 this bug is closed as described in the policy above. 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 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.