Bug 993567 - yum --downloadonly corrupting local repository
yum --downloadonly corrupting local repository
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-06 04:08 EDT by nvwarr
Modified: 2013-08-07 18:56 EDT (History)
6 users (show)

See Also:
Fixed In Version: yum-3.4.3-105.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-07 18:56:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description nvwarr 2013-08-06 04:08:51 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):


How reproducible:

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

Actual results:

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!

Expected results:

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.

Additional info:

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>
    yummain.user_main(sys.argv[1:], exit_code=True)
  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
    os.rename(po.localpath, rpmfile)
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.
Comment 1 Zdeněk Pavlas 2013-08-06 11:06:19 EDT
Hi, thanks for the report.  Seems related to bug 903294, the fix we currently have in is invalid.
Comment 2 Fedora Update System 2013-08-06 11:54:51 EDT
yum-3.4.3-105.fc19 has been submitted as an update for Fedora 19.
Comment 3 Fedora Update System 2013-08-06 19:38:32 EDT
Package yum-3.4.3-105.fc19:
* 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).
Comment 4 nvwarr 2013-08-07 00:26:22 EDT
Yes, that solves the problem. I'm impressed by how fast this got fixed. Great work!
Comment 5 Fedora Update System 2013-08-07 18:56:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.