Bug 851274

Summary: Traceback during install - mount: /dev/sr0 is already mounted or /run/install/repo busy
Product: [Fedora] Fedora Reporter: Tim Flink <tflink>
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, awilliam, dcantrell, g.kaviyarasu, hamzy, jonathan, jsedlak, robatino, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-06 16:22:32 UTC Type: Bug
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: 752654, 846989    
Attachments:
Description Flags
anaconda traceback none

Description Tim Flink 2012-08-23 16:14:45 UTC 
Created attachment 606642 [details]
anaconda traceback

I built an x86_64 test boot iso using anaconda-18.6.1-1. When I attempt to install, I get through all the menus and package selection but when I try to actually do the installation, anaconda crashes pretty quickly.

anaconda 18.6.1 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 626, in mount
    raise FSError("mount failed: %s" % e)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 856, in setup
    return self.mount(**kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 493, in _setUpMedia
    device.format.setup(mountpoint=INSTALL_TREE)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1084, in preInstall
    self._setUpMedia(self.install_device)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 70, in doInstall
    payload.preInstall(packages=packages, groups=payload.languageGroups(ksdata.lang.lang))
  File "/usr/lib64/python2.7/threading.py", line 504, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 87, in run
    threading.Thread.run(self, *args, **kwargs)
FSError: mount failed: (32, 'mount: /dev/sr0 is already mounted or /run/install/repo busy\n       /dev/sr0 is already mounted on /run/install/repo')


There are X errors in the logs as well but I don't see much information on why X is having issues and am assuming that it isn't directly related to the problem shown in the traceback.

ISO used:
http://imagebuilder.fedoraproject.org/testimage/18/pretc4/20120822_f18alpha_pretc4.x64.iso

Installing to a KVM/qemu VM using F17 as the virthost.
Comment 1 Jan Sedlák 2012-08-23 18:09:18 UTC 
Perhaps it's somewhat related to bug 849997?
Comment 2 Tim Flink 2012-08-23 19:01:15 UTC 
I can reproduce this every time that I've tried but I seem to have found a workaround.

If you manually add a remote installation source (I used http), the install pretty much finishes and results in a bootable system.

Is it possible that the netinstall iso I'm using is being treated like a DVD and something is looking for the packages that would be on the DVD?
Comment 3 Adam Williamson 2012-08-23 20:19:41 UTC 
I can confirm at least half of Tim's result: I *don't* see this traceback when configuring a remote installation source manually to point to a specific URL. I can't confirm that I do see the traceback if I just leave it at the default 'nearest mirror' setting, never entering the installation source screen, because I always hit a dep issue with sssd from updates-testing when I do that. But he says he's reproduced it multiple times on multiple machines, and I trust him...
Comment 4 Adam Williamson 2012-08-23 20:24:22 UTC 
Obvious Alpha blocker...
Comment 5 Adam Williamson 2012-08-23 20:38:59 UTC 
See also https://bugzilla.redhat.com/show_bug.cgi?id=851336 , which I suspect may be somehow related: I think the 'closest mirror' setting is just busted, somehow.
Comment 6 Jesse Keating 2012-08-23 22:26:30 UTC 
Are you sure this used anaconda-18.6.1?  Booting it up I see it say anaconda 18.99, and it's missing text mode changes from anaconda-18.5.  Is it possible a different anaconda or image got used here?
Comment 7 Jesse Keating 2012-08-23 22:28:07 UTC 
Disregard.
Comment 8 Jesse Keating 2012-08-23 23:52:59 UTC 
I can reproduce at will with this iso, both graphical or text mode.  I'm tracing the code to see where things are going wrong.
Comment 9 Jesse Keating 2012-08-24 00:55:55 UTC 
Here is a rundown of what's happening.

Dracut is mounting the boot.iso/netinst.iso to /run/install/repo.

Anaconda is finding this in pyanaconda/packaging/yumpayload.py in _configureBaseRepo.

Problem A) is we just go ahead and make whatever is mounted to /mnt/install/repo the install_device, even if there is no repodata there (no /mnt/install/repo/os/repodata directory).

Later in preInstall we find that we have an install_device, and we try to mount that install device to INSTALL_TREE.

Problem B) we don't check to see if install_device is already mounted somewhere.  There is some logic in yuminstall.py to figure this out and do a bind mount instead of a regular mount.

Fixing problem A is pretty easy, and it would at least get boot.iso based installs working again.  A patch is being sent for that.  However full DVD installs will still hit problem B, and I'm out of time tonight to figure out a fix for problem B.
Comment 10 Adam Williamson 2012-08-27 16:37:09 UTC 
Discussed at 2012-08-27 QA meeting, functioning as a blocker review meeting. Accepted as a blocker per criterion "The installer must be able to complete package installation with the default package set for each supported installation method" (though really a failure this early in install can be considered to infringe any number of criteria).
Comment 11 Jesse Keating 2012-08-28 03:33:22 UTC 
Patches pushed upstream.
Comment 12 Adam Williamson 2012-09-01 00:23:45 UTC 
Confirmed that a straight-through netinstall of TC4 works fine, this bug does not occur.
Comment 13 Adam Williamson 2012-09-06 16:22:32 UTC 
18.6.5-1 was pushed stable, so closing.