Haiku's partition map representation looks weird.

[bga]

This is more obvious when looking at DriveSetup but I think the problem is in our disk manager. For example, I have this 500 Gb disk it has one single primary partition created (465.8 Gb of usable size). But due to what is probably some kind of block alignment, there is a bit of free space before the partition (around 5 kb) and this is reported as a different partition in Haiku. So I have:

/dev/disk/ata/1/slave/raw

/dev/disk/ata/1/slave/0

/dev/disk/ata/1/slave/0_0

The 0_0 one is the 5 Kb partition. Although it is there, it is not reported by any other OS (not Linux nor Windows) that I have in the same machine.

With DriveSetup it even looks a bit weirder as it markes the partition exactly like it would mark a extended/logical partition so the /0 partition (the real 465.8 Gb one) looks like it is a logical partition and it is not.

Is this intended; This can get things confusing I guess. What if when DriveSetup can create partitions people try to remove that 0_0 partition?

[bonefish]

Please attach the sector 0 of your HD and the first sector of the extended partition (the ".../0").

[anevilyak]

I actually get a somewhat strange list of partitions from Installer here as well, though I'm not certain if that's a matter of Installer not filtering what it gets back from the disk system properly, or the disk manager weirdly interpreting the partition map. Specifically, I get:

(null) - 186.3GB (Intel Partition Map) [(null) partition: 0]
null (0B) [(null)] [/dev/disk/ata/3/master/raw partition: 2]
Haiku - 18.6GB [Be File System] [/dev/disk/ata/3/master/raw partition: 3]
HaikuData - 148.2GB [Be File System] [/dev/disk/ata/3/master/raw partition: 4]

On the command line, Installer presents the following output:

SourceVisitor::Visit(BPartition *) : /dev/disk/ata/3/master/1
SourceVisitor::Visit(BPartition *) : (null)
ScanDisksPartitions partitions begin
TargetVisitor::Visit(BDiskDevice *) : /dev/disk/ata/3/master/raw
TargetVisitor::Visit(BPartition *) : /dev/disk/ata/3/master/0
TargetVisitor::Visit(BPartition *) : (null)
TargetVisitor::Visit(BPartition *) : /dev/disk/ata/3/master/1
TargetVisitor::Visit(BPartition *) : (null)
TargetVisitor::Visit(BPartition *) : /dev/disk/ata/3/master/2
TargetVisitor::Visit(BPartition *) : (null)

According to FreeBSD's fdisk, the partition map is:

******* Working on device /dev/ad6 *******
parameters extracted from in-core disklabel are:
cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 40949622 (19994 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
sysid 235 (0xeb),(BeOS file system)
    start 40949685, size 39070080 (19077 Meg), flag 0
        beg: cyl 1023/ head 254/ sector 63;
        end: cyl 1023/ head 254/ sector 63
The data for partition 3 is:
sysid 235 (0xeb),(BeOS file system)
    start 80019765, size 310697100 (151707 Meg), flag 0
        beg: cyl 1023/ head 254/ sector 63;
        end: cyl 1023/ head 254/ sector 63
The data for partition 4 is:
<UNUSED>

Is this related to Bruno's issue, or should I file a separate bug against Installer for this?

[bga]

Requested sectors.

[bga]

Added the requested data. There are 3 files in the zip file:

raw.bin (HD's sector 0). 0.bin (First sector of partition identified as /0) 0_0.bin (Just added this for completeness. First sector of partition identified as /0_0).

Let me know if you need anything else.

[bonefish]

OK, confirmed, the partition map contains only a single descriptor for a primary partition with type 0x7 starting at 1 MB with a size of about 465 GB. The problem is that we support nesting partition maps and that this partition contains a sector that has a valid partition table sector signature. Since we are relatively lenient evaluating the partition map and it contains at least one descriptor describing a valid child, and since no file system claims to recognize the partition, the partitioning system is allowed to scan the partition and publish child partitions. I guess I'll disable the feature of nested partition maps for the time being.

[bga]

Cool. I take it you will remove support for nested partitions *EXCEPT* if it is a extended partition, right? As it will have logical partitions inside it).

[bonefish]

Replying to bga:

Cool. I take it you will remove support for nested partitions *EXCEPT* if it is a extended partition, right? As it will have logical partitions inside it).

Yep, I meant only a nested partition map (which describes the primary partitions).

Done in hrev27215.