Bug 381561 - /usr and /usr/local umount during installation post-processing
Summary: /usr and /usr/local umount during installation post-processing
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 8
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Fedora Extras Quality Assurance
Whiteboard: NeedsRetesting
: 497211 (view as bug list)
Depends On:
Blocks: F9Blocker
TreeView+ depends on / blocked
Reported: 2007-11-14 04:49 UTC by Matt Marnell
Modified: 2009-04-22 19:55 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2008-04-14 19:02:12 UTC

Attachments (Terms of Use)
Anaconda log (23.52 KB, text/plain)
2008-01-03 16:12 UTC, David Tonhofer
no flags Details
Exception details/install log (51.23 KB, text/plain)
2008-03-22 02:38 UTC, Alan
no flags Details

Description Matt Marnell 2007-11-14 04:49:04 UTC
Description of problem:

If you choose to have a /usr and /usr/local partition, during post processing
these filesystems are mounted and umounted.  /mnt/sysimage/usr is umounted
before /mnt/sysimage/usr/local, causing an uncaught exception that causes the
install to fail.

Version-Release number of selected component (if applicable):

Fedora 8

How reproducible:

Very.  3 times now before I realized that I wasn't having my nfsnobody.

Steps to Reproduce:
1.create both /usr and /usr/local in the "create custom partition" step
2.format, copy, yada, yada, yada
3.tada, failure during post copy processing, device or resource busy when it
umounts /mnt/sysimage/usr
Actual results:

no files copied, install failure

Expected results:

files copied, installation goes on to the next stage, which I haven't seen yet.

Additional info:

I'm trying again without actually mounting the /usr/local partition as part of
the base install.  I'm not sure if I've made it past 376741, but I believe I
have.  The reason I didn't realize this was a new bug was that when
/mnt/sysimage first appears, I started a wrapped find down /mnt/sysimage to
catch any files that might get in there owned by nfsnobody, and thought that the
find got caught in the /mnt/sysimage/usr directory.  The second time I thought I
must have had a shell open.  The third time I set up and stepped aware, and then
stepped down the file tree under /mnt/sysimage/usr, tried the umount by hand,
went into /mnt/sysimage/usr and umounted local, and then was able to go back up
and umount /mnt/sysimage/usr.  It doesn't appear that the stack is getting
unwound properly, or the list isn't in the right order when you pick a
/usr/local as a separate mount.  Not as big a deal as the other one, I doubt
many people are a pedantic as I am about partitioning, but it is in all the
pull-downs as a possible mount point.

Comment 1 Matt Marnell 2007-11-14 05:28:00 UTC
This must have been an order thing, the order defined when I went through the
dialogs, or the order they got stored off into whatever list is used, because I
didn't get this error before.  The first and only exception I got before was the
one being discussed in 376741, so this is definitely different.  If you do not
choose to have a /usr/local partition, you do get past this, although I was
apparently getting past this in my original install.

Comment 2 David Tonhofer 2008-01-03 16:09:58 UTC
I have quite possibly the same problem:



to place MySQL stuff into.

Installation proceeds fine up until the very end, where we see:

22:21:38 CRITICAL: anaconda None exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/isys.py", line 356, in umount
    rc = _isys.umount(what)
  File "/usr/lib/anaconda/fsset.py", line 207, in umount
    isys.umount(path, removeDir = 0)
  File "/usr/lib/anaconda/fsset.py", line 1852, in umount
  File "/usr/lib/anaconda/livecd.py", line 252, in _doFilesystemMangling
  File "/usr/lib/anaconda/livecd.py", line 306, in doPostInstall
  File "/usr/lib/anaconda/backend.py", line 195, in doPostInstall
  File "/usr/lib/anaconda/dispatch.py", line 203, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
  File "/usr/lib/anaconda/gui.py", line 1048, in nextClicked
  File "/usr/lib/anaconda/iw/progress_gui.py", line 67, in renderCallback
  File "/usr/lib/anaconda/gui.py", line 1075, in handleRenderCallback
SystemError: (16, 'Device or resource busy')

The title of the bug should be changed - from

"/usr and /usr/local umount during installation post-processing"


"anaconda umounts partitions in arbitrary order, potentially leading to failed

Comment 3 David Tonhofer 2008-01-03 16:12:38 UTC
Created attachment 290737 [details]
Anaconda log

Attached the Anaconda logfile, saved from to an USB stick after the
installation went south. We have come a long way since the 90's... :-)

Comment 4 Alan 2008-03-22 02:38:36 UTC
Created attachment 298818 [details]
Exception details/install log

Comment 5 Alan 2008-03-22 02:41:14 UTC
Comment on attachment 298818 [details]
Exception details/install log

I have experienced this issue as well. Linux is still a learning experience for
me, but apparently that does not preclude me from being equally pedantic about
partitioning as Matt is; I also specified separate /usr and /usr/local mounts.
I have attached the exception details.

As a side note, this is truly a new and exciting experience--not the unhandled
exception during installation--but being able to hit the internet, search for a
cause and possible solution, attach an exception log, and do it all from the
same system without rebooting. Pretty cool stuff!

Comment 6 Jeremy Katz 2008-03-25 17:18:02 UTC
Can you try with the Fedora 9 beta?  I _think_ this is fixed up there

Comment 7 Jesse Keating 2008-04-09 02:46:47 UTC
Moving to modified, would still like to get a re-test.

Comment 8 Jon Stanley 2008-04-14 19:02:12 UTC
yep, everything's good.

Comment 9 Chris Lumens 2009-04-22 19:55:09 UTC
*** Bug 497211 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.