Bug 460574 - dbus can't start in chroot
dbus can't start in chroot
Status: CLOSED CURRENTRELEASE
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Clark Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-28 14:57 EDT by Andrew Overholt
Modified: 2013-01-09 23:47 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-27 14:47:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Overholt 2008-08-28 14:57:39 EDT
I'd like to run some unit tests as part of an RPM build.  I've set it up so that Xvnc gets started and the tests run in it (some are GUI tests that need X to run).  This fails in koji due to the fact that dbus can't start.  Colin Walters kindly wrote a small patch to fix this and posted it here:

http://fpaste.org/paste/5434

In case that gets erased, I'll copy it here:

diff --git a/py/mock/backend.py b/py/mock/backend.py
index 3cc0a9f..566f615 100644
--- a/py/mock/backend.py
+++ b/py/mock/backend.py
@@ -13,6 +13,7 @@ import logging
 import os
 import shutil
 import stat
+import uuid
 
 # our imports
 import mock.util
@@ -207,6 +208,7 @@ class Root(object):
         self.root_log.debug('touch required files')
         for item in [self.makeChrootPath('etc', 'mtab'),
                      self.makeChrootPath('etc', 'fstab'),
+                     self.makeChrootPath('var', 'lib', 'dbus')]:
                      self.makeChrootPath('var', 'log', 'yum.log')]:
             mock.util.touch(item)
 
@@ -233,6 +235,15 @@ class Root(object):
                 os.remove(resolvpath)
             shutil.copy2('/etc/resolv.conf', resolvdir)
 
+        # Anything that tries to use libdbus inside the chroot will require this
+        # FIXME - merge this code with other OS-image building code
+        machine_uuid = uuid.uuid4().hex()
+        dbus_uuid_path = self.makeChrootPath('var', 'lib', 'dbus', 'machine-id')
+        f = open(dbus_uuid_path, 'w')
+        f.write(machine_uuid)
+        f.write('\n')
+        f.close()
+
         # files in /etc that need doing
         for key in self.chroot_file_contents:
             p = self.makeChrootPath(key)
Comment 1 Clark Williams 2008-09-10 18:32:47 EDT
I don't have any fundamental objection to having the ability to use dbus in the chroot, but I wonder if there are going to be any side effects of having (at least) two dbus daemons running on a system?
Comment 2 Colin Walters 2008-09-30 10:06:47 EDT
There's normally at least two - the system bus and the per-user session bus.  This patch simply enables the session bus to run; there should be no effect whatsoever on the rest of the OS.

Starting a system bus in the chroot is a different matter and while it would likely mostly work I would strongly discourage people from doing that.  But this bug was about the session.
Comment 3 Clark Williams 2009-02-05 23:53:25 EST
Ugh, I missed this in the 0.9.14 spin. queued for 0.9.15

Note You need to log in before you can comment on or make changes to this bug.