Description of problem: When booting Fedora 17 DVD to perform upgrade of existing Fedora 14, Fedora 15 or Fedora 16 systems (all configured using LVM2), anaconda fails to "find any existing partitions". Nor does it find any when using the "Recover" mode. Version-Release number of selected component (if applicable): anaconda 16.25 (as displayed when booting from F17 DVD) How reproducible: Always Steps to Reproduce: 1. Boot F17 DVD and select "Install/Upgrade" 2. F17 scans storage devices but does not present an existing environment to upgrade Actual results: Fedora (anaconda) fails to identify the existing environment contained inside the LVM partitions, and thus doesn't permit an upgrade instead assumes that it's a clean installation. Expected results: anaconda should detect the LVM partition, scan it, identify the VG and LVs within, and present the underlying installation for upgrade. Additional info: Filesystem (LVM) layout: LVM Path File System rootvg/lv_root / rootvg/lv_home /home rootvg/lv_opt /opt rootvg/lv_usr /usr rootvg/lv_usrl /usr/local rootvg/lv_var /var rootvg/lv_varc /var/cache rootvg/lv_varl /var/log rootvg/lv_vars /var/spool rootvg/lv_swap0 SWAP /dev/sda1 /boot /dev/sda2 LVM2 partition All LVM-based file systems are ext4. /boot either ext2 or ext3 **** WORKAROUND **** I've successfully been able to upgrade all the above systems to Fedora 17 by appending the following options to the Install/Upgrade vmlinuz command line: rd_LVM_LV=rootvg/lv_root rd_LVM_LV=rootvg/lv_usr rd_LVM_LV=rootvg/lv_var (FYI, these kernel loader options were already present in the grub configuration file for booting the older Fedora installations, so there's no reason why anaconda couldn't have used this to identify the correct LVM volumes during the scan phase.) This seems to force anaconda to scan and activate the LVM VG and successfully mount the file systems so that the existing installation is presented as a candidate for upgrade. From that point (assuming there is sufficient space in /usr), the usr merge script runs successfully, and the system upgrades to Fedora 17. Before rebooting, I switched to a console screen, then chroot /mnt/sysimage and executed a "dracut -f" to ensure that the initial ram disk for the kernel was viable. The reboot was then permitted and the system successfully booted a Fedora 17 environment. I still needed to perform some package clean-ups due to the fact that I had some i686 packages installed for 32 bit support in my x86_64 installations. These were not upgraded automatically (to be expected as they wouldn't have been present on the x86_64 DVD).
I should clarify one thing here. In my comment about the rd_LVM_LV options already being present in the grub configuration, the only option that had *ORIGINALLY* been present was the one specifying the location of the root file system. I added the others during my various attempts to get a clean upgrade because when I manually added them to the anaconda upgrade command line, they new grub/grub2 configuration DID NOT save them. It appears that the upgrade copied what was in the older kernel loader, and I failed to get a successful startup on reboot because the LVs for /var and /usr were not "pre-loaded", and thus the system couldn't find the binaries now located in /usr (and the RPM database couldn't be found because /var wasn't mounted).
anaconda-16.25 is included in the F16 DVD -- not F17. Please attach the logs from installation. They'll be in /var/log/anaconda/. Do not create an archive. Instead, attach the following log files one at a time as type text/plain: anaconda.storage.log anaconda.log anaconda.program.log anaconda.syslog Thanks.
With Fedora 18 Alpha, the existing installations are displayed, but AFAICT upgrade is impossible.
(In reply to amylaar from comment #3) > With Fedora 18 Alpha, the existing installations are displayed, but AFAICT > upgrade is impossible. Correct. Upgrade is now handled by fedup (the Fedora Upgrade Tool) as of Fedora 18. Closing this report due to lack of response from the reporter.