Description of problem: Go to reclaim space on a device that contains a filesystem that is larger that its container. 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 155, in populate % {"freeSize": size_str(freeSize), "devSize": size_str(dev.size)} File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 299, in refresh self.populate(disks) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 919, in _show_resize_dialog resizeDialog.refresh(disks) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 872, in on_back_clicked if not self._show_resize_dialog(disks): 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-KDE-x86_64-20-TC5 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 834536 [details] File: anaconda-tb
Created attachment 834537 [details] File: anaconda.log
Created attachment 834538 [details] File: environ
Created attachment 834539 [details] File: journalctl
Created attachment 834540 [details] File: lsblk_output
Created attachment 834541 [details] File: nmcli_dev_list
Created attachment 834542 [details] File: os_info
Created attachment 834543 [details] File: program.log
Created attachment 834544 [details] File: storage.log
Created attachment 834545 [details] File: ifcfg.log
Steps to reproduce: 1. Create a partition with ext4 filesystem of, say, 8G. Do something on it. 2. Delete that partition. Recreate it with same start and 500M size. 3. Start installer, go to reclaim space. (Didn't want to resize it, just delete.) It crashes. Anyway, proposing as a blocker due to: When using the guided partitioning flow, the installer must be able to: Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation It doesn't say that filesystems must be correct. Has same summary as bug 1038847 but crashes from different operation.
Are you trying to say that you kept the 8 GB ext4 filesystem, but shrunk the underlying partition to 500 MB? That is certainly an invalid setup. It would be nice if anaconda didn't crash on start, sure. But I don't think such malicious attempts are covered by our release criteria.
(In reply to Kamil Páral from comment #12) > Are you trying to say that you kept the 8 GB ext4 filesystem, but shrunk the > underlying partition to 500 MB? That is certainly an invalid setup. It would > be nice if anaconda didn't crash on start, sure. But I don't think such > malicious attempts are covered by our release criteria. Yes, true. But then criteria might need to be reworded to cover filesystems too, not only partition table.
I just hope this is rejected as final blocker
yeah, I'd be -1 on this. look, writing criteria is *hard enough* without people apparently trying intentionally to game them. please give them a bit of leeway, unless you want the criteria to wind up looking like a legal code: 900 pages long and hedged around with impenetrable language meant to cover every goddamn eventuality. I can write an explicit 'the partitions must not be weirdly hacked up to be invalid' clause into the criteria or we can stop trying to poke holes in the goddamn language and keep them short...
Okay-okay, lifting it.
This exception no longer exists.