Bug 965865

Summary: ValueError: ('invalid size specification', '-880.000000 MB')
Product: [Fedora] Fedora Reporter: Mark Hamzy <hamzy>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, awilliam, clumens, dshea, g.kaviyarasu, hamzy, jonathan, mkolman, robatino, sbueno, tomas.vanderka, vanmeeuwen+fedora, vbocek
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Unspecified   
Whiteboard: abrt_hash:b54a1e182fabfda9fbd300a5ab4f53de7b3f857f4e24975cf8c561e5134272f0
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-03 16:58:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 834090, 920770    
Attachments:
Description Flags
File: anaconda-tb
none
File: anaconda.log
none
File: backtrace
none
File: environ
none
File: ifcfg.log
none
File: lsblk_output
none
File: nmcli_dev_list
none
File: packaging.log
none
File: program.log
none
File: storage.log
none
File: syslog
none
Video answer none

Description Mark Hamzy 2013-05-21 21:07:14 UTC
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')

Comment 1 Mark Hamzy 2013-05-21 21:07:19 UTC
Created attachment 751375 [details]
File: anaconda-tb

Comment 2 Mark Hamzy 2013-05-21 21:07:24 UTC
Created attachment 751376 [details]
File: anaconda.log

Comment 3 Mark Hamzy 2013-05-21 21:07:27 UTC
Created attachment 751377 [details]
File: backtrace

Comment 4 Mark Hamzy 2013-05-21 21:07:31 UTC
Created attachment 751378 [details]
File: environ

Comment 5 Mark Hamzy 2013-05-21 21:07:40 UTC
Created attachment 751379 [details]
File: ifcfg.log

Comment 6 Mark Hamzy 2013-05-21 21:07:46 UTC
Created attachment 751380 [details]
File: lsblk_output

Comment 7 Mark Hamzy 2013-05-21 21:07:51 UTC
Created attachment 751381 [details]
File: nmcli_dev_list

Comment 8 Mark Hamzy 2013-05-21 21:07:55 UTC
Created attachment 751382 [details]
File: packaging.log

Comment 9 Mark Hamzy 2013-05-21 21:08:00 UTC
Created attachment 751383 [details]
File: program.log

Comment 10 Mark Hamzy 2013-05-21 21:08:04 UTC
Created attachment 751384 [details]
File: storage.log

Comment 11 Mark Hamzy 2013-05-21 21:08:08 UTC
Created attachment 751385 [details]
File: syslog

Comment 12 Chris Lumens 2013-05-22 20:21:07 UTC
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.

Comment 13 Mark Hamzy 2013-05-23 19:05:07 UTC
Created attachment 752342 [details]
Video answer

Comment 14 Mark Hamzy 2013-05-28 16:46:52 UTC
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."

Comment 15 Vojtěch Boček 2013-05-29 08:51:40 UTC
I can't reproduce this with Fedora Beta RC4 (Anaconda 19.30-1) in x86_64 KVM with three 20gb disks.

Comment 16 Mark Hamzy 2013-05-29 13:58:39 UTC
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

Comment 17 Adam Williamson 2013-05-29 17:32:50 UTC
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.

Comment 18 Vojtěch Boček 2013-05-30 12:14:38 UTC
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.

Comment 19 Mark Hamzy 2013-05-30 16:04:30 UTC
I tried recreating this with clean disks and ran into bug 966795.

Comment 20 Mark Hamzy 2013-05-30 16:05:31 UTC
By the way, the three disks are virtual scsi disks created by the hypervisor (HMC).

Comment 21 Mark Hamzy 2013-05-30 18:58:14 UTC
Nope, sorry.  I performed the wrong action.  I zeroed out the disks again and then recreated this bug again.

Comment 22 Tomas Vanderka 2013-06-01 13:28:13 UTC
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.

Comment 23 Tomas Vanderka 2013-06-01 14:04:40 UTC
Probably a duplicate of bug 959714

Comment 24 Tomas Vanderka 2013-06-03 16:34:44 UTC
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.

Comment 25 Adam Williamson 2013-06-03 16:48:55 UTC
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!

Comment 26 Adam Williamson 2013-06-03 16:58:50 UTC
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 ***