Created attachment 1051990 [details] storage.log Using the 2015-07-14 Rawhide nightly and an updates.img to avoid https://bugzilla.redhat.com/show_bug.cgi?id=1243090 (the 'version' typo bug), in a typical KVM setup with a single VirtIO disk (containing an existing Fedora install), after running through INSTALLATION DESTINATION and trying to reclaim the whole disk (using the guided path), the spoke stays in incomplete state (shows 'Automatic partitioning selected' but the orange triangle overlay) and 'Begin Installation' remains insensitive. storage.log shows some suspicious messages and tracebacks: will attach.
It looks like https://github.com/rhinstaller/blivet/commit/26b23b13eba437ffbdbcd60013d3c202a7546cbb is responsible for this; I'm not sure exactly what's triggering that check, though. I'll dig into it a bit more.
I twiddled the error message to be a bit more informative: - raise errors.DeviceError("device is too small for new format") + raise errors.DeviceError("device {0} is too small for new format {1}".format(self.size, fmt.minSize)) and that gets us: "device 0 is too small for new format 8388608" so at some point that check is being invoked when self.size is 0, which doesn't seem like a good idea.
So here's what I've figured out so far. As I understand it, StorageDevice.format is set up as a property with the instance's _getFormat() method as its getter and the instance's _setFormat() method as its setter. So when StorageDevice.__init__() hits this line: self.format = fmt it calls its own _setFormat() method - which is where the size check is. At this point, the size property's getter function - _getSize() - must be returning 0. _getSize() basically returns self.targetSize if the device exists and is resizable and it actually has a targetSize, or self._size otherwise. StorageDevice.targetSize is itself a property whose getter function just returns self._targetSize. StorageDevice.__init__() takes size as a parameter. Before the 'self.format = fmt' line, it initializes both self._size and self._targetSize to that parameter (after turning it into a numeric type). The default value for size is None, which means that if you initialize a StorageDevice without passing size (or passing size as something 0-ish) but with a fmt parameter that's a real format with some sort of size, you're always going to have this problem. This does in fact seem to be what's going on here. We're in blivet/autopart.py _scheduleImplicitPartitions() here. What that winds up doing is calling storage.newPartition() with some format type parameters and the 'grow' parameter set to True, but no size. If you follow that path, you wind up in Blivet.newPartition() , which messes around with the format type parameters a bit then returns a PartitionDevice, without adding any kind of size parameter. A PartitionDevice is a subclass of StorageDevice that lives in blivet/devices/partition.py . It keeps the default value of the size parameter as None, and doesn't really do a lot before it calls StorageDevice.__init__(). *After* calling StorageDevice.__init__() it sets a default size, but even then the default size is only 500MiB. So basically, on this path, we wind up instantiating a PartitionDevice with 'None' as its size parameter but a valid 'fmt' parameter which does have a size. Then when we try to set the instance's 'format' property to the 'fmt' parameter, we run into this size check, which wants the instance's 'size' property to be bigger than the format object's size, which it obviously isn't going to be. I haven't figured out exactly how 'grow=True' takes effect yet; obviously it eventually winds up setting the partition's size to whatever we need it to be, but it looks like it does it after this size check gets hit.
So dlehman figured all this out a few hours ahead of me (wish I'd noticed...) and posted: https://lists.fedorahosted.org/pipermail/anaconda-patches/2015-July/021223.html my theory is basically correct except that actually the default size of 500MiB is fine (the largest 'minSize' for any format is 256MiB) so the fix is simply to apply the default size for PartitionDevice() instances before calling StorageDevice.__init__(). I've created an updates.img with the fix for this and 1243090 combined: https://www.happyassassin.net/updates/1243106.img and it definitely seems to fix the problem here.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This is fixed in 23.16.