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: | anaconda | Assignee: | David Cantrell <dcantrell> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 18 | CC: | 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
Tim Flink
2012-08-23 16:14:45 UTC
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. |