Version-Release number of selected component: anaconda-18.6.5 Additional info: libreport version: 2.0.12 cmdline: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2018\x20x86_64 quiet nouveau.modeset=0 vesa BOOT_IMAGE=vmlinuz kernel: 3.6.0-0.rc2.git2.1.fc18.x86_64
Created attachment 610765 [details] File: ifcfg.log
Created attachment 610766 [details] File: anaconda-tb
Created attachment 610767 [details] File: environ
Created attachment 610768 [details] File: type
Created attachment 610769 [details] File: storage.log
Created attachment 610770 [details] File: version
Created attachment 610771 [details] File: program.log
Created attachment 610772 [details] File: product
Created attachment 610773 [details] File: syslog
Created attachment 610774 [details] File: hashmarkername
Created attachment 610775 [details] File: anaconda.log
Created attachment 610776 [details] File: release
Created attachment 610777 [details] File: description
10:04:54,378 DEBUG anaconda: populate_right_side: existing 10751MB partition sda3 (5) with existing ntfs filesystem 10:04:54,384 DEBUG anaconda: min: 10886 max: 16777216 current: 10751.0 Looks like NTFS.minSize is telling us a value larger then the block device's current size in spite of this: 10:01:20,873 INFO program: Running... ntfsresize -m /dev/sda3 10:01:21,020 INFO program: ntfsresize v2012.1.15 (libntfs-3g) 10:01:21,021 INFO program: Minsize (in MB): 10636
Apparently we have some ancient code that adds 250 MB to the minimum size reported by ntfsresize -m. That's how the minimum size ends up greater than the current size. Now to figure out whether to keep that and, if so, how to deal with such nonsense.
This should be fixed in anaconda-18.13-1.
This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.