kickstart too short timeouts, too little retries

[Tero Karvinen]

Installer has too short timeouts and too little retries for kickstart. Downloading packages and writing to disk should simply try again if not succeeding at first.

1) Started installing Breezy with kickstart on 17 computers
2) 4 computers failed to install, failed: base system, partitioning, grub-install, downloading from network
3) retried a couple of times
Every computer was installed successfully after manual retries.

If retrying fixes the problem, why can't the installer do it for me? When installing a lot of computers, it really does not matter (that much) if automatic installation takes 30 min or an hour and a half, but it really matters if I have to continously run around to manually force retries.

Suggestion: make installer more robust by adding more retries with growing timeouts.

[Tero Karvinen (karvinen+launchpad)]

There are too short timeouts in interactive installation too. On about 30 interactive Breezy cdrom installs on computers with dirty cdrom drives, most installations succeeded after retries. Installer could try harder to read cdroms.

[Phoenix591 (phoenix591)]

so have you retried with a newer version? marking as invaild for now....

[Tero Karvinen (karvinen+launchpad)]

Yes, the same thing with Dapper and interactive installation from network.

If you need more info, I think the marking is something like "needs info", not invalid.

Thanks for your comment!

[Phoenix591 (phoenix591)]

ok, sorry, this seemed like an abandoned bug, you never know with bugs that go 2 years without a comment. Have you tried any newer releases, like fiesty or gutsy to see if they have changed the amount of retries and timeouts? I'm very inframiller with network installs

[fool (cmccraw)]

this is still a problem with hardy. i experience exactly the same symptoms as the original poster--sometimes the install hangs as the network goes up/down, retrying enough times will fix it. while the true source of my problems is probably a flaky ethernet driver in the installer kernel or a network cable (new setup, haven't debugged yet), a little robustness would work around a lot of problems.

[Vish (vish)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[rusivi2 (rusivi2-deactivatedaccount)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Colin Watson (cjwatson)]

Gah. Please stop it. People have repeatedly asked for more information on this bug, apparently as a default action. Generally somebody has replied. On the occasion where nobody bothered to reply, it gets closed. This isn't how it works. Bugs don't get fixed simply by time expiring - a developer has to take action on them.

Reopening and setting to Triaged in the hope that people will stop playing with the status. This is a hard bug to fix because it spans lots of layers; there are several different components (apt, debootstrap, anna, etc.) responsible for downloads here, and each of them would have to arrange for retries. As a result I don't expect that it will be fixed particularly soon. However, that's no reason to close it simply because time has passed.

[Tero Karvinen (karvinen+launchpad)]

Thanks Colin. My thoughts exactly, but written in a better way.