Bug 707746

Summary: "Upgrade root not found" when using preupgrade to upgrade from Fedora 14 to Fedora 15
Product: [Fedora] Fedora Reporter: Lei Zhou <lzhou5>
Component: preupgradeAssignee: Richard Hughes <richard>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: anton, joel_rees, maurizio.antillon, richard
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 11:19:16 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Anaconda Log
syslog none

Description Lei Zhou 2011-05-25 16:02:59 EDT
Created attachment 500929 [details]
Anaconda Log

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
mkdir /mnt/sysimage
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)

How reproducible:

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
   but exit.

The existence of data drive /dev/md127 (RAID1 from /dev/sdb1 and /dev/sdc1) is not necessary to reproduce this bug.
Actual results:

Fedora 14 was not upgraded to Fedora 15.  Original Fedora 14 installation is intact, still boot-able and useable.

Expected results:

Fedora 14 is upgraded to Fedora 15.

Additional info:

# 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

# /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
        initrd /upgrade/initrd.img
title Fedora (
        root (hd0,0)
        kernel /vmlinuz- ro root=UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6 rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
        initrd /initramfs-

/boot/upgrade]#>ls -al
total 100088
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
lang en_US.UTF-8
keyboard us
bootloader --upgrade --location=none
clearpart --none
upgrade --root-device=UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6

grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*
Comment 1 Lei Zhou 2011-05-25 16:07:02 EDT
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
Comment 2 Lei Zhou 2011-05-25 16:14:12 EDT
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.
Comment 3 Lei Zhou 2011-05-25 16:15:59 EDT
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'
Comment 4 Lei Zhou 2011-05-25 16:17:15 EDT
Created attachment 500934 [details]

Comment 5 Lei Zhou 2011-05-25 17:29:52 EDT
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
        initrd /upgrade/initrd.img

this bug is still reproduced.
Comment 6 Lei Zhou 2011-05-25 19:02:38 EDT
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.
Comment 7 Lei Zhou 2011-05-26 10:43:15 EDT
Proven that this bug does not affect systems with / on soft RAID1 drives.
Comment 8 Lei Zhou 2011-05-26 12:07:13 EDT
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

in /boot/upgrade/ks.cfg

the preupgrading worked normally.


I'd retest this with lvm.  Why this trick works for soft RAID but not for lvm?
Comment 9 Anton Arapov 2011-10-13 13:59:43 EDT
hit the same issue today while tried upgrade to f16beta.
Comment 10 John Chivall 2011-10-25 10:48:11 EDT
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.
Comment 11 John Chivall 2011-10-27 07:40:00 EDT
Actually, my issue was related to Bug 748119. I had to copy /var/lib/rpm/* to the root LV before anaconda picked it up.
Comment 12 Joel Rees 2012-06-16 13:40:36 EDT
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.

System structure: 

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.
Comment 13 Fedora End Of Life 2012-08-16 11:19:19 EDT
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: