Description of problem: openbsd was installed in disk1 selected both disk1 and disk2 choose shrink for bsd (only preserve / delete should be avaiable for this partition type) choose delete for /boot, swap and / on the other disk (previous f18) started installing Version-Release number of selected component: anaconda-18.19 Additional info: libreport version: 2.0.14 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.1-1.fc18.x86_64 description: :The following was filed automatically by anaconda: :anaconda 18.19 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/parted/geometry.py", line 55, in __init__ : self.__geometry = _ped.Geometry(self.device.getPedDevice(), start, length) : File "/usr/lib64/python2.7/site-packages/parted/decorators.py", line 32, in new : ret = fn(*args, **kwds) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 1485, in _computeResize : length=newLen) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 1506, in resize : (constraint, geometry) = self._computeResize(partition) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 370, in execute : self.device.resize() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 323, in processActions : action.execute() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 357, in doIt : self.devicetree.processActions() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 195, in turnOnFilesystems : storage.doIt() : File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 107, in doInstall : turnOnFilesystems(storage) : File "/usr/lib64/python2.7/threading.py", line 504, in run : self.__target(*self.__args, **self.__kwargs) : File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run : threading.Thread.run(self, *args, **kwargs) :CreateException: Can't have the end before the start! (start sector=64 length=0)
Created attachment 633106 [details] File: anaconda-tb
Created attachment 633107 [details] File: product
Created attachment 633108 [details] File: type
Created attachment 633109 [details] File: ifcfg.log
Created attachment 633110 [details] File: storage.log
Created attachment 633111 [details] File: version
Created attachment 633112 [details] File: environ
Created attachment 633113 [details] File: anaconda.log
Created attachment 633114 [details] File: syslog
Created attachment 633115 [details] File: hashmarkername
Created attachment 633116 [details] File: packaging.log
Created attachment 633117 [details] File: cmdline_file
Created attachment 633118 [details] File: release
Created attachment 633119 [details] File: program.log
i tried automatic partitioning, type BTRFS on a guest with a previous instance. a biosboot (delete) lvm(delete) and another (shrink). and ext4 (shrink) Package: anaconda-18.24 OS Release: Fedora release 18-Beta-TC7
Can you please try this again with a tree containing anaconda-18.31 or later? Note that this would have to be later than the beta, unfortunately. With the reworked resize dialog in there, I have the shrink button shaded out for devices we don't know how to shrink, and I am hoping that will take care of this problem. We shouldn't be scheduling a resize action for this type of device.
sure, i am leaving it with the needinfo flag not cleared.
I tested it again with smoke5 Package: anaconda-18.37 OS Release: Fedora release 18
It is still possible to start installing by selecting 'shrink' for ufs (openbsd) partition/filesystem and 'delete' for the rest.
It looks like StorageDevice.resizable makes the mistake of assuming that a DeviceFormat means unformatted when it can also indicate unrecognized formatting, which should not be treated as resizable.
It sounds like uncrecognized formats are detected as resizable when they shouldn't be so that if anaconda attempts to resize them, it crashes. Am I understanding correctly? If so, it would be a violation of the following F18 beta release criterion [1]: The installer's custom partitioning mode must be capable of the following ... Rejecting obviously invalid operations without crashing . [1] http://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria
Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . We agreed this isn't really serious enough to be a blocker, as it's likely to be comparatively rarely encountered ('typical' scenarios will only have known partition types) and doesn't cause any terrible consequences (you can really just reboot and try again). But it's accepted as NTH as it's a crasher that should be fixed.
The worst-case scenario is that we actually succeed in resizing the device and cause data loss by not managing the formatting accordingly. I'm not sure if this is possible or not.
dlehman: well we were working on the assumption that all actually *resizing* requires calling a hardcoded command name related to the format - there isn't a single generic 'resize' command. So we assumed this will always fail for an unknown filesystem type. If we're wrong about that, please let us know, as that could certainly change the equation.
It will always crash like this from the reclaim dialog because the new target size will always be zero, which is the immediate cause of the traceback from this bug. If the device is resized from the custom spoke, I'm fairly certain you could end up shrinking the device without touching the formatting, which is really bad.
ah, we shrink the device and then the filesystem? seems ass-backwards. But yeah, that would be awful.
(In reply to comment #26) > ah, we shrink the device and then the filesystem? seems ass-backwards. But > yeah, that would be awful. It depends on whether you are growing or shrinking the device which you do first. It is possible to schedule a device resize without scheduling an accompanying format resize (think actually unformatted device, although in retrospect I don't really care about that case) -- that's what would happen in this case if the new target size was non-zero.
anaconda-18.37.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.37.4-1.fc18
Package anaconda-18.37.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.37.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20677/anaconda-18.37.4-1.fc18 then log in and leave karma (feedback).
anaconda-18.37.4-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Reartes, can you please confirm this is fixed in smoke9? http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/
i was not able to select 'shrink' for type ufs (openbsd), so i was unable to reproduce the issue in the 'description'. So it seems fixed. Please note that this does not cover comment #15 yet, since i did not re-test it.
Thanks.