Bug 505409

Please attach the complete traceback to this bug report.  What you're experiencing should have been fixed right before F11 was released.  Are you sure you're using the final release and not a preview?

*** Bug 506115 has been marked as a duplicate of this bug. ***

My apologies for taking so long to respond. Since I am new to Fedora, but not to Linux, and Bugzilla in particular, I have been thoroughly misled by phrases that I interpret differently from how they ought to be interpreted
As part of that misinterpretation, here is the correct sequence of events to trigger that bug:
Step 1: install three partitions on a SATA drive (mine is a ST3320613AS): 15 GB on sdb1 formatted as VFAT; 5 GB on both sdb5 and sdb6, formatted as ext3. The remainder of the drive is empty
Step 2: Install Fedora-11 (see below for details), specifying
 a: Replace existing Linux system, and 
 b: tick "review and modify partition layout"
Step 3: Go to the next screen and delete the LVM volume group that Fedora auto created.
Step 4: Delete sdb5. This partition may be deleted successfully. 
Step 5: Delete sdb6. This action triggers the bug.
I have repeated this sequence 3 times, obtaining the same result. 
If I should have selected, on the previous screen, "Create Custom Layout", the bug would not have been triggered.

To answer your other questions:
1. Traceback of bug has been saved under https://bugzilla.redhat.com/bugzilla//506110
2. I have used file Fedora-11-x86_64-Live, downloaded with start file Fedora-11-x86_64-Live.torrent on 10 June 2009 at 20:21 Universal Time. I presume that is the correct file

In my attempts to nail down the steps that do trigger the bug, I have made a few other observations that may, or may not, give additional information. 
1. My Windows installation on sdb1 would no longer work. Since I cannot figure out how to gain root access under Fedora, I cannot edit the Grub menu list manually either. The boot loader program will work only after I manually install kudzu, but even then, it is all automated and I have no control.
2. Re-installing bootsector (FIXBOOT) and Master Boot Record (FIXMBR) in Windows would not allow Windows to start on its own: "NTLDR is missing".
3. Inspecting the partition table from a Mandriva 2009-1 installation, installed on another PATA disk, showed 2 sectors to be crossed (if I remember correctly that was the term Mandriva used). These were supposed to be on two disks with about 80 and 800 GB capacity. A few tests showed that both "disks" were physically located on the 320 GB ST3320613AS. To remove it required two action steps: 
a. clear all partitions on sdb and 
b. reformat the whole disk with the ReiserFS file system. Reformatting as ext3 or 4 would not remove the crossed sectors.

To me these observations indicate that Fedora11 has a loose pointer somewhere, writes to sdb onto places that it is not supposed to do and messes up the partition table information in the process. I may be wrong with my conclusion, but unless I know Fedora can be trusted, I am not allowing it onto my computer.

And that means ambiguities like "Replace existing Linux system" are replaced by e.g."use Logical Volume Management", or something similar, and that user names are either always referred to as <User Name>@<Service Provider> and not just as <User Name>. And if that is too difficult to fix, fix the error message that results if the full <User Name>@<Service Provider> structure was not keyed in. True, long term Fedora users won't be confused by such ambiguities, but I have been taken for the ride. And that hurts . . .

I had supposed, from the sober screen shots, I get competent work. What I actually got feels more like an elaborate April 1 job. My only consolation is that the testers, being longstanding Fedora enthusiasts, were misled also, assigning meaning to instructions that do not convey that meaning to all and sundry.

The traceback you referenced is actually a PackageKit bug, which has nothing to do with either partitioning or anaconda at all.  We've tested this sort of scenario before and have not hit a traceback.  Since you are unable to supply the traceback, I'll be forced to close this bug as INSUFFICIENT_DATA.  There are a variety of partitioning-related bugs open right now and they are highly dependent on what's already present on your drives.

I'm not sure where you're going with the last three paragraphs.  They're kind of rambling.  We don't even ask for user names, for instance.