Created attachment 530802 [details]
File: anaconda-tb-8rt6cn

This looks like a live install.  Did you mount anything manually yourself after anaconda started, or is there something running that has automatically mounted filesystems as they are created for you?

i got this bug too , system is killed disks wiped no hope for installing fedora it seems.

I did nothing but click install to disk from the live install and follow instructions.

I chose a custom layout so that I could overwrite FC16 onto the same partitions as fc15 had  /boot / and swap as normal

Found a work around,  problem seems to stem from the page on which you select the drive to install fedora.

Make sure that on the page that selects the drive to install fedora there is only one disk on the right hand side of the page.


This page has a non-intuitive UI at best or call it bugs.  Page starts with USB and HD in the right hand box. The HD appears selected it has a black dot.  Trying to move the USB with the arrow buttons fails, next button is available, leaving the page with 2 entries in the right pane but one selected is permitted and the following pages setup the HD as expected, but then anaconda crashes at the end.

I could move the USB file out of the right hand box by double clicking on it, which makes no sense, double click on the disk you <em>don't</em> want to install on to get it to work.

Not sure if its causing it, or caused by it: when the installation crashed, a box pops up at the bottom of the screen, giving options to Eject / Open disks.

The workaround in comment 4 did not work for me: I can remove the additional disks, but they still show up in the list of possible disks to install to on next step, and I still crash. I'm installing to multiple disks, not just a single disk.

Originated from dual boot of Linux Mint LXDE 11, and Ubuntu Oneric (11.10) on Toshiba NB305. Created a live USB using latest Unetbootin (Ubuntu), of Fedora 16 (i386).

Ran disk check before booting into Fedora 16 Live, and it passed.

