Description of problem: On two machines, I've tried to upgrade from F14 to F15 using preupgrade, and it's installed most of the packages and then given up because the F15 openjpeg-devel RPM was corrupt for some reason. It's a leaf node on my installation, and it's not a critical package. Anaconda could have continued, or at least asked me whether I wanted to retry, ignore or cancel. Instead, it left me with a broken system. Running the upgrade again installed the remaining packages, but didn't remove F14 versions of ones installed during the first run, and didn't give me a working dracut image, so I had some messy work to do to uninstall and reinstall the F15 kernel rpm manually before I could boot. This makes me wonder if other tasks were left undone: were other %post scriptlets run? Aborting an upgrade should be a VERY last resort, because it will almost always result in a mess. Version-Release number of selected component (if applicable): F14 -> F15 on release day Steps to Reproduce: 1. Install F14 2. Install openjpeg-devel 3. Run preupgrade Actual results: "Installation cannot continue" Expected results: Warning, and possibility of continuing with upgrade (maybe after some Ctrl-Alt-F2 and some manual work)
I have just tried preupgrade from F13 to F15. The valgrind RPM was corrupt (despite preupgrade reporting no problems prior to beginning the upgrade). The consequences of this have just wasted several hours. Actual results: "Installation cannot continue" and an aborted upgrade Expected results: 1) Warning of bad RPM. 2) Ask me if I would just prefer to delete the bad RPM (for valgrind, this would have been just fine) or pull a new copy. 3)Continue with remaining non-dependent RPMs. 4)Whatever happens, clean up RPMDB for the succesfully upgraded RPMs (over 1000 fc13 entries were left behind for me to clear up). 5)If the kernel RPM has been installed before the problem occurs, the boot loader MUST be updated. This must be the very first - or very last - action. The kernel is NOT "just another RPM". [ In my case, reinstalling the kernel from BFO rescue mode did NOT correct the boot loader - I had to reinstall via BFO and explicitly request a new boot loader configuration. ] 6) Provide the option of a rescue environment with tools where are remaining problems can be easily fixed. It would be much safer to update RPMs in dependency order, so that the kernel and vital libraries are updated as early as possible and also to update the RPMDB after every RPM install.
See also bug 708343.
Same problem here, after a year since OP reported this error for the first time. Keep up the good work guys. I had done preupgrade from F15->F16. All went smoothly till booting into anaconda. It failed over, o irony, qt-examples package. NO OTHER OPTIONS WERE OFFERED TO ME EXCEPT 'EXIT INSTALLER'. I find it outrageous, really, think about it. After exiting I manually removed offending package and continued installation. It left me with systemd not starting udev, no initrd in the first place, no modules.dep to generate initramfs for myself. No working repair options were given to me. It's broken my system that I've kept since f12. Fresh installation failed again with rpm checksum error on some non-important package, I do not even dare to count how many hours I've wasted on this.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping