Launchpad has imported 18 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=39603.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-07-27T18:12:38+00:00 Mikhail Titov wrote: Created attachment 49623 udevadm info --export-db Probably some non-free partitioning tools produce nested though valid partition scheme involving nested partitions. That is there is a reference for extended partition of type 0x0f in MBR that refers to another partition (/dev/sda2 in my case) that has only single record in EBR of type 0x05 and all other extended partition are within that and are not linked from very first EBR. This leads to incorrect report of valid partitions as if they have partition type 0x05. This breaks some things in gnome environment in particular like https://bugs.launchpad.net/ubuntu/+source/gnome-disk- utility/+bug/571038 . I'm running udisks 1.0.2, gvfs 1.8.0, no libatasmart installed Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/31 ------------------------------------------------------------------------ On 2011-07-27T18:13:07+00:00 Mikhail Titov wrote: Created attachment 49624 /etc/fstab Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/32 ------------------------------------------------------------------------ On 2011-07-27T18:13:35+00:00 Mikhail Titov wrote: Created attachment 49625 udisks dump Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/33 ------------------------------------------------------------------------ On 2011-07-27T18:14:37+00:00 Mikhail Titov wrote: Created attachment 49626 cat /proc/self/mountinfo Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/34 ------------------------------------------------------------------------ On 2011-07-27T18:15:40+00:00 Mikhail Titov wrote: Created attachment 49627 sfdisk -l Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/35 ------------------------------------------------------------------------ On 2011-07-28T03:42:40+00:00 Mikhail Titov wrote: Created attachment 49636 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 . Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/36 ------------------------------------------------------------------------ On 2011-07-28T03:44:52+00:00 Mikhail Titov wrote: Created attachment 49637 ./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. Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/37 ------------------------------------------------------------------------ On 2011-07-28T04:00:14+00:00 Mikhail Titov wrote: Created attachment 49642 /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. Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/39 ------------------------------------------------------------------------ On 2011-07-28T04:12:42+00:00 Mikhail Titov wrote: Created attachment 49644 hexdump enabled ./probers/udisks-part-id /dev/sda5 > /tmp/udisks_hexdump.txt 2>&1 Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/40 ------------------------------------------------------------------------ On 2011-07-28T04:22:24+00:00 Mikhail Titov wrote: Comment on attachment 49644 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! Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/41 ------------------------------------------------------------------------ On 2011-07-28T05:45:16+00:00 Mikhail Titov wrote: Created attachment 49646 slightly rewritten patch but still not final Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/42 ------------------------------------------------------------------------ On 2011-07-28T05:50:25+00:00 Mikhail Titov wrote: Created attachment 49647 ./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 Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/43 ------------------------------------------------------------------------ On 2011-07-28T05:53:01+00:00 Mikhail Titov wrote: (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. Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/44 ------------------------------------------------------------------------ On 2011-07-28T06:58:59+00:00 Mikhail Titov wrote: Created attachment 49650 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. Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/45 ------------------------------------------------------------------------ On 2012-03-28T13:28:45+00:00 Martin Pitt wrote: 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! Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/69 ------------------------------------------------------------------------ On 2012-03-28T13:57:33+00:00 Martin Pitt wrote: 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.. Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/70 ------------------------------------------------------------------------ On 2012-03-28T15:10:08+00:00 Martin Pitt wrote: 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? Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/71 ------------------------------------------------------------------------ On 2012-03-28T19:44:47+00:00 Mikhail Titov wrote: @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 Reply at: https://bugs.launchpad.net/gnome-disk- utility/+bug/571038/comments/72 ** Changed in: udisks Status: Unknown => Confirmed ** Changed in: udisks Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-disk-utility in Ubuntu. https://bugs.launchpad.net/bugs/571038 Title: palimpsest crash with libgdu:ERROR:gdu-pool.c:2369:device_recurse: assertion failed: (depth < 100) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-disk-utility/+bug/571038/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
