Created attachment 49624 [details]
/etc/fstab

Created attachment 49625 [details]
udisks dump

Created attachment 49626 [details]
cat /proc/self/mountinfo

Created attachment 49627 [details]
sfdisk -l

Created attachment 49636 [details] [review]
some changes

I'm not familiar with the code well and this patch is far from being final. It is just to demonstrate the issue. It helps to discover some other partitions. Also it reports correct partition type for my /dev/sda5 i.e. 0x83 instead of 0x05 .

Created attachment 49637 [details]
./udisks-part-id /dev/sda5 > log 2>&1

This is what I'm getting after that patch. Someone should double check everything as I'm not that big expert in EBR.

Created attachment 49642 [details]
/lib/udev/udisks-part-id /dev/sda5 > /tmp/udisks_part_id_original.txt 2>&1

This is for comparison with previous one. You can see that original report 0x05 for my root on /dev/sda5 and this make libgdu to confuse a lot.

Created attachment 49644 [details]
hexdump enabled ./probers/udisks-part-id /dev/sda5 > /tmp/udisks_hexdump.txt 2>&1

Comment on attachment 49644 [details]
hexdump enabled ./probers/udisks-part-id /dev/sda5 > /tmp/udisks_hexdump.txt 2>&1

While second hexdump looks like mbr, in fact it is not. Also note that consequent ebr points to another ebr using partition type 0x05 again. That is crazy!

Created attachment 49646 [details] [review]
slightly rewritten patch but still not final

Created attachment 49647 [details]
./probers/udisks-part-id /dev/sda6 > /tmp/udisks_part_id_sda6.txt 2>&1

This is an attempt to get info for /dev/sda6 . part-id failed to find /dev/sda6 at 142856695296 , however patched parser found yet another extended partition 0x05 at 142856694784 just one sector (512 bytes) ahead.

mlt@nb:~/workspace/udisks/src$ fdisk -lu
omitting empty partition (5)

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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: 0x046a411b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63   192008879    96004408+   7  HPFS/NTFS
/dev/sda2       192008880   312581807    60286464    f  W95 Ext'd (LBA)
/dev/sda5       192008943   279016919    43503988+  83  Linux
/dev/sda6       279016983   306279224    13631121    7  HPFS/NTFS
/dev/sda7       306290136   312581807     3145836   82  Linux swap / Solaris

(In reply to comment #11)
> Created an attachment (id=49647) [details]
> ./probers/udisks-part-id /dev/sda6 > /tmp/udisks_part_id_sda6.txt 2>&1
> 
> This is an attempt to get info for /dev/sda6 . part-id failed to find /dev/sda6
> at 142856695296 , however patched parser found yet another extended partition
> 0x05 at 142856694784 just one sector (512 bytes) ahead.

Note pstart = 512 before the last hexdump when it failed to find signature! Those pstart must be relative to that nested extended partition.

Created attachment 49650 [details] [review]
And that is all that was missing :-)

In some cases EBR has only a single non-zero entry that should be interpreted as a link.

Mikhail, thanks a lot for your help here!

I have tried for an hour to replicate such a nested partition layout, but haven't succeeded so far. The easiest and safest is to do "sudo modprobe scsi_debug" and use the new virtual 8 MB device for this. I used sfdisk and fdisk trying to recreate such a structure, but no luck. Did you happen to succeed with this? If you have a small device with no actual data, it might also be possible to just dd it and compress the dump.

I'd like to be able to reproduce this to put it into udisks' test suite. Both udisks 1.x and libgdu (where this crash happens) are being deprecated, and I'd rather ensure that this bug does not happen again with udisks 2, or whatever the replacement will be in 5 years.

Thanks!

Oh, I just happened to crash gvfs-gdu-volume-monitor with that very problem (https://bugzilla.gnome.org/show_bug.cgi?id=622066). Now I need to find a way to reliably reproduce it..

Sorry, I've been trying for 3.5 hours now, and I'm unable to reproduce this. Perhaps someone else has more luck than me?

@Martin

I did not know about scsi_debug. I'll see what I can do. But it is likely going to be later this week. And I have to unpatch udisk to actually reproduce it:-)

Otherwise, try creating few logical partitions, then discard offset pointers and replace those with the link pointing to the next partition. In terms of [1] just copy data for "Partition table's second entry" in place of "Partition table's first entry" and fill the former with 00s. You'll actually waste space on disk that was allocated for that partition. I guess GNU/Linux tools are smart enough not to insert such unnecessary stuff if you try to create 0 sized partition.

I have my dumps of my EMBR attached [2] within this post.

[1] http://en.wikipedia.org/wiki/Extended_boot_record
[2] https://bugs.freedesktop.org/attachment.cgi?id=49647

In udisks 2.0 this is now handled by libblkid through invocation from udev so I'm closing this NOTOURBUG.

That said, if you don't mind, please test if it's the problem also exists with that codebase (it's completely different from udisks-part-id). Thanks!