I experience this with mga8 classic installer, but it is probably the diskdrake part entirely.

Version-Release: mga8 i586 and x86_64 classig install ISOs.

How reproducible: Always - hit it on four different in-use machines with and without dual boot, plus some extra experimental install cycles.

Steps to Reproduce:
1. Install Mageia using LVM, entirely by installer.
2. Run installer again, and in the LVM remove all lv,
3. and in same vg tell it to create a new lv ...
4. ... After many minutes a popup "lvcreate failed: "
  one example from report.bug:

* running: lvm2 lvcreate --size 12639232k -n lv_root vg-M4400
  Rounding up size to full physical extent 12.05 GiB
* ERROR: killing runaway process (process=lvm2, pid=724, args=lvcreate --size 12639232k -n lv_root vg-M4400, error=ALARM at /usr/lib/libDrakX/run_program.pm line 235.
)
* error: lvcreate failed: 

(During the previous install i have already named the vg "vg-M4400", default is vg-mga)
(Yes there is a single ")" on one line, no idea why.)


__Notes__

§ The pv may be encrypted or not, only difference is diskdrake asks for phrase to decrypt it.

§ It does not help to abort install and come back to a empty vg, lvcreate fails then too.

§ Pretty annoying...  I first thought it was disk surface error https://bugs.mageia.org/show_bug.cgi?id=29916#c22 because my first working workaround was to use another part of the disk.

§ Obvious workaround (tested) is to remove the pv, and create a new ( that worked at least one time, but another time it resulted in GRUB not finding partition, but that is probably another bug i happened to trig (i have had such problems when removing and creating lv without restarting installer, i once posted a bug on that), so see best workaround below)

§ Note that in some installs it is not possible to remove the partition due to partition numbering. - That makes this problem severe in systems where you have to keep the blocking partition(s) (i.e another OS, like when dual booting, which is specifically one good use of LVM where you can easily move Linux system around when you need to change size of the Redmond system.)

§ One workaround in that case is to schrink the borked pv partition, and make a new pv to use to the vg. (tested OK)  Possible problem with that is if it is encrypted - i believe diskdrake do not support shrinking encrypted partition. 

§ Best workaround i think is to format that old pv partition to ext4, then set it back to LVM. (tested OK repeatedly (without encryption, but should work with, too))


While the problem is severe for dual boot and similar requirements, there is a workaround, and both dual boot and LVM usage is rather low.