Description of problem: I wanted to reproduce bug 1039491, but I received a different crash instead. I created two empty partitions and this crash occured when I click Shrink button while having the first one selected. Probably not reproducible, I haven't seen it before. Version-Release number of selected component: anaconda-20.25.14-1.fc20.x86_64 The following was filed automatically by anaconda: anaconda 20.25.14-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/size.py", line 96, in _parseSpec raise SizeNotPositiveError("spec= param must be >=0") File "/usr/lib/python2.7/site-packages/blivet/size.py", line 164, in __new__ self = Decimal.__new__(cls, value=_parseSpec(en_spec, False)) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/lib/disks.py", line 80, in size_str size = Size(en_spec="%f mb" % mb) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 219, 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 376, in _actionChanged self._update_labels(selectedReclaimable=self._selectedReclaimableSpace) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 340, 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-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-TC rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.10-300.fc20.x86_64 other involved packages: python-blivet-0.23.8-1.fc20.noarch product: Fedora release: Fedora release 20 (Heisenbug) type: anaconda version: 20
Created attachment 834767 [details] File: anaconda-tb
Created attachment 834768 [details] File: anaconda.log
Created attachment 834769 [details] File: environ
Created attachment 834770 [details] File: journalctl
Created attachment 834771 [details] File: lsblk_output
Created attachment 834772 [details] File: nmcli_dev_list
Created attachment 834773 [details] File: os_info
Created attachment 834774 [details] File: program.log
Created attachment 834775 [details] File: storage.log
Created attachment 834776 [details] File: ifcfg.log
Oh, so it is reproducible - bug 1040012. I used gnome-disks to format the whole disk with GPT and then create two empty 500M ext4 partitions. In Anaconda I clicked on "I want more space" and then selected vda1 and clicked "Shrink". Immediate crash. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-TC rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.10-300.fc20.x86_64 other involved packages: python-blivet-0.23.8-1.fc20.noarch package: anaconda-20.25.14-1.fc20.x86_64 packaging.log: product: Fedora reason: SizeNotPositiveError: spec= param must be >=0 release: Fedora release 20 (Heisenbug) version: 20
I reproduced bug following Kamil's instructions from comment 11. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-TC rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 hashmarkername: anaconda kernel: 3.11.10-300.fc20.x86_64 other involved packages: python-blivet-0.23.8-1.fc20.noarch package: anaconda-20.25.14-1.fc20.x86_64 packaging.log: product: Fedora reason: SizeNotPositiveError: spec= param must be >=0 release: Fedora release 20 (Heisenbug) version: 20
This sounds like a dup of bug 1039728.
No matter whether I use GPT or MBR, it crashes on partitions produced by gnome-disks and works on partitions produced by gparted. Also it is interesting it crashes only for certain partitions (probably just small ones). When I used a single whole disk partition (8GB) it worked. When I used a single 3.7GB partition, it worked. But when I used a single 500 MB partition (or two of them, it doesn't matter), it crashed. Is this another alignment issue? Is this another occurrence of bug 1013586? Proposing as a Final blocker.
I tried gdisk and its partitions also work by default. However, I found the difference. gdisk creates 500 MiB partitions when I say "500M": Number Start (sector) End (sector) Size Code Name 1 34 1024033 500.0 MiB 8300 Linux filesystem But gnome-disks create 500 MB partitions: Number Start (sector) End (sector) Size Code Name 1 2048 978610 476.8 MiB 8300 Linux filesystem If I re-create the same partition (sectors 2048-978610) in gdisk, it crashes as well. Anaconda doesn't handle certain partitions sizes well. I guess it could be connected to bug 1039288.
https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-December/007749.html
I noticed the fix is only in pyanaconda/ui/gui/spokes/lib/resize.py ; do we need to check whether custom partitioning is affected by this too?
doesn't appear to affect custom.
Bug didn't affect F19, this is a new breakage in F20.
The patch works - no more crash when selecting Shrink for the problematically-sized partition - but it allows me to try and make the partition very slightly larger, and if I do so, I hit a crash at the start of install (during partitioning). It looks like anaconda made the filesystem larger than the size of the partition: 00:06:24,834 INFO program: Running... e2fsck -f -p -C 0 /dev/vdb1 00:06:24,858 INFO program: /dev/vdb1: The filesystem size (according to the superblock) is 488280 blocks 00:06:24,858 INFO program: The physical size of the device is 487424 blocks 00:06:24,858 INFO program: Either the superblock or the partition table is likely to be corrupt! 00:06:24,858 INFO program: 00:06:24,858 INFO program: 00:06:24,858 INFO program: /dev/vdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. from program.log .
More details - the 'Reclaim disk space' screen shows the current size (above the slider) as 476.83 MB, and the maximum size (label under the slider on far right) as 476.84 MB. I can hit the crash by dragging the slider to the right - at this point the 'Total selected space to reclaim' is listed as '4 B' - then hitting Reclaim Space and proceeding with install. If I actually reduce the size of the partition, even just to 475 MB (the smallest change I can manage), no crash.
Please try this updates.img: http://vpodzime.fedorapeople.org/f20_blockers_updates.img
(In reply to Vratislav Podzimek from comment #22) > Please try this updates.img: > http://vpodzime.fedorapeople.org/f20_blockers_updates.img I wasn't able to reproduce this bug anymore, seems to be fixed...
Discussed in 2013-12-11 Blocker Review Meeting [1]. Voted as an AcceptedBlocker. Violates the Final criterion "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.". In this case anaconda crashes for certain partition sizes. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-12-11/ [2] http://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Storage_volume_resize
https://www.happyassassin.net/extras/updates-1040012.img should now have the 'state of the art' for this bug, with the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1040650 (which I discovered during the blocker meeting this morning) as well. Please try it out.
anaconda-20.25.15-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.15-1.fc20
This no longer seems to happen with F20 RC1.
anaconda-20.25.15-1.fc20, python-blivet-0.23.9-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.