Bug 708343 - Fatal error during F14->15 upgrade package install breaks system
Fatal error during F14->15 upgrade package install breaks system
Product: Fedora
Classification: Fedora
Component: preupgrade (Show other bugs)
i386 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-05-27 07:10 EDT by Martin Ellison
Modified: 2012-08-07 14:11 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-07 14:11:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martin Ellison 2011-05-27 07:10:59 EDT
Description of problem: After preupgrade on F14, during installation, when installing packages, anaconda gives a message box that a fatal error occurred when installing openjpeg-devel. After this, my system is not bootable.

Version-Release number of selected component (if applicable): n/a

How reproducible: probably not.

Steps to Reproduce:
1. run preupdate.
2. boot into anaconda.
Actual results: see above.

Expected results: update installs packages.

Additional info: Trying anaconda again results in the same error (ie the same package).

There doesn't seem to be any way to recover from this.
Comment 1 Martin Ellison 2011-05-27 10:25:40 EDT
Progress report: Using Fedora Live, I mounted my partitions and erased openjpeg-devel. I then restarted anaconda and it went ahead and installed the remaining packages. 

However, when I went to reboot, the system was still not bootable. Specifically, it gives a kernel panic saying that it cannot find a partition to mount. 

I notice that there is no initrd in the new grub.conf, but maybe this is a F15 feature.

