Bug 542167
| Summary: | livecd-creator fails to unmount | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Heather <drfudgeboy> |
| Component: | livecd-tools | Assignee: | David Huff <dhuff> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | apevec, bruno, drfudgeboy, itamar, katzj, kernel-maint, mclasen, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 509427 | Environment: | |
| Last Closed: | 2010-09-11 17:35:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
James Heather
2009-11-28 16:33:21 UTC
Is there any movement on this? This seems like quite an important bug (and probably a five minute fix). James This is from /usr/lib/python2.6/site-packages/imgcreate/creator.py:
def unmount(self):
"""Unmounts the target filesystem.
The ImageCreator class detaches the system from the install root, but
other subclasses may also detach the loopback mounted filesystem image
from the install root.
"""
try:
os.unlink(self._instroot + "/etc/mtab")
except OSError:
pass
self.__destroy_selinuxfs()
self._undo_bindmounts()
self._unmount_instroot()
It seems that first unmount operation is being tried, and any exceptions raised are being ignored. The final unmount is being unmounted without any error checking, which is where the fatal exception happens.
All that is needed is for any unmount that fails to be retried after a short sleep.
I'd do this myself, but I don't speak Python. I hope I have given enough information for this to be a very simple fix, though.
James
> Some background processes are being started, possibly by the rpm installation,
> that are running within the chrooted environment.
That's a broken RPM then, %post must not start anything.
Another thing to check is to make sure nscd is not running, see bugs 501334 481796
(In reply to comment #3) > > Some background processes are being started, possibly by the rpm installation, > > that are running within the chrooted environment. > > That's a broken RPM then, %post must not start anything. Thanks. As far as I can see, something like akmods (from rpmfusion), and presumably dkms, has little choice in the matter. When a new kernel gets installed, they need to trigger automatic building and installing of kernel module rpms. This can't be done synchronously within the %post, because the rpm database is locked to allow the kernel to be installed. So the only option is to kick off a background process that builds the new rpms and then installs them when the database becomes free again. This is very useful. James This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This has been mostly resolved. The umounts were being blocked because they weren't being done in the correct order. To fix this we use lazy umounts if needed and log the issue (well will do this in th next F14 release, 033 just does lazy umounts). There is still an issue with control c's leaving stuff mounted, but that's a bit outside of this report. Currently in F12 033 is still in testing waiting for karma to move to stable. |