Comment 6 for bug 324987

I've tested a comprehensive set of partition layouts and it looks as if this issue is triggered *when an extended partition exists*, whether or not it has logical partitions and even if they aren't used by the installation.

In eight tests I tried variations of the location of /boot/ (as a primary and as a logical in the extended), before or after root, with and without a separate /home/.

I tried different partition sizes which caused the extended to be at different locations. I tried it with no logicals, logicals defined but not used, and of course, trying to use logicals.

Whenever an extended partition exists it is deleted by the installer, which removes everything within it. Therefore if the installer has been set to use one of the logicals it gets deleted which obviously leads to the failure.

Aside from this issue, the fact the installer silently fails without notifying the user is very confusing, especially if you've looked away whilst letting the installer get on with the job and return to find it at the partitioning page again.

I'm trying to figure out *why* this occurs. Is it possible that something in the layout of this particular disk is triggering the bug, or is it more widespread? The only thing I can see that is slightly non-standard is that the first primary partition starts at sector 2048 (usually it is at 63) - this layout was inherited from the previous 200GB disk-drive and didn't cause a problem when Feisty, Gutsy, and Hardy were installed from live-CD.

Luckily I have back-ups of everything so I am next going to try a new partition table with partition #1 starting at 63 - it is possible that partman is confused by the *empty* space at the start of the disk.