Red Hat Bugzilla – Full Text Bug Listing
|Summary:||/usr and /usr/local umount during installation post-processing|
|Product:||[Fedora] Fedora||Reporter:||Matt Marnell <matt>|
|Component:||anaconda||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||8||CC:||adrianvnc, bughunt, jonstanley|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-14 15:02:12 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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.