Bug 381561

Summary: /usr and /usr/local umount during installation post-processing
Product: [Fedora] Fedora Reporter: Matt Marnell <matt>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: adrianvnc, bughunt, jonstanley
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: NeedsRetesting
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-14 19:02:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235706    
Attachments:
Description Flags
Anaconda log
none
Exception details/install log none

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:

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 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. ***