I tried rebooting using the F14 kernel, and this gets a lot further, but does not give me a shell prompt. It puts out lots of messages saying that systemd-kmesg-syslogd.servivce has failed with status 218, whatever that means.
Comment 2 Martin Ellison 2011-05-27 11:10:46 EDT
- the yum repository is still set to version 14
- there are many, many duplicate packages ("yum-presto-0.6.2-3.fc15.noarch is a duplicate with yum-presto-0.6.2-2.fc14.noarch...") and yum will not process them
- from grub,conf:
title Fedora (
	root (hd0,2)
	kernel /vmlinuz- ro root=UUID=c136a7a6-830e-41a6-b4bc-9d44bc6f2c08 SYSFONT=latarcyrheb-sun16 LANG=en_AU.UTF-8 KEYTABLE=us selinux=0
It is this entry that I was using when I got the kernel panic. The old F14 entries are similar (eg the root line) but they have an initrd line as well.
Comment 3 Jean-Philippe-Prade 2011-05-28 08:22:14 EDT
I have exactly the same problem... I need help to solve it
Comment 4 Toby Haynes 2011-05-28 09:57:33 EDT
Likewise. The partially upgraded system is still at the old kernel level but has most of systemd installed. I can get to a login prompt but it never gives the password prompt before it times out sixty seconds later.
Comment 5 David G. Mackay 2011-05-28 14:44:22 EDT
I had the exact same problem.  I was able to get the system to boot by using the rescue on the netinstall cd.  I had to re-download the kernel rpm.  Then I did an:
rpm -e --nodeps kernel-, and then reinstall the kernel.
There's still the issue of the duplicate rpms.
Comment 6 Toby Haynes 2011-05-28 21:30:32 EDT
There is built-in duplicate RPM removal in Yum Utils

yum install yum-utils
package-cleanup --cleandupes
Comment 7 Toby Haynes 2011-05-28 21:44:33 EDT
For those who need help reviving their system (and I'm only part of the way there),,,

You need to interrupt GRUB to alter the boot parameters to drop you into single user mode as root. Add a space character and a numeric character 1 to the boot line for a known good kernel.

Once in as root, remove the RPM causing the grief

rpm -e openjpeg-devel

Reboot and choose the Upgrade to Lovelock option.

Let Anaconda do its thing. If you are lucky you have a working system after the reboot. If not, use the GRUB menu to again drop into single user root mode. 

Get your machine networked. The simplest approach is simply to plug in an ethernet cable and hopefully

ifup eth0

will get you a working network. From there

yum install yum-utils
package-cleanup --cleandupes

and possibly some judicious removal of "bad" RPMs
Comment 8 Toby Haynes 2011-05-29 20:55:12 EDT
Removal of the duplicate RPMS has left me with a decent working system. 

One important point: do not attempt to run systemd on the F14 kernel - it will just about run but the system-logger continuously returned status 218. Even the text console is slow when this is happening. Use the F15 kernel to avoid this issue. I had to reinstall the kernel to get a properly set up initial ram disk.

If you are stuck with a zero-second timeout in GRUB and can't apply the information from Comment 7, create a Live USB key or CD and boot from that. Mount your /boot partition and edit /boot/grub/grub.conf to give you a non-zero timeout. Remeember to save and unmount the partition before rebooting.
Comment 9 Martin Ellison 2011-06-03 02:17:14 EDT
(As reporter) I have reinstalled F15 from the live disk, so I do not need this any more.

The problem that I was unable to solve was that the F15 kernel was unable to mount my root file system. I tried various GRUB options but nothing worked. I was able to mount the file system as non-root from the live disk. (The reason that I have taken this long from raising the bug till reporting this comment is that I backed everything up to a new drive before repartitioning and installing).
Comment 10 Federico Cáceres 2011-06-04 03:45:39 EDT
I have also faced this issue, upgrading from F14 x86_64 to F15, but I could solve it following some suggestions that where written here and others around the net. What I did to make the installation finish correctly is the following:

First, once anaconda failed with the openjpeg-devel package, I rebooted the computer and ran F14 in "single" mode (added "single" to the kernel line in the grub entry). F14 complained about some deprecated stuff but it finally took me to a usable terminal. I removed the package using the "$ rpm -e openjpeg-devel" command, I tried using yum before that, but it couln't complete the transaction.

Once the offending package was removed, booting back to the Update process (grub entry) worked flawlessly and the install procedure finished correctly. But F15 didn't boot though, the error message was: "kernel panic-not syncing VFS:unable to mount root fs on unknown-block(0,0)".

After a little bit of fiddling, I discovered that the grub entry for F15 missed the initrd line. Closer inspection (booting back into F14 single mode) also revealed that there was only one initramfs file in the /boot, the one corresponding to the F14 kernel. I was unsure whether the F15 kernel was installed correctly so I decided to reinstall it all together. This is, more or less, what I did (the download url was reverse engineered from yum's repositories):

# kernel- is the one installed by anaconda when I did the preupgrade, yours could be different
$ rpm -e kernel-
$ wget http://download.fedoraproject.org/pub/fedora/linux/updates/15/x86_64/kernel-
$ rpm -i kernel-

(I got 5 or 6 warnings about possible missing firmwares.)

After the installation was complete, I confirmed that a ramdisk was created for this kernel and decided to reboot. Finally, F15 booted. I checked I was running the correct kernel with "$ uname -r".

The system seems stable (running KDE4) although networking has to be started by hand ($ system network start) and yum had a weird behaviour where it echoed into the screen all the installed packages when printing the transaction results... but after a reboot it seems to have... stabilized.

In any case:
- Removing offending package with rpm -e
- Completing anaconda install
- Reinstalling kernel

... seems to work.
Comment 11 T-Gergely 2011-06-07 16:42:05 EDT
Same bug here. I used mkinitrd and edited grub.conf instead of reinstalling the kernel, otherwise nice solutions, guys.
Comment 12 Richard Heck 2011-12-19 11:59:17 EST
I ran into this problem going from F14 to F16, so it seems still to be an issue, at least if the base version is F14.
Comment 13 bztdlinux 2012-01-07 21:07:48 EST
I have also hit this bug. My solution was just to roll back to an image of the root partition I made before upgrading. I think it's reported to the wrong people. If someone could reassign this bug to anaconda and openjpeg, that would be great.

Also related is bug 707909 which is assigned to anaconda.
Comment 14 Fedora End Of Life 2012-08-07 14:11:45 EDT
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:

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