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.
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.
Created attachment 321434 [details] yum --version
Created attachment 321435 [details] yum repolist
Created attachment 321436 [details] yum list --showduplicates kmod\* kernel\*
yum -d 9 had to wait a bit until a new kernel is pushed to Rawhide
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.
Created attachment 321571 [details] yum -d9 -y update 2>&1 | tee yum-d9.run-fail Initial run -- fails the download
Created attachment 321572 [details] yum -d9 -y update 2>&1 | tee yum-d9.run-rerun Rerun -- uses local kernel downloaded just now
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.
The case works for me in yum-3.2.20-3.fc10, closing.