Bug 498095 - Yum forgets that there are updates if cancelled
Yum forgets that there are updates if cancelled
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-28 16:39 EDT by Neil
Modified: 2014-01-21 18:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-28 19:37:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil 2009-04-28 16:39:58 EDT
Description of problem:
If there are updates available and yum is interrupted while downloading primary_db, it will think that it is up-to-date.

Version-Release number of selected component (if applicable):
yum-3.2.22-4.fc11.noarch

How reproducible:
Unsure; I've seen this several times.

Steps to Reproduce:
1. Wait until there are updates available that you haven't installed
2. Start an update, but interrupt it while it's downloading primary_db:
>> yum update
Loaded plugins: changelog, dellsysidplugin2, fastestmirror, merge-conf, presto,
              : refresh-packagekit
Loading mirror speeds from cached hostfile
rawhide/metalink                                         | 7.5 kB     00:03     
 * rawhide: archive.linux.duke.edu
 * rpmfusion-free-rawhide: mirrors.tummy.com
 * rpmfusion-nonfree-rawhide: mirrors.tummy.com
rawhide                                                  | 3.8 kB     00:00     
rawhide/primary_db                                       | 8.0 kB     00:08 ... 

 Current download cancelled, interrupt (ctrl-c) again within two seconds to exit.

^C

Exiting on user cancel

3. Now run the update again.  It will think that there are no updates available:
>> yum update
Loaded plugins: changelog, dellsysidplugin2, fastestmirror, merge-conf, presto,
              : refresh-packagekit
Loading mirror speeds from cached hostfile
 * rawhide: mirrors.kernel.org
 * rpmfusion-free-rawhide: mirrors.tummy.com
 * rpmfusion-nonfree-rawhide: mirrors.tummy.com
Setting up Update Process
No Packages marked for Update

4. Clear its cache:
>> yum clean all
Loaded plugins: changelog, dellsysidplugin2, fastestmirror, merge-conf, presto,
              : refresh-packagekit
Cleaning up Everything
Cleaning up list of fastest mirrors

5. Now run the update again.  This time, it finds updates:
>> yum update
Loaded plugins: changelog, dellsysidplugin2, fastestmirror, merge-conf, presto,
              : refresh-packagekit
Determining fastest mirrors
rawhide/metalink                                         | 7.5 kB     00:00     
 * rawhide: mirror.hiwaay.net
 * rpmfusion-free-rawhide: mirror.web-ster.com
 * rpmfusion-nonfree-rawhide: mirror.web-ster.com
rawhide                                                  | 3.8 kB     00:00     
rawhide/primary_db                                       |  10 MB     02:34     
rpmfusion-free-rawhide                                   | 3.3 kB     00:00     
rpmfusion-free-rawhide/primary_db                        | 321 kB     00:03     
rpmfusion-nonfree-rawhide                                | 3.3 kB     00:00     
rpmfusion-nonfree-rawhide/primary_db                     |  97 kB     00:01     
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package bind-libs.x86_64 32:9.6.1-0.2.b1.fc11 set to be updated
---> Package bind-utils.x86_64 32:9.6.1-0.2.b1.fc11 set to be updated
---> Package cpp.x86_64 0:4.4.0-3 set to be updated
---> Package cups.x86_64 1:1.4-0.b2.15.fc11 set to be updated
---> Package cups-libs.x86_64 1:1.4-0.b2.15.fc11 set to be updated
---> Package gcc.x86_64 0:4.4.0-3 set to be updated
...etc...

Actual results:
In step 3, it thinks that there are no updates available, likely because it was using the partially-downloaded primary_db from the interrupted step 2.

Expected results:
In step 3, it should have downloaded primary_db again, as the copy obtained in step 2 was incomplete (and shouldn't have been saved or used)

Additional info:
Comment 1 James Antill 2009-04-28 19:37:03 EDT
 It doesn't "forget". When you hit C-c it has a bad/incomplete copy and so reverts to the version it had before (presumably working). It does mark the repo. cache timeout, but I think that's what people want 95%+ of the time.
 "yum clean expire-cache" will ask it to refresh again.

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