Hide Forgot
Description of problem: I tried to install to a firmware RAID (level 5). First of all, I twice tried guided partitioning. I saw an error on the main hub, but when I entered the storage spoke, there was no error there. That itself is a bug. Then I tried custom partitoning. When I entered it, there was "Volume 0 (type raid 5)" in the Unknown tab, so I tried to remove it. Then anaconda crashed. Version-Release number of selected component: anaconda-21.48.12-1 The following was filed automatically by anaconda: anaconda 21.48.12-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1306, in destroyDevice raise ValueError("cannot modify protected device") File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1724, in _destroy_device self._storage_playground.destroyDevice(device) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 121, in decorated return func(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1848, in on_remove_clicked self._destroy_device(dev) ValueError: cannot modify protected device Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:UUID=a6fb7862-fa16-46a1-bdad-24d5bc61b15c rd.live.check quiet BOOT_IMAGE=vmlinuz executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.17.1-302.fc21.x86_64 product: Fedora" release: Cannot get release name. type: anaconda version: Fedora
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.