Created attachment 685773 [details]
anaconda.log

Created attachment 685774 [details]
anaconda-yum.conf

Created attachment 685775 [details]
ifcfg.log

Created attachment 685776 [details]
packaging.log

Created attachment 685777 [details]
program.log

Created attachment 685779 [details]
storage.log

Created attachment 685780 [details]
syslog

Created attachment 685782 [details]
X.log

Created attachment 685784 [details]
lsblk_and_list-harddrives.png

Attaching also outputs of lsblk and list-harddrives commands.

I suppose they could be live-related.  Those are the only things in your storage.log I see as reporting 0 size,  but I would have thought we'd run into those problems already.  If you hover the mouse over them, do you get any more identifying information?

Those may be 2 drives that are marked in BIOS/UEFI as Virtual floppy and Virtual CD-ROM. Those are not visible by anaconda on the same system in RHEL-6 anaconda.

On hover those drives show:
sda | 20080519
sda | 20080519

Well, I've got a commit for this pushed for anaconda-19.3.  Unfortunately those builds are not being pulled into RHEL7 at the moment, for understandable reasons.  How do you want to handle the resolution?

anaconda-19 is ok, we can have this bug in alpha3 since it doesn't block anything.

I still can test the fix however on newer anaconda either on Fedora or using internal anaconda builds.

0b drives are still visible in custom partitioning. There are visible in UNKNOWN system. If I try to delete this 0b UNKNOWN drive, bug 960794 is appeared.

Please, when you reopen a bug, attach details - log files, pictures, etc.

Created attachment 818298 [details]
0b devices in custom partitioning

Created attachment 818299 [details]
anaconda-tb after removing 0b device

Do you remember what steps you took?  Did the disks in question appear on the first storage screen you saw?  If not, did they just later appear on custom storage, or did you do something special to cause that to happen?

0b devices are showed on custom storage (see attachment 818298 [details]), they are not showed on first storage screen. These 0b devices are card readers (every supported card type is showed as 0b device, except SD reader)

Created attachment 857511 [details]
anaconda-tb

Issue as is described in comment 19 is also in anaconda-19.31.54-1. Traceback (attachment 857511 [details]) is from attempt to remove this 0b device.

*** Bug 1056568 has been marked as a duplicate of this bug. ***

I am going to need actual, physical, in-person hardware to work on this.  I'll try to find some around here but if anyone knows of any in Westford, that would be very helpful.

I'm not aware of any system in westford, but it seems, that any system with non-SD card reader should be sufficient.
We have such system in BRQ office available, so any anaconda guy in BRQ can come and test on it.

*** Bug 1051897 has been marked as a duplicate of this bug. ***

This is a python-blivet's issue and the patch is already applied in Rawhide.

Another user experienced a similar problem:

After I tried to delete all partititions from previous installation of RHEL Atomic host on UEFI enabled machine a traceback has occured.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL\x20Atomic\x20Host\x207\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.10.0-123.8.1.el7.x86_64
package:        anaconda-19.31.79-1
packaging.log:  
product:        Red Hat Enterprise Linux
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Red Hat Enterprise Linux Workstation release 7.0 (Maipo)
release_type:   pre-release
version:        7.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-0313.html