#354 RFE: prevent broken rawhide network install due to repo change
Closed: Fixed None Opened 16 years ago by afarris.

RFE: prevent broken rawhide network install due to repo change

Problem: network installs will currently fail if the repository changes during the installation, which can take 2-4 hours or more, and changed files are removed from the repo, making anaconda fail to download the expected version of that changed file

If a user has started a network install then any change in files not yet downloaded will completely break that install. The user will see anaconda fail to get the file 10 times, then suggest rebooting and starting the install again. This wastes time and network traffic, since the repository could have only changed the last file that installer needed... and they will subsequently download them all again (this time hopefully missing the period the repo changes).

To solve the problem all that is necessary is for the repo to hold all changed files for a period (probably 3-4 hours for the typical install time) so that any installs that have begun before the changes to the repo data can finish. The depsolving in anaconda does not recognize a change in the repodata and attempt to resume the install with the new data, so either 1) that needs implemented, or 2) the mirrors need to hold the files for awhile even though the repodata no longer has them included.

Would it be possible for the repository data to be created while excluding any files that were updated during that build, leaving the old files out of listings, but actually leave the file present and accessible by direct request?

This would improve the network install experience because it is difficult to anticipate when the repo changes will break the install process for \insert random mirror.

The caveat to the solution is that the repository needs to be cleaned some time later by another process which would know which files are now old (not included in the repo data) and delete them. In the meantime (again suggesting 3-4 hour overlap) there will be a slightly larger disk space needed because of the duplication.

Any mirrors that sync to rawhide while there are duplicated files should have those files already (from the day before) and would only fetch the new files. Those mirrors could either 1) keep the duplicate files all day until the next sync, or 2) have their own cleaning process such as a cron job. In either case, anyone requesting an installation while the duplicates are there would not be effected.

There may be replies to my email to fedora-devel (subject same as this ticket) I sent before opening this.


Any comment on this idea?

I've recently had another rawhide network test install fail due to this; the mirror changed at a time of day I did not expect it to sync, and after downloading several Gb it had to be restarted.

I thought of a possibly simpler method of creating this directory overlap.

Assuming the primary mirror is doing directory renaming when it constructs the new repo build, the files in the prior repo could be symlinked into the new repo directory (without overwriting existing files). After the suggested 3-4 hour grace period lapses all these symlinks could quickly be removed from the new build directory, leaving only files from the new repo build accessible.

Again, it is only the files that get replaced or removed from the new repo that are potentially cause the install failure. If they are available a short time during repo change it is less likely to happen.

please file a bug against anaconda with an RFE to handle redownloading metadata. or a RFE with Release enginering to keep 2 rawhides.

Thanks Dennis

Login to comment on this ticket.

Metadata