Description of problem: This happened when I tried to verify bug 876897. I booted netinst and hand-selected dvd.iso on a local partition. I got this traceback during "Preparing to install". Version-Release number of selected component: anaconda-18.29.2 Additional info: libreport version: 2.0.17 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.6-3.fc18.i686 description: :The following was filed automatically by anaconda: :anaconda 18.29.2 exception report :Traceback (most recent call first): : File "/usr/lib/python2.7/site-packages/pyanaconda/isys/__init__.py", line 152, in umount : rc = _isys.umount(what) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 656, in unmount : rc = isys.umount(self._mountpoint, removeDir = False) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 863, in teardown : return self.unmount(*args, **kwargs) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/devices.py", line 743, in _preTeardown : self.format.teardown() : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/devices.py", line 755, in teardown : if not self._preTeardown(recursive=recursive): : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 1969, in teardownAll : device.teardown(recursive=True) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py", line 165, in turnOnFilesystems : storage.devicetree.teardownAll() : File "/usr/lib/python2.7/site-packages/pyanaconda/install.py", line 113, in doInstall : turnOnFilesystems(storage) : File "/usr/lib/python2.7/threading.py", line 504, in run : self.__target(*self.__args, **self.__kwargs) : File "/usr/lib/python2.7/site-packages/pyanaconda/threads.py", line 91, in run : threading.Thread.run(self, *args, **kwargs) :SystemError: (32, 'umount: /run/install/isodir: target is busy.\n (In some cases useful info about processes that use\n the device is found by lsof(8) or fuser(1))')
Created attachment 650396 [details] File: anaconda-tb
Created attachment 650397 [details] File: product
Created attachment 650398 [details] File: type
Created attachment 650399 [details] File: ifcfg.log
Created attachment 650400 [details] File: storage.log
Created attachment 650401 [details] File: version
Created attachment 650402 [details] File: environ
Created attachment 650403 [details] File: executable
Created attachment 650404 [details] File: anaconda.log
Created attachment 650405 [details] File: syslog
Created attachment 650406 [details] File: hashmarkername
Created attachment 650407 [details] File: packaging.log
Created attachment 650408 [details] File: cmdline_file
Created attachment 650409 [details] File: release
Created attachment 650410 [details] File: program.log
The installer must be able to use all supported local and remote package source options https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
Discussed at 2012-11-29 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-29/f18final-blocker-review-1.1.2012-11-29-17.01.log.txt . Accepted as a blocker per criterion cited in comment #16.
I did the same procedure as in bug 882147, but this time I was very careful not to touch existing vda1. I used manual partitioning to create the layout and left vda1 unchanged. It crashed in "Preparing to install". Package: anaconda-18.29.2 OS Release: Fedora release 18-Beta
Isn't this the same as bug #855513?
Customized the installation and manual partitioning as far as possible _without_ unlocking my LUKS encrypted /home volume, which crashes as reported before. Then clicked "Begin Installation". Immediately got this crash also related to the isodir. Something is terribly wrong there. Package: anaconda-18.29.2 Architecture: x86_64 OS Release: Fedora release 18-Beta
For those reporting dupes, check that your error is actually the same as the one in the subject - I've noticed libreport is a bit over-enthusiastic about duping bugs with umount error messages.
Well, that implies that if one reports a crash from within Anaconda, one loses the backtrace if one doesn't save a backup of it manually.
yes, which is a shame. we've kicked around the idea of asking for libreport to grow an option to report the tb even if the bug is a dupe, but the problem with that is you'd wind up with people checking it all the time, and we don't want that...
I can't reproduce this with anaconda from git plus my patch for bug 879142. Perhaps there's the difference. In the original report, did you perhaps visit storage first?
(In reply to comment #24) That's very possible. Can't you tell from the logs? I really don't remember. I can try to reproduce if necessary. Just tell me which anaconda version to try.
I've tried a couple different ways to reproduce this, but no luck. If you can please test again with a tree containing anaconda-18.34-1 or later (so, some post-beta tree) and attach detailed reproducer steps, it would really help move this bug along. Thanks.
Trying to verify bug 879610. I have 5GB vda1 partition with dvd.iso on it. I have 6 GB of free space after it. I booted netinst and hand-selected dvd.iso as installation source. In the partitioning I was told I have plenty of space to install Fedora, so I just hit Continue (no reclaiming space, no manual partitioning, nothing). Crashed during Preparing to install. Package: anaconda-18.35 Architecture: x86_64 OS Release: Fedora release 18
Created attachment 658107 [details] 18.35 anaconda-tb
*** Bug 882351 has been marked as a duplicate of this bug. ***
anaconda-18.36-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.36-1.fc18
This is fixed in anaconda 18.36. I tried both manual picking of dvd.iso and booting with inst.repo=hd:vda1:/dvd.iso.
anaconda-18.36-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.