curtin-dev team mailing list archive

[Olivier Gayot <mp+462140@xxxxxxxxxxxxxxxxxx>]

Olivier Gayot has proposed merging ~ogayot/curtin:systemd-offline into curtin:master.

Commit message:
apt: ensure systemd knows it runs in a chroot, when executing postinst

Since we added the --mount-proc option to unshare, the postinst script
for openssh-server (and most likely other packages) started failing with
the following error when `systemctl daemon-reload` was invoked:

  > Failed to connect to bus: No data available

Before the option was added, it would simply do nothing because systemd
rightly understood it was running in a chroot.

To determine if we are running in a chroot, systemd checks if
/proc/1/root (corresponding to the init process) and / are the same
inode. If they are different, systemd assumes we are in a chroot.

However, we are running apt-get in a new PID namespace which means that
in the new namespace, apt-get gets assigned PID 1 and is therefore the
"init" process.

Now that /proc is properly mounted in the chroot, when systemd compares
/proc/1/root and /, it sees they are identical because the init process
(which is apt-get) is actually running inside the chroot.

Without the --mount-proc option, /proc/1 in the chroot would still refer
to the systemd init process (running outside the chroot), so it would
work properly.

With the SYSTEMD_OFFLINE variable, one can "force" systemd to assume
it is running in a chroot. Let's use it.

Signed-off-by: Olivier Gayot <olivier.gayot@xxxxxxxxxxxxx>


Requested reviews:
  curtin developers (curtin-dev)

For more details, see:
https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/462140

Since we added the --mount-proc option to unshare, the postinst script for openssh-server (and most likely other packages) started failing with the following error when `systemctl daemon-reload` was invoked:

  > Failed to connect to bus: No data available

This would cause failed installations of Ubuntu. This happens because systemd fails to determine that we are running in a chroot when executed in the postinst script context.

To determine if we are running in a chroot, systemd checks if /proc/1/root (corresponding to the init process) and / are the same inode. If they are different, systemd assumes we are in a chroot.

However, we are running apt-get in a new PID namespace which means that in the new namespace, apt-get gets assigned PID 1 and is therefore the "init" process.

Now that /proc is properly mounted in the chroot, when systemd compares /proc/1/root and /, it sees they are identical because the init process (which is apt-get) is actually running inside the chroot.

Without the --mount-proc option, /proc/1 in the chroot would still refer to the systemd init process (running outside the chroot), so it would work properly.

With the SYSTEMD_OFFLINE variable, one can "force" systemd to assume it is running in a chroot. Let's use it.
-- 
Your team curtin developers is requested to review the proposed merge of ~ogayot/curtin:systemd-offline into curtin:master.

diff --git a/curtin/distro.py b/curtin/distro.py
index 3284b69..15a52ef 100644
--- a/curtin/distro.py
+++ b/curtin/distro.py
@@ -269,7 +269,8 @@ def run_apt_command(mode, args=None, opts=None, env=None, target=None,
 def apt_install(mode, packages=None, opts=None, env=None, target=None,
                 allow_daemons=False,
                 download_retries: Optional[Sequence[int]] = None,
-                download_only=False, assume_downloaded=False):
+                download_only=False, assume_downloaded=False,
+                systemd_force_offline=True):
     """ Install or upgrade a set or all the packages using apt-get. """
     defopts = ['--quiet', '--assume-yes',
                '--option=Dpkg::options::=--force-unsafe-io',
@@ -280,6 +281,25 @@ def apt_install(mode, packages=None, opts=None, env=None, target=None,
     if opts is None:
         opts = []
 
+    if systemd_force_offline:
+        env = env.copy() if env is not None else os.environ.copy()
+        # To determine if we are running in a chroot, systemd checks if
+        # /proc/1/root (corresponding to the init process) and / are the same
+        # inode. If they are different, systemd assumes we are in a chroot.
+        # However, we are running apt-get in a new PID namespace (with /proc
+        # properly mounted). This means that in the new namespace, apt-get gets
+        # assigned PID 1 and is therefore the "init" process.
+        # When systemd compares /proc/1/root and /, it sees they are identical
+        # because the init process is actually running in the chroot.
+        #
+        # Before we started passing the --mount-proc option to unshare, it was
+        # working because /proc/1 in the chroot would still refer to the
+        # systemd init process (running outside the chroot).
+        #
+        # With the SYSTEMD_OFFLINE variable, one can "force" systemd to assume
+        # it is running in a chroot. Let's use it.
+        env['SYSTEMD_OFFLINE'] = True
+
     if mode not in ['install', 'upgrade', 'dist-upgrade']:
         raise ValueError(
             'Unsupported mode "%s" for apt package install/upgrade' % mode)