OK, I'm not able to reproduce the problem on wipefs level on Fedora:

# dd if=/home/archive/iso/Fedora-Live-Desktop-x86_64-20-1.iso of=/dev/sdb bs=8M
119+1 records in
119+1 records out
999292928 bytes (999 MB) copied, 411.443 s, 2.4 MB/s

# eject /dev/sdb

... remove and insert again the flash

# lsblk /dev/sdb
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   1  3.7G  0 disk
├─sdb1   8:17   1  953M  0 part /run/media/kzak/Fedora-Live-Desktop-x86_64-20-1
├─sdb2   8:18   1  4.9M  0 part
└─sdb3   8:19   1 19.7M  0 part

... as expected, partitions visible, sdb1 mounted

# umount /run/media/kzak/Fedora-Live-Desktop-x86_64-20-1

# 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
                                                  ^^^^^^^^^^^^^^^^
... this is stupid thing, but without affect to wipefs functionality

Now try it again to see what is on the device:

# wipefs  /dev/sdb1
# blkid -p  /dev/sdb1

... nothing visible on the device.

# eject /dev/sdb

... remove and insert again the flash 

# lsblk /dev/sdb
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb    8:16   1  3.7G  0 disk

kernel does not see any partition table here.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Improved by upstream commit 24ed07818403f2ce52f9116a749036d58b91ca81:

# 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.

... we can backport it to RHEL-7.1.

Udev still see the wrong fs type after calling "wipefs -a /dev/sdb1" with the announced commit:

$ udevadm info --query=env /sys/block/sdb/sdb1 | grep ID_FS_TYPE
ID_FS_TYPE=iso9660

The following fix have been found by Harald Hoyer:

$ 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

Wipefs affects also sdb, but no change uevent is send to him. Consequently there is wrong fs type for sdb1, because the type is inherited from sdb.

Could we call the missing uevent from wipefs for those hybrid isos (e.g. call it in case when force option is needed)?

(In reply to Ondrej Holy from comment #5)
>
> $ 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
> 
> Wipefs affects also sdb, but no change uevent is send to him. Consequently
> there is wrong fs type for sdb1, because the type is inherited from sdb.
> 
> Could we call the missing uevent from wipefs for those hybrid isos (e.g.
> call it in case when force option is needed)?

hmm... seems like request for nasty workaround.

Would be better to have a generic solution? The partition could be modified by many other tools. I guess it's possible to detect this situation in udev rules -- all you need is to scan also whole-disk device (e.g. sdb) on partition (e.g. sdb1) "change" event if the partition has ID_PART_ENTRY_OFFSET=0.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0501.html