Red Hat Bugzilla – Bug 851274
Traceback during install - mount: /dev/sr0 is already mounted or /run/install/repo busy
Last modified: 2013-01-10 01:53:37 EST
Created attachment 606642 [details]
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
File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 493, in _setUpMedia
File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1084, in preInstall
File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 70, in doInstall
File "/usr/lib64/python2.7/threading.py", line 504, in run
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.
Installing to a KVM/qemu VM using F17 as the virthost.
Perhaps it's somewhat related to bug 849997?
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?
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...
Obvious Alpha blocker...
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.
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?
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.
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.
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).
Patches pushed upstream.
Confirmed that a straight-through netinstall of TC4 works fine, this bug does not occur.
18.6.5-1 was pushed stable, so closing.