Description of problem: Select custom partitioning. Change the RAID level in the configure volume group dialog. The following was filed automatically by anaconda: anaconda 19.25-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/size.py", line 80, in _parseSpec raise ValueError("invalid size specification", spec) File "/usr/lib/python2.7/site-packages/blivet/size.py", line 138, in __new__ self = Decimal.__new__(cls, value=_parseSpec(spec)) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/accordion.py", line 61, in selectorFromDevice size = Size(spec="%f MB" % device.size) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1027, in _replace_device selector=selector) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1305, in _save_right_side selector=selector) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1814, in on_back_clicked self._save_right_side(self._current_selector) ValueError: ('invalid size specification', '-880.000000 MB') Version-Release number of selected component: anaconda-19.25-1 Additional info: reporter: libreport-2.1.4 cmdline: /usr/bin/python /sbin/anaconda cmdline_file: ro inst.vnc inst.sshd ip=9.5.114.36::9.5.114.1:255.255.255.0:sharpie.rch.stglabs.ibm.com:eth0:none ip=9.5.114.41::9.5.114.1:255.255.255.0::eth1:none nameserver=9.10.244.100 bootdev=eth0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.2-301.fc19.ppc64 product: Fedora release: Cannot get release name. type: anaconda version: 19 Truncated backtrace: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1814, in on_back_clicked self._save_right_side(self._current_selector) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1305, in _save_right_side selector=selector) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1027, in _replace_device selector=selector) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/accordion.py", line 61, in selectorFromDevice size = Size(spec="%f MB" % device.size) File "/usr/lib/python2.7/site-packages/blivet/size.py", line 138, in __new__ self = Decimal.__new__(cls, value=_parseSpec(spec)) File "/usr/lib/python2.7/site-packages/blivet/size.py", line 80, in _parseSpec raise ValueError("invalid size specification", spec) ValueError: ('invalid size specification', '-880.000000 MB')
Created attachment 751375 [details] File: anaconda-tb
Created attachment 751376 [details] File: anaconda.log
Created attachment 751377 [details] File: backtrace
Created attachment 751378 [details] File: environ
Created attachment 751379 [details] File: ifcfg.log
Created attachment 751380 [details] File: lsblk_output
Created attachment 751381 [details] File: nmcli_dev_list
Created attachment 751382 [details] File: packaging.log
Created attachment 751383 [details] File: program.log
Created attachment 751384 [details] File: storage.log
Created attachment 751385 [details] File: syslog
Hm, a quick test did not reproduce this problem. Could you please be a little more specific about what disks you started with and what choices you made that resulted in this problem? Thanks.
Created attachment 752342 [details] Video answer
Proposing as a FinalBlocker: "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above."
I can't reproduce this with Fedora Beta RC4 (Anaconda 19.30-1) in x86_64 KVM with three 20gb disks.
I can reproduce this with http://ppc.koji.fedoraproject.org/stage/f19-20130523-Beta-RC4.1/ppc64/iso/Fedora-19-ppc64-DVD.iso anaconda-19.30-1.fc19.ppc64
Discussed at 2013-05-29 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-29/f19final-blocker-review-1.2013-05-29-16.02.log.txt . We agreed we really don't have enough information to evaluate this yet. The reporter's config is unusual in all kinds of ways: it's PPC64, using disks which clearly have existing data/configuration, the disks appear to be remote-attached SCSI or something. The bug doesn't appear to be reproducible using a primary arch and local disks, so at least some of the weirdness is inherent to reproducing the bug, it appears. We can't really make a blocker determination until we know what factors are necessary to trigger the bug - particularly if it's arch-specific or dependent on the pre-existing data. Mark, can you re-test with the disks being clean initially? From the video it looks like at least one of them was part of a RAID array previously. We'll only really be able to decide if this is a blocker once we nail down what's actually causing it.
I tried to make software raid from three 20gb disks in x86_64 kvm (without lvm), then destroy the raid (new partition table on one of the disks in fdisk). Anaconda says that the raid array is broken like in Mark's video, but it still does not crash after I set-up the partitions like in the video.
I tried recreating this with clean disks and ran into bug 966795.
By the way, the three disks are virtual scsi disks created by the hypervisor (HMC).
Nope, sorry. I performed the wrong action. I zeroed out the disks again and then recreated this bug again.
I can reproduce this on physical system with 2x 3TB fresh new disks with no previous partitioning and selecting RAID1 instead of RAID5 in the video. The system is x86_64 and the installation was started with F19 Beta netinstall image via USB.
Probably a duplicate of bug 959714
This can be worked around by removing/resizing LVs before changing redundancy on VG. Otherwise effective VG size is reduced but LVs still have the original size resulting in negative VG free space. Anaconda/blivet should probably resize automatically sized LVs when resizing VG, or warn there's not enough space to modify the VG.
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . Thanks to shadof for the information. We agreed that if shadof's assessment in c#23 and c#24 is accurate, this bug is a dupe of 959814 and 959814 will be accepted as a blocker. Otherwise we will re-assess at the next meeting. anaconda devs, can you please advise whether shadof is correct? Thanks!
dlehman thinks this and 959714 are probably both cases of 965805, so marking them as dupes of that and marking that as a blocker. *** This bug has been marked as a duplicate of bug 965805 ***