I'm running Xubuntu 18.04 on my current laptop, as well as my old laptop that I'm trying to sell. I recently installed it on the latter; it's totally clean, no PPAs or extra kernels.

Both systems are Nvidia Optimus laptops, and both were installed in UEFI mode. My current laptop has secure boot turned off. I haven't done anything like that on the old one yet. I have installed nvidia 396 from the graphics-driver PPA on my main laptop, and used nvidia 390 from the official repo on the old laptop. My main laptop has the xanmod kernel and the stock kernel. The old laptop has only the stock kernel.

Both systems experience complete hangs in dpkg while trying to upgrade kernels. The system itself doesn't hang but the upgrade gets stuck. A little bit of terminal sleuthing shows this:

TiZLappy:~$ pgrep dpkg
TiZLappy:~$ pstree -l 2499
TiZLappy:~$ ps aux | grep securebo
root      5146  0.0  0.1 111876 22928 pts/1    S+   23:57   0:00 /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-secureboot-policy --enroll-key
root      5160  0.0  0.0   4628  1844 pts/1    S+   23:57   0:00 /bin/sh /usr/sbin/update-secureboot-policy --enroll-key
tiz      10409  0.0  0.0  22004  1028 pts/2    S+   23:59   0:00 grep --color=auto securebo
TiZLappy:~$ ps aux | grep whiptail
root      5175  0.0  0.0  32356  4252 pts/1    S+   Jul03   0:00 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 21 84
tiz      30605  0.0  0.0  22004  1040 pts/2    S+   00:07   0:00 grep --color=auto whiptail

So the update-secureboot-policy script is straight up frozen and it's stalling the whole upgrade. I don't know if whiptail is supposed to be presenting some sort of dialog or useful interactible, but it's not; neither on apt, nor on dpkg --configure -a.

Killing these stuck processes doesn't allow the upgrade process to continue with apt.

This behavior is the same on both my main laptop with xanmod and graphics-drivers PPA, and on my old laptop with stock everything, so additional packages can't be blamed for this.

  • 2
    So the dialog backend for debconf seems to be broken in this case, potentially others. If I sudo dpkg-reconfigure debconf and select readline as the backend, I am able to give it the info it wants and proceed. This is a workaround, not a solution. – TiZ Jul 12 '18 at 4:28

With ps you can see what whiptail is asking you. The problem is: Its output is being redirected to /dev/null. Some "higherup" script didn't want the clobber of one of the subscripts it was calling and redirects the output to devnull. But when you have secureboot, the update-secureboot-policy output becomes very important.

In the file /usr/lib/dkms/common.postinst you will find about 30 lines before the end a redirect to /dev/null. Remove the redirect.

On my system the non-normal stopping of the upgrades has mangled the system that it will no longer attempt installing the key. I hope yours is not in that state.....

  • There are two redirects to null. I removed the one for dkms build. It didn't help. Setting up linux-image-4.17.6-xanmod5 (1.180711) ... is still just completely frozen. – TiZ Jul 12 '18 at 4:04
  • This sounds like the answer. I haven't been able to force a reinstall of DKMS, but looking through the script, I think the line you're talking about is this one: dkms build -m $NAME -v $VERSION -k $KERNEL $ARCH – Gargravarr May 15 '19 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.