[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
This bug was fixed in the package dkms - 2.3-3ubuntu9.2 --- dkms (2.3-3ubuntu9.2) bionic; urgency=medium * 0009-Add-support-for-UEFI-Secure-Boot-validation-toggling.patch: source /usr/share/debconf/confmodule from dkms_common.postinst to ensure we have all the environment ready to successfully show debconf prompts when dkms modules are being built. (LP: #1781001) -- Mathieu Trudel-Lapierre Wed, 18 Jul 2018 09:33:31 -0400 ** Changed in: dkms (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: Fix Released Status in dkms source package in Bionic: Fix Released Bug description: [Impact] All users of third-party modules on Ubuntu when running under SecureBoot experience a package manager hang trying to initially configure the dkms package from the commandline. [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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
Just tested https://launchpad.net/ubuntu/+source/dkms/2.3-3ubuntu9.2 (had the same issue while installing wireguard), works as expected, thanks! ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: Fix Released Status in dkms source package in Bionic: Fix Committed Bug description: [Impact] All users of third-party modules on Ubuntu when running under SecureBoot experience a package manager hang trying to initially configure the dkms package from the commandline. [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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
This bug was fixed in the package dkms - 2.3-3ubuntu11 --- dkms (2.3-3ubuntu11) cosmic; urgency=medium * 0009-Add-support-for-UEFI-Secure-Boot-validation-toggling.patch: source /usr/share/debconf/confmodule from dkms_common.postinst to ensure we have all the environment ready to successfully show debconf prompts when dkms modules are being built. (LP: #1781001) -- Mathieu Trudel-Lapierre Mon, 16 Jul 2018 16:14:29 -0400 ** Changed in: dkms (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: Fix Released Status in dkms source package in Bionic: Fix Committed Bug description: [Impact] All users of third-party modules on Ubuntu when running under SecureBoot experience a package manager hang trying to initially configure the dkms package from the commandline. [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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
Hello rew, or anyone else affected, Accepted dkms into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dkms/2.3-3ubuntu9.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: dkms (Ubuntu Bionic) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-bionic ** Changed in: dkms (Ubuntu Bionic) Milestone: None => ubuntu-18.04.1 ** Changed in: dkms (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: Fix Committed Status in dkms source package in Bionic: Fix Committed Bug description: [Impact] All users of third-party modules on Ubuntu when running under SecureBoot experience a package manager hang trying to initially configure the dkms package from the commandline. [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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
** Description changed: [Impact] - All users of third-party modules on Ubuntu. + All users of third-party modules on Ubuntu when running under SecureBoot experience a package manager hang trying to initially configure the dkms package. [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 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:
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
** 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 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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
** Changed in: dkms (Ubuntu) Status: New => Fix Committed ** Changed in: dkms (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: Fix Committed Bug description: [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 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
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
Dear bot, In your explanation you tell me to think about it and remove the patch flag if it is inappropriate. But then you go ahead and do it yourself without thinking about it? Liar! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: New Bug description: (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 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1781001/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
Dear bot, Yes, it's a patch. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: New Bug description: (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 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1781001/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
The attachment "This causes the proper behaviour for me, probably a bit noisy for others in other situations. At least a workaround." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1781001 Title: DKMS seems to hang after installing a module. Status in dkms package in Ubuntu: New Bug description: (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 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) To manage notifications about this bug go to:
[Kernel-packages] [Bug 1781001] Re: DKMS seems to hang after installing a module.
** Package changed: dpkg (Ubuntu) => dkms (Ubuntu) ** Description changed: + (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 + 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: + 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) + | | `-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 + (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. + 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 + 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: + 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 to not hang wihtout explaining why. + 3: People (not just me) expect a simple apt-get install 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