Bug 709130

Summary: the root for the previous installed system was not found
Product: [Fedora] Fedora Reporter: Matias Kreder <delete>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: anaconda-maint-list, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-31 16:02:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
storage log
none
anaconda log
none
program log
none
anaconda syslog
none
fdisk -l
none
lvs -v output
none
df -h none

Description Matias Kreder 2011-05-30 18:44:39 UTC 
Description of problem:

After running preupgrade to Fedora 15, and rebooting into anaconda, it says that there is a problem with my LVM data, and if I want to re-initialize all my disks. After ignoring this, it gives the error of "the root for the previous installed system was not found"

Version-Release number of selected component (if applicable):
anaconda (shipped with fedora 15)
fedora-release-14-1.noarch
preupgrade-1.1.9-1.fc14.noarch

How reproducible:
It may depend on the LVM configuration

Steps to Reproduce:
1. Install fedora 14 with a complex LVM configuration (1 volume group, several PV's (1 PV is an MD device) 
2. run preupgrade
3. reboot to anaconda
  
Actual results:

upgrade fails

Expected results:

upgrade working

Additional info:

I'm attaching all the anaconda log's
Comment 1 Matias Kreder 2011-05-30 18:45:11 UTC 
Created attachment 501859 [details]
storage log
Comment 2 Matias Kreder 2011-05-30 18:45:44 UTC 
Created attachment 501860 [details]
anaconda log
Comment 3 Matias Kreder 2011-05-30 18:46:43 UTC 
Created attachment 501861 [details]
program log
Comment 4 Matias Kreder 2011-05-30 18:47:28 UTC 
Created attachment 501862 [details]
anaconda syslog
Comment 5 Matias Kreder 2011-05-30 18:48:58 UTC 
Created attachment 501863 [details]
fdisk -l
Comment 6 Matias Kreder 2011-05-30 20:18:08 UTC 
Created attachment 501879 [details]
lvs -v output
Comment 7 Matias Kreder 2011-05-30 20:18:32 UTC 
Created attachment 501880 [details]
df -h
Comment 8 Matias Kreder 2011-05-30 21:17:59 UTC 
looking at storage.log, anaconda has a problem with my physical volume under a raid device.

18:27:17,044 DEBUG storage: lvm filter: adding md0p1 to the reject list
18:27:17,045 DEBUG storage: ignoring partition md0p1
18:27:17,116 WARN storage: Skipping LVs for incomplete VG vg_mirror
18:27:21,372 DEBUG storage:          PartitionDevice.removeChild: kids: 1 ; name: sda2 ;
18:27:21,374 DEBUG storage:          PartitionDevice.removeChild: kids: 1 ; name: sdc2 ;
18:27:21,376 DEBUG storage:          PartitionDevice.removeChild: kids: 1 ; name: sdd1 ;
18:27:21,376 DEBUG storage: lvm filter: adding vg_mirror to the reject list
18:27:21,377 DEBUG storage: lvm filter: adding sda2 to the reject list
18:27:21,378 DEBUG storage: lvm filter: adding sdc2 to the reject list
18:27:21,378 DEBUG storage: lvm filter: adding sdd1 to the reject list
Comment 9 Matias Kreder 2011-05-31 15:13:05 UTC 
As a workaround, I backed up the content of my LV's hosted in the md0p1 PV. I removed md0p1 from the same volume group I had the root mount point. I created a new VG, and restored all my data there. 

upgrade was done smoothly, without any warnings.
Comment 10 David Lehman 2011-05-31 16:02:27 UTC 
Partitioned md arrays are not supported at this time except for certain varieties of bios/firmware raid which use md instead dmraid. I'm glad you were able to work around the issue and complete your upgrade.

There is an existing RFE for support for partitioned md in bug 507578.

*** This bug has been marked as a duplicate of bug 507578 ***