Description of problem:
The partprobe tool on finding a backup GPT signature on a block device that
lacks a correct primary signature/protective MBR will attempt to restore the GPT
disk label without confirmation from the user.

If the device previously contained a GPT partition table but has since been
re-used for other data without being completely wiped this risks corruption of
the device contents.

Version-Release number of selected component (if applicable):
parted-1.6.19-4.EL

How reproducible:
100%

Steps to Reproduce:
[ Example - there are lots of ways to trigger this ]
1. Set up a GPT label with a couple of partitions, e.g.:
       Disk /dev/sdc: 65.5MB
       Sector size (logical/physical): 512B/512B
       Partition Table: gpt
       
       Number  Start   End     Size     File system  Name     Flags
        1      17.4kB  20.0MB  20.0MB                primary       
        2      20.0MB  30.0MB  10000kB               primary       

2. Overwrite the device with something else, e.g.:
# mke2fs /dev/sdc 2000
mke2fs 1.39 (29-May-2006)
/dev/sdc is entire device, not just one partition!
Proceed anyway? (y,n) y 
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
256 inodes, 2000 blocks
100 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=2097152
1 block group
8192 blocks per group, 8192 fragments per group
256 inodes per group

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

3. Run partprobe on the device:
# partprobe /dev/sdc
  
Actual results:
Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT table. 
However, it does not have a valid fake msdos partition table, as it should. 
Perhaps it was corrupted - possibly by a program that doesn't understand GPT
partition tables.  Or perhaps you deleted the GPT table, and are now using an
msdos partition table.  Is this a GPT partition table?
Error: The primary GPT table is corrupt, but the backup appears ok, so that will
be used.

Note that none of these prompts are interactive - partprobe does not accept user
input before carrying on and correcting the GPT table.

# file -s /dev/sdc
/dev/sdc: x86 boot sector, extended partition table

# e2fsck -fn /dev/sdc
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Inode 7 has illegal block(s).  Clear? no

Illegal block #11021 (33619980) in inode 7.  IGNORED.
Illegal block #11024 (33685516) in inode 7.  IGNORED.
Illegal block #11027 (34210792) in inode 7.  IGNORED.
Illegal block #11028 (1953722220) in inode 7.  IGNORED.
Illegal block #11029 (1970234923) in inode 7.  IGNORED.
Illegal block #11277 (33619980) in inode 7.  IGNORED.
Illegal block #11280 (33686516) in inode 7.  IGNORED.
Inode 7, i_blocks is 2492, should be 2108.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sdc: ********** WARNING: Filesystem still has errors **********

/dev/sdc: 11/16000 files (9.1% non-contiguous), 3286/63968 blocks


Expected results:
Either partprobe waits for user input (as the prompts suggest it will) before
modifying the disk contents, or aborts with a message instructing the user to
resolve the partitioning problem first and try again.

Additional info:
This is in practise fairly easy to run into since most disk labeling / file
system / data base schemes store their superblock or equivalent at the front of
the disk.

This was seen in production with Oracle ASM volumes where the ASM label is
written at the start of the disk. In this case, the devices had been
automatically partitioned as GPT at installation time due to architecture (ia64).