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.
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: ---tp-smapi- dkms.p( 18880)- --common. postinst( 18881)- --dkms( 19146)- --dkms( 19161)- --frontend( 20224)- +-update- securebo( 20238)
-dpkg(18879)
| | `-whiptail(20253)
(with the update-secureboot and whiptail both being children from "frontend". ). 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. ... dkms/common. postinst would redirect its own stdout to /dev/null.
The tp-smapi-
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/
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 ature: Ubuntu 4.15.0- 23.25-generic 4.15.18
DistroRelease: Ubuntu 18.04
Package: dpkg 1.19.0.5ubuntu2
ProcVersionSign
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)