Bug 468401 - package installed/updated twice, due to newer version obsoleting other package (kernel, kernel-xen)
Summary: package installed/updated twice, due to newer version obsoleting other packag...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-24 15:49 UTC by Pete Zaitcev
Modified: 2014-01-21 23:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-11-16 05:58:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
yum --version (564 bytes, text/plain)
2008-10-24 16:46 UTC, Pete Zaitcev
no flags Details
yum repolist (443 bytes, text/plain)
2008-10-24 16:46 UTC, Pete Zaitcev
no flags Details
yum list --showduplicates kmod\* kernel\* (6.48 KB, text/plain)
2008-10-24 16:47 UTC, Pete Zaitcev
no flags Details
yum -d9 -y update 2>&1 | tee yum-d9.run-fail (112.21 KB, text/plain)
2008-10-27 03:00 UTC, Pete Zaitcev
no flags Details
yum -d9 -y update 2>&1 | tee yum-d9.run-rerun (233.96 KB, text/plain)
2008-10-27 03:01 UTC, Pete Zaitcev
no flags Details

Description Pete Zaitcev 2008-10-24 15:49:17 UTC
Description of problem:

At every run of yum update, there's a download error for kernel. A re-run
installs all packages (including kernel!) without downloading anything.

Version-Release number of selected component (if applicable):

yum-3.2.19-5.fc10

How reproducible:

Every time.

Steps to Reproduce:
1. Run "yum update"
2. It fails with "Error Downloading Packages:"
3. Run "yum update" again
4. Everything 
  
Actual results:

yum must be run twice

Expected results:

yum working from the first attempt

Additional info:

It started happening a while ago, but I thought it was a problem with
mirrors or something, so didn't file a bug. Sorry.

This may require actual failures to download the kernel. It looks like
failures do occur, yum retries and eventually downloads the right kernel,
but gets confused about its success. On restart it rechecks what is
available, finds and uses the good package.

No idea why only kernel fails this way.

Comment 1 James Antill 2008-10-24 16:14:30 UTC
Can you run:

yum --version
yum repolist
yum list --showduplicates kmod\* kernel\*

...also if you could attach a -d 9 yum update that fails, that might also help.

Comment 2 Pete Zaitcev 2008-10-24 16:46:10 UTC
Created attachment 321434 [details]
yum --version

Comment 3 Pete Zaitcev 2008-10-24 16:46:37 UTC
Created attachment 321435 [details]
yum repolist

Comment 4 Pete Zaitcev 2008-10-24 16:47:01 UTC
Created attachment 321436 [details]
yum list --showduplicates kmod\* kernel\*

Comment 5 Pete Zaitcev 2008-10-24 16:47:34 UTC
yum -d 9 had to wait a bit until a new kernel is pushed to Rawhide

Comment 6 James Antill 2008-10-24 17:55:24 UTC
Well apart from the fact some of the rpmfusion kmod names make my eyes bleed, it looks it should be fine ... from what I can see.

So if you could post the -d9 output when a new kernel is released, that'd be great.

Comment 7 Pete Zaitcev 2008-10-27 03:00:39 UTC
Created attachment 321571 [details]
yum -d9 -y update 2>&1 | tee yum-d9.run-fail

Initial run -- fails the download

Comment 8 Pete Zaitcev 2008-10-27 03:01:35 UTC
Created attachment 321572 [details]
yum -d9 -y update 2>&1 | tee yum-d9.run-rerun

Rerun -- uses local kernel downloaded just now

Comment 9 James Antill 2008-10-27 04:16:35 UTC
 Ok, I think this is the problem:

 kernel                        x86_64 2.6.27.4-47.rc3.fc10      rawhide    21 M
 kernel                        x86_64 2.6.27.4-47.rc3.fc10      rawhide    21 M
     replacing  kernel-xen.x86_64 2.6.26-0.1.rc6.git2.fc10

...what is happening here is that it counts them as two packages, so downloads the first one and then when it comes to downloading the second it assumes it already has _some_ of it, but not all ... so it asks for the rest, and HTTP responds with "request range not satisfiable". At which points it goes to the next mirror until it fails.
 Then next boot it just checks the file of "both" and sees it's all there, so is happy.

Fixed in upstream commit: cfe3b8342976ba05e140d776ba67660c893cabd5

We might want to fix the root cause too, so I'm going to leave this open.

Comment 10 Pete Zaitcev 2008-11-16 05:58:53 UTC
The case works for me in yum-3.2.20-3.fc10, closing.


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