No Linux did not install, same problem as in the beginning, but partition order is nice 
Trying to install KDE-mini
[root@localhost ~]# draklive-install
/media/ user
Backtrace has 11 calls on stack:
11: /usr/lib/libparted.so.0(ped_assert+0x29) [0xb71f08b9]
10: /usr/lib/libparted.so.0(+0x41435) [0xb7226435]
9: /usr/lib/libparted.so.0(+0x422b7) [0xb72272b7]
8: /usr/lib/libparted.so.0(+0x436aa) [0xb72286aa]
7: /usr/lib/libparted.so.0(+0x1028e) [0xb71f528e]
6: /usr/lib/libparted.so.0(ped_disk_add_partition+0x271) [0xb71f8bf1]
5: /usr/lib/libparted.so.0(+0x450e3) [0xb722a0e3]
4: /usr/lib/libparted.so.0(+0x4530e) [0xb722a30e]
3: /usr/lib/libparted.so.0(ped_disk_new+0x79) [0xb71f9a29]
2: /usr/lib/libDrakX/auto/c/stuff/stuff.so(XS_c__stuff_get_disk_type+0x1ed) [0xb7275fd5]
1: /usr/lib/perl5/5.10.1/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x56e) [0xb773d1ee]
A bug has been detected in GNU Parted. Refer to the web site of parted http://www.gnu.org/software/parted/parted.html for more information of what could be useful for bug submitting! Please email a bug report to bug-parted@gnu.org containing at least the version (2.3) and the following message: Assertion (head_size <= 63) at dos.c:661 in function probe_partition_for_geom() failed.
Aborted
[root@localhost ~]#
Is it possible that using fdisk-old to partition drive that problem will occur when trying to install latest pclos systems? Hmmm interesting but beyond me at the moment.
I am out of ideas?? Something about geometry?
grub> geometry (hd0)
drive 0x80: C/H/S = 9729/255/63, The number of sectors = 156301488, /dev/sda
Partition num: 0, Filesystem type is fat, partition type 0xb
Partition num: 4, Filesystem type is fat, partition type 0xb
Partition num: 5, Filesystem type is fat, partition type 0xb
Partition num: 6, Filesystem type is ext2fs, partition type 0x83
grub>
There is a bug in parted, and I believe you are seeing it. It's supposed to be backwards compatible with existing partitions from older versions, but seems to do a wally over the first partition starting at sector 63, cylinder 1. I've not encountered this myself, so far. I have the following for my /dev/sda;
[root@fatman ~]# fdisk -l /dev/sdaDisk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000d21c
Device Boot Start End Blocks Id System
/dev/sda1 63 626534 313236 83 Linux
<-- Note the start at sector 63/dev/sda2 626535 16820054 8096760 82 Linux swap / Solaris
/dev/sda3 16820055 114495254 48837600 83 Linux
/dev/sda4 114495255 1953520064 919512405 5 Extended
/dev/sda5 114495318 329332499 107418591 83 Linux
/dev/sda6 329332563 534434354 102550896 83 Linux
/dev/sda7 534434418 596943269 31254426 83 Linux
/dev/sda8 596943333 659452184 31254426 83 Linux
/dev/sda9 659452248 721961099 31254426 83 Linux
/dev/sda10 721961163 784470014 31254426 83 Linux
/dev/sda11 784470078 994198589 104864256 83 Linux
/dev/sda12 994198653 1623368249 314584798+ 83 Linux
/dev/sda13 1623368313 1685893229 31262458+ 83 Linux
/dev/sda14 1685893293 1749366044 31736376 83 Linux
/dev/sda15 1749366108 1816485614 33559753+ 83 Linux
/dev/sda16 1816487663 1889887982 36700160 83 Linux
/dev/sda17 1889892080 1953520064 31813992+ 83 Linux
[root@fatman ~]# fdisk -l /dev/sda -u=cylindersDisk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000d21c
Device Boot Start End Blocks Id System
/dev/sda1 1 39 313236 83 Linux
<-- This is the equivalent of sector 63; cylider 1, first sector /dev/sda2 40 1047 8096760 82 Linux swap / Solaris
/dev/sda3 1048 7127 48837600 83 Linux
/dev/sda4 7128 121601 919512405 5 Extended
/dev/sda5 7128 20500 107418591 83 Linux
/dev/sda6 20501 33267 102550896 83 Linux
/dev/sda7 33268 37158 31254426 83 Linux
/dev/sda8 37159 41049 31254426 83 Linux
/dev/sda9 41050 44940 31254426 83 Linux
/dev/sda10 44941 48831 31254426 83 Linux
/dev/sda11 48832 61886 104864256 83 Linux
/dev/sda12 61887 101050 314584798+ 83 Linux
/dev/sda13 101051 104942 31262458+ 83 Linux
/dev/sda14 104943 108893 31736376 83 Linux
/dev/sda15 108894 113071 33559753+ 83 Linux
/dev/sda16 113072 117641 36700160 83 Linux
/dev/sda17 117641 121601 31813992+ 83 Linux
All but the last two partitions were created with old fdisk, and I'm currently running the 64 bit test release from /dev/sda9, with two other 64 bit installations on /dev/sda15 and /dev/sda17, with an older 32 bit MiniMe installation on /dev/sda16. I had no problem installing to any of the partitions, whether created with old fdisk or new fdisk. I have not tried to install the newest MiniMe anywhere on this drive, so don't know whether the change in parted is reflected only there. I've had previous versions of LXDE and Phoenix installed on various partitions on this drive without issue, so I suspect this is a quite new problem.
If you want to try an experiment, and have a spare drive, you could see if you can install MiniMe to a single partition on it, then rsync copy the installation to the sda7 partition. If that works, you'd need to edit the
/etc/fstab / partition entry on the /dev/sda7 copy to reflect the new location, and also edit the /boot/grub/menu.lst of the copy, for the same reason. Once that's done, from the liveCD, you can then use the
grub native install method to install grub to the MBR of /dev/sda.
If there's nothing wrong with the partition or the format of /dev/sda7, it should then boot normally. This would eliminate any actual problems with the drive involved, and place the fault on the installer, and more particularly, the version of parted involved on the MiniMe liveCD.