Red Hat Bugzilla – Bug 1024144
SizeNotPositiveError: spec= param must be >=0
Last modified: 2013-12-03 16:24:50 EST
Description of problem:
Tried to add a 25gb root thinp LV to existing thinpool, all existing and the new installation listing on the left vanished (totally blank space) and about a minute later a crash.
Version-Release number of selected component:
The following was filed automatically by anaconda:
anaconda 20.25.4-1 exception report
Traceback (most recent call first):
File "/tmp/updates/blivet/size.py", line 88, in _parseSpec
raise SizeNotPositiveError("spec= param must be >=0")
File "/tmp/updates/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/lib/accordion.py", line 176, in addSelector
selector = selectorFromDevice(device, mountpoint=mountpoint)
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 989, in _do_refresh
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2064, in on_add_clicked
self._do_refresh(mountpointToShow=mountpoint or fstype)
SizeNotPositiveError: spec= param must be >=0
cmdline: /usr/bin/python /sbin/anaconda
cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-Beta-TC6\x20x86_64 quiet elevator=noop updates=http://dlehman.fedorapeople.org/updates/updates-1024076.0.img BOOT_IMAGE=vmlinuz
release: Cannot get release name.
Created attachment 816942 [details]
Created attachment 816943 [details]
Created attachment 816944 [details]
Created attachment 816945 [details]
Created attachment 816946 [details]
Created attachment 816947 [details]
Created attachment 816948 [details]
Created attachment 816949 [details]
Created attachment 816950 [details]
Created attachment 816951 [details]
Created attachment 816952 [details]
This is with Fedora-20-Beta-TC6-x86_64-DVD.iso, anaconda-20.25-4.1 with this applied http://dlehman.fedorapeople.org/updates/updates-1024076.0.img.
Could possibly be related to or duplicate of bug 1013586.
Oh great, as it turns out I did alter the LVM layout outside of the installer, and overcommitted it by 250GB afterall. I may have been suitably punished by spending hours trying to reproduce this bug thinking I hadn't until I read the logs. *sigh*
A. Without any external (non-installer) modifications to an existing LVM thinp install, I can easily get the installer to free up space in the pool and use it for a new installation. But the whole point of thinp is the ability to overcommit be it with snapshots, or with vLVs that exceed the size of the pool.
B. To reproduce the crash, via thinp overcommitting outside the installer I have these steps.
1. Install to a new clean disk using LVM Thin Provisioning partition scheme via the guided partitioning path.
2. Reboot to the installed system and create a new vLV, format it ext4.
lvcreate --thinpool fedora/pool00 --virtualsize 250g -n punishment
3. Reboot to the installer, applying updates.img, set partition scheme again to LVM thinp, go to custom partitioning.
4. Add new mount point /, at 25gb.
Installer says "Added new LVM Thin Provisioning to existing container fedora." And crashes about 15 seconds later. No warnings, error messages, or corrections to the 25GB entry I put in.
But it lies: It actually created new VG fedora00 and new thinp pool00 within that VG, and tried to create fedora00-root. There simply isn't enough free space on the disk to create a new VG. Here's the incriminating evidence:
00:17:35,038 INFO storage.ui: added lvmvg fedora00 (id 18) to device tree
00:17:35,038 INFO storage.ui: registered action:  Create Device lvmvg fedora00 (id 18)
00:17:35,039 DEBUG storage.ui: requested size is 25000.0
00:17:35,039 DEBUG storage.ui: fedora00 size is 0MB
00:17:35,039 DEBUG storage.ui: vg fedora00 has 0MB free
00:17:35,040 INFO storage.ui: adjusting pool size from 25000.00 to 0.00 so it fits in container fedora00
00:17:35,045 DEBUG storage.ui: fedora00 size is 0MB
00:17:35,045 DEBUG storage.ui: vg fedora00 has 0MB free
00:17:35,046 DEBUG storage.ui: Adding fedora00-pool00/0MB to fedora00
It should have tried to add a new root00 to existing VG/pool fedora-pool00 instead of trying to create a new VG with essentially non-existing space.
Or it should have told me to go pound salt, only one thinp installation per customer, please do not pass go or collect $200.
Proposed as a Blocker for 20-beta by Fedora user chrismurphy using the blocker tracking app because:
F20 Beta Criteria for installer: "When using the custom partitioning flow, the installer must be able to correctly interpret, and modify LVM volumes; create mount points backed by LVM volumes."
Interpret fail: Installer doesn't grok that it lacks enough space to create another VG; or that it should use the existing VG and pool for the new root.
Modify and create fail: Crashes.
It's difficult to waive off as "edge case" because all of thinp is edge case; and the point of LVM thinp is overcommitting in this fashion.
As the criteria are written, it's a beta blocker. A "conditional blocker" exception is possible if it's agreed that the trigger conditions are sufficiently rare/unique: the bug requires back to back installs, in between which the user has overcommitted the pool. Should this work? Yes. Is it likely to be depended on during beta? Probably not. Does it cause corruption or data loss, or prevent significant testing of LVM thinp? No.
I think -1 beta block, +1 final block, is a reasonable compromise.
Discussed in 2013-10-31 Go/No-Go meeting . Voted as a rejected blocker. This bug involves a disk layout which was modified outside of the installer and thus, is too much of a corner case to block the release of F20 beta. Please re-propose for final.
Proposed as a Blocker for 20-final by Fedora user chrismurphy using the blocker tracking app because:
Reproposed for final blocker per comment 16.
Chris, what are you testing with? Can you use an updates image against blivet-0.23.3-1 or would 0.23.2 be better due to what's available in a compose?
Tested with beta TC6 which would have been 0.23.2-1.
This bug is about anaconda/blivet not handling the case of a preexisting overcommitted thin pool. I have patches that have resolved the issue in my testing.
python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20 has been submitted as an update for Fedora 20.
Package python-blivet-0.23.6-1.fc20, anaconda-20.25.11-1.fc20, pykickstart-1.99.48-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-blivet-0.23.6-1.fc20 anaconda-20.25.11-1.fc20 pykickstart-1.99.48-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
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.
Fixed in that anaconda will not allow further creation of LVs once a thin pool is overcommitted.