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.
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.
Nominating as NTH, in case we do decide to Do Something about it.
*** Bug 815474 has been marked as a duplicate of this bug. ***
+1 NTH
I will +1 NTH in case we Do Something About It as well.
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.
+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?
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.
I see +4 NTH, moving to accepted
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
I also have F16 kernel after upgrade to F17. Boot is OK, but shutdown causes kernel panic.
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.
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.
*** Bug 823247 has been marked as a duplicate of this bug. ***
*** Bug 825092 has been marked as a duplicate of this bug. ***
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?
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.
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.
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.
*** Bug 826276 has been marked as a duplicate of this bug. ***
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.
(In reply to comment #21) How did your /boot/grub2/grub.cfg look like and which files did you have in /boot ?
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.
*** Bug 826600 has been marked as a duplicate of this bug. ***
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
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, 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.
(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
(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?
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.
grubby-8.12-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17
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...
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 .
(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....
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.
(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...
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?
(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?
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.
(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.
(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.
(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.
(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
(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?
(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.
(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!
(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.
mads: see #826537. I explained there why preupgrade is only editing the grub config file and not doing grub2-install...
(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...'.
(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 ...
(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.
Let's try and keep the discussion of preupgrade issues in https://bugzilla.redhat.com/show_bug.cgi?id=826537 .
(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?
*** Bug 827876 has been marked as a duplicate of this bug. ***
(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).
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
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?
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?
It's the contents of the files that's important. 'cat /etc/yum.repos.d/fedora-updates.repo' .
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 ~]#
yeah, try commenting out the baseurl= lines...
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
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.
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.
(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).
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.
Bob Mckay, I have the exact same problem you do/did. How did you solve it ? Thanks
I was able to update with the following command. yum --skip-broken --exclude mesa-dri-drivers
(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...
*** Bug 826920 has been marked as a duplicate of this bug. ***
*** Bug 842427 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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
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.
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.
(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 .
Stuart: this bug *is* about upgrading. The problems you describe are not really a case of this bug.
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.
"(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.
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.
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.
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.)
"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.
'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?
"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.
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).
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.)
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'.
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.
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!).
(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?
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.
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.
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?
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.
(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.
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.
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 ***