Created attachment 744969 [details]
File: anaconda-tb

Created attachment 744970 [details]
File: anaconda.log

Created attachment 744971 [details]
File: backtrace

Created attachment 744972 [details]
File: environ

Created attachment 744973 [details]
File: ifcfg.log

Created attachment 744974 [details]
File: lsblk_output

Created attachment 744975 [details]
File: nmcli_dev_list

Created attachment 744976 [details]
File: packaging.log

Created attachment 744977 [details]
File: program.log

Created attachment 744978 [details]
File: storage.log

Created attachment 744979 [details]
File: syslog

Description of problem:
Tried to delete all partitions from disks selected for installation. The installation was done from USB media.

Version-Release number of selected component:
anaconda-19.30-1

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Beta\x20x86_64 rd.live.check quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Beta

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2137, in on_remove_clicked
    self._destroy_device(dev)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2013, in _destroy_device
    self.__storage.initializeDisk(device)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 812, in initializeDisk
    labelType = _platform.bestDiskLabelType(disk)
  File "/usr/lib/python2.7/site-packages/blivet/platform.py", line 107, in bestDiskLabelType
    labelType = self.requiredDiskLabelType(device.partedDevice.type)
AttributeError: 'NoneType' object has no attribute 'type'

Description of problem:
When trying to delete all partitions by pressing minus button in manual partitioning screen and ticking that I want to delete all partitions, traceback occured.

Version-Release number of selected component:
anaconda-19.30-1

Additional info:
reporter:       libreport-2.1.4
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-Beta\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.2-301.fc19.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        19-Beta

Truncated backtrace:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2137, in on_remove_clicked
    self._destroy_device(dev)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2013, in _destroy_device
    self.__storage.initializeDisk(device)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 812, in initializeDisk
    labelType = _platform.bestDiskLabelType(disk)
  File "/usr/lib/python2.7/site-packages/blivet/platform.py", line 107, in bestDiskLabelType
    labelType = self.requiredDiskLabelType(device.partedDevice.type)
AttributeError: 'NoneType' object has no attribute 'type'

Reproduced a 2nd time. This is when I  try to delete an existing partition.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019-TC6\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.9-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19-TC6

Probably a duplicate of #977279, I guess you could mark either one as a duplicate.

Clyde: the device causing the problem for you appears to be sde, aka '/dev/disk/by-id/usb-Generic_2.0_Reader_-0_070302014067000001-0:0' . Do you know what this 'Generic 2.0 Reader' is on your system? Did you explicitly select it as a target disk (perhaps in error)? Is it removable?

Ladislav, you likely have a similar device in your system causing problems; can you identify what it is (look for 'no media present' in storage.log) or attach your logs so we can see?

Discussed at 2013-06-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-24/f19final-blocker-review-8.2013-06-24-16.00.log.txt . We agreed this is a potentially worrisome issue, but we need more data to make a blocker determination.

In particular we'd like to have more detailed information on the devices known to trigger this apart from Dan's iPhone - so Clyde's 'generic USB reader' and Ladislav's device - and we'd *really* like to know if you have to explicitly select the problematic device as an install target in order to hit the bug.

sde was not selected.  It is a 1TB internal sata.  The only generic USB reader would have been sdi, the installation USB key.

For me this bug did not make any sense, the storage logs didn't make sense, and at the time I felt it was probably an artifact of a previous unsuccessful install attempt.

Probably a real corner case and I have not encountered it subsequently.

No, for this install attempt, it was definitely sde. Just look at storage.log :

02:27:44,179 DEBUG blivet:          DeviceTree.addUdevDevice: info: {'DEVLINKS': '/dev/disk/by-id/usb-Generic_2.0_Reader_-0_070302014067000001-0:0 /dev/disk/by-path/pci-0000:00:1a.7-usb-0:3:1.0-scsi-0:0:0:0',
 'DEVNAME': 'sde',

sounds like perhaps your device tree somehow got screwed up in this attempt and perhaps you selected the wrong disks inadvertently? but if you can't reproduce it, might be hard to investigate further.

What system were you testing on? Does it have some kind of SD card reader?

No card reader.  Just the usual USB ports on an ASUS P5K-E mobo.  The disks presented for selection on this system have been consistent throughout this release.  sdi has been consistently the USB key and sde the 1TB disk.  That is why I think this is an artifact.  The fact that someone else hit this speaks against it being an artifact, tho.

Getting ready to try the test again with RC6, but I won't be able to remember every step.  Lets see what happens.

clyde: well we're fairly sure the basic bug here is when the storage code tries to deal with a disk that reports 'no media present', but what we're trying to figure out is how exactly that can be triggered and how likely it is to occur. We know Dan's case was triggered by having an iPhone connected during install; we don't know much about your case and less about Ladislav's.

I'm working as fast as I can, but it is taking forever to create the USB key for some reason.  Could test from DVD, but this bz occurred when a USB key was used.

I hit this on the DVD while trying to delete a partition of 0 bytes that pre-existed.

Steps to reproduce:

1) Install fedora on a clean hard drive. Create the partitions manually. 
- 1 partition for swap, 1 partition for / 
- Use EXT4 without LVM


