Toutes les mises à niveau du noyau se bloquent sur update-secureboot-policy --enroll-key
J'utilise Xubuntu 18.04 sur mon ordinateur actuel, ainsi que mon ancien ordinateur que je tente de vendre. Je l'ai récemment installé sur ce dernier; c'est totalement propre, pas de PPA ni de noyaux supplémentaires.
Les deux systèmes sont des ordinateurs portables Nvidia Optimus, et les deux ont été installés en mode UEFI. Le démarrage sécurisé de mon ordinateur portable actuel est désactivé. Je n'ai encore rien fait de tel sur l'ancien. J'ai installé nvidia 396 à partir du pilote graphique PPA sur mon ordinateur principal et utilisé nvidia 390 à partir du référentiel officiel de l'ancien ordinateur portable. Mon ordinateur portable principal a le noyau xanmod et le noyau standard. Le vieil ordinateur portable n'a que le noyau en stock.
Les deux systèmes ont complètement bloqué dpkg lors d’une tentative de mise à niveau de noyaux. Le système lui-même ne se bloque pas mais la mise à niveau reste bloquée. Un peu de recherche terminale le montre:
TiZLappy:~$ pgrep dpkg
2499
TiZLappy:~$ pstree -l 2499
dpkg───linux-image-4.1───run-parts───dkms_autoinstal───dkms───dkms───frontend─┬─update-securebo
└─whiptail
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
Ainsi, le script update-secureboot-policy est gelé et bloque toute la mise à niveau. Je ne sais pas si whiptail est censé présenter une sorte de dialogue ou d'interaction utile, mais ce n'est pas le cas; ni sur apt, ni sur dpkg --configure -a.
Tuer ces processus bloqués ne permet pas au processus de mise à niveau de continuer avec apt.
Ce comportement est identique sur mon ordinateur portable principal avec xanmod et PPA de pilotes graphiques et sur mon ancien ordinateur portable avec tout en stock, de sorte que des paquets supplémentaires ne peuvent pas être blâmés pour cela.
Avec ps, vous pouvez voir ce que whiptail vous demande. Le problème est le suivant: sa sortie est redirigée vers/dev/null. Certains scripts "upperup" ne voulaient pas le poids d'un des indices qu'il appelait et redirigeaient la sortie vers devnull. Mais lorsque vous avez Secureboot, la sortie de update-secureboot-policy devient très importante.
Dans le fichier /usr/lib/dkms/common.postinst, vous trouverez environ 30 lignes avant la fin d'une redirection vers/dev/null. Supprimer la redirection.
Sur mon système, l’arrêt non normal des mises à niveau a empêché le système de tenter d’installer la clé. J'espère que le tien n'est pas dans cet état .....