Red Hat Bugzilla – Full Text Bug Listing
|Summary:||"Upgrade root not found" when using preupgrade to upgrade from Fedora 14 to Fedora 15|
|Product:||[Fedora] Fedora||Reporter:||Lei Zhou <lzhou5>|
|Component:||preupgrade||Assignee:||Richard Hughes <richard>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||14||CC:||anton, joel_rees, maurizio.antillon, richard|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-16 11:19:16 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 message: "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 %pre vgchange -a y %end and %pre vgchange -a y mkdir /mnt/sysimage mount /dev/dm-0 /mnt/sysimage mount /dev/sda1 /mnt/sysimage/boot %end 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): preupgrade-1.1.9-1.fc14.noarch 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 /dev/mapper/VolGroup00-LogVol00 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 /boot/grub/grub.conf # 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 #boot=/dev/sda default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu 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 (126.96.36.199-91.fc14.i686) root (hd0,0) kernel /vmlinuz-188.8.131.52-91.fc14.i686 ro root=UUID=ffeb3019-5c76-488b-b277-1ea36db95cd6 rhgb quiet SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us initrd /initramfs-184.108.40.206-91.fc14.i686.img /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 reboot %post grubby --remove-kernel=/boot/upgrade/vmlinuz rm -rf /boot/upgrade /var/cache/yum/preupgrade* %end
Comment 1 Lei Zhou 2011-05-25 16:07:02 EDT
Created attachment 500931 [details] dmesg 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] program.log 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] storage.log 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 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 ks=hd:UUID=6e6af18a-132a-4190-82fe-306d4272f5d6:/upgrade/ks.cfg 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 %pre mdadm -A -s %end in /boot/upgrade/ks.cfg the preupgrading worked normally. Interesting. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping