Red Hat Bugzilla – Bug 993567
yum --downloadonly corrupting local repository
Last modified: 2013-08-07 18:56:42 EDT
Description of problem:
I package several site-specific programs into rpm packages and have a local repository for those rpms. This is on a disk, which is local and the .repo file in /etc/yum.repos.d uses file: in the baseurl followed by the path.
After creating a new version of an rpm with a higher version number, and createrepo --update, yum update offers to update this package and prompts "Is this ok [y/d/N]:" Selecting "y" or "n" at this stage is fine. Selecting "d" causes the rpm in the local repository to be renamed, so that it no longer has the architecture and .rpm extension in the filename. This breaks the repository. Renaming the file back manually, makes it work again.
Version-Release number of selected component (if applicable):
Always, but the procedure is complicated
Steps to Reproduce:
1. Build a new version of an installed rpm package (with a new version number), sign it and place it in the repository
2. createrepo --update on the repository
3. sudo yum update --downloadonly
Everything looks as though it has worked perfectly, but actually the file in the repository has been renamed. e.g. I had hv_server-20130426-1.fc19.x86_64.rpm installed and created a new version hv_server-20130805-1.fc19.x86_64.rpm and placed it in the local directory and ran createrepo --update. After that, the file was still the same. On running yum update --downonly, the filename changed from hv_server-20130805-1.fc19.x86_64.rpm to hv_server-20130805-1.fc19 (i.e. without the .x86_64.rpm extension).
Note that hv_server is just an example, the same occurs with any package. This just happens to be the one, which annoyed me enough to spend half a morning tracking down the problem!
yum should never alter the repositories. Surely it should just be "downloading" the packages into its cache directory, just like it does for remote repositories? Apparently, that is not the case. Whatever the reason, yum certainly has no business changing _anything_ in the repository.
If I remount the disk where the repository resides readonly just before the yum update --downloadonly, I get:
Traceback (most recent call last):
File "/bin/yum", line 29, in <module>
File "/usr/share/yum-cli/yummain.py", line 316, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 219, in main
return_code = base.doTransaction()
File "/usr/share/yum-cli/cli.py", line 630, in doTransaction
problems = self.downloadPkgs(downloadpkgs,callback_total=self.download_callback_total_cb)
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 2471, in downloadPkgs
OSError: [Errno 30] Read-only file system
It really should be quite legitimate for a repository to be readonly for yum! It might be nfs mounted.
I guess the comment in __init__.py:2470 "overwriting another copy should not be a problem" was a bit optimistic:) Is this connected with bug 491523?
It doesn't make any difference if I do createrepo with or without the --update, though obviously it is much faster with.
yum update --downloadonly and yum update followed by entering "d" give identical results, as one would expect.
I had a cron job running yum update --downloadonly at 2.30 AM so it took me a while to figure out how the corruption was appearing in the repository. If I put a new rpm into the repository and there was no previous version of the rpm installed, no problem. If I installed the new rpm straight away, also no problem, but if I left the old version installed overnight, then the next morning the repository was broken. It took me a while to spot the pattern, so I think it was already before I upgraded from F18 to F19.
Hi, thanks for the report. Seems related to bug 903294, the fix we currently have in is invalid.
yum-3.4.3-105.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing yum-3.4.3-105.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Yes, that solves the problem. I'm impressed by how fast this got fixed. Great work!
yum-3.4.3-105.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.