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.
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?
Disregard.
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.