** Description changed:

+ [Impact]
+ All users of third-party modules on Ubuntu.
+ 
+ [Test cases]
+ 1) Install Ubuntu on an UEFI system
+ 2) Clear any files in /var/lib/shim-signed/mok: "sudo rm -rf 
/var/lib/shim-signed/mok/*"
+ 3) Install virtualbox-dkms: "sudo apt install virtualbox-dkms"
+ 4) Verify that you are prompted for a password to enroll a new MOK, and that 
you are asked that password at reboot.
+ 
+ Without the patch, no prompt will appear at install of virtualbox-dkms.
+ 
+ [Regression Potential]
+ 
+ ----
+ 
  (while gathering info for this bugreport, my knowledge about this issue
  has been growing. So the top part was written with not everything known
  yet)
  
  In my case I installed tp_smapi, but on the internet I've found others
  that have installed other modules.
  
  When configuring the tp-smapi-dkms package it says it will uninstall the
  module first and the it reports: Building initial module for
  4.15.0-23-generic
  
  After that it hangs, or so it seems. It turns out that somewhere in
  there a script is being called with output redirected to /dev/null. But
  under certain circumstances, in my case "the computer is configured for
  secure boot", whiptail is being called asking for a password.
  
  Whiptail outputs curses codes to write stuff to the screen but that is
  redirected to /dev/null. It then waits for input from the user. I've
  debugged this to the point that it is saying this:
  
   whiptail --backtitle Package configuration --title Configuring Secure
  Boot --output-fd 12 --nocancel --msgbox Your system has UEFI Secure Boot
  enabled.  UEFI Secure Boot requires additional configuration to work
  with  third-party drivers.  The system will assist you in configuring
  UEFI Secure Boot. To permit  the use of third-party drivers, a new
  Machine-Owner Key (MOK) has been  generated. This key now needs to be
  enrolled in your system's firmware.  To ensure that this change is being
  made by you as an authorized user,  and not by an attacker, you must
  choose a password now and then confirm  the change after reboot using
  the same password, in both the "Enroll  MOK" and "Change Secure Boot
  state" menus that will be presented to you  when this system reboots.
  If you proceed but do not confirm the password upon reboot, Ubuntu will
  still be able to boot on your system but any hardware that requires
  third-party drivers to work correctly may not be usable. --scrolltext 20
  77
  
  but, as I said the output is redirected to /dev/null.
  
  The call-tree is as follows:
  
-dpkg(18879)---tp-smapi-dkms.p(18880)---common.postinst(18881)---dkms(19146)---dkms(19161)---frontend(20224)-+-update-securebo(20238)
             |           |                                                      
                                                                                
                                             `-whiptail(20253)
  
  (with the update-secureboot and whiptail both being children from "frontend". 
).
  The tp-smapi-dkms.postinst  program is still being called with stdout 
connected to my controlling terminal. The common.postinst has stdout connected 
ot /dev/null, so I'd first look in /var/lib/dpkg/info/tp-smapi-dkms.postinst....
  I have looked there, and I don't see a reason why it would redirect the 
output of a subprocess to /dev/null. (the word does not occur in the short 
script.)
  Alternatively I'd think that maybe the subprocess 
/usr/lib/dkms/common.postinst would redirect its own stdout to /dev/null.
  
  On the other hand.... I found
    dkms build -m $NAME -v $VERSION -k $KERNEL $ARCH > /dev/null
  
  which explains the dkms subprocess running with output redirected to
  devnull, but not why the common.postinst runs with output redirected to
  devnull.
  
  Anyway. DKMS kernel module install postponed, apt  inoperable until I
  can physically access the machine....
  
  Should have been automatically added, but here goes:
  1:
  Description:    Ubuntu 18.04 LTS
  Release:        18.04
  2: dkms: 2.3-3ubuntu9.1
  3: People (not just me) expect a simple apt-get install <a module> to not 
hang wihtout explaining why.
  4: it hung without any explanation.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dpkg 1.19.0.5ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 10 16:54:20 2018
  ExecutablePath: /usr/bin/dpkg
  InstallationDate: Installed on 2018-06-28 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: dpkg
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  [Impact]
  All users of third-party modules on Ubuntu.
  
  [Test cases]
  1) Install Ubuntu on an UEFI system
  2) Clear any files in /var/lib/shim-signed/mok: "sudo rm -rf 
/var/lib/shim-signed/mok/*"
  3) Install virtualbox-dkms: "sudo apt install virtualbox-dkms"
  4) Verify that you are prompted for a password to enroll a new MOK, and that 
you are asked that password at reboot.
  
  Without the patch, no prompt will appear at install of virtualbox-dkms.
  
  [Regression Potential]
+ Shuffling of file descriptors as required by this change may impact dkms 
builds if these builds do special steps requiring different file descriptors. 
Any failure to install a -dkms package should be investigated as a potential 
regression coming from this SRU.
  
  ----
  
  (while gathering info for this bugreport, my knowledge about this issue
  has been growing. So the top part was written with not everything known
  yet)
  
  In my case I installed tp_smapi, but on the internet I've found others
  that have installed other modules.
  
  When configuring the tp-smapi-dkms package it says it will uninstall the
  module first and the it reports: Building initial module for
  4.15.0-23-generic
  
  After that it hangs, or so it seems. It turns out that somewhere in
  there a script is being called with output redirected to /dev/null. But
  under certain circumstances, in my case "the computer is configured for
  secure boot", whiptail is being called asking for a password.
  
  Whiptail outputs curses codes to write stuff to the screen but that is
  redirected to /dev/null. It then waits for input from the user. I've
  debugged this to the point that it is saying this:
  
   whiptail --backtitle Package configuration --title Configuring Secure
  Boot --output-fd 12 --nocancel --msgbox Your system has UEFI Secure Boot
  enabled.  UEFI Secure Boot requires additional configuration to work
  with  third-party drivers.  The system will assist you in configuring
  UEFI Secure Boot. To permit  the use of third-party drivers, a new
  Machine-Owner Key (MOK) has been  generated. This key now needs to be
  enrolled in your system's firmware.  To ensure that this change is being
  made by you as an authorized user,  and not by an attacker, you must
  choose a password now and then confirm  the change after reboot using
  the same password, in both the "Enroll  MOK" and "Change Secure Boot
  state" menus that will be presented to you  when this system reboots.
  If you proceed but do not confirm the password upon reboot, Ubuntu will
  still be able to boot on your system but any hardware that requires
  third-party drivers to work correctly may not be usable. --scrolltext 20
  77
  
  but, as I said the output is redirected to /dev/null.
  
  The call-tree is as follows:
  
-dpkg(18879)---tp-smapi-dkms.p(18880)---common.postinst(18881)---dkms(19146)---dkms(19161)---frontend(20224)-+-update-securebo(20238)
             |           |                                                      
                                                                                
                                             `-whiptail(20253)
  
  (with the update-secureboot and whiptail both being children from "frontend". 
).
  The tp-smapi-dkms.postinst  program is still being called with stdout 
connected to my controlling terminal. The common.postinst has stdout connected 
ot /dev/null, so I'd first look in /var/lib/dpkg/info/tp-smapi-dkms.postinst....
  I have looked there, and I don't see a reason why it would redirect the 
output of a subprocess to /dev/null. (the word does not occur in the short 
script.)
  Alternatively I'd think that maybe the subprocess 
/usr/lib/dkms/common.postinst would redirect its own stdout to /dev/null.
  
  On the other hand.... I found
    dkms build -m $NAME -v $VERSION -k $KERNEL $ARCH > /dev/null
  
  which explains the dkms subprocess running with output redirected to
  devnull, but not why the common.postinst runs with output redirected to
  devnull.
  
  Anyway. DKMS kernel module install postponed, apt  inoperable until I
  can physically access the machine....
  
  Should have been automatically added, but here goes:
  1:
  Description:    Ubuntu 18.04 LTS
  Release:        18.04
  2: dkms: 2.3-3ubuntu9.1
  3: People (not just me) expect a simple apt-get install <a module> to not 
hang wihtout explaining why.
  4: it hung without any explanation.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dpkg 1.19.0.5ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Tue Jul 10 16:54:20 2018
  ExecutablePath: /usr/bin/dpkg
  InstallationDate: Installed on 2018-06-28 (11 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
  SourcePackage: dpkg
  UpgradeStatus: No upgrade log present (probably fresh install)

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

Title:
  DKMS seems to hang after installing a module.

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to