Red Hat Bugzilla – Bug 381561
/usr and /usr/local umount during installation post-processing
Last modified: 2009-04-22 15:55:09 EDT
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):
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
no files copied, install failure
files copied, installation goes on to the next stage, which I haven't seen yet.
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.
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.
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
Created attachment 290737 [details]
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... :-)
Created attachment 298818 [details]
Exception details/install log
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!
Can you try with the Fedora 9 beta? I _think_ this is fixed up there
Moving to modified, would still like to get a re-test.
yep, everything's good.
*** Bug 497211 has been marked as a duplicate of this bug. ***