Started the install process but, upon seeing the available partitioning options (specifically that I couldn't easily erase only the Mint partition), exited to back up current data.

Before shutting down, tested the Suspend functionality. Returned from suspended mode and shutdown.

Booting normally (to backup data) revealed a "Booting into Fedora 16" screen, which then led to a kernel panic.

Booted back into live USB and examined HDD partitions using Fedora's Disk Partition utility. Completely unallocated except for ~634MB at the end dedicated to Fedora 16, which is odd since I never confirmed erasing anything up to that point. No big loss since I have older backups.

Exited partition utility and opened installer again, this time selecting the entire disk. Threw an error indicating insufficient free space available on the HDD.

Exited the installer and opened partition utility again. Reformatted entire HDD with MBR schema. Closed utility and opened installer to discover the same error. Closed installer, opened utility, and reformatted using GUID schema. Closed utility, opened installer, and found this solved the insufficient-free-space error.

Installation progressed as normal until the very end, when Bug 750002 appeared. Anaconda repored a failed installation while I was simultaneously notified of a new hard drive that was mounted. Attempted to eject it with Nautilus and it failed, stating it was being used by some other daemon. Attempted to umount it in the terminal with the same result as reported in comment #1.

(In reply to comment #4)
> Found a work around,  problem seems to stem from the page on which you select
> the drive to install fedora.
> 
> Make sure that on the page that selects the drive to install fedora there is
> only one disk on the right hand side of the page.

Did this to begin with...

> This page has a non-intuitive UI at best or call it bugs.  Page starts with USB
> and HD in the right hand box. The HD appears selected it has a black dot. 
> Trying to move the USB with the arrow buttons fails, next button is available,
> leaving the page with 2 entries in the right pane but one selected is permitted
> and the following pages setup the HD as expected, but then anaconda crashes at
> the end.

My page had the arrow enabled, but I was still able to double-click to change it over to the "Data Storage" side (as opposed to "Install Location").

> I could move the USB file out of the right hand box by double clicking on it,
> which makes no sense, double click on the disk you <em>don't</em> want to
> install on to get it to work.

That's a UI issue that is more for asthetics. So long as there's a workaround to get Fedora working, it's not critical. Failed installation however...

Going to first see if Fedora will boot from HDD, then will try to reinstall in case Bug 750002 was a fluke. Standby for results.

As stated at the end of comment #6, I tried booting from HDD as if installation was successful, which revealed the OS hangs a the logo screen. Unsure how to boot verbose to give more detail.

Upon reinstallation, I realized another action I forgot to report, which may be the root cause. A popup appeared at the bottom of the screen giving me the option to either open or eject "524 MB Filesystem". This time around I left it alone, but last time I chose "Open with Files" to get rid of the popup.

So far the Bug 750002 has yet to appear...

... and the installation finished without issue.

Don't use Unetbootin to make fedora live usb sticks. Use livecd-iso-to-disk to liveusb-creator. They setup the kernel args correctly, and label the filesystem so that it is recognized as the boot device. Having the wrong label may be the cause of it showing up on the right in the disk filter screen.

I have two hard disks. One has system (/), swap and home partitions, the other has a single partition and is used as a data archive. The workaround in comment 4 solved my problem as long as I refrained from assigning a mount point (/ark) for the second disk on the partition editing page. After installation I manually added the archive disk to /etc/fstab and it all worked normally. My thanks to teknopaul for finding the secret; I never thought to double click the data archive disk listing in the right hand pane. Non-intuitive is an understatement.

On the right hand pane/window there is a column titled "Boot" and the corresponding black dot (aka radio button) indicates which disk is currently selected as the boot disk. Did you pay any attention to this?

I tried installing on a virtual machine (VirtualBox, host a Fedora 16 system) and got this error with the first try.  I tried again, and the second time the install worked.
The virtual guest was newly set up with just a single disk.
Apart from clicking the install to hard drive and following the instructions from anaconda, I didn't do anything.

Hello,
I am getting the sam error when I try to upgrade a FC16 System to FC17 Release (x64).

Cheers,
Michael

$ cat reason 
SystemError: (32, 'umount: /mnt/sysimage: target is busy.\n        (In some cases useful info about processes that use\n         the device is found by lsof(8) or fuser(1))')[michaelc@pc-micha unpack]$ cat description 
The following was filed automatically by anaconda:
anaconda 17.29 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/isys/__init__.py", line 151, in umount
    rc = _isys.umount(what)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 682, in unmount
    rc = isys.umount(self._mountpoint, removeDir = False)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 889, in teardown
    return self.unmount(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 746, in _preTeardown
    self.originalFormat.teardown()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 761, in teardown
    if not self._preTeardown(recursive=recursive):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2030, in _parseOneLine
    device.teardown()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2112, in parseFSTab
    device = self._parseOneLine((devspec, mountpoint, fstype, options, dump, passno))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1676, in mountExistingSystem
    fsset.parseFSTab(anaconda=anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/upgrade.py", line 178, in upgradeMountFilesystems
    mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 383, in dispatch
    self.dir = self.steps[self.step].target(self.anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 247, in go_forward
    self.dispatch()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1201, in nextClicked
    self.anaconda.dispatch.go_forward()
SystemError: (32, 'umount: /mnt/sysimage: 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 588387 [details]
log which leads to this error

Here is the logile of anaconda leading to this bug. System has two disk drives (one holding /root and /boot, the second drive holds just data and swap.

What does /proc/mounts look like when this happens?

(In reply to comment #13)
> Created attachment 588387 [details]
> log which leads to this error
> 
> Here is the logile of anaconda leading to this bug. System has two disk
> drives (one holding /root and /boot, the second drive holds just data and
> swap.

This is a different problem. Please open a separate bug report. Thanks.

Same problem here. I just downloaded the XFCE spin of F17 x64, created with virtualbox a new VM (called Fedora 17 x64, it was correctly considered by virtualbox), and tried to install it (always clicked next, only entered timezone Europe/Berlin and root password, left everything other untouched, and clicked on use complete space for installation).

When this message appears and i click on "Debug" it looks like its still working but nothing happens. I can see now "Post-Installation. Performing post-installation filesystem changes. This may take several minutes."

IMO this is a release blocker.

Download liveCD from http://download.fedoraproject.org/pub/alt/releases/17/Spins/x86_64/Fedora-17-x86_64-Live-XFCE.iso
Start Virtualbox: - new - in vm name and bs type: Fedora 17 x64 - memory: 8096 - on chose of hdd format use vdi - dynamic allocated - size: 20GB - stored on: D:\VMware\Fedor 17 x64.vdi -create
change Fedora 17: System->processor-> 8; Display->memory-> 128MB; Audio->Disable
ok -> start 

choose Fedora-17-x86_64-Live-XFCE.iso

click on install to harddrive 
choose swiss german (latin1)
basic storage -> yes, discard any data
chosed a weak root pw - use anyway
use all space, use lvm, write changes to disk
wait... until exception occurs - always reproducable, not able to install fedora...

unchecked "use lvm" and created my own layout, now its working
my layout:
/boot 500MB
/    15GB
swap all space left (about 4gb)

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.