Bug 468401

Summary:

package installed/updated twice, due to newer version obsoleting other package (kernel, kernel-xen)

Product:

[Fedora] Fedora

Reporter:

Pete Zaitcev <zaitcev>

Component:

yum

Assignee:

Seth Vidal <skvidal>

Status:

CLOSED RAWHIDE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

rawhide

CC:

ffesti, james.antill, katzj, pmatilai, tim.lauridsen

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2008-11-16 05:58:53 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
yum --version	none
yum repolist	none
yum list --showduplicates kmod\* kernel\*	none
yum -d9 -y update 2>&1 \| tee yum-d9.run-fail	none
yum -d9 -y update 2>&1 \| tee yum-d9.run-rerun	none

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.