Description of problem: When trying a net install from an FTP site anaconda just hangs while preparing to install the list of packages. This has happened to me before on FC6 final. I remember this is the URL I tried: ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/core/test/6.92/Prime/i386/os The same URL but with HTTP worked fine.
When it hangs, can you switch ttys? If so, can you run top and see what's going on and also grab /tmp/anaconda.log?
FWIW EL5 seems to have the same bug. Last lines of anaconda.log (actually what is sent to the syslog server, which seems to be identical to anaconda.log): May 29 10:42:18 xxxx INFO moving (1) to step migratefilesystems May 29 10:42:18 xxxx INFO moving (1) to step setuptime May 29 10:42:18 xxxx INFO moving (1) to step preinstallconfig May 29 10:42:18 xxxx WARNING no dev package, going to bind mount /dev May 29 10:42:18 xxxx INFO self.hostname = xxxx.yyyy.zz May 29 10:42:18 xxxx INFO moving (1) to step installpackages May 29 10:42:18 xxxx INFO Preparing to install packages and then it just hangs (tested overnight). The screen on the system itself shows the "preparing to install the list of packages" popup.
Closing due to inactivity; please reopen if you have further information to add to this report
What information do you need? Just try to make a network install from an ftp server. It's 100% reproducible under different versions of Fedora.
I just managed to reproduce this bug in F8t3 on qemu. It's very simple, just do a net install with this server: ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/test/7.92/Fedora/i386/os/ * When it hangs, can you switch ttys? Yes * If so, can you run top and see what's going on and also grab /tmp/anaconda.log? No, it's probably qemu bug. I can't swith to any other tty after switching to tty 1.
Created attachment 226101 [details] Anaconda log All right, I got it.
Thank goodness, I've encountered this bug over and over since FC4, I only thought to report today when I encountered this bug AGAIN recently with F8. It has been present in every version in between. It can also be reproduced with certain mirrors using the http protocol, so it's not something confined to ftp. I've done a lot of experimenting trying to pin down what exactly induces the bug but I've come up blank. It seems any mirror under either protocol can be affected. I look forward to a solution to this, it's been driving me mad for years.
When the bug is encountered, Anaconda comes up with "Starting install process. This may take several minutes..." and stalls at this point. It does not crash, and the other ttys can be switched to. Bug affects both graphical and text mode. Bug is widely reported on range of architectures, I've personally seen it affect x86, x86_64 and ppc64. I've yet to find a sure-find workaround.
Lately I also experienced the same problem with HTTP.
This bug seems to be the same than #152378 (HTTP and FTP URLs are not flexible for netinstall) and #207278 (upgrade failed to get ftp url - path contains /%2F/). The reason seems to be that Anaconda adds a spurious %2F ('/') between the host name xxx.yyy.zzz and the directory pub/..., after adding / on both sides, thus the url looks like xxx.yyy.zzz/%2F/pub/..., and it seems the ftp server rejects this. The reason you don't get anything above (#2 and #6) is probably due that different ftp servers have different timeouts. On ftp.proxad.net the timeout is about 2 seconds, thus you clearly see the problem with Ctrl-Alt-F3. On ftp.ciril.fr the timeout seems to be 10 minutes. If you found a workaround, please tell me.
I see this bug is still alive and well. I've been trying to do a netinstall for the last 2 hours (my DVD burner is broken, unfortunately). On my 6th mirror now, alternating protocols but simply no joy. Does NO-ONE have any idea about this? I actually don't think it's the '/' suffixing bug, since it works sometimes on certain mirrors and then fails at a later date on the same mirror. Argh...
Also it wouldn't be able to download the stage2.img if it was rejecting the file transfer on the account of incorrect URL.
Can you retest on F9-Alpha or current rawhide ? Do you see the new URL method and URL entry dialog ? When you see the apparent hang {waiting}, do you see on VT3 {ctrl-alt-f3} messages like: WARNING : Try 2/10 for xxx://yyy/path.rpm Failed ? What is the exact message ?
I attached a log, do you need more information?
Felipe: I guess I was asking: with the changes since 2008-01-25 is this still a problem ? Note, this wont fix F8 or earlier {it's part of the released installer}. As you can imagine the Fedora code base keeps moving forward, and F9Alpha {2008-01-20} is the current development release or rawhide {current} to test if changes since 2007-12-15 have solved this problem {in your opinion} ? For me, while booting boot.iso and doing a ftp install took a long time at the preparing to install stage - but it does succeed.
I tried http install with mirrors.kernel.org and it failed exactly the same way. Fedora 9 Alpha.
Tried http and ftp install using boot.iso from Rawhide. Anaconda seems to print twice the server name from user entered URL: INFO : transferring http://ftp.uni-erlangen.deftp.uni-erlangen.de//pub/... Installer version is Anaconda-11.4.0.53.
I saw some changes go into rawhide that fix the double slash issue. can you please test with current rawhide.
This is not a double slash issue, it's probably a mirroring issue. I have tried multiple times, before and after the releases and there's always one who thinks the issue is fixed and I should try again. I'll wait for the final release and since nobody has done anything to fix this particular issue I will probably report back that the issue is still there.
Hi Felipe, I am about to install f9preview to test this net install issue, and I want to duplicate your method of booting the installer. I don't need the details, just the method: - rescue iso image ? - pxelinux/vmlinux & initrd to /boot ? - images/boot.iso ? - other ? Also, gui or text mode install ? I'll try my nearest mirror first, but then I would like to try the one you have the most trouble with, if you would like to mention that. ps. There is less than two weeks to re-test whether the latest installer changes have improved this situation, and potentially have a fix included in F9. Testing now would be greatly appreciated if you have some hardware and the time -;)
Actually quite often I use diskboot.img, but I've had the issue with boot.iso, Live CD, etc. I use GUI, but I've had the issue with text mode too. This is the one that I think has never worked with me: ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/ As I already mentioned, I also tried with mirrors.kernel.org and it failed the same way.
(In reply to comment #21) > Actually quite often I use diskboot.img, but I've had the issue with boot.iso, > Live CD, etc. > > I use GUI, but I've had the issue with text mode too. I just tested on an old HP omnibook 4150 notebook, by downloading and burning: http://mirror.pacific.net.au/linux/fedora/linux/development/i386/os/images/ boot.iso 29-Apr-2008 22:57 115M Then booting that and performing a gui URL install: ftp://mirror.pacific.net.au/linux/fedora/linux/development/i386/os I unselected office/productivity to reduce the download time. This succeeded without problems. Going to try funet now.
(In reply to comment #22) > Going to try funet now: ===== Example ftp, gui install, grub booting the pxeboot/vmlinux,initrd.img: Downloading stage2 took a long time. Checking dependencies in packages selected for installation. took a long time. Error: The file system-config-language-1.2.15-2.fc9.noarch.rpm cannot be opened. This is due to a missing file, a corrupt package or corrupt media. Please verify your installation source. If you exit, your system will be left in an inconsistent state that will likely require reinstallation. Checking dependencies in packages selected for installation. took a long time. ctrl-alt-F3: WARNING : Try 6/10 for ftp://ftp.funet.fi... failed ... WARNING : Try 10/10 for ftp://ftp.funet.fi... failed WARNING : Failed to get ftp://ftp.funet.fi... from mirror 1/1, or download is corrupt Went to starting install process. This may take a few minutes... Same sequence to determination of can't find the file. Note that: checking whether that file exists from another machine shows that it no longer exists. ie has changed to -3.fc9. ===== So the cause of this particular failure is that the file that anaconda thinks it requires no longer exists on the server we are downloading from. Felipe: Are these the messages that you see, or did I just randomly hit another issue ?
I've had that error, specially with non final releases. That's why I think the original bug is related to mirrors, but that's not it. In the bug I'm reporting anaconda hangs before starting all that process, no error. I'll try again with the latest build.
With the latest build I'm not able to reproduce this error, but it might still be there.
While netinst (Fedora 9 Beta, text-mode installation via ftp) has failed with two german mirrors, it suceeded with the third one. Mirrors that failed (retrieval of rpm meta data): ftp://ftp-stud.hs-esslingen.de ftp://fedora.tu-chemnitz.de Mirror that suceeded: ftp://ftp.uni-bayreuth.de The md5sum's didn't match.
Clearly something needs to be done about the way the "mirrors" are set up. Perhaps a new bug report?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The reason you're seeing it hang in that one particular place is because anaconda is downloading headers for each package so it can perform a transaction test. So, you are likely seeing the same problem regarding downloading there that you were seeing with other mirrors, just in a different place. Seems to me like the problem here is that you are installing at a time when the packages on a specific mirror have been updated, but the repodata itself has not. So, the mirror is in an inconsistent state and anaconda gets confused. I'm not sure exactly what we can do about that, really.
The combination of defaulting to the use of the mirror list as well as some of the checks which MirrorManager now does should help with this problem significantly for Fedora 10.
Awesome! Thanks.(In reply to comment #30) > The combination of defaulting to the use of the mirror list as well as some of > the checks which MirrorManager now does should help with this problem > significantly for Fedora 10. Awesome! Thanks.