[Bug 2103618] [NEW] Installer hangs forever when DKMS package is installed due to diffeernt pid namespace

[Renato Botelho]

Public bug reported:

When custom image is created and it contains a package that installs a
kernel module built using DKMS installer will hang forever.

Installing the kernel runs a command prepended with 'unshare --pid --fork',
The /proc filesystem of the new PID namespace is not mounted in the namespace
so dkms breaks.

When subiquity, using curtin, execute DKMS scripts, it creates a
separate PID namespace.  DKMS doesn't know about it and keeps waiting
for a PID in the wrong namespace and this situation can lead installer
to get stuck forever.

The way we found to workaround this situation was to change curtin
function run_apt_command() like this:

-cmd_rv = inchroot.subp(cmd, env=env)
+cmd_rv = inchroot.subp(cmd, env=env, unshare_pid=False)

It worked for me because I only consumed curtin source to build a
custom subiquity package but I don't know if it is the right approach
or if it will break other things.  If you think the proper way is to
open a bug on curtin project, just let me know and I will do it.

** Affects: subiquity (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to subiquity in Ubuntu.
https://bugs.launchpad.net/bugs/2103618

Title:
  Installer hangs forever when DKMS package is installed due to
  diffeernt pid namespace

Status in subiquity package in Ubuntu:
  New

Bug description:
  When custom image is created and it contains a package that installs a
  kernel module built using DKMS installer will hang forever.

  Installing the kernel runs a command prepended with 'unshare --pid --fork',
  The /proc filesystem of the new PID namespace is not mounted in the namespace
  so dkms breaks.

  When subiquity, using curtin, execute DKMS scripts, it creates a
  separate PID namespace.  DKMS doesn't know about it and keeps waiting
  for a PID in the wrong namespace and this situation can lead installer
  to get stuck forever.

  The way we found to workaround this situation was to change curtin
  function run_apt_command() like this:

  -cmd_rv = inchroot.subp(cmd, env=env)
  +cmd_rv = inchroot.subp(cmd, env=env, unshare_pid=False)

  It worked for me because I only consumed curtin source to build a
  custom subiquity package but I don't know if it is the right approach
  or if it will break other things.  If you think the proper way is to
  open a bug on curtin project, just let me know and I will do it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/2103618/+subscriptions