Red Hat Bugzilla – Bug 707746
"Upgrade root not found" when using preupgrade to upgrade from Fedora 14 to Fedora 15
Last modified: 2013-04-14 15:31:43 EDT
Created attachment 500929 [details]
Description of problem:
I am trying to upgrade to Fedora 15 from Fedora 14 using
preupgrade-1.1.9-1.fc14.noarch but produces a window with the following error
"Upgrade root not found" and under this another message saying "The root for
the previously installed system was not found" with a exit installer button. I
have seached bugzilla and the net, and found similar issues as of "Red Hat Bugzilla – Bug 603653" for earlier versions of fedora but no solution or
explantion on why this could be happening.
I figured that the reason caused this was that anaconda and/or vmlinuz/initrd.img for installing Fedora 15 in /boot/upgrade couldn't activate LVM volumes where the / of Fedora 14 resides.
I tried to insert a %pre section in the /boot/upgrade/ks.cfg like
vgchange -a y
vgchange -a y
mount /dev/dm-0 /mnt/sysimage
mount /dev/sda1 /mnt/sysimage/boot
to help anaconda to locate system root, but resulted in vain, since it looks
anaconda decided to fail before the "%pre" section was run, although the error pop up after running "%pre".
The anaconda.log and other files will be attached for your analysis.
Version-Release number of selected component (if applicable):
for Fedora release 14 (Laughlin)
Always as long as the / partition of Fedora 14 in on a LVM volume.
Does not have problem if / is on a physical partition like /dev/sda2.
will try other two possibilities soon and report the result here:
/ on a RAID volume like /dev/md127p1;
Fedora 14 is an virtual machine.
Steps to Reproduce:
1. Clean install Fedora 14 on a single empty hard drive, say /dev/sda,
with the partion /dev/sda1 (190MB or larger) in ext4 for /boot,
/dev/sda2 as "Linux LVM",
create two logical volumes as
/dev/VolGroup00/LogVol00 in ext4 (70GB or larger) for /
/dev/VolGroup00/LogVol01 as swap (1GB or larger)
2. Boot into Fedora 14. Log in as root. yum update -y. This will update
All modules to latest version.
3. Clean up /boot of older kernel versions to make space for /boot/upgrade
4. Reboot, log in as root. Run preupgrade or preupgrade-cli, let it go and
answer everything yes, until it prompt you to reboot.
5. Reboot. Wait a few minutes. Then the error pops up and you have no choice
The existence of data drive /dev/md127 (RAID1 from /dev/sdb1 and /dev/sdc1) is not necessary to reproduce this bug.
Fedora 14 was not upgraded to Fedora 15. Original Fedora 14 installation is intact, still boot-able and useable.
Fedora 14 is upgraded to Fedora 15.
# df -h
Filesystem Size Used Avail Use% Mounted on
71G 14G 55G 20% /
tmpfs 1007M 88K 1007M 1% /dev/shm
/dev/sda1 190M 173M 7.8M 96% /boot
/dev/md127p1 111G 16G 89G 16% /data/home19
# more /etc/fstab
# Created by anaconda on Wed Dec 3 00:23:56 2008
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info
UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6 / ext3 defaults 1 1
UUID=6e6af18a-132a-4190-82fe-306d4272f5d6 /boot ext3 defaults 1 2
UUID=3d66631c-c6b3-42f8-b9b8-def99391c75b /data/home19 ext4 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
UUID=a3b6b66b-5568-405a-8d5e-de631c5098ed swap swap defaults 0 0
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
title Upgrade to Fedora 15 (Lovelock)
kernel /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=6e6af18a-132a-4190-82fe-306d4272f5d6:/upgrade/ks.cfg
title Fedora (188.8.131.52-91.fc14.i686)
kernel /vmlinuz-184.108.40.206-91.fc14.i686 ro root=UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6 rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
drwxr-xr-x. 2 root root 1024 May 24 19:11 .
dr-xr-xr-x. 6 root root 1024 May 25 12:50 ..
-rw-r--r--. 1 root root 98272524 May 13 15:52 initrd.img
-rw-r--r--. 1 root root 293 May 25 14:39 ks.cfg
-rw-r--r--. 1 root root 3804304 May 9 16:48 vmlinuz
# more ks.cfg
# ks.cfg generated by preupgrade
bootloader --upgrade --location=none
rm -rf /boot/upgrade /var/cache/yum/preupgrade*
Created attachment 500931 [details]
the last a few lines regarding /dev/dm-0 was the result of hand mounting.
[ 233.835829] EXT3-fs (dm-0): using internal journal
[ 233.835841] EXT3-fs (dm-0): mounted filesystem with ordered data mode
Created attachment 500932 [details]
The following ERRORs are found in the program.log
program.log:19:22:27,758 ERR program: mount: special device /var/cache/yum/preupgrade does not exist
program.log:19:22:42,807 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:42,875 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:42,907 ERR program: resize2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,766 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,767 ERR program: Journal superblock magic number invalid!
program.log:19:22:45,834 ERR program: dumpe2fs 1.41.14 (22-Dec-2010)
program.log:19:22:45,834 ERR program: Journal superblock magic number invalid!
program.log:19:22:45,868 ERR program: resize2fs 1.41.14 (22-Dec-2010)
program.log:19:22:46,945 ERR program: mdadm: stopped /dev/md0
program.log:19:22:48,510 ERR program: mdadm: /dev/md0 has been started with 2 drives.
program.log:19:22:48,993 ERR program: mount: wrong fs type, bad option, bad superblock on /dev/md0,
program.log:19:22:49,307 ERR program: mdadm: stopped /dev/md0
storage.log:19:22:47,367 ERR storage: failed to remove /etc/mdadm.conf: [Errno 2] No such file or directory: '/etc/mdadm.conf'
storage.log:19:22:47,369 ERR storage: failed to remove /etc/multipath.conf: [Errno 2] No such file or directory: '/etc/multipath.conf'
syslog:19:22:21,0 ERR udevd-work: device node '/dev/rtc' already exists, link to '/dev/rtc0' will not overwrite it
syslog:19:22:23,0 ERR udevd-work: device node '/dev/rtc' already exists, link to '/dev/rtc0' will not overwrite it
syslog:19:22:24,0 ERR NetworkManager: <error> [1306351345.912] [nm-session-monitor.c:349] nm_session_monitor_init(): Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directory
syslog:19:22:25,0 ERR NetworkManager: <error> [1306351345.61871] [nm-device-ethernet.c:753] real_update_permanent_hw_address(): (p3p1): unable to read permanent MAC address (error 0)
syslog:19:22:48,992 ERR kernel:[ 71.156716] EXT4-fs (md0): no journal found
The first line implies that the upgrade rpms on /mnt/sysimage/var/cache/yum/preupgrade could not be found. This setting is in /boot/grub/grub.conf. I am testing about this.
It is weird that anaconda tried to mount /dev/md0, which was the RAID1 for data and should not be involved in upgrading. I will try disable/remove it to see if it will help.
Created attachment 500933 [details]
Two look irrelevant errors:
19:22:47,367 ERR storage: failed to remove /etc/mdadm.conf: [Errno 2] No such file or directory: '/etc/mdadm.conf'
19:22:47,369 ERR storage: failed to remove /etc/multipath.conf: [Errno 2] No such file or directory: '/etc/multipath.conf'
Created attachment 500934 [details]
Proven that even have the soft raid drives physically removed, this bug is still reproduced.
Proven that even specify UUID in /boot/grub/grub.cfg as of:
title Upgrade to Fedora 15 (Lovelock)
kernel /upgrade/vmlinuz preupgrade repo=hd:UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6:/var/cache/yum/preupgrade
this bug is still reproduced.
Even if you do not have a way to fix this, it is very appreciated to NOT allow anaconda to "Exit" after this error. A "retry" or "force continue" will be very helpful since the lvms can be hand mounted to rightful places.
My attempts of work arounds resulted in vain. If I do not hand mount, it does not mount, and break. If I hand mount, it attempts to mount but cannot since "already mounted"/"mount point busy" and break.
Reading all history of this since FC2, I'd say this is historical.
To no longer use lvm as installation default since Fedora 15 is a wise move. The troubles LVM made are way more than the convenience it provided.
Nevertheless I will just dd the / to a new HD without lvm and have this issue killed for all.
Proven that this bug does not affect systems with / on soft RAID1 drives.
For a virtual system, I have a / on a very complex RAID6, for testing purpose. This bug prevented it from upgrading. However, by applying
mdadm -A -s
the preupgrading worked normally.
I'd retest this with lvm. Why this trick works for soft RAID but not for lvm?
hit the same issue today while tried upgrade to f16beta.
This also happens to me with preupgrade F15 -> F16 Beta. F15 installed on LVM (have been on LVM since FC6). I'm not in a position to migrate off LVM at the moment, so it looks like I'm unable to upgrade.
Actually, my issue was related to Bug 748119. I had to copy /var/lib/rpm/* to the root LV before anaconda picked it up.
Getting the same dialog (but in Japanese).
preupgrade 15 to 16.
Downloaded 3.5 Gb of packages. (Took 10 hours.)
Rebooted to debian, did a grub configuration there and found the upgrade kernel for Fedora, congigured the grub on that disk to boot the Fedora kernel on the disk with Fedora. (I do this stupid trick every time I get a new kernel for Fedora.)
Rebooted and started the upgrade process, went to scanning for storage devices. Then the message, as given in the title for this bug.
First disk is an 80 G disk with (currently) Debian Squeeze. BIOS is set to boot this disk.
Second disk is a 160 G disk with Fedora. I have installed Grub to the boot sector of this disk but it does not find Debian, so I don't use it. Also, Debian's grub2 does not successfully chain to Fedora on this disk. (Grub2 seems to assume chaining is only for MSWindblows? Something about BSD, but it does not successfully chain to openBSD, either, IIRC.) So I have to boot Debian and do a grub-update (or was it update-grub?) there, to find Fedora's kernel and add a direct reference to it.
root is in a primary DOS type partition on the second drive, as is /boot. The rest of the system is in LVM. (Why can't we do labels like the BSDs, and just get ourselves free of the entire DOS primary/extended partition junk? Well, EUFI or whatever is going to "fix" that, too? Baloney.)
(I have a third drive I'm using mostly for backup, but other than being unable to boot or chain that drive unless it's hung on the secondary channel with the second drive, it has no effect on the boot process.)
(Direct booting a foreign kernel is a serious bug in grub, but that's a related-but-separate topic. Grub should default to chaining any multiboot, and chaining needs to be fixed in grub2. The reason for that is, for example, Debian's grub has no way of knowing that the kernel in the Fedora system has been updated until I boot Debian.)
(Microsoft and Intel seem to have successfully re-directed all the productive engineers in the free/open-source movement in so many directions as to significantly reduce the technological threat, while they attack in the courts. We do ourselves no favors chasing their dreams.)
My next step is to try yum upgrade or just burn a netinstall CD and abandon the cached packages that took all day to download. I'm more and more inclined, though, to let my next step be to move Debian in as my main OS and bring openBSD back as my rescue OS. Too much imitating MSWindows going on here.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. 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 '14' 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 14 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: