Bug 381561 - /usr and /usr/local umount during installation post-processing
/usr and /usr/local umount during installation post-processing
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
8
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
NeedsRetesting
:
: 497211 (view as bug list)
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
 
Reported: 2007-11-13 23:49 EST by Matt Marnell
Modified: 2009-04-22 15:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-14 15:02:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Matt Marnell 2007-11-13 23:49:04 EST
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 00:28:00 EST
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 11:09:58 EST
I have quite possibly the same problem:

Partitions  

/var/dbcontainers
/var/dbcontainers/backups
/var/dbcontainers/binlog

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
    self.mountpoint))
  File "/usr/lib/anaconda/livecd.py", line 252, in _doFilesystemMangling
    e.umount(anaconda.rootPath)
  File "/usr/lib/anaconda/livecd.py", line 306, in doPostInstall
    self._doFilesystemMangling(anaconda)
  File "/usr/lib/anaconda/backend.py", line 195, in doPostInstall
    anaconda.backend.doPostInstall(anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 203, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 126, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/gui.py", line 1048, in nextClicked
    self.anaconda.dispatch.gotoNext()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 67, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 1075, in handleRenderCallback
    self.currentWindow.renderCallback()
SystemError: (16, 'Device or resource busy')
---------------

The title of the bug should be changed - from

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

to 

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

Comment 3 David Tonhofer 2008-01-03 11:12:38 EST
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-21 22:38:36 EDT
Created attachment 298818 [details]
Exception details/install log
Comment 5 Alan 2008-03-21 22:41:14 EDT
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 13:18:02 EDT
Can you try with the Fedora 9 beta?  I _think_ this is fixed up there
Comment 7 Jesse Keating 2008-04-08 22:46:47 EDT
Moving to modified, would still like to get a re-test.
Comment 8 Jon Stanley 2008-04-14 15:02:12 EDT
yep, everything's good.
Comment 9 Chris Lumens 2009-04-22 15:55:09 EDT
*** 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.