Bug 1024144
| Summary: | SizeNotPositiveError: spec= param must be >=0 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||||||||||||||||
| Component: | python-blivet | Assignee: | David Lehman <dlehman> | ||||||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||
| Version: | 20 | CC: | amulhern, anaconda-maint-list, bcl, bugzilla, dlehman, g.kaviyarasu, jonathan, mruckman, robatino, vanmeeuwen+fedora | ||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:217c2a42032defe171c0ff12a40f424990d9c954092e73c11499392dc26b1e36 RejectedBlocker | ||||||||||||||||||||||||||
| Fixed In Version: | python-blivet-0.23.7-1.fc20 | Doc Type: | Bug Fix | ||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
| Clone Of: | |||||||||||||||||||||||||||
| : | 1027376 (view as bug list) | Environment: | |||||||||||||||||||||||||
| Last Closed: | 2013-11-29 13:56:17 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: | 980656, 1027376 | ||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
Created attachment 816942 [details]
File: anaconda-tb
Created attachment 816943 [details]
File: anaconda.log
Created attachment 816944 [details]
File: environ
Created attachment 816945 [details]
File: lsblk_output
Created attachment 816946 [details]
File: nmcli_dev_list
Created attachment 816947 [details]
File: os_info
Created attachment 816948 [details]
File: program.log
Created attachment 816949 [details]
File: storage.log
Created attachment 816950 [details]
File: syslog
Created attachment 816951 [details]
File: ifcfg.log
Created attachment 816952 [details]
File: packaging.log
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. Result: 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: [4] 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 Expected result: 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 [1]. 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. [1] http://meetbot.fedoraproject.org/meetbot/meetbot/fedora-meeting-2/2013-10-31/ 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. https://admin.fedoraproject.org/updates/FEDORA-2013-21928/python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20 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: https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.6-1.fc20,anaconda-20.25.11-1.fc20 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. |
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: anaconda-20.25.4-1 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 mountpoint=mountpoint) 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 Additional info: 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 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.6-301.fc20.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 20-Beta-TC6