2) Install fedora again on top of the existing installation using the same media (DVD in my case)

3) Follow the same steps to get back to custom partitioning. You will see 3 partitions. The 2 you created on the first install and a 0 byte partition. Try to delete the 0 byte partition and Anaconda will crash.

Dan: we don't think that is the reproducer for you. We think the reproducer for you is this:

'name': 'sdb'
'symlinks': ['/dev/disk/by-id/usb-HTC_Android_Phone_HT119HV00691-0:0',
...
01:23:04,611 DEBUG blivet: looking up parted Device: /dev/sdb
01:23:04,634 DEBUG blivet: no device or no media present

i.e., your Android phone (not iPhone, got that mixed up) reports 'no device or no media present', like Clyde's mysterious USB reader reports 'no media present'.

That's from the storage.log you attached to 977279 .

Dan: if you disconnect your phone, do you still hit the crash? How about if you leave it connected but don't select it at the disk selection screen?

Good catch. I did not even think about that. Let me try that when I get home.

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

I have tried to duplicate the original sequence used that caused this bz to no avail.  All I can think of is that I had inadvertently selected sde.  In any case there is no card reader on this system and never has been.

Reproduced when my phone is plugged in, it shows a 0 byte sized partition that crashes anaconda when I attempted to delete it.

So to be clear: when your phone is plugged in, your phone does not appear on the disk selection screen - the first screen after clicking Installation Destination - but a 0-byte partition shows up as part of your primary hard disk, and trying to delete that causes the bug? And if you boot without the phone connected, that 0-byte partition does not appear?

1) In custom partitioning only 1 hard drive shows
2) Phone is set to charge only, does not try to present itself as a drive.
3) The 0 byte partition shows as a 0 byte partition under my primary hard drive.
4) On second try when the phone is not plugged in it does not show up as a 0 byte partition
5) I never click "installation destination" doing that deselects my primary hard drive. By default it is checked, clicking on it would deselect it. I just click next -> custom partitioning. 
6) Only 1 installation destination ever shows with or without the phone.

(In reply to Adam Williamson from comment #16)
> Ladislav, you likely have a similar device in your system causing problems;
> can you identify what it is (look for 'no media present' in storage.log) or
> attach your logs so we can see?

Adam, I will try to reproduce it later in the evening when I return home as it happened during installation to my home desktop. 

The installation was done from USB flash disk connected directly to the PC. The 'no media present' message might come from SD card reader in my Dell 2410 LCD. From what I remember, Anaconda detected some disk (named sdf) with 0b size and that could be troubled SD card reader.

I left one bit of clarification out of Dan's case: the crash only happens if he tries to delete the mysterious 0-byte partition. If he does not, he doesn't hit the crash. He hasn't tried completing a full installation without deleting that partition (I wouldn't either, I'd be worried it'd nuke my phone), but at least there seems to be a way to avoid the crash.

On the current data I'm -1 blocker on this, but it'd be nice to hear back from Ladislav. Ladislav, as well as general background, we're specifically interested in whether you have to explicitly select the disk as a target disk on the first screen after clicking 'Installation Destination' from the hub, and whether you can avoid the crash and install successfully simply by not trying to manipulate the problematic device/partition.

Ladislav is going to take a look once he gets home, based on the info available, I'm also leaning to -1 blocker. Another thing is - it it would be more widespread with no media in internal sd readers, I'd say we would see explosion on this bug (it's part of every single laptop now). We had similar issue in KDE as far as I remember and it was reported with ipads and similar hw - it could be detached for installation.

I'm also -1 blocker unless this turns out to be much more widespread.

So bcl and dlehman poked at this and figured out what's going on.

Drives which report 'no media present' won't show up in the 'disk selection' screen (the first screen you see on clicking Installation Destination) - they're filtered out of a list called 'storage.disks'. However, they aren't filtered out of a list called 'storage.devices', which is used to construct the list of volumes on the left hand side of the custom partitioning screen. So if you have such a drive, it will always show up in custom partitioning, and if you try to manipulate it, you'll likely hit this bug.

We believe that this bug is only likely to hit removable devices which can actually have 'media present' and 'no media present' states (Dan's phone appears to use 'drive with no media present' when it's in 'charge only' mode, for instance). In most cases it will be easy to 'work around' this bug by just unplugging the offending device. We also don't expect that anything bad will happen if you just complete custom partitioning without making any changes to the offending 'drive'. There may be corner cases where, say, a media card reader built into a laptop or desktop behaves in this way and isn't really 'removable', but overall, our assessment is this is unlikely to hit that many people and there are two fairly obvious workarounds, so we don't see a reason to block release for it.

Note that in Dan's case we don't think the device isn't really showing up 'as a partition on his main drive', that's just a mis-interpretation of what anaconda was showing him: because he'd only selected his main disk as an install target he assumed the phone 'drive' showing up in custom partitioning was being seen as a partition on his main drive, but really what was happening was what I described in the first paragraph of this post.

We have several -1 votes now so setting rejectedblocker. We can re-assess this if Ladislav's info contradicts the above assessment somehow, but we don't expect it to.

Created attachment 765188 [details]
anaconda-tb

I can confirm that bug is triggered by attempt to remove SD Card reader which is detected as sdf on my system with zero byte size. Attaching logs.

Created attachment 765201 [details]
anaconda.log

Created attachment 765202 [details]
ifcg.log

Created attachment 765203 [details]
packaging.log

Created attachment 765205 [details]
program.log

Created attachment 765206 [details]
storage.log

Created attachment 765207 [details]
syslog

Created attachment 765208 [details]
lsblk

Thanks, Ladislav. Is the device removable or built in to your system? Can you do an install successfully if you just leave the offending 'partition' alone? Thanks!

(In reply to Adam Williamson from comment #46)
> Thanks, Ladislav. Is the device removable or built in to your system? Can
> you do an install successfully if you just leave the offending 'partition'
> alone? Thanks!

The SD card reader is built-in in the LCD and it is internally connected to LCD's USB hub which is further connected to the PC. If I disconnect LCD's USB hub from the PC the SC card reader (sdf) disappears as well and problem is solved. I can remove all partitions without triggering traceback.

Another solution to the problem is not touching the problematic zero byte partition.

On Custom partitition window device sdc (empty memcard reader) appeared as unknow device. I've selected this device and clicked on minus for remove.
I didn't select this drive on previous screen, it didn't appeared there.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

While reviewing partitions, try deleting a zero-byte device (flash memory card reader built in to a Dell Optiplex).

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   graphical ksdevice=bootif repo=http://download.wpi.edu/pub/fedora/linux/releases/19/Fedora/x86_64/os lang=en_US keymap=us initrd=f19-x86_64-initrd.img BOOTIF=01-b8-ca-3a-8c-c4-b8 BOOT_IMAGE=f19-x86_64-vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

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

I had an unknown partition with 0 Bytes of data during the custom partitioning screen.

I proceeded to delete that partition which gave anaconda a white screen.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 rd.live.check quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

I attempted to delete an unknown partition with 0 Bytes of data.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

Installation. A hard disk is detected as Unknown device. While manual partitioning, press "-" to remove a partition, select "Remove all partitions on Unknown device" (do not remember exactly expression) checkbox. Press OK.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

anaconda folks, looks like enough people inexplicably decide it's a good idea to go around wiping 0 byte partitions they are unsure of the origin of that we should really fix this for f20...(do people really hate their data or something? if an installer showed me a weird 0 byte partition for reasons I didn't understand, the last thing I'd do is *try and delete it*...)

Deleted all partitions in the root

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

I was trying to reinstall Fedora 19 from an old RHEL6 server where some old iscsi connexions where apparently still discovered. 
The partitioning tool showed me the old system on /dev/sda but also a /dev/sdb disk (which should not have been there).

When I tried to remove it, the error triggered.

cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 quiet nomodeset usbcore.autosuspend=-1 BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
package:        anaconda-19.30.13-1
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Cannot get release name.
version:        19

While using the live cd installer, the error prevents removal of existing disk partitions to create space to intsall fedora. I've hit it twice now, and I'm not sure how to work around it. Will try a "normal" install dvd shortly to see if that has the same issue

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=/Fedora-Live-Desktop-x86_64-19-1/isolinux/initrd0.img root=live:CDLABEL=Multi-Boot live_dir=/Fedora-Live-Desktop-x86_64-19-1/LiveOS/ rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=/Fedora-Live-Desktop-x86_64-19-1/isolinux/vmlinuz0 
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-blivet-0.17-1.fc19.noarch
package:        anaconda-19.30.13-1.fc19.x86_64
packaging.log:  
product:        Fedora
reason:         AttributeError: 'NoneType' object has no attribute 'type'
release:        Fedora release 19 (Schrödinger’s Cat)
version:        19

steve: every case of this we've seen so far involved removing a bogus partition that represents a storage device with no medium. If that's not the case for you, we'll need more details.

Created attachment 826800 [details]
Boot sector of troublesome disk

I don't think that the problem in this case was related to anything of zero size. The partition size was fairly large in the cases that I was trying to delete.

In the end I didn't bother to try the install image, and stayed with the live image, but simply blotted out the boot sector. Since it was then installing from scratch, there was no problem after that.

well, no-one's filed a report of this with F20, so let's say bcl's fix in 20.19 worked.

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