This looks like a wipefs(8) problem to me as it's apparently not doing its job ("Erase all available signatures."). Why do you think it's a udisks problem?

Btw, you should be running

 LIBBLKID_DEBUG=0xffff wipefs -a /dev/sdb

and not /dev/sdb1 as you said in comment 0. (The reread-partition-table ioctl will definitely fail if not called on the whole disk.)

Btw, my guess is that wipefs(8)/blkid is getting confused by the rather complicated hybrid thing that the Fedora-live ISOs are. See http://mjg59.dreamwidth.org/11285.html

(In reply to comment #1)
> This looks like a wipefs(8) problem to me as it's apparently not doing its
> job ("Erase all available signatures."). Why do you think it's a udisks
> problem?

I'm not sure where is the error, bacuse I do not understand it deeply.

(In reply to comment #2)
> Btw, you should be running
> 
>  LIBBLKID_DEBUG=0xffff wipefs -a /dev/sdb
> 
> and not /dev/sdb1 as you said in comment 0. (The reread-partition-table
> ioctl will definitely fail if not called on the whole disk.)

It works like a charm if I call format on /dev/sdb. However there is multiple volumes on the image. The org.freedesktop.UDisks2.Block object offers Format method, so why I can't call it on sdb1? This is working in other cases. 

Udisks shouldn't call wipefs -a /dev/sdb1 if it isn't possible and it should return error immediately.

(In reply to comment #3)
> Btw, my guess is that wipefs(8)/blkid is getting confused by the rather
> complicated hybrid thing that the Fedora-live ISOs are. See
> http://mjg59.dreamwidth.org/11285.html

That's the problem probably if it should work for /dev/sdb1 in case of iso9660, but udisks should return error immediatlly and don't do that if it shouldn't work...

Wipefs works correctly according dowstream wipefs bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1077310

The error doesn't affect functionality. See:

$ wipefs /dev/sdb1
offset               type
----------------------------------------------------------------
0x0                  mac   [partition table]

0x1fe                dos   [partition table]

0x8001               iso9660   [filesystem]
                     LABEL: Fedora-Live-Desktop-x86_64-20-1
                     UUID:  2013-12-12-00-56-55-00

$ wipefs -a /dev/sdb1
/dev/sdb1: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
/dev/sdb1: 2 bytes were erased at offset 0x000001fe (dos): 55 aa
/dev/sdb1: 2 bytes were erased at offset 0x00000000 (mac): 45 52
/dev/sdb1: calling ioclt to re-read partition table: Invalid argument
$ sudo wipefs /dev/sdb1
$ 

The type should be empty, but udisks still see iso9660 from some reasons :-(

The error could be avoided by:
sudo wipefs -a -t nodos,mac /dev/sdb1 

but still this doesn't solve the problem...

Also result of blkid is empty:

$ sudo blkid /dev/sdb1
$

Finally the solution was found thanks to Harald Hoyer. The uevents have to be sent also for the /dev/sdb after wipe of /dev/sdb1 for this crazy iso to reflect the changes in the udev. But the uevent is send only for /dev/sdb1. So we can do this manually:

$ wipefs -a /dev/sdb1
/dev/sdb1: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31
wipefs: /dev/sdb1: ignore nested "dos" partition table on non-whole disk device
wipefs: /dev/sdb1: ignore nested "mac" partition table on non-whole disk device
wipefs: Use the --force option to force erase.
$ udevadm info --query=env /sys/block/sdb/sdb1 | grep ID_FS_TYPE
ID_FS_TYPE=iso9660
$ echo "change" > /sys/block/sdb/uevent
$ echo "change" > /sys/block/sdb/sdb1/uevent
$ udevadm info --query=env /sys/block/sdb/sdb1 | grep ID_FS_TYPE

(It is used patched wipefs from master.)

It can be fixed by changing udev rules, but Kay don't want it. So we can do this in udisks to fix it, but not sure how to do that. David, have you some ideas?

Created attachment 101654 [details] [review]
Fail before formating if partition contains partition table

I made workaround to read correct filesystem type after wipefs, however the formating procedure fails also for mkfs :-( It would be good to check if we have non-standard layout (partition contains partition table) and fail at the beginning without any modification...

For the record, I was talking to Ondrej on IRC yesterday, and he's working on reproducing this situation with some sfdisk calls, so that we can also cover this in the tests. Thanks!

Created attachment 103499 [details]
sfdisk /dev/sdb -O BACKUP

Unfortunately I'm not able to simply create partition starting with zero offset using fdisk/sfdisk, following code doesn't work:
sfdisk /dev/sdb << EOF
0,
EOF

The partition starts after the partition table. However I'm able to backup and restore the layout from the iso using (though that it prints the error):
sfdisk /dev/sdb -O BACKUP
sfdisk /dev/sdb -I BACKUP
sfdisk: write failed: /dev/sdb

So attaching the BACKUP file for the Fedora iso if it helps somehow. 

Fedora iso is created using the isohybrid tool. So another way is use the tool to make test iso...

I tried to format a USB stick containing a Fedora 21 image this morning (using Nautilus 3.14.1). It failed and an error dialog was shown:

"Error formatting volume

Error synchronising after initial wipe: Timed out waiting for object (udisks-error-quark, 0)"

Still happens on GNOME 3.16. Using Antergos(Arch based distro). I tried to format a USB drive to which a Fedora ISO was written to.
 
Error synchronizing after initial wipe: Timed out waiting for object (udisks-error-quark, 0)

Those live disks are pretty specific and it isn't possible to format just the first partition alone. You can see "This partition cannot be modified because probably contains partition table, please reinitialize layout of the whole device." error with the applied attachment 101654 [details] [review]. Whole device have to be reinitialized, not only partition. You can't do it in Nautilus, but you can do it e.g. using Gnome Disks application.

Unfortunately the fix was not applied yet...

Martin, can't you push the patch without the test case?

Ondrej, I'm ok with applying https://bugs.freedesktop.org/attachment.cgi?id=101654, but as far as I understand this doesn't fix the actual problem, just makes a better error message, right?

(In reply to Martin Pitt from comment #15)
> Ondrej, I'm ok with applying
> https://bugs.freedesktop.org/attachment.cgi?id=101654, but as far as I
> understand this doesn't fix the actual problem, just makes a better error
> message, right?

Yeah. The problem is that you can't sanely wipe a partition when it overlaps with another partition or the entire drive.

OK, I applied this with some grammar updates. Thanks!