Bug 1156354

Created attachment 950284 [details]
File: anaconda-tb

Created attachment 950285 [details]
File: anaconda.log

Created attachment 950286 [details]
File: environ

Created attachment 950287 [details]
File: lsblk_output

Created attachment 950288 [details]
File: nmcli_dev_list

Created attachment 950289 [details]
File: os_info

Created attachment 950290 [details]
File: program.log

Created attachment 950291 [details]
File: storage.log

Created attachment 950292 [details]
File: syslog

Created attachment 950293 [details]
File: ifcfg.log

Created attachment 950294 [details]
File: packaging.log

Another user experienced a similar problem:

Trying again bug 1156354, this time with raid 0.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   initrd=initrd.img inst.stage2=hd:UUID=a6fb7862-fa16-46a1-bdad-24d5bc61b15c quiet BOOT_IMAGE=vmlinuz 
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
package:        anaconda-21.48.12-1
product:        Fedora"
reason:         ValueError: cannot modify protected device
release:        Cannot get release name.
version:        Fedora

Created attachment 950297 [details]
anaconda screen

This is how it looks like, when I go to custom part and try to create a new automatic layout without trying to remove "Volume0_0" first. It says "no disks selected" in the status bar, and after clicking on it, there's the dialog that you can see.

On the very same machine and drive, I installed F20 without problems.

This seems to violate https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria#Hardware_and_firmware_RAID :
"The installer must be able to detect and install to hardware or firmware RAID storage devices."

I can confirm exactly the same experience as kparal with my usual fwraid test system: the 'error saving storage configuration' after trying to do guided partitioning to an empty disk, the "No disks selected" message and inability to create partitions in custom part, the weird Unknown 'volume' shown as an existing volume in custom part (the array I'm testing with is freshly created and entirely empty), and the crash when trying to delete it.

+1 blocker, as it seems like fwraid is simply broken, with at least two reports on systems known to work with F20 (mine did too - it's the system I did F20 validaiton testing on).

+1 blocker - clearly violates the criterion cited above.

actually, I got a slightly different crash - it didn't crash when I removed the 'existing volume' but it crashed as soon as I tried to create a new partition after doing that. The traceback is 'KickstartValueError: The following problem occurred on line 0 of the kickstart file: Requested boot drive "Volume0_0" doesn't exist or cannot be used.'

it's probably all the same bug, though, just different consequences of anaconda handling the RAID set wrong.

Just some extracted information from the logs:
Local variables in innermost frame:
device: existing 3807 MiB partition sdd1 (338) with existing ext4 filesystem


from the storage.log file::
05:26:39,835 DEBUG blivet:              DeviceTree.getDevicesByInstance returned [PartitionDevice instance (0x7fe142c25d10) --
  name = sdd1  status = True  kids = 0 id = 338
  parents = ['existing 3810 MiB disk sdd (333) with existing msdos disklabel']
  uuid = None  size = 3807 MiB
  format = existing ext4 filesystem
  major = 8  minor = 49  exists = True  protected = True
  sysfs path = /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/host6/target6:0:0/6:0:0:0/block/sdd/sdd1  partedDevice = parted.Device instance --
  model: Unknown  path: /dev/sdd1  type: 0
  sectorSize: 512  physicalSectorSize:  512
  length: 7796736  openCount: 0  readOnly: False
  externalMode: False  dirty: False  bootDirty: False
  host: 13107  did: 13107  busy: True
  hardwareGeometry: (1022, 123, 62)  biosGeometry: (485, 255, 63)
  PedDevice: <_ped.Device object at 0x7fe137aa5e60>
  target size = 0 B  path = /dev/sdd1
  format args = []  originalFormat = ext4  grow = None  max size = 0 B  bootable = True
  part type = 0  primary = None  start sector = None  end sector = None
  partedPartition = parted.Partition instance --
  disk: <parted.disk.Disk object at 0x7fe142c2b150>  fileSystem: <parted.filesystem.FileSystem object at 0x7fe142b713d0>
  number: 1  path: /dev/sdd1  type: 0
  name: None  active: True  busy: True
  geometry: <parted.geometry.Geometry object at 0x7fe142b711d0>  PedPartition: <_ped.Partition object at 0x7fe142c1da70>
  disk = existing 3810 MiB disk sdd (333) with existing msdos disklabel
  start = 2048  end = 7798783  length = 7796736
  flags = boot]


I think the core of the issue is that the partedPartition is reported to be 'busy'.

sdd1 is the USB key he's installing from, not the array he's installing to. We don't actually want to be doing anything to sdd1. I think either somehow anaconda got confused about the 'delete this weird volume' request and wound up trying to apply it to sdd1, or sdd1 isn't actually the 'protected device' in question, the RAID set is.

Either way, things start going wrong quite a long way before the crash, so it's not just the traceback that's relevant here. I think the crashes are almost junk data - anaconda's actual interpretation of the storage situation seems so wrong that it's almost not surprising that trying to do anything in custom part causes odd-looking crashes.

Discussed at 2014-10-24 Go/No-Go meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-24/f21_beta_gono-go_meeting.2014-10-24-17.01.log.txt . Accepted as a blocker per criterion cited in c#15.

dlehman has a fix for this which seems to work for me:

https://dlehman.fedorapeople.org/updates/updates-1156534.2.img

(careful with the URL - he typo'ed the bug number as 6534 not 6354)

with that updates.img I get a successful install, however boot of the installed system fails - that's https://bugzilla.redhat.com/show_bug.cgi?id=1156614 .

I tried both guided and manual partitioning and this updates.img (and also the one from bug 1156614 comment 4) fixes the problem for me.

Unfortunately I have discovered a new bug that seems related to this one - bug 1157657 - when the raid volume is deleted, anaconda is not able to start until the disks are completely wiped.

anaconda-21.48.13-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/anaconda-21.48.13-1.fc21

With Beta RC2, everything seems to work correctly.

anaconda-21.48.13-1.fc21, python-blivet-0.61.8-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.