Bug 903294 - yum --downloadonly install fails for the media repo with "Read-only file system"
Summary: yum --downloadonly install fails for the media repo with "Read-only file system"
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 18
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-23 16:39 UTC by Cristian Ciupitu
Modified: 2013-12-21 16:23 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-12-21 16:23:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Cristian Ciupitu 2013-01-23 16:39:30 UTC
Description of problem:
yum --downloadonly install fails with packages from the media repository, e.g. install DVD (which is read-only). While the error is "Read-only file system", the packages already exist in that repository, so yum doesn't need to write anything there.

Version-Release number of selected component (if applicable):
yum-3.4.3-47.fc18.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Configure the media repository like this:
[media]
name=Fedora $releasever - $basearch media
baseurl=file:///mnt/misc/Fedora-DVDs/$releasever/$basearch/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
metadata_expire=-1
cost=500
#async=0

2. Try to download a package from the DVD repository, e.g. gnome-icon-theme-extras
	yum -y --downloadonly install gnome-icon-theme-extras
  
Actual results:
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 319, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 227, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 558, in doTransaction
    problems = self.downloadPkgs(downloadpkgs, callback_total=self.download_callback_total_cb) 
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 2344, in downloadPkgs
    os.rename(po.localpath, rpmfile)
OSError: [Errno 30] Read-only file system

Expected results:
No error.

Additional info:
It fails with async=0 too.
yum install without --downloadonly works fine.

Comment 1 James Antill 2013-01-25 19:19:39 UTC
 Simple fix, upstream:

commit a27f69747c5c82b35d39dc631d3964436e3eec13
Author: James Antill <james>
Date:   Fri Jan 25 14:18:58 2013 -0500

    Don't fail for file based repos. when using --downloadonly. BZ 903294.

diff --git a/yum/__init__.py b/yum/__init__.py
index 3411bd7..509b231 100644
--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -2322,7 +2322,10 @@ much more problems).
                     # we may throw away partial file here- but we don't lock,
                     # so can't rename tempfile to rpmfile safely
                     misc.unlink_f(po.localpath)
-                if po not in errors:
+
+                #  Note that for file:// repos. urlgrabber won't "download"
+                # so we have to check that po.localpath exists.
+                if po not in errors and os.path.exists(po.localpath):
                     # verifyPkg() didn't complain, so (potentially)
                     # overwriting another copy should not be a problem
                     os.rename(po.localpath, rpmfile)

Comment 2 Zdeněk Pavlas 2013-01-30 17:39:54 UTC
Hmm, --downloadonly from file:// URLs is effectively a no-op.  
Maybe --downloadonly should imply copy_local=True instead.

Comment 3 James Antill 2013-01-31 18:22:15 UTC
 Yeh, I wondered about this ... it would make a lot of sense for NFS based repos. but it would be wrong for non-NFS based file repos. ... and we'd have to have magically get yum to use copy_local=true when running the transaction later (or it's just refer to the NFS copies anyway, at that point).

Comment 4 Fedora End Of Life 2013-12-21 15:44:04 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Cristian Ciupitu 2013-12-21 16:23:07 UTC
Fixed in yum-3.4.3-127.fc20.noarch.


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