Bug 1013586 - SizeNotPositiveError: spec= param must be >=0
Summary: SizeNotPositiveError: spec= param must be >=0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:267490d8b33741741827b8ee140...
Depends On:
Blocks: F20FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2013-09-30 11:57 UTC by Kamil Páral
Modified: 2013-12-11 01:57 UTC (History)
13 users (show)

Fixed In Version: python-blivet-0.23.7-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-29 13:55:33 UTC


Attachments (Terms of Use)
File: anaconda-tb (206.18 KB, text/plain)
2013-09-30 11:57 UTC, Kamil Páral
no flags Details
File: anaconda.log (5.83 KB, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: environ (518 bytes, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: lsblk_output (2.98 KB, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: nmcli_dev_list (4.79 KB, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: os_info (291 bytes, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: program.log (30.98 KB, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: storage.log (131.81 KB, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
File: ifcfg.log (567 bytes, text/plain)
2013-09-30 11:58 UTC, Kamil Páral
no flags Details
bug demonstration video (1.08 MB, video/ogg)
2013-10-09 10:06 UTC, Kamil Páral
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1040012 None None None Never

Internal Links: 1040012

Description Kamil Páral 2013-09-30 11:57:53 UTC
Description of problem:
I tried to shrink NTFS partition (GPT, UEFI).

Version-Release number of selected component:
anaconda-20.18-1.fc20.x86_64

The following was filed automatically by anaconda:
anaconda 20.18-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/size.py", line 88, in _parseSpec
    raise SizeNotPositiveError("spec= param must be >=0")
  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/lib/disks.py", line 82, in size_str
    return str(Size(spec=spec)).upper()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 218, in _update_labels
    text = _("Total selected space to reclaim: <b>%s</b>") % size_str(selectedReclaimable)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 375, in _actionChanged
    self._update_labels(selectedReclaimable=self._selectedReclaimableSpace)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 339, in on_shrink_clicked
    self._actionChanged(itr, SHRINK)
SizeNotPositiveError: spec= param must be >=0

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.11.0-300.fc20.x86_64
other involved packages: python-blivet-0.20-1.fc20.noarch
product:        Fedora
release:        Fedora release 20 (Heisenbug)
type:           anaconda
version:        20

Comment 1 Kamil Páral 2013-09-30 11:57:58 UTC
Created attachment 805138 [details]
File: anaconda-tb

Comment 2 Kamil Páral 2013-09-30 11:58:03 UTC
Created attachment 805139 [details]
File: anaconda.log

Comment 3 Kamil Páral 2013-09-30 11:58:11 UTC
Created attachment 805140 [details]
File: environ

Comment 4 Kamil Páral 2013-09-30 11:58:16 UTC
Created attachment 805141 [details]
File: lsblk_output

Comment 5 Kamil Páral 2013-09-30 11:58:21 UTC
Created attachment 805142 [details]
File: nmcli_dev_list

Comment 6 Kamil Páral 2013-09-30 11:58:26 UTC
Created attachment 805143 [details]
File: os_info

Comment 7 Kamil Páral 2013-09-30 11:58:31 UTC
Created attachment 805144 [details]
File: program.log

Comment 8 Kamil Páral 2013-09-30 11:58:36 UTC
Created attachment 805145 [details]
File: storage.log

Comment 9 Kamil Páral 2013-09-30 11:58:41 UTC
Created attachment 805146 [details]
File: ifcfg.log

Comment 10 Petr Schindler 2013-09-30 12:16:27 UTC
On Fedora-20-Alpha Live CD. I have one NTFS partition on GPT. Exception is raised after I choose ntfs partition and click on shrink in 'reclaim disk space'. Everything works fine with MBR.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb
hashmarkername: anaconda
kernel:         3.11.0-300.fc20.x86_64
other involved packages: python-blivet-0.20-1.fc20.noarch
package:        anaconda-20.18-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         SizeNotPositiveError: spec= param must be >=0
release:        Fedora release 20 (Heisenbug)
version:        20

Comment 11 Kamil Páral 2013-09-30 12:36:08 UTC
This happens when you select a partition in the guided dialog and click on Shrink button. It happens for both NTFS and Ext4 partitions. It happens only with GPT, not with MBR. It doesn't seem to happen with custom partitioning dialog.

Strangely enough, if I do a default Win8 UEFI (i.e. GPT) installation, I can resize its NTFS partition just fine. Maybe our tools create broken partition tables (protective MBR?) somehow?

Reproducer:
1. Boot F20 Alpha Live
2. Format the disk with GPT, create a single NTFS/ext4 partition covering the whole disk.
3. Run anaconda, click on Reclaim space, click on the partition, click on Shrink.

Reproduced both on bare metal and in VM, by several people.

Comment 12 Kamil Páral 2013-09-30 12:39:43 UTC
I guess this could fall into Beta criteria:

" When using the guided partitioning flow, the installer must be able to: 
 Remove existing storage volumes to free up space, at the user's direction "
https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria

It says remove, but it should say shrink as well, probably, because we don't have that covered in Final criteria.

Comment 13 Kamil Páral 2013-09-30 12:46:51 UTC
(In reply to Kamil Páral from comment #11)
> 2. Format the disk with GPT, create a single NTFS/ext4 partition covering
> the whole disk.

Just a note, I used gnome-disks for this.

Comment 14 Chris Murphy 2013-10-02 16:00:08 UTC
For OP: The failure occurs if the target is produced by gnome-disks (both creating the GPT and the NTFS volume); but does not occur if the Windows installer creates them?

For dlehman: Some size parameter has a negative value and it should be positive? Is this possibly related to how the file system was created, maybe due to a bug in ntfs-3G?

Comment 15 Kamil Páral 2013-10-02 16:58:29 UTC
Interestingly enough, if I create the layout with gparted, it doesn't crash. It's not important which tools creates the gpt table, the important thing is the partition creation. If gparted creates it, everything works. If gnome-disks creates it, anaconda crashes.

Please note that gparted creates a smaller partition (by 1MB) than gnome-disks:

gdisk output:
gparted:

Disk /dev/vda: 20971520 sectors, 10.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AE2D9C61-6F59-47FB-8FE9-4C09ABF9B246
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 20971486
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        20971486   10.0 GiB    8300   

gnome-disks:
Disk /dev/vda: 20971520 sectors, 10.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): AE2D9C61-6F59-47FB-8FE9-4C09ABF9B246
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 20971486
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        20969471   10.0 GiB    0700  


Also the Code is different, but I don't know what that means.

Comment 16 Kamil Páral 2013-10-02 17:01:23 UTC
Please note once again: This is _not_ related to NTFS. It happens with ext4 as well.

Comment 17 Chris Murphy 2013-10-02 18:29:52 UTC
Partition size shouldn't matter, nor the code. 8300 maps to the partition type GUID for Linux volumes, and 0700 maps to the partition type GUID for Microsoft basic data which is what parted has been using for GPT disks since day 1 for some reason. So that shouldn't matter either.

Comment 18 Mike Ruckman 2013-10-02 19:53:44 UTC
Discussed this in the 2013-10-02 Blocker Review Meeting [1]. We need more information and testing to figure out how common this failure mode is. Will re-visit once more testing has been done.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/

Comment 19 Kamil Páral 2013-10-03 08:41:10 UTC
In comment 15 I have swapped the output of gparted and gnome-disks, I'm sorry. Gparted creates a smaller partition (there is a small space at the end of the disk), gnome-disks creates a fully-sized partition.

I reproduced the issue with gdisk. I used gdisk to create a partition with end sector 20969471 -> no crash. Then I deleted the partition and created a new one with end sector 20971486 (last usable sector) -> crash.

This seems to be a problem anaconda, it crashes when the partition occupies a completely full size of the disk.

Comment 20 David Lehman 2013-10-08 17:02:45 UTC
Can someone post a URL pointing to (or exact instructions for creating) a disk image file that causes this failure reliably?

Comment 21 Kamil Páral 2013-10-09 10:06:53 UTC
Created attachment 809836 [details]
bug demonstration video

This is reproduced with F20 Beta TC2 Live x86_64.

Comment 22 Mike Ruckman 2013-10-09 20:54:12 UTC
Discussed this in 2013-10-09 Blocker Review Meeting [1]. Voted an AcceptedBlocker as it violates the following F20 beta release criterion for partitions not created using parted: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select" [2]

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/
[2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning

Comment 23 Adam Williamson 2013-10-16 18:35:36 UTC
Discussed at 2013-10-16 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-16/f20beta-blocker-review-4.2013-10-16-16.02.log.txt . We agreed to move this to be a Final blocker. The criterion cited in c#22 was not intended to cover shrinking from the 'reclaim space' screen, it is more about the 'installation options' screen: the criteria were in fact intended to specifically exclude shrinking from being required to work at Beta, and require it to work to a certain degree at Final.

https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Storage_volume_resize

"Any installer mechanism for resizing storage volumes must correctly attempt the requested operation."

Comment 24 Chris Murphy 2013-10-31 18:06:11 UTC
Weird bug. I can reproduce this in qemu/kvm. If crash will occur, it happens within a few seconds of clicking the shrink button, the slider UI does not appear.

With gparted, no crash.
With gdisk created partition + mkfs.ext4 = crash.

If I start with the working gparted result, and change the partitiontypeGUID from 0700 to 8300, no crash. If I reformat using mkfs.ext4, no crash. So there's something specific about the partition size I think; possibly the fact gnome-disk and gdisk are leaving some space at the end of the block device before the backupt GPT?

Odd bug.

Comment 25 Adam Williamson 2013-11-20 19:27:28 UTC
Status reviewed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . This bug seems to be clearly defined and reproducible and is now just waiting in the queue to be fixed by anaconda devs.

Comment 26 David Lehman 2013-11-26 17:24:39 UTC
Based on the data from comment 15 gnome-disks aligns the end of the partition, while gparted does not. From what I can tell it has nothing to do with the contents of the partition -- only the partition itself.

I am interested to see if the fix for bug 1034232 also resolves this one, so someone please try it once that fix becomes available.

Comment 27 Kamil Páral 2013-11-27 12:02:37 UTC
Vratislav created
http://vpodzime.fedorapeople.org/1008965_updates.img
which should contain the fix from bug 1034232 against TC3. With that applied, I was able to create a new ext4 partition in gnome-disks, shrink it in anaconda and proceed in installation. Please push to f20 branch.

Comment 28 Fedora Update System 2013-11-28 02:03:18 UTC
python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.7-1.fc20,anaconda-20.25.12-1.fc20

Comment 29 Fedora Update System 2013-11-29 13:55:33 UTC
python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Kamil Páral 2013-12-02 08:45:14 UTC
I used TC3, updated anaconda to 20.25.12-1 and reproduced the steps. The problem is fixed.

Comment 31 Chris Murphy 2013-12-09 06:38:43 UTC
Possible dup bug 1038847 has appeared proposed as blocker, same summary different abrt hash. Regression or different entirely?

Comment 32 Kamil Páral 2013-12-09 13:56:42 UTC
(In reply to Chris Murphy from comment #31)
> Possible dup bug 1038847 has appeared proposed as blocker, same summary
> different abrt hash. Regression or different entirely?

In my completely uninformed point of view this is entirely different.

Comment 33 Vratislav Podzimek 2013-12-10 08:41:07 UTC
(In reply to Kamil Páral from comment #32)
> (In reply to Chris Murphy from comment #31)
> > Possible dup bug 1038847 has appeared proposed as blocker, same summary
> > different abrt hash. Regression or different entirely?
> 
> In my completely uninformed point of view this is entirely different.
Agreed, that's an entirely different thing.


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