While trying to install gentoo 2006.0 from the live cd on a system with a windows installation on (hd0,0) (grub-speak) using the graphical installation method, the partition tool created an superflous partition boot record on an extended partition containing both an NTFS partition and a swap partition (being created). The result was the following layout, unfortunately transcribed from the notes I took due to not remembering that I should save info for the bug report. These are probably not 100% accurate, but the problem should be apparent: /dev/hda0: NTFS, start sector: 63, total sectors: 81,915,372 /dev/hda1: reiserfs, start sector: 81,915,435, total sectors: 49,255,290 /dev/hda2: extended, start sector: 131,170,725, total sectors: 181,389,915 EPBR: start sector: 131,170,725, total sectors: 63 EPBR: start sector: 131,170,726, total sectors: 2,152,709 /dev/hda3: swap, start sector: 131,170,851, total sectors: 2,152,584 /dev/hda4: NTFS(broken), start sector: 133,323,435, total sectors: 179,237,205 As you can see, the boot sector containing information about the NTFS partition was destroyed by the partition tool when creating the swap partition, and it seemed that both of the entries created were misaligned as well, and therefore unusable. The data on the NTFS partition was recoverable so it doesn't seem as if the partition was actually overwritten, but I would still class this as a pretty dire mistake by the partition tool. Of course I probably got something wrong somewhere, but I can't figure out what that might be.
What program did that data come from? The first partition should be hda1 and any logical partitions should be hda5 or higher. Second, without the original disk layout, this bug report doesn't have any useful information for me.
Yeah, I realise this is pretty useless information, but I thought I'd report it even so. The partitions were sequential but yeah, the exact device ids are wrong. I got that info from a recovery program and it wasn't obvious how to map it back to fdisks format (oh, and I tend to revert to 0-based indexing without realising it). basically how it looked before was hda1: NTFS hda2: ext3 hda3: extended (somewhere here there's a boot record with 2 entries) hda5: NTFS hda6: swap What I did was I removed the existing ext3 and swap partitions and created new ones in their places. It seemed as if the new swap partition was enumerated before the preexisting NTFS partition, but no data seems to have been overwritten so I am not sure how that would map to actual sector use..
Uhh, how can the boot record be in the extended partition? The x86 BIOS can only boot from one of the 4 primary partitions.
Reopen if you can provide more information