Merge lp://staging/~yuningdodo/usb-creator/usb-creator.lp1424915-check-for-iso9660 into lp://staging/usb-creator

If we attempt to print the disk layout of an isohybrid ISO image with parted, we'll get below error messages:

$ file ubuntu-14.04.1-desktop-amd64.iso
ubuntu-14.04.1-desktop-amd64.iso: x86 boot sector

$ parted --script -- ubuntu-14.04.1-desktop-amd64.iso print
Warning: /home/yun/Downloads/iso/ubuntu-14.04.1-desktop-amd64.iso contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.

We'll get the same error from an usbstick if it's dd'ed with the ISO.

In such a case most operations will fail or result in incorrect result, that's why we get the error messages in bug #1424915.

To fix this issue we should check if the usbstick is dd'ed with isohybrid ISO images. One possible way is checking for the drive's partition type since the isohybrid ISO image has type iso9660 for the drive.

In my own test this patch works on utopic and vivid. For trusty we also need to do some extra tricks due to the util-linux/wipefs bugs, we can discuss it later.

I can't confirm this patch fixes the bug on vivid. Have you tested this specifically on vivid?

No, I haven't tested on vivid yet, I'll give it a try.

Checked on vivid, the patch doesn't work unless we retry with some delay for udisks objects to be ready.

The branch has been updated, in my tests it can fix the bug on the daily vivid image (20150306).

I'm not overly happy with sleeping to wait for objects, especially since you're using synchronous calls anyway which should be returning proper objects when they are called. The problem is that while delays can work in some circumstances, they tend to introduce issues on slower or differently-configured systems where the delay might not be sufficient.

I see in the API doc for udisks that there is a udisks_client_settle(UdisksClient *client) function, so it's possible that calling udisks.settle() after the get_object call might be sufficient to ensure we always get a valid partition table.

One further issue I see is that you're re-creating the udisks client in every loop iteration, something which shouldn't be necessary.

Actually I have the same concern with you, sleep is never the preferred
solution to me. Thanks for the hint, I will give it a try next week.
2015年3月7日 上午1:38于 "Mathieu Trudel-Lapierre" <email address hidden>写道：

> Review: Needs Fixing
>
> I'm not overly happy with sleeping to wait for objects, especially since
> you're using synchronous calls anyway which should be returning proper
> objects when they are called. The problem is that while delays can work in
> some circumstances, they tend to introduce issues on slower or
> differently-configured systems where the delay might not be sufficient.
>
> I see in the API doc for udisks that there is a
> udisks_client_settle(UdisksClient *client) function, so it's possible that
> calling udisks.settle() after the get_object call might be sufficient to
> ensure we always get a valid partition table.
>
> One further issue I see is that you're re-creating the udisks client in
> every loop iteration, something which shouldn't be necessary.
> --
>
> https://code.launchpad.net/~yuningdodo/usb-creator/usb-creator.lp1424915-check-for-iso9660/+merge/250718
> You are the owner of
> lp:~yuningdodo/usb-creator/usb-creator.lp1424915-check-for-iso9660.
>

I have made some tests with udisks_client_settle(), but no luck, we still can't get the new-create objects successfully.