If the intel partitioning system doesn't detect any children and is not

directly on a device (i.e. has a parent), then don't indicate that we want to
support it at all, but just return -1. Most probably it is actually a
filesystem and not a partition. Indicating that we might support it a bit
could lead to the situation that the partition was associated with the intel
partitioning system in the end because the module for the actually present
filesystem wasn't yet loaded in the first initial device scan (during early
boot when looking for the boot partition).
The later rescan wouldn't touch that partition anymore as it was already
(wrongly) associated with the intel partitioning system, therefore leading to
unrecognized partitions as seen in bug #2424. By not pretending to support the
partition when we most probably don't, a later rescan that has all filesystems
available therefore has a chance of identifying that partition correctly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26128 a95241bf-73f2-0310-859d-f6bbb57e9c96

src/add-ons/kernel/partitioning_systems/intel/intel.cpp

@@ -164,9 +164,12 @@ pm_identify_partition(int fd, partition_data *partition, void **cookie)
 	if (hasChildren)
 		return 0.4;
 
-	// No children. Extremely unlikely, that this is a desired. But if no one
-	// else claims the partition, we take it anyway.
-	return 0.1;
+	// No children but a parent. Extremely unlikely that this is desired.
+	// Just indicate that we don't support this partition, it's probably a
+	// filesystem and not a partition at all.
+	*cookie = NULL;
+	delete map;
+	return -1;
 }
 
 // pm_scan_partition