Bug 820351 - It's possible not to get a kernel from the new release when doing an upgrade
It's possible not to get a kernel from the new release when doing an upgrade
Status: CLOSED DUPLICATE of bug 892061
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
AcceptedNTH https://fedoraproject.org...
: CommonBugs
: 815474 823247 825092 826276 826600 826920 827876 (view as bug list)
Depends On:
Blocks: F17-accepted/F17FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2012-05-09 14:13 EDT by Adam Williamson
Modified: 2013-01-23 12:37 EST (History)
34 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-23 12:37:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2012-05-09 14:13:01 EDT
So I'm leaving this kinda open-ended as we're not sure what if anything can be done about it. But it's worth tracking and at least commonbugs'ing for F17 in particular.

Here's the problem:

The kernel team now has a policy of keeping the kernels on all currently supported releases very fresh, and often completely in sync. So let's say we release Fedora N+1 with kernel 4.1.0-2, and at that time, the latest kernel in Fedora N was, say, 4.1.0-1 or even the same (4.1.0-2). Given our current kernel update policies, Fedora N likely has 4.1.0-3 and then 4.2.0-1 coming down the chute. It's highly likely that, quite soon after Fedora N+1 ships, the newest kernel in Fedora N will be *newer* than what's on the Fedora N+1 DVD.

So you do a DVD upgrade from Fedora N to Fedora N+1, and...you wind up still with the Fedora N kernel. I've tested this - I installed Fedora 16 and updated it to the latest kernel, which was newer than what's on the Fedora 17 Beta DVD, then did an upgrade using the Fedora 17 Beta DVD. Result: the upgraded system has only the F16 kernels, no F17 kernel at all.

Sometimes, it's not really a problem to boot a kernel from Fedora N on Fedora N+1, but in the 16/17 case, this isn't true, because of /usr move. You need an initramfs generated post-/usr move to correctly boot and shut down a Fedora 17 system. If you boot Fedora 17 with a kernel whose initramfs was generated prior to /usr move - like a kernel installed while the system was still running Fedora 16! - then the system may possibly fail to boot (I think, with some hardware) and certainly will fail to shut down properly (see http://www.happyassassin.net/extras/shutdown_fail.png ).

As mentioned at the start, it's not entirely clear what can be done about this. It's difficult to handle purely with package versioning, short of using release epochs. Jesse has a suggestion:

<jlk> so in a strict "yum update", I think yum figures out if there is a kernel with a higher n-v-r, and adds it to the transaction as an "install"
<jlk> but we don't have to do that in anaconda
<jlk> we could just find the highest kernel in the install sources and add it as an install

But he's not 100% sure it's plausible or a good thing to do. There may be other options. I definitely wanted to highlight the issue, though, and at least make sure we can note it in documentation for F17.
Comment 1 Adam Williamson 2012-05-09 14:14:02 EDT
Just to save Kevin Kofler the trouble, everyone can imagine Kevin saying 'I've been saying all along that DVD upgrades are completely broken! You fools! YOU FOOLS!' here, and move on.
Comment 2 Adam Williamson 2012-05-09 14:14:26 EDT
Nominating as NTH, in case we do decide to Do Something about it.
Comment 3 Adam Williamson 2012-05-09 14:18:27 EDT
*** Bug 815474 has been marked as a duplicate of this bug. ***
Comment 4 John Dulaney 2012-05-11 23:04:25 EDT
+1 NTH
Comment 5 Robyn Bergeron 2012-05-12 01:14:37 EDT
I will +1 NTH in case we Do Something About It as well.
Comment 6 Bruno Wolff III 2012-05-13 09:11:16 EDT
While I agree that having anaconda do something special for kernels is something we probably want and that can't be fixed for the media after release, I'd want any such fix at this point to be pretty well tested. So in theory I am +1 NTH, but I think we'd want to be careful before pulling in such a fix for f17.
Comment 7 Kamil Páral 2012-05-14 12:27:00 EDT
+1 NTH for sure, but isn't this even more important? If it really can break a lot of upgraded systems, maybe we should completely disable DVD upgrades unless we find a clever work-around? Or we allow DVD upgrades only with network repositories enabled, so that newer packages can be pulled?
Comment 8 Kevin Kofler 2012-05-14 13:07:16 EDT
This just proves what I've been saying all along. As long as the DVD does upgrades without the updates repository, it is a COMPLETELY UNSUPPORTABLE upgrading method.
Comment 9 Tim Flink 2012-05-14 13:39:07 EDT
I see +4 NTH, moving to accepted
Comment 10 Adam Williamson 2012-05-14 19:08:22 EDT
kevin: I already did that for you. comment #1. ;)

kamil: well, 'break' is putting it strongly, I think. I think it depends on the hardware - stuff like software RAID may be problematic, I guess - but in a 'stock' KVM at least, booting 17 on a 16 kernel mostly works, but fails to shutdown cleanly. So really it's okay once you do a 'yum update' and get a real 17 kernel. It would be nice to know for sure if there are configurations that get completely broken, though.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Josef Skladanka 2012-05-16 06:52:54 EDT
I also have F16 kernel after upgrade to F17. Boot is OK, but shutdown causes kernel panic.
Comment 12 Josef Skladanka 2012-05-16 07:00:00 EDT
Also, I can't really install the F17 version (or at least using yum). The version I have installed is 3.3.5-2.fc16, there is 3.3.4-5.fc17 available.

Both `yum install kernel-3.3.4-5.fc17` and `yum downgrade kernel-3.3.4-5.fc17` return "Nothing to do." status.
Comment 13 Ismael Juma 2012-05-19 08:05:51 EDT
I ran into this issue when using preupgrade to go from Fedora 16 to Fedora 17 RC1. Many packages were affected (not just the kernel). The issue seemed to be that Fedora 16 had many newer packages than Fedora 17 RC1 as the respective update for Fedora 17 were only available in updates-testing. It looks to me like enabling updates-testing would have fixed the issue.
Comment 14 Kamil Páral 2012-05-20 08:00:28 EDT
*** Bug 823247 has been marked as a duplicate of this bug. ***
Comment 15 Jesse Keating 2012-05-25 15:21:20 EDT
*** Bug 825092 has been marked as a duplicate of this bug. ***
Comment 16 Panos Kavalagios 2012-05-28 01:53:00 EDT
DVD upgrade is the most robust method to upgrade a Fedora distribution for years now. I'm using that method since Fedora CORE 2. Even I have a network connection, I'm too lazy to setup the network in the installer. I prefer to perform a "yum distro-sync" afterwards. I'm using preupgrade only on systems that I wouldn't care much to have them broken, as preupgrade does that pretty often on packages that are not downloaded correctly or for grub that fails to be installed on master boot sector. So, please leave DVD upgrade alone.

I understand that kernel not being updated is a common issue, but what about the login (relative to Bug 825092)? Is there anything about not being able to log in to the system? Virtual screens are not working either. Is that issue related to the old kernel being loaded?
Comment 17 Adam Williamson 2012-05-28 02:56:20 EDT
That's not a general problem with older kernels on f17, no, but some specific part of your system config could theoretically be triggering it somehow.
Comment 18 Panos Kavalagios 2012-05-28 03:02:37 EDT
OK, thanks Adam! It might be related to systemd that fails to spawn ttys when Xorg fails to start. It might affect systems that their video card is not supported. If I manage to gather more information about that issue, I will file a separate bug.
Comment 19 Kevin Kofler 2012-05-28 09:29:50 EDT
IMHO, the most robust method to upgrade a Fedora distribution is plain yum, but that method is also affected by a variant of this issue, for different reasons: While the current F17 updates kernel will be pulled in by yum, you'll still be running the old F16 kernel until the next reboot.
Comment 20 Jesse Keating 2012-05-29 18:18:35 EDT
*** Bug 826276 has been marked as a duplicate of this bug. ***
Comment 21 Dan Scott 2012-05-29 19:11:08 EDT
After running yum update && preupgrade today, I had both kernel 3.3.7-1 for F16 and 3.3.7-1 for F17 installed. However, grub2.cfg didn't get the F17 version of the kernel (perhaps because N == N?) and continued to boot into an F16 kernel (with corresponding panic on shutdown), until I copied the F16 section of grub2.cfg and ran s/f1c6/fc17/ and grub2-install; then it was happy.
Comment 22 Mads Kiilerich 2012-05-30 08:35:58 EDT
(In reply to comment #21)

How did your /boot/grub2/grub.cfg look like and which files did you have in /boot ?
Comment 23 Kamil Páral 2012-05-30 09:04:18 EDT
Confirmed comment 21. This is an urgent issue, we need to find the problem and fix it ASAP. Currently the upgrades are probably broken for *everyone*. I have created a separate bug for it, bug 826537.
Comment 24 Josh Boyer 2012-05-30 11:15:27 EDT
*** Bug 826600 has been marked as a duplicate of this bug. ***
Comment 25 Adam Williamson 2012-05-30 21:22:16 EDT
Kamil: I already hit and reported that issue earlier in the cycle, but didn't succeed in triaging it at all. https://bugzilla.redhat.com/show_bug.cgi?id=820340
Comment 26 Adam Williamson 2012-05-30 21:29:46 EDT
BTW, I don't think it's correct that 'the upgrades are probably broken for everyone'. I believe the issue, for some reason, affects only preupgrade. I tried to reproduce it with a DVD upgrade (yes, the kernel versions still matched at the time) and couldn't.
Comment 27 Kamil Páral 2012-05-31 03:34:19 EDT
Adam, you're right. Bug 826537 hits only preupgrade users (still a large part of userbase) and it's non-trivial to fix it. This bug (bug 820351) hits DVD upgrades and can be fixed by "yum update". Netinst upgrades are fully functional.
Comment 28 Gilboa Davara 2012-05-31 08:34:36 EDT
(In reply to comment #26)
> BTW, I don't think it's correct that 'the upgrades are probably broken for
> everyone'. I believe the issue, for some reason, affects only preupgrade. I
> tried to reproduce it with a DVD upgrade (yes, the kernel versions still
> matched at the time) and couldn't.

Adam,

Sadly enough, you're most likely incorrect.
On SoftRAID machines I usually install Fedora X along-side Fedora X-1, while both share the same /boot.
Sadly enough, the mere presence of the F16 kernel images in /boot, was enough to trigger this bug on two different machines (2/2).

Thus far, I'm 0/8. :(

- Gilboa
Comment 29 Mads Kiilerich 2012-05-31 08:45:44 EDT
(In reply to comment #28)

Please clarify
- how do you upgrade? (which media / method)
- do you get the f17 kernel correctly installed in /boot with both vmlinuz and initramfs?
- what options for boot loader installation do you choose?
- what /boot/grub2/grub.cfg do you get?
Comment 30 Adam Williamson 2012-05-31 11:52:43 EDT
Kamil: right, sorry, since we've now mixed discussion of two bugs, it has got confusing. :/ I agree with the situation as you summarized it. It is probably impossible to 'fix' _this particular_ bug for the case of f17 DVD upgrades, now.

Gilboa: as Kamil says, _this_ bug - 820351 - does indeed happen quite often, but it shouldn't be a showstopper at all.
Comment 31 Fedora Update System 2012-05-31 12:32:56 EDT
grubby-8.12-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17
Comment 32 Hin-Tak Leung 2012-05-31 12:51:46 EDT
okay, I am bitten by this, despite both being the same version (3.3.7-1)... the f17 kernel is not functional for some reason though, so am using the f16 kernel still...
Comment 33 Adam Williamson 2012-05-31 14:06:31 EDT
Hin-Tak: that is not the same bug, that's https://bugzilla.redhat.com/show_bug.cgi?id=820340 and/or https://bugzilla.redhat.com/show_bug.cgi?id=826537 .
Comment 34 Hin-Tak Leung 2012-05-31 19:40:10 EDT
(In reply to comment #33)
> Hin-Tak: that is not the same bug, that's
> https://bugzilla.redhat.com/show_bug.cgi?id=820340 and/or
> https://bugzilla.redhat.com/show_bug.cgi?id=826537 .

You are right - my problem isn't the same bug, and don't seem to be either of those two. I have (had) two problems: 3.3.7-1.fc16 crashes on shutdown, while 3.3.7-1.fc17 is not functional - fails to find /dev/mapper/Vol... [my root device]. I fixed the latter by reinstalling 3.3.7-1.fc17 with  rpm -ivh --force <koji-url>. Actually I have a 3rd: grub have 3 lines of "error: not found" before giving me the menu, and also after. and a 4th: it did not prompt for "press any key to continue", now it does... (but the 3rd/4th are rather minor considered all the rest are crash/non-bootable problems...). Thanks for the reading though, I'll keep looking elsewhere and possibly filing....
Comment 35 Adam Williamson 2012-05-31 20:30:11 EDT
The crash on shutdown when booting an F16 kernel on F17 is known. It's not really explicitly filed anywhere (we close reports of it as dupes of this bug), because it is unfixable, it's because of usrmove. (Strictly, it happens when you boot using an initramfs generated prior to the /usr move being implemented on your system, but 'f16 kernel on f17' is a close enough approximation).

Your issue with 3.3.7-1.fc17 seems kind of confusing, could you explain in more detail? Exactly what happened when you upgraded? Thanks.
Comment 36 Hin-Tak Leung 2012-05-31 21:37:54 EDT
(In reply to comment #35)
> Your issue with 3.3.7-1.fc17 seems kind of confusing, could you explain in
> more detail? Exactly what happened when you upgraded? Thanks.

I took a digital picture of the messages (before I reinstall the same kernel via rpm -ivh --force <koji-url>). The messages are:

-----------------
error: file not found.
error: file not found.
error: file not found.
Loading Linux 3.3.7-1.fc17.x86_64 ...

Press any key to continue...
------------------

(this part is common to all kernels since I upgraded - I never used to need to confirm, nor have those three lines of errors, which appears both before the grub menu and after making a choice) Then:

--------------
[   0.020998] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[   1.457035] ata1: softreset failed (device not ready)
ata_id[241]: unable to open '$devnode'

dracut Warning: Unable to process initqueue
dracut Warning: /dev/mapper/VolGroup01-LogVol00 does not exist

Dropping to debug shell.

dracut:/#
---------------

The two lines have always been with this machine; /dev/mapper/VolGroup01-LogVol00 is my root device, so I know it exist...
Comment 37 Adam Williamson 2012-05-31 22:14:02 EDT
that sounds almost like the initramfs is messed up, somehow. to be clear, are you saying that this is how the system behaved after you ran preupgrade? and you fixed it by reinstalling the kernel package?
Comment 38 Hin-Tak Leung 2012-05-31 22:35:51 EDT
(In reply to comment #37)
> that sounds almost like the initramfs is messed up, somehow. to be clear,
> are you saying that this is how the system behaved after you ran preupgrade?
> and you fixed it by reinstalling the kernel package?

Yes, to both of your questions. My guess is with a messed up initramfs also. Although the problem is now fixed by rpm -i --force <thesamefromkoji> . The problem is serious enough, given that the old kernel panics on shutdown and the new one did not work :-) - I'd like to understand how it went that way.

Somebody else in a different unrelated bug report commented that when one is doing an upgrade of a few thousand packages, the initramfs may not have pulled all the right things from the filesystem, depends on at what position the kernel is installed among that few thousand packages. Does it sound pausible (and warrant filing a report, or an existing similar report somewhere)?

Actually since preupgrade does upgrade via mounting the existing installation under /mnt/sysimage, does it put something under /mnt/sysimage/dev for "/dev/mapper/...." to work?
Comment 39 Adam Williamson 2012-05-31 22:49:39 EDT
It's vaguely plausible, but the thing is, the /usr move happens before any package installation is started, so that _shouldn't_ be it.

The fact that you have /boot on LVM probably is relevant to your issue somehow, but I'm not sure how.
Comment 40 Hin-Tak Leung 2012-05-31 23:06:15 EDT
(In reply to comment #39)
> It's vaguely plausible, but the thing is, the /usr move happens before any
> package installation is started, so that _shouldn't_ be it.

> The fact that you have /boot on LVM probably is relevant to your issue
> somehow, but I'm not sure how.

No, my /boot is on dos partition 3. /dev/mapper/VolGroup01-LogVol00 is my root and sits in an LVM inside partition 4.
Comment 41 Kamil Páral 2012-06-01 03:44:31 EDT
(In reply to comment #36)
> -----------------
> error: file not found.
> error: file not found.
> error: file not found.
> Loading Linux 3.3.7-1.fc17.x86_64 ...
> 
> Press any key to continue...
> ------------------

I have seen exactly same issue when I performed preupgrade, run grub2-mkconfig, but didn't run grub2-install. The system booted OK after pressing a key. When I executed grub2-install afterwards, the grub was fixed completely.

PS: This is actually a bad bug to discuss this. I believe it's more related to bug 826537. But there so much chaos already that we will have to re-create a bug about DVD upgrades anyway, so it doesn't matter so much.
Comment 42 Kamil Páral 2012-06-01 03:50:41 EDT
(In reply to comment #41)
> I have seen exactly same issue when I performed preupgrade, run
> grub2-mkconfig, but didn't run grub2-install. The system booted OK after
> pressing a key. When I executed grub2-install afterwards, the grub was fixed
> completely.

Actually, the grub is fixed completely, but the system doesn't boot. It's stuck on loading initrd and then nothing happens. Great. I'll investigate further.
Comment 43 Germano Massullo 2012-06-01 04:42:30 EDT
(In reply to comment #42)
> (In reply to comment #41)
> > I have seen exactly same issue when I performed preupgrade, run
> > grub2-mkconfig, but didn't run grub2-install. The system booted OK after
> > pressing a key. When I executed grub2-install afterwards, the grub was fixed
> > completely.
> 
> Actually, the grub is fixed completely, but the system doesn't boot. It's
> stuck on loading initrd and then nothing happens. Great. I'll investigate
> further.

Is your boot stuck similar to this one? (my screenshot)
http://i.imgur.com/SMatx.jpg
Comment 44 Germano Massullo 2012-06-01 04:48:52 EDT
(In reply to comment #27)
> Adam, you're right. Bug 826537 hits only preupgrade users (still a large
> part of userbase) and it's non-trivial to fix it. This bug (bug 820351) hits
> DVD upgrades and can be fixed by "yum update". Netinst upgrades are fully
> functional.

Why is it not trivial to fix it? Which problems can generate forcing the installation of a Fedora N+1 kernel even if the version is older than the Fedora N?
Comment 45 Michal Schmidt 2012-06-01 05:34:59 EDT
(In reply to comment #43)
> Is your boot stuck similar to this one? (my screenshot)
> http://i.imgur.com/SMatx.jpg

The usbfs filesystem has been deprecated for years and does not exist in F17 anymore. Remove it from your fstab.
Comment 46 Germano Massullo 2012-06-01 05:44:36 EDT
(In reply to comment #45)
> (In reply to comment #43)
> > Is your boot stuck similar to this one? (my screenshot)
> > http://i.imgur.com/SMatx.jpg
> 
> The usbfs filesystem has been deprecated for years and does not exist in F17
> anymore. Remove it from your fstab.

That's incredible, I commented that line and it worked. I remember I had to add it to let VirtualBOX reconnize USB devices!
Comment 47 Mads Kiilerich 2012-06-01 05:45:37 EDT
(In reply to comment #41)
> I have seen exactly same issue when I performed preupgrade, run
> grub2-mkconfig, but didn't run grub2-install. The system booted OK after
> pressing a key. When I executed grub2-install afterwards, the grub was fixed
> completely.

grub2 is not stable yet, and configurations generated by grub2-mkconfig is not fully compatible with older /boot content. It is thus sometimes important to run grub2-install before grub2-mkconfig ... and the only feasible way to handle such a 'sometimes' is to 'always' do it.
Comment 48 Adam Williamson 2012-06-01 11:19:14 EDT
mads: see #826537. I explained there why preupgrade is only editing the grub config file and not doing grub2-install...
Comment 49 Mads Kiilerich 2012-06-01 11:29:33 EDT
(In reply to comment #48)

Yes, if "editing the grub config file" means by grubby then everything is fine (but a bit fragile) - the user will keep using the old bootloader and the matching (patched) old config file in /boot.

I was just explaining why running grub2-mkconfig without running grub2-install then would give a situation where the new configuration file couldn't be handled properly by the old bootloader in /boot which cause 'file not found' and 'press...'.
Comment 50 Hin-Tak Leung 2012-06-01 12:41:51 EDT
(In reply to comment #49)
> I was just explaining why running grub2-mkconfig without running
> grub2-install then would give a situation where the new configuration file
> couldn't be handled properly by the old bootloader in /boot which cause
> 'file not found' and 'press...'.

Argh... I think we need a new bug for preupgrade not doing grub2-install ...
Comment 51 Mads Kiilerich 2012-06-01 13:05:40 EDT
(In reply to comment #50)
> Argh... I think we need a new bug for preupgrade not doing grub2-install ...

No - preupgrade will create a kickstart that either tell anaconda to run both grub2-install and grub2-mkconfig _or_ neither of them and rely and grubby.
Comment 52 Adam Williamson 2012-06-01 13:15:43 EDT
Let's try and keep the discussion of preupgrade issues in https://bugzilla.redhat.com/show_bug.cgi?id=826537 .
Comment 53 Mads Kiilerich 2012-06-02 11:44:56 EDT
(In reply to comment #36)
> -----------------
> error: file not found.
> error: file not found.
> error: file not found.
> Loading Linux 3.3.7-1.fc17.x86_64 ...
> 
> Press any key to continue...
> ------------------

Kamil saw this when he ran grub2-mkconfig without grub2-install. That is expected - don't do that.

Hin-Tak Leung, you saw this after a 'clean' anaconda update without any manual tweaking? It shouldn't be possible, but it seems like you are right. Do you have the anaconda logs? Please file a new bug and attach the logs and post a link here ... unless it can be found on some other bug already?
Comment 54 Chris Lumens 2012-06-03 18:09:51 EDT
*** Bug 827876 has been marked as a duplicate of this bug. ***
Comment 55 Hin-Tak Leung 2012-06-03 21:04:07 EDT
(In reply to comment #53)
> Hin-Tak Leung, you saw this after a 'clean' anaconda update without any
> manual tweaking? It shouldn't be possible, but it seems like you are right.
> Do you have the anaconda logs? Please file a new bug and attach the logs and
> post a link here ... unless it can be found on some other bug already?
		
Filed
[Bug 827987] preupgrade does not run grub2-install

I have a 250MB /var/cache/yum/x86_64/17/anaconda-0/ but I don't think that's of any use. I just have "rpm -qa --last" before and after, which may give the order of installation; and also a few digital cam images of the boot messages (which are already transcribed verbatim).
Comment 56 akvasu@gmail.com 2012-06-04 13:01:50 EDT
Hi 

I have tried preupgrade multiple times - with some some ideas from 826537 but I just can't get the F17 kernel. 

Is there any workaround? I am not able to upgrade to Fedora 17 

Thanks
Anup
Comment 57 Adam Williamson 2012-06-04 14:39:26 EDT
You seem to be having problems no-one else is having. What repos do you have enabled in your F16 system? Do you not have the updates repo explicitly enabled, or something?
Comment 58 akvasu@gmail.com 2012-06-05 13:47:46 EDT
Hi Adam 

I have the standard repo's only - 

[root@localhost ~]# cd /etc/yum.repos.d/ 
[root@localhost yum.repos.d]# ls 
adobe-linux-i386.repo            rpmfusion-free-rawhide.repo
fedora.repo                      rpmfusion-free.repo
fedora.repo.BaK                  rpmfusion-free-updates.repo
fedora-updates.repo              rpmfusion-free-updates-testing.repo
fedora-updates.repo.BaK          rpmfusion-nonfree-rawhide.repo
fedora-updates-testing.repo      rpmfusion-nonfree.repo
fedora-updates-testing.repo.BaK  rpmfusion-nonfree-updates.repo
google-talkplugin.repo           rpmfusion-nonfree-updates-testing.repo
[root@localhost yum.repos.d]# 

so I have the updates repo enabled (I think) 

Do I need to add any other repo's to this?
Comment 59 Adam Williamson 2012-06-05 14:34:42 EDT
It's the contents of the files that's important. 'cat /etc/yum.repos.d/fedora-updates.repo' .
Comment 60 akvasu@gmail.com 2012-06-05 14:38:09 EDT
Hi Adam 

Maybe I am using an internal mirror for Fedora... let me try to remove that and check. 

[root@localhost ~]# sudo cat /etc/yum.repos.d/fedora-updates.repo
[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
baseurl=http://rtp-linux.cisco.com/fedora/updates/$releasever/$basearch/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
proxy=_none_
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

[updates-debuginfo]
name=Fedora $releasever - $basearch - Updates - Debug
failovermethod=priority
baseurl=http://rtp-linux.cisco.com/fedora/updates/$releasever/$basearch/debug/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-debug-f$releasever&arch=$basearch
proxy=_none_
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

[updates-source]
name=Fedora $releasever - Updates Source
failovermethod=priority
baseurl=http://rtp-linux.cisco.com/fedora/updates/$releasever/SRPMS/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-source-f$releasever&arch=$basearch
proxy=_none_
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
[root@localhost ~]#
Comment 61 Adam Williamson 2012-06-05 14:46:36 EDT
yeah, try commenting out the baseurl= lines...
Comment 62 bob mckay 2012-06-21 13:08:31 EDT
The original problem described in comment 1 (i.e. upgrading from DVDs without the update repos enabled) seems to have got much worse recently - presumably as more and more f16 packages supersede those on the f17 DVD. I recently upgraded two systems from DVD without knowing about the issue. I ended up with the list of dependency problems at the bottom when I tried to do a post-upgrade update. Attempts to fix this by individually updating packages failed with apparently spurious messages about space on /usr.
Any hints on how to repair this would be greatly appreciated.


###############################################################################
%yum update kernel:

Transaction Check Error:
  installing package kernel-3.4.3-1.fc17.x86_64 needs 98MB on the /usr filesystem

Error Summary
-------------
Disk Requirements:
  At least 98MB more space needed on the /usr filesystem.


###############################################################################
df output:
/dev/mapper/vg_sc2-lv_usr       20415616   8343620  11047996  44% /usr
(i.e. /usr has over 8GB space available). 

###############################################################################
dependency error report from running global yum update after F16->F17 upgrade:

--> Finished Dependency Resolution
Error: Package: sane-backends-drivers-scanners-1.0.22-10.fc16.i686 (@updates/16)
           Requires: sane-backends-libs(x86-32) = 1.0.22-10.fc16
           Removing: sane-backends-libs-1.0.22-10.fc16.i686 (@updates/16)
               sane-backends-libs(x86-32) = 1.0.22-10.fc16
           Updated By: sane-backends-libs-1.0.22-10.fc17.i686 (updates)
               sane-backends-libs(x86-32) = 1.0.22-10.fc17
           Available: sane-backends-libs-1.0.22-9.fc17.i686 (fedora)
               sane-backends-libs(x86-32) = 1.0.22-9.fc17
Error: Package: sane-backends-drivers-scanners-1.0.22-10.fc16.i686 (@updates/16)
           Requires: sane-backends = 1.0.22-10.fc16
           Removing: sane-backends-1.0.22-10.fc16.x86_64 (@updates/16)
               sane-backends = 1.0.22-10.fc16
           Updated By: sane-backends-1.0.22-10.fc17.x86_64 (updates)
               sane-backends = 1.0.22-10.fc17
           Available: sane-backends-1.0.22-9.fc17.x86_64 (fedora)
               sane-backends = 1.0.22-9.fc17
 You could try using --skip-broken to work around the problem
** Found 179 pre-existing rpmdb problem(s), 'yum check' output follows:
ConsoleKit-x11-0.4.5-1.fc15.x86_64 has missing requires of ConsoleKit = ('0', '0.4.5', '1.fc15')
GConf2-gtk-3.2.3-1.fc16.x86_64 has missing requires of GConf2 = ('0', '3.2.3', '1.fc16')
ORBit2-devel-2.14.19-2.fc15.x86_64 has missing requires of ORBit2 = ('0', '2.14.19', '2.fc15')
abrt-retrace-client-2.0.7-3.fc16.x86_64 has missing requires of abrt = ('0', '2.0.7', '3.fc16')
apper-0.7.2-1.fc16.x86_64 has missing requires of libpackagekit-qt2.so.2()(64bit)
atk-2.4.0-1.fc17.x86_64 is a duplicate with atk-2.2.0-2.fc16.i686
audit-libs-2.2.1-1.fc17.x86_64 is a duplicate with audit-libs-2.2.1-1.fc16.i686
avahi-libs-0.6.30-7.fc17.x86_64 is a duplicate with avahi-libs-0.6.30-4.fc16.i686
avahi-ui-0.6.30-4.fc16.x86_64 has missing requires of avahi = ('0', '0.6.30', '4.fc16')
avahi-ui-0.6.30-4.fc16.x86_64 has missing requires of libgdbm.so.3()(64bit)
cairo-1.10.2-7.fc17.x86_64 is a duplicate with cairo-1.10.2-4.fc16.i686
cairo-gobject-1.10.2-7.fc17.x86_64 is a duplicate with cairo-gobject-1.10.2-4.fc16.i686
caribou-antler-0.4.1-3.fc16.x86_64 has missing requires of caribou = ('0', '0.4.1', '3.fc16')
caribou-gtk2-module-0.4.1-3.fc16.x86_64 has missing requires of caribou = ('0', '0.4.1', '3.fc16')
caribou-gtk3-module-0.4.1-3.fc16.x86_64 has missing requires of caribou = ('0', '0.4.1', '3.fc16')
cmake-2.8.8-4.fc16.x86_64 has missing requires of libarchive.so.2()(64bit)
compiz-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64 has missing requires of libboost_serialization-mt.so.1.47.0()(64bit)
compiz-gtk-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64 has missing requires of libboost_serialization-mt.so.1.47.0()(64bit)
compiz-plugins-main-0.9.5.92-1.fc16.x86_64 has missing requires of libboost_serialization-mt.so.1.47.0()(64bit)
cracklib-python-2.8.18-2.fc15.x86_64 has missing requires of cracklib = ('0', '2.8.18', '2.fc15')
db4-utils-4.8.30-3.fc15.x86_64 has missing requires of db4 = ('0', '4.8.30', '3.fc15')
1:dbus-libs-1.4.10-4.fc17.x86_64 is a duplicate with 1:dbus-libs-1.4.10-3.fc16.i686
dkms-2.2.0.3-1.fc16.noarch has missing requires of modutils
expat-2.1.0-1.fc17.x86_64 is a duplicate with expat-2.1.0-1.fc16.i686
farsight2-python-0.0.31-1.fc16.x86_64 has missing requires of farsight2 = ('0', '0.0.31', '1.fc16')
farsight2-python-0.0.31-1.fc16.x86_64 has missing requires of libgstfarsight-0.10.so.0()(64bit)
file-devel-5.07-6.fc16.x86_64 has missing requires of file = ('0', '5.07', '6.fc16')
fontconfig-2.8.0-6.fc17.x86_64 is a duplicate with fontconfig-2.8.0-4.fc16.i686
freetype-2.4.8-3.fc17.x86_64 is a duplicate with freetype-2.4.6-5.fc16.i686
gamin-0.1.10-12.fc17.x86_64 is a duplicate with gamin-0.1.10-10.fc16.i686
gd-2.0.35-16.fc17.x86_64 is a duplicate with gd-2.0.35-14.fc16.i686
gdk-pixbuf2-2.26.1-1.fc17.x86_64 is a duplicate with gdk-pixbuf2-2.24.1-1.fc16.i686
glib2-2.32.1-1.fc17.x86_64 is a duplicate with glib2-2.30.3-1.fc16.i686
glibc-2.14.90-24.fc16.7.i686 has missing requires of glibc-common = ('0', '2.14.90', '24.fc16.7')
glibc-2.15-37.fc17.x86_64 is a duplicate with glibc-2.14.90-24.fc16.7.i686
glibmm24-devel-2.30.0-1.fc16.x86_64 has missing requires of glibmm24 = ('0', '2.30.0', '1.fc16')
gnome-panel-devel-3.2.1-2.fc16.x86_64 has missing requires of gnome-panel-libs = ('0', '3.2.1', '2.fc16')
gnome-user-share-3.0.1-1.fc16.x86_64 has missing requires of libgnome-bluetooth.so.8()(64bit)
gnome-vfs2-devel-2.24.4-6.fc16.x86_64 has missing requires of gnome-vfs2 = ('0', '2.24.4', '6.fc16')
gnutls-2.12.17-1.fc17.x86_64 is a duplicate with gnutls-2.12.14-3.fc16.i686
gpsd-2.95-7.fc16.x86_64 has missing requires of gpsd-libs = ('0', '2.95', '7.fc16')
gpsd-2.95-7.fc16.x86_64 has missing requires of libgps.so.19()(64bit)
gpsd-2.95-7.fc16.x86_64 has missing requires of libgpsd.so.0()(64bit)
gtk2-2.24.8-3.fc16.i686 has missing requires of libcups.so.2
gtk2-2.24.10-1.fc17.x86_64 is a duplicate with gtk2-2.24.8-3.fc16.i686
gtk3-3.2.4-1.fc16.i686 has missing requires of libcups.so.2
gtk3-3.4.3-2.fc17.x86_64 is a duplicate with gtk3-3.2.4-1.fc16.i686
gvfs-afp-1.10.1-3.fc16.x86_64 has missing requires of gvfs(x86-64) = ('0', '1.10.1', '3.fc16')
gvfs-afp-1.10.1-3.fc16.x86_64 has missing requires of libbluray.so.0()(64bit)
ibus-hangul-1.4.1-2.fc16.x86_64 has missing requires of libibus-1.0.so.0()(64bit)
jasper-1.900.1-18.fc16.x86_64 has missing requires of jasper-libs(x86-64) = ('0', '1.900.1', '18.fc16')
jasper-libs-1.900.1-19.fc17.x86_64 is a duplicate with jasper-libs-1.900.1-18.fc16.i686
6:kdemultimedia-4.8.3-1.fc16.x86_64 has missing requires of kdemultimedia-dragonplayer = ('6', '4.8.3', '1.fc16')
6:kdemultimedia-4.8.3-1.fc16.x86_64 has missing requires of kdemultimedia-kmix = ('6', '4.8.3', '1.fc16')
6:kdemultimedia-juk-4.8.3-1.fc16.x86_64 has missing requires of kdemultimedia-libs(x86-64) = ('6', '4.8.3', '1.fc16')
6:kdemultimedia-kio_audiocd-4.8.3-1.fc16.x86_64 has missing requires of kdemultimedia-libs(x86-64) = ('6', '4.8.3', '1.fc16')
7:kdenetwork-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-common = ('7', '4.8.3', '1.fc16')
7:kdenetwork-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-kdnssd = ('7', '4.8.3', '1.fc16')
7:kdenetwork-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-kget = ('7', '4.8.3', '1.fc16')
7:kdenetwork-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-krdc = ('7', '4.8.3', '1.fc16')
7:kdenetwork-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-krfb = ('7', '4.8.3', '1.fc16')
7:kdenetwork-fileshare-samba-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-common = ('7', '4.8.3', '1.fc16')
7:kdenetwork-kopete-libs-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-common = ('7', '4.8.3', '1.fc16')
7:kdenetwork-kppp-4.8.3-1.fc16.x86_64 has missing requires of kdenetwork-common = ('7', '4.8.3', '1.fc16')
kdm-themes-4.8.3-3.fc16.noarch has missing requires of kdm = ('0', '4.8.3', '3.fc16')
keyutils-libs-1.5.5-2.fc17.x86_64 is a duplicate with keyutils-libs-1.5.2-1.fc16.i686
krb5-libs-1.10-5.fc17.x86_64 is a duplicate with krb5-libs-1.9.3-2.fc16.i686
lcms2-2.3-2.fc17.x86_64 is a duplicate with lcms2-2.3-1.fc16.i686
libIDL-devel-0.8.14-3.fc15.x86_64 has missing requires of libIDL = ('0', '0.8.14', '3.fc15')
libX11-1.4.3-1.fc16.i686 has missing requires of libX11-common = ('0', '1.4.3', '1.fc16')
libX11-1.4.99.901-2.fc17.x86_64 is a duplicate with libX11-1.4.3-1.fc16.i686
libXau-1.0.6-3.fc17.x86_64 is a duplicate with libXau-1.0.6-2.fc15.i686
libXcomposite-0.4.3-3.fc17.x86_64 is a duplicate with libXcomposite-0.4.3-2.fc15.i686
libXcursor-1.1.13-1.fc17.x86_64 is a duplicate with libXcursor-1.1.11-3.fc15.i686
libXdamage-1.1.3-3.fc17.x86_64 is a duplicate with libXdamage-1.1.3-2.fc15.i686
libXext-1.3.1-1.fc17.x86_64 is a duplicate with libXext-1.3.0-1.fc16.i686
libXfixes-5.0-2.fc17.x86_64 is a duplicate with libXfixes-5.0-1.fc16.i686
libXft-2.3.0-2.fc17.x86_64 is a duplicate with libXft-2.2.0-2.fc15.i686
libXi-1.6.1-1.fc17.x86_64 is a duplicate with libXi-1.4.5-1.fc16.i686
libXinerama-1.1.2-1.fc17.x86_64 is a duplicate with libXinerama-1.1.1-2.fc15.i686
libXpm-3.5.10-1.fc17.x86_64 is a duplicate with libXpm-3.5.8-3.fc15.i686
libXrandr-1.3.1-3.fc17.x86_64 is a duplicate with libXrandr-1.3.1-2.fc15.i686
libXrender-0.9.7-1.fc17.x86_64 is a duplicate with libXrender-0.9.6-2.fc15.i686
libXtst-1.2.0-3.fc17.x86_64 is a duplicate with libXtst-1.2.0-2.fc15.i686
libart_lgpl-devel-2.3.21-2.fc15.x86_64 has missing requires of libart_lgpl = ('0', '2.3.21', '2.fc15')
libbonobo-devel-2.32.1-1.fc16.x86_64 has missing requires of libbonobo = ('0', '2.32.1', '1.fc16')
libbonoboui-devel-2.24.5-1.fc16.x86_64 has missing requires of libbonoboui = ('0', '2.24.5', '1.fc16')
libcom_err-1.42-4.fc17.x86_64 is a duplicate with libcom_err-1.41.14-2.fc15.i686
libcompizconfig-0.9.5.92-1.fc16.x86_64 has missing requires of libboost_serialization-mt.so.1.47.0()(64bit)
libexif-0.6.20-2.fc17.x86_64 is a duplicate with libexif-0.6.20-1.fc16.i686
libffi-3.0.10-2.fc17.x86_64 is a duplicate with libffi-3.0.10-1.fc16.i686
libgcc-4.7.0-5.fc17.x86_64 is a duplicate with libgcc-4.6.3-2.fc16.i686
libgcj-4.6.3-2.fc16.x86_64 has missing requires of libgmp.so.3()(64bit)
libgcrypt-1.5.0-3.fc17.x86_64 is a duplicate with libgcrypt-1.5.0-2.fc16.i686
libglade2-devel-2.6.4-5.fc15.x86_64 has missing requires of libglade2 = ('0', '2.6.4', '5.fc15')
libgnome-devel-2.32.1-2.fc15.x86_64 has missing requires of libgnome = ('0', '2.32.1', '2.fc15')
libgnomecanvas-devel-2.30.3-2.fc15.x86_64 has missing requires of libgnomecanvas = ('0', '2.30.3', '2.fc15')
libgnomeui-devel-2.24.5-2.fc15.x86_64 has missing requires of libgnomeui = ('0', '2.24.5', '2.fc15')
libgpg-error-1.10-2.fc17.x86_64 is a duplicate with libgpg-error-1.10-1.fc16.i686
libgphoto2-2.4.11-3.fc17.x86_64 is a duplicate with libgphoto2-2.4.11-1.fc16.i686
libgtop2-devel-2.28.4-1.fc16.x86_64 has missing requires of libgtop2 = ('0', '2.28.4', '1.fc16')
libgudev1-182-1.fc17.x86_64 is a duplicate with libgudev1-173-3.fc16.i686
libgusb-0.1.3-2.fc17.x86_64 is a duplicate with libgusb-0.1.3-1.fc16.i686
libieee1284-0.2.11-11.fc17.x86_64 is a duplicate with libieee1284-0.2.11-10.fc15.i686
libjpeg-turbo-1.2.0-1.fc17.x86_64 is a duplicate with libjpeg-turbo-1.2.0-1.fc16.i686
libktorrent-1.2.0-2.fc16.x86_64 has missing requires of libgmp.so.3()(64bit)
2:libpng-1.5.10-1.fc17.x86_64 is a duplicate with 2:libpng-1.2.49-1.fc16.i686
libproxy-python-0.4.7-1.fc16.noarch has missing requires of libproxy = ('0', '0.4.7', '1.fc16')
libpurple-2.10.4-1.fc16.x86_64 has missing requires of libgstfarsight-0.10.so.0()(64bit)
libreport-plugin-reportuploader-2.0.10-3.fc16.x86_64 has missing requires of libreport = ('0', '2.0.10', '3.fc16')
libselinux-2.1.10-3.fc17.x86_64 is a duplicate with libselinux-2.1.6-6.fc16.i686
libsigc++20-devel-2.2.10-1.fc16.x86_64 has missing requires of libsigc++20 = ('0', '2.2.10', '1.fc16')
libstdc++-4.7.0-5.fc17.x86_64 is a duplicate with libstdc++-4.6.3-2.fc16.i686
libtasn1-2.12-1.fc17.x86_64 is a duplicate with libtasn1-2.12-1.fc16.i686
libthai-0.1.14-5.fc17.x86_64 is a duplicate with libthai-0.1.14-4.fc15.i686
libtiff-3.9.5-3.fc17.x86_64 is a duplicate with libtiff-3.9.5-3.fc16.i686
libtool-ltdl-2.4.2-3.fc17.x86_64 is a duplicate with libtool-ltdl-2.4-9.fc16.i686
libudev-182-1.fc17.x86_64 is a duplicate with libudev-173-3.fc16.i686
1:libusb-0.1.3-10.fc17.x86_64 is a duplicate with 1:libusb-0.1.3-9.fc16.i686
libusb1-1.0.9-0.6.rc1.fc17.x86_64 is a duplicate with libusb1-1.0.9-0.6.rc1.fc16.i686
libv4l-0.8.7-1.fc17.x86_64 is a duplicate with libv4l-0.8.7-1.fc16.i686
libvpx-devel-1.0.0-1.fc16.x86_64 has missing requires of libvpx(x86-64) = ('0', '1.0.0', '1.fc16')
libxcb-1.8-2.fc17.x86_64 is a duplicate with libxcb-1.7-3.fc16.i686
libxkbfile-1.0.8-1.fc17.x86_64 is a duplicate with libxkbfile-1.0.7-2.fc15.i686
libxklavier-5.2.1-1.fc17.x86_64 is a duplicate with libxklavier-5.1-1.fc15.i686
libxml2-2.7.8-7.fc17.x86_64 is a duplicate with libxml2-2.7.8-6.fc16.i686
libxslt-python-1.1.26-8.fc16.x86_64 has missing requires of libxslt = ('0', '1.1.26', '8.fc16')
ncurses-libs-5.9-2.20110716.fc16.i686 has missing requires of ncurses-base = ('0', '5.9', '2.20110716.fc16')
ncurses-libs-5.9-4.20120204.fc17.x86_64 is a duplicate with ncurses-libs-5.9-2.20110716.fc16.i686
nss-softokn-freebl-3.13.4-2.fc17.x86_64 is a duplicate with nss-softokn-freebl-3.13.4-1.fc16.i686
p11-kit-0.12-1.fc17.x86_64 is a duplicate with p11-kit-0.6-1.fc16.i686
pango-1.30.0-1.fc17.x86_64 is a duplicate with pango-1.29.4-1.fc16.i686
pixman-0.24.4-2.fc17.x86_64 is a duplicate with pixman-0.24.4-1.fc16.i686
policycoreutils-gui-2.1.4-13.fc16.x86_64 has missing requires of policycoreutils-python = ('0', '2.1.4', '13.fc16')
polkit-0.104-6.fc17.x86_64 is a duplicate with polkit-0.102-3.fc16.i686
pulseaudio-module-gconf-0.9.23-1.fc16.x86_64 has missing requires of libpulsecommon-0.9.23.so()(64bit)
pulseaudio-module-gconf-0.9.23-1.fc16.x86_64 has missing requires of libpulsecore-0.9.23.so()(64bit)
pulseaudio-module-gconf-0.9.23-1.fc16.x86_64 has missing requires of pulseaudio = ('0', '0.9.23', '1.fc16')
pycairo-devel-1.8.10-4.fc16.x86_64 has missing requires of pycairo = ('0', '1.8.10', '4.fc16')
pyclutter-1.3.2-2.fc15.x86_64 has missing requires of libclutter-glx-1.0.so.0()(64bit)
pygobject2-devel-2.28.6-2.fc16.x86_64 has missing requires of pygobject2 = ('0', '2.28.6', '2.fc16')
pygtk2-devel-2.24.0-3.fc15.x86_64 has missing requires of pygtk2 = ('0', '2.24.0', '3.fc15')
python-caribou-0.4.1-3.fc16.noarch has missing requires of caribou = ('0', '0.4.1', '3.fc16')
readline-6.2-4.fc17.x86_64 is a duplicate with readline-6.2-2.fc16.i686
setools-console-3.3.7-19.fc16.x86_64 has missing requires of setools-libs = ('0', '3.3.7', '19.fc16')
sqlite-3.7.11-2.fc17.x86_64 is a duplicate with sqlite-3.7.7.1-1.fc16.i686
sssd-1.8.4-13.fc16.x86_64 has missing requires of libldb(x86-64) = ('0', '1.1.0', None)
system-config-network-1.6.3-1.fc16.noarch has missing requires of system-config-network-tui = ('0', '1.6.3', '1.fc16')
tomcat6-jsp-2.1-api-6.0.32-17.fc16.noarch has missing requires of tomcat6-servlet-2.5-api = ('0', '6.0.32', '17.fc16')
2:vim-enhanced-7.3.515-2.fc16.x86_64 has missing requires of libruby.so.1.8()(64bit)
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-acecad
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-aiptek
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-elographics
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-fpit
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-hyperpen
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-mutouch
xorg-x11-drivers-7.4-2.fc15.x86_64 has missing requires of xorg-x11-drv-penmount
xorg-x11-drv-apm-1.2.3-8.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-glint-1.2.5-2.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-i128-1.3.4-9.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-i740-1.3.2-9.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-intel-2.19.0-3.fc16.x86_64 has missing requires of libxcb-aux.so.0()(64bit)
xorg-x11-drv-intel-2.19.0-3.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-keyboard-1.6.0-2.fc16.x86_64 has missing requires of xserver-abi(xinput-13) >= ('0', '0', None)
xorg-x11-drv-mach64-6.9.0-2.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-mouse-1.7.1-2.fc16.x86_64 has missing requires of xserver-abi(xinput-13) >= ('0', '0', None)
xorg-x11-drv-nv-2.1.18-8.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-r128-6.8.1-11.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-rendition-4.2.4-7.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-s3virge-1.10.4-9.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-savage-2.3.3-1.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-siliconmotion-1.7.5-2.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-sis-0.10.3-7.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-sisusb-0.9.4-7.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-tdfx-1.4.3-9.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-trident-1.3.4-7.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-v4l-0.2.0-14.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
xorg-x11-drv-voodoo-1.2.4-7.fc16.x86_64 has missing requires of xserver-abi(videodrv-11) >= ('0', '0', None)
zlib-1.2.5-6.fc17.x86_64 is a duplicate with zlib-1.2.5-6.fc16.i686
Comment 63 Adam Williamson 2012-06-21 13:19:38 EDT
Bob: it certainly is the case that as time goes on, this issue can happen to more packages. But I suspect in that specific case, there's something else going on. Really not sure what, but I think it would be best to open a new bug and poke about in the logs and stuff.
Comment 64 bob mckay 2012-06-21 13:28:10 EDT
Thanks for the comment Adam. 
I'm currently running:
yum --skip-broken distro-sync
It looks like it's working (at least, it got past the dependency checks OK) - I guess I'll know tomorrow. Will update when I know the result, and will open a new bug if distro-sync doesn't fix it.
Comment 65 bob mckay 2012-06-23 02:20:51 EDT
(In reply to comment #63)
> Bob: it certainly is the case that as time goes on, this issue can happen to
> more packages. But I suspect in that specific case, there's something else
> going on. Really not sure what, but I think it would be best to open a new
> bug and poke about in the logs and stuff.

Adam, you are right, this seems to be a mix of two problems - the original issue here, combined with anaconda(?) not handling a separate /usr partition correctly. I have filed Bug 834746 for it. Basically, after the upgrade /usr only gets mounted ro (maybe this is also happening during the upgrade, which might partially explain the huge mix of f16 and f17 packages). Anyway, for anyone who happens to come here, the solution seems to be to remount /usr rw, then do a distro-sync (see Bug 834746 for more details).
Comment 66 mlatelcom 2012-07-02 05:05:09 EDT
I ran preupgrade-cli and all packages where downloaded. after rebooting I got a grub entry to start the installation process but once it starts booting suddenly drops me to the dracut shell with the no /dev/root msg. Booted into another OS on the same machine(another HDD)to check the files and all the installation files are under /var/cache/yum/ directory but there is nothing in /boot directory.Some directories are empty too; so it looks like the installation process haven't start yet.
Comment 67 Linuxguy123 2012-07-02 23:15:16 EDT
Bob Mckay, I have the exact same problem you do/did.   How did you solve it ?

Thanks
Comment 68 Linuxguy123 2012-07-02 23:42:51 EDT
I was able to update with the following command.

yum --skip-broken --exclude mesa-dri-drivers
Comment 69 bob mckay 2012-07-04 08:12:07 EDT
(In reply to comment #67)
> Bob Mckay, I have the exact same problem you do/did.   How did you solve it ?
> 
> Thanks

What worked for me was, in more detail,

$ mount -o rw,remount /usr
$ yum --skip-broken distro-sync
$ package-clean --orphans > orphs
   (then edit orphs into a 'yum remove' command for all the orphans - lots)
Warning: if you get many dependencies pulled in by the yum remove command, check it again carefully.
$ yum update

reboot
     YMMV...
Comment 70 Josh Boyer 2012-07-05 14:46:58 EDT
*** Bug 826920 has been marked as a duplicate of this bug. ***
Comment 71 Josh Boyer 2012-07-23 17:13:03 EDT
*** Bug 842427 has been marked as a duplicate of this bug. ***
Comment 72 Stuart D Gathman 2012-07-23 22:57:56 EDT
I'd like to point out that upgrading is not the issue.  I did a fresh install - but with a shared /boot with f16.  The f17 kernel was installed, but grub2.cfg picked the f16 kernel as the default!  Boot correctly was a simple matter of going to the "Advanced" subment and picking the correct kernel.

This is related to an ongoing problem for F16,F17 - grub2 adds kernels from older installs in a shared /boot, but with the wrong root filesystem!  You have to manually edit grub2.cfg to fix the root filesystem for older kernels (actually edit /etc/grub.d to avoid doing with every kernel upgrade).

The core problem is grub2-install knowing which kernel goes with which root filesystem.  For starters, it should remember what was in grub.conf or grub2.cfg previously.
Comment 73 Mads Kiilerich 2012-07-24 08:04:21 EDT
(In reply to comment #72)

A shared /boot is thus a very bad idea. It might have worked in the past even though it was a bit fragile, but with grub2 we are moving towards being more well-defined and less fragile, and a ambiguous /boot will not work correctly.

A setup with multiple linux distros will currently require some manual tweaking of grub.cfg.
Comment 74 Bruno Wolff III 2012-07-24 08:48:02 EDT
While I don't have multiple linux instances on my systems, what I have heard recommended for this is to have each instance have its own grub/grub2 area and to have the initial boot on an independent grub or grub2 instance that chain loads into the various instances.
Comment 75 Mads Kiilerich 2012-07-24 09:43:04 EDT
Agreed, and in addition to that:

* Grub upstream has reserved the term "chain load" to imply the "chainload" command that is more deprecated than the documentation imply. It should be better to use "configfile" or the undocumented "legacy_configfile".

* The os-prober part of grub2-mkconfig will currently not handle secondary linux instances correctly.

See also the very brief but uptodate comment in file:///usr/share/doc/grub2-tools-2.0/grub.html#Multi_002dboot-manual-config
Comment 76 Stuart D Gathman 2012-07-24 12:12:09 EDT
While everyones plate is full, and priorities have to be set, in an ideal world, installing multiple linux distros should be straightforward and reliable.  Even considering just Fedora alone, I need to boot F16 (for stuff that's broken in F17),F17, and F18 (to help testing).  

This isn't so much an anaconda bug, as a grub2-install bug, as it happens with every kernel update.  I opened a grub2-install bug, but it was closed as a duplicate of this.  And yet, this doesn't reference grub2.
Comment 77 Mads Kiilerich 2012-07-24 12:38:47 EDT
Stuart, it wasn't mentioned on bug 842427 that you were using a /boot that was shared with a f16 installation and it wasn't clear that it wasn't an upgrade (except that you were "upgrading" your /boot). Your issue should thus perhaps not be marked as a duplicate of this one. It there is more to say then it would be better to continue the discussion there.

Nobody disagree that installing multiple linux distros should be straightforward and reliable. As mentioned in the grub documentation it is a known issue that should be improved "soon".

It is however arguably an anaconda bug that it allowed you to reuse /boot.

(Nitpicking: grub2-install is not involved in creating grub.cfg. That is done by grub2-mkconfig.)

grub2-mkconfig is not invoked on kernel updates. Kernel updates is handled by grubby which will clone the "best" kernel entry. But we don't know what problem you see after kernel updates - it might be a different issue.
Comment 78 Mads Kiilerich 2012-07-24 12:43:38 EDT
(In reply to comment #75)
> See also the very brief but uptodate comment in
> file:///usr/share/doc/grub2-tools-2.0/grub.html#Multi_002dboot-manual-config

I just noticed that the documentation in the official f17 grub2 is outdated. See
http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config .
Comment 79 Adam Williamson 2012-07-25 17:12:26 EDT
Stuart: this bug *is* about upgrading. The problems you describe are not really a case of this bug.
Comment 80 Will Woods 2012-10-10 15:40:25 EDT
There's no inherent reason we need to always install the kernel package. 

Upgrades generally don't install packages that are older than what's already there. (I think we can all agree that's the correct behavior, right?)

The problem is here:

  "You need an initramfs generated post-/usr move to correctly boot and
  shut down a Fedora 17 system."

This bug triggers because *UsrMove migration happens in initramfs*, and initramfs only gets built if kernel is installed.

Unless we're confining all migration tasks to initramfs, I don't think "always install the kernel package" is a good general solution to migration-related problems.
Comment 81 Adam Williamson 2012-10-10 20:19:41 EDT
"(I think we can all agree that's the correct behavior, right?)"

well no, not really. this behaviour has been the source of problems before. A system composed of half packages from the F18 DVD and half packages from F17 updates that happen to be newer than the versions that were current in F18 at the time of release, fr'instance, is not likely to be a very consistent system.

For yum upgrades, we recommend the use of 'distro-sync', not 'update'. The difference between the two, for practical purposes, is *exactly this*: yum --releasever=18 distro-sync will give you all the latest packages from F18, even if they're older than the ones you have installed already. So if you have foo-1.0-2.fc17 installed, and the latest version in F18 is foo-1.0-1.fc18 and you do 'yum --releasever=18 distro-sync', foo will get downgraded to 1.0-1.fc18.

So I don't think it's actually clear-cut that 'always prefer the package with the highest NEVR' is the behaviour we want, no. In another upgrade context, we expressly recommend the process which does _not_ do this.
Comment 82 Kevin Kofler 2012-10-10 20:36:19 EDT
The problem is, if the DVD starts doing a distro-sync, that can lead to downgrading a lot of packages (not just the odd package with broken upgrade path from Fn updates to Fn+1 updates, which IMHO is a packaging bug), and upstream packages often do not support downgrading, especially when it comes to configuration and other user data.

I only have to reiterate that the DVD upgrade as it is implemented now (or at least last I checked, which was before the Anaconda redesign), i.e. no use of the updates repository (the option isn't even offered for upgrades as opposed to fresh installs), is just plain broken and unsupportable. I see only 2 solutions out of this:
* fix the DVD upgrade to (always) include the updates repository (and yes, that requires working network access) OR
* deprecate DVD upgrades entirely (first stop recommending them, then either desupport them entirely or only allow them with the "upgrade" boot-time cheat code as RHEL already does for different reasons).

The fact that we insist on recommending the most broken upgrade method we have to offer (calling it "best" and "safest" when it most definitely isn't) is really bad.
Comment 83 Adam Williamson 2012-10-10 21:12:58 EDT
kev: that was by way of an example, actually. For F18 there is no DVD upgrade, as I understand it. the new upgrade tool, which broadly speaking works like preupgrade - do a 'preparation' step from the running desktop, then reboot to complete the upgrade - is The One True Way.

Will says it will cope with offline upgrades, but I'm not 100% sure what's meant by that - whether it can use an F18 DVD as a package source, or it just means you can download all the packages in the 'preparation' step and then run the upgrade itself without a network connection, or what. But there is no 'DVD upgrade' as there was previously, any more.
Comment 84 Kevin Kofler 2012-10-10 21:36:36 EDT
That makes a lot of sense. :-) Why has it taken 17 releases with the same upgrade path issues to finally get there?

So if the new method includes the updates repository (as it should, and as preupgrade did), shouldn't we just close this bug as NEXTRELEASE? (I don't think it's possible to fix this issue for F17 anymore.)
Comment 85 Adam Williamson 2012-10-10 22:30:50 EDT
"So if the new method includes the updates repository (as it should, and as preupgrade did), shouldn't we just close this bug as NEXTRELEASE? (I don't think it's possible to fix this issue for F17 anymore.)"

well I'd rather know exactly what Will has in mind when he says 'offline upgrades' first, so we know whether this is likely to be an operative concern in future or not.
Comment 86 Will Woods 2012-10-12 14:54:31 EDT
'offline' as in 'from a DVD image, unconnected to the internet before or during upgrade'

Which means that yes, it's still possible the system will have a newer kernel than what's available in the upgrade source(s).

My point is this: if a given .fc18 package should sort as newer than its .fc17 counterpart, but it doesn't - isn't that a *packaging* problem?
Comment 87 Adam Williamson 2012-10-15 18:57:56 EDT
"My point is this: if a given .fc18 package should sort as newer than its .fc17 counterpart, but it doesn't - isn't that a *packaging* problem?"

Well that specific case sounds like it, sure. But this bug isn't about that, this bug is more just about the case where whatever you had installed on F(n-1) really *is* newer - a genuinely higher NEVR, not a package error - than what's available in the F(n) you're upgrading to. The two main cases of this are:

* Upgrading from F(n-1) with packages from updates-testing to F(n) without updates-testing enabled

* Upgrading from updated F(n-1) - even without updates-testing - to a frozen-at-release-time F(n) package set, like that you'd get from the DVD media

now I come to think about it, I rather like the idea of doing the equivalent of distro-sync on upgrade, rather than the current behaviour. But I'm just the idiot monkey, so I'm sure someone can see a problem with it.
Comment 88 Kevin Kofler 2012-10-15 19:09:20 EDT
Why can't we just entirely drop support for upgrades of updated F(n-1) to Fn without the updates repository, or at least document them as "not supported"? You must have had the F(n-1) updates from somewhere, so I don't see why you can't also get the Fn updates the same way, BEFORE upgrading.

The only place where a pure offline upgrade makes sense is a completely disconnected system installed from F(n-1) GA with no updates at all (or possibly some unofficial respin still older than Fn, but surely not any F(n-1) updates released after Fn).
Comment 89 Kevin Kofler 2012-10-15 19:14:20 EDT
If you want to support the completely disconnected case, it's quite easy to check for an unsupported offline upgrade: check the build times of all the installed packages, then:
if (newest build time > latest freeze time of the set of offline media) {
  error("Unsupported offline upgrade (installed packages newer than upgrade media), enable online updates or get newer media");
}
(Note that the relevant time for a safe comparison is the time of the freeze, not the time of the compose.)
Comment 90 Adam Williamson 2012-10-15 19:57:34 EDT
Kev: I'm not particularly opposed to that approach, and as you say it should be possible to detect the 'offline upgrade of an updated install' case and warn the user.

There can still be cases where something goes stable in F(n-1) before F(n), but that's not massively common and probably comes under the heading of 'stuff that's just going to happen'.
Comment 91 Kamil Páral 2012-10-16 07:11:56 EDT
I believe Fedora should reject upgrades where any of the new packages have lower version than currently installed packages. (*)

That means:
1) require that packages from Fn-updates repository are downloaded prior or during the upgrade process
2) provide a tool that will easily allow upgrades of network-disconnected computers. The tool would get list of packages of computer A, download all the necessary files on computer B, and then run the upgrade process on computer A.

If we want upgrade process to be reliable (more reliable than it is), we can't afford issues like this bug. It's like taking a stroll in a mine field.

(*) There might be an exception for packages installed from third-party repos, in that case yum distro-sync would be performed or the like.
Comment 92 Kevin Kofler 2012-10-16 10:57:09 EDT
Checking the EVR of each package is of course the safest solution. The only caveat I have with that is that we need to ensure that maintainers actually start taking upgrade path issues seriously. Whenever I have filed bugs for upgrade path issues, usually nothing happened, and months later the issue was still not fixed! (In fact, vbetool STILL doesn't have an EVR higher than in F12 (!) updates.) I also often see maintainers happily pushing Fn updates to stable before the matching Fn+1, and the way Bodhi works (with separate karma for every release) even encourages this (in fact, if you use that braindead autokarma misfeature, Bodhi will even break upgrade paths automatically for you!).
Comment 93 Will Woods 2012-10-16 11:47:08 EDT
(In reply to comment #87)
> "My point is this: if a given .fc18 package should sort as newer than its
> .fc17 counterpart, but it doesn't - isn't that a *packaging* problem?"
> 
> Well that specific case sounds like it, sure. But this bug isn't about that,
> this bug is more just about the case where whatever you had installed on
> F(n-1) really *is* newer - a genuinely higher NEVR, not a package error -
> than what's available in the F(n) you're upgrading to.

Sorry, I think you've missed my point.

I'm not disputing the fact that sometimes F(n) will have packages with NEVR older than F(n-1+updates). This is true and basically unavoidable given the current state of things.

You've also said that Bad Things Happen in the specific case of n=17, because the UsrMove migration that's supposed to happen in initramfs doesn't happen, because the kernel package isn't installed. Again, I'm not disputing this. That's a bug.

So, given that there's a bug that happens if F17 kernel is older than F16 kernel during upgrade, wouldn't the simplest solution be to make the F17 kernel newer than F16? Perhaps by using Epoch?

Or in general: If you maintain package 'foo', and a serious bug happens if 'foo' isn't installed during upgrade, shouldn't it be your responsibility to make sure it gets installed? By making sure F(n) 'foo' is always newer than F(n-1+upgrades), so that doesn't happen?

Either by setting an Epoch for your package, or even by changing general packaging policy (and/or RPM version comparison) so that *all* F(n) packages are always considered newer than F(n-1)?

Either way my question is: Why is it considered *necessary* to special-case/override these things in the upgrade tool? Aren't there perfectly good ways of handling this in the packages themselves?
Comment 94 Adam Williamson 2012-10-16 15:46:28 EDT
I see what you mean, and yeah, I think that's a valid position. I believe the opposition to it has been on the grounds that it's really impossible to enforce without using Epoch, and devs _really_ don't like using Epoch. I don't think there's a stronger grounds for resisting it than that.
Comment 95 Kamil Páral 2012-10-17 05:14:46 EDT
I might be wrong in some of my answers, I don't have much packaging experience, but:

> So, given that there's a bug that happens if F17 kernel is older than F16
> kernel during upgrade, wouldn't the simplest solution be to make the F17
> kernel newer than F16? Perhaps by using Epoch?

That would involve using Epoch in lots of packages, probably, because lots of packages may cause really weird problems if not upgraded properly. Currently Epoch is recommended to be used only for the most unavoidable situations (mistakes in versioning, or upstream changing versioning scheme).

> Either by setting an Epoch for your package, or even by changing general
> packaging policy (and/or RPM version comparison) so that *all* F(n) packages
> are always considered newer than F(n-1)?

We would have to override RPM version comparison algorithm, which doesn't seem like a good way to go to me. Yet another way how to become incompatible with the rest of the world. I don't see how changing the policy could help here.

> Either way my question is: Why is it considered *necessary* to
> special-case/override these things in the upgrade tool? Aren't there
> perfectly good ways of handling this in the packages themselves?

It's much easier to implement the correct behavior in a single tool than in thousands of packages maintained by hundreds of people. Running "yum distro-sync" (or requiring higher ENVR everywhere) in the upgrade tool is easier than asking all maintainers to set correct Epoch, and it yields the same result (or maybe better, since it's less error-prone). And all it takes is disallowing offline-upgrades from outdated package sets (a.k.a DVD) and changing the upgrade algorithm a bit.
Comment 96 Adam Williamson 2013-01-22 21:07:55 EST
So, kernel team has moved to address this with recent builds, using a cunning numbering scheme. Kernel team, reckon this one could be closed out now?
Comment 97 Panos Kavalagios 2013-01-23 02:20:27 EST
I assume that numbering scheme is already in force for Fedora 18 upgrades. The upgrade to F18 should always get the F18 kernel. Indeed, the latest F18 kernel is 3.7 and F17 is 3.6. 

However, I have witnessed a similar issue in Bug 902441. After the upgrade the F18 kernel was not installed. I don't know if it is related to the present issue as the investigation is ongoing.
Comment 98 Josh Boyer 2013-01-23 08:43:45 EST
(In reply to comment #96)
> So, kernel team has moved to address this with recent builds, using a
> cunning numbering scheme. Kernel team, reckon this one could be closed out
> now?

No.  The numbering scheme helps, but it isn't a 100% solution.  When branched is in freeze, we still have the issue that the stable releases can progress past the branched freeze kernel.  That should mostly be a problem when doing DVD installs without network/updates enabled, but it still exists.

There isn't much we can do about the freeze issue.  Shoving a new kernel in during freeze makes people nervous, and keeping the stable releases held back during a long freeze isn't tenable.  We'll try to minimize it, but there is no guarantee the issue won't happen.
Comment 99 Kamil Páral 2013-01-23 08:49:11 EST
It's worth noting that this is not a problem of kernel alone, it concerns all packages (some of them are more critical, some of them less). This is something the upgrade tool has to deal with, not individual packages.
Comment 100 Will Woods 2013-01-23 12:37:28 EST
In that case, closing as duplicate of bug 892061 - "Fedup should replace all packages from old version, when possible"

*** This bug has been marked as a duplicate of bug 892061 ***

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