Bug 965865 - ValueError: ('invalid size specification', '-880.000000 MB')
Summary: ValueError: ('invalid size specification', '-880.000000 MB')
Status: CLOSED DUPLICATE of bug 965805
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: ppc64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:b54a1e182fabfda9fbd300a5ab4...
Keywords:
Depends On:
Blocks: F19Blocker, F19FinalBlocker F19PPCFinal, F19PPCFinalBlocker, PPCFinalBlocker
TreeView+ depends on / blocked
 
Reported: 2013-05-21 21:07 UTC by Mark Hamzy
Modified: 2013-06-03 16:58 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-06-03 16:58:50 UTC


Attachments (Terms of Use)
File: anaconda-tb (894.01 KB, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: anaconda.log (24.33 KB, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: backtrace (958 bytes, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: environ (811 bytes, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: ifcfg.log (881 bytes, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: lsblk_output (2.80 KB, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: nmcli_dev_list (2.49 KB, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: packaging.log (306.29 KB, text/plain)
2013-05-21 21:07 UTC, Mark Hamzy
no flags Details
File: program.log (44.76 KB, text/plain)
2013-05-21 21:08 UTC, Mark Hamzy
no flags Details
File: storage.log (308.97 KB, text/plain)
2013-05-21 21:08 UTC, Mark Hamzy
no flags Details
File: syslog (54.75 KB, text/plain)
2013-05-21 21:08 UTC, Mark Hamzy
no flags Details
Video answer (3.86 MB, application/octet-stream)
2013-05-23 19:05 UTC, Mark Hamzy
no flags Details

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 ***


Note You need to log in before you can comment on or make changes to this bug.