Joey Boggs wrote this to me:
> Been working on an issue with device-mapper/parted for RHEV-H's
> upstream project just not sure where the fault possibly lies.
> I'm specifically working on adding efi support to the installation
> drive, which involves creating a specific partition on the disk and
> marking with the boot flag. /dev/mapper device names are used where
> available for all available devices including local sata/ide/scsi
> Typical Installer parted steps in order for ovirt-node/RHEV-H
> parted -s /dev/mapper/XXXXX "mklabel gpt"
> parted -s /dev/mapper/XXXXX "mkpart efi 0M 256M"
> parted -s /dev/mapper/XXXXX "mkpart primary 256M 512M"
> parted -s /dev/mapper/XXXXX "mkpart primary 512M 768M"
> mkfs.vfat /dev/mapper/XXXXp1 -n EFI
> mke2fs /dev/mapper/XXXXp2 -L Root
> mke2fs /dev/mapper/XXXXp3 -L RootBackup
> The created efi partition is fine up to this point and can be
> mounted/unmounted freely
> When adding a fourth and final partition we run into an issue.
> parted -s /dev/mapper/XXXXX "mkpart efi 768M -1" is ran for the last
> partition used for lvm
> # this step erases/corrupts the vfat file system(unable to mount)
> somehow easily reproduced by adding a 4th partition no matter the size
> with parted
> Any ideas what could possibly be happening to corrupt that file system
> or write to a part of the disk incorrectly within parted?
> Using RHEL6.2 based parted/device-mapper this completes fine but there
> is a major version difference with parted
> Fedora 16 Versions
> parted 3.0.4
> device-mapper 1.02-65-5
> RHEL6.2 Versions
> parted 2.1.17
> device-mapper 1.02-66-6
Thanks for the report.
I first tried to reproduce that on F16 using a regular scsi device:
modprobe scsi_debug dev_size_mb=1000
parted -s $dev mklabel gpt
mkpart efi 0M 256M
mkpart root 256M 512M
mkpart roo2 512M 768M