Description of problem: Anaconda fails with Python stacktrace if LVM partition created and no VG uses it Version-Release number of selected component (if applicable): 5.1 How reproducible: Always Steps to Reproduce: 1. Create a partition and tell it is a LVM type 2. Do NOT go into the "LVM" and create a volume group for it 3. Watch the stacktrace with a vgcreate with a unexpanded %s on it Actual results: Stacktrace Expected results: Disk partitioned, formated and installation continuing Additional info: Unfortunately I lost the stacktrace and it would be hard to copy anyway (the system is now in use). It should be straightforward to reproduce though.
I started a RHEL5 installation on a machine with a disk that only had a physical volume in it. Anaconda did not see the physical volume but did not trace back. I installed a new PV and could successfully install a VG on top of that with no tracebacks. Can you be more descriptive of the situation in which you encountered the problem. Were you using ks file. Were you in a Graphical installation?
That is not the situation described in the "steps to reproduce". It happens when you create in your disk a partition marked as LVM type but don't go into the LVM GUI to create a volume group. I had /, /usr swap, all other partitions defined. The only extraordinary thing was this partition marked as LVM for which I did not create a volume group for. If you look at the error message I described, Anaconda expects to provide that 'vgcreate' command with the name of a group and replace that %s with it. As I did not create the volume groups, there was no volume group number to replace the %s.
(In reply to comment #2) > That is not the situation described in the "steps to reproduce". Sorry about this, I misunderstood. I tested again and did not see any trace back. I went into the partitioning gui, created a lvm partition but did not put any volume group in the partition. Anaconda formated the filesystem and finished installation as expected. Are you still seeing this? Can you please test again to see if it is still an issue?
Its been a couple of months. Please reopen this issue if you are still seeing this with RHEL52