Created attachment 346197 [details] ks to reuse existing lvm vg Description of problem: Kickstart installations from the F11-rc2 DVD which attempt to reuse existing LVM volume groups (volgroup --useexisting) will fail with an error that the VG name is not recognized. Anaconda cannot reuse LVM PV partitions in any existing volume groups. Semi-automatic kickstart installations with manual layout also exhibit the issue. This bug did not exist with the F11-preview DVD. Version-Release number of selected component (if applicable): 11.5.0.57 (i386 RC2 DVD) How reproducible: Always Steps to Reproduce: 1. create a ks.cfg which reuses existing volume groups 2. install with the kickstart Actual results: The following error was found while parsing your kickstart configuration The following problem occurred on line 17 of the kickstart file No preexisting VG with the name "vg0" was found Expected results: Successful installation Additional info: The same kickstart works fine with F11-preview. This is yet another regression from Preview to RC2. Before F11 installation, the disk is laid out as follows: sda1 /boot sda2 swap sda3 lvm pv of volume group vg0 Volume group vg0 contains f9 - the F9 / free space to become the F11 /
Created attachment 346198 [details] i386 Preview anaconda.log (ks works)
Created attachment 346199 [details] i386 Preview program.log (ks works)
Created attachment 346200 [details] i386 Preview storage.log (ks works)
Created attachment 346201 [details] i386 Preview syslog (ks works)
Created attachment 346202 [details] i386 RC2 anaconda.log (ks doesn't work)
Created attachment 346203 [details] i386 RC2 program.log (ks doesn't work)
Created attachment 346204 [details] i386 RC2 storage.log (ks doesn't work)
Created attachment 346205 [details] i386 RC2 syslog (ks doesn't work)
I looked into it and it seems we are not setting DeviceTree.clearPartType correctly somewhere (it is set to default CLEARPART_TYPE_LINUX, while it should be CLEARPART_TYPE_NONE), so the existing vg device is not added to devicetree during storage initialization because it it doesn't pass this check:(storage.devicetree.py:1529) if shouldClear(device, self.clearPartType, self.clearPartDisks, self.protectedPartitions): # if this is a partition that will be cleared by clearpart, # don't bother with format-specific processing return The clearPartType setting became hard to follow in the code through the storage rewrite, and as Chris did some changes of it recently, I think he'll know better where/how to change it (if I am right).
I posted a patch for review. It makes attached ks work for me. You can try this updates file for version .58 of anaconda containing the patch: http://rvykydal.fedorapeople.org/updates.clearpart.img
Re: Comment 10 Confirmed. The patch works for me. I actually tried it with two ks files, the one included and the one I'll actually use when I install real systems. You can set this bug to MODIFIED, too. Thanks for the effort. *** ??? Will this fix be on the GA media (if you know)? If so, I'll update the wiki page with that info now and remove to the bug from the wiki once I confirm the media have (or at least the i386 medium has) the fix. *** ??? Thanks again. Now on to try out the RAID bug...
Should be fixed in next build of anaconda for rawhide. Unfortunately it is too late for F11.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 504913 has been marked as a duplicate of this bug. ***
Re: Comment 36 Moving from F11 back to rawhide. It only makes sense there.
Re: Comment 15 Oops. Cut & Paste. I meant Re: Comment 13, not Re: Comment 36 (which doesn't exist yet here).
*** Bug 505575 has been marked as a duplicate of this bug. ***
According to koji, there have been no builds for anaconda since 2 June. Therefore this bug cannot be fixed yet. Am I missing something?
*** Bug 508455 has been marked as a duplicate of this bug. ***
I do experience the same problem. Does the bug fix ?
(In reply to comment #20) > I do experience the same problem. > Does the bug fix ? For F11, there's not a genuine bug fix. You have a few options. I would recommend, in the order listed: 1. Don't use kickstart. 2. Try the anaconda update from Comment 10, although it's older than the version of anaconda on the GA media, so there's no guarantee it doesn't regress other bug fixes that made it on to the GA media. If the update is still available by the time anyone reads this comment, this option is the closest thing to a bug fix for F11 until ... 3. Wait for a respin, which will probably have an updated anaconda. For Rawhide, I'm downloading today's boot.iso now. Today's boot.iso/install.img should include yesterday's anaconda build (12.1), so I'm hopeful.
Unable to verify fix in anaconda-12.0 due to Bug 509572 Unable to verify fix in anaconda-12.1 due to Bug 510172
Putting to modified, fix has been pushed into anaconda 12.0.
I was able to verify the fix in anaconda-12.3 with today's (21 July 2009) boot.iso. Closing...
It looks like I hit this bug in Fedora 14 again. Here is my partitioning from the kickstart config file: # Use all existing partition schema and reformat all but /home clearpart --none partition /boot --usepart=sda1 partition pv.6fZc4L-gojR-fTgc-Twhq-LcaN-XYc8-yeomBJ --usepart=sda2 volgroup vg_prhost2 pv.6fZc4L-gojR-fTgc-Twhq-LcaN-XYc8-yeomBJ --useexisting logvol / --vgname=vg_prhost2 --name=lv_root --useexisting logvol /home --vgname=vg_prhost2 --name=lv_home --useexisting --noformat logvol swap --vgname=vg_prhost2 --name=lv_swap --useexisting [root@prhost2 ag]# pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name vg_prhost2 PV Size 465.27 GiB / not usable 23.00 MiB Allocatable yes (but full) PE Size 32.00 MiB Total PE 14888 Free PE 0 Allocated PE 14888 PV UUID Jlexvs-KWlQ-dhR9-vdNr-yUrK-QbAg-2wjcPg [root@prhost2 ag]# vgdisplay --- Volume group --- VG Name vg_prhost2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 1 Act PV 1 VG Size 465.25 GiB PE Size 32.00 MiB Total PE 14888 Alloc PE / Size 14888 / 465.25 GiB Free PE / Size 0 / 0 VG UUID UU4f01-PIEA-VvSL-7bxb-Mm3k-DVVc-gnQ97J