Comment 7 for bug 1621367
Revision history for this message
| nicht-vergessen (nicht-vergessen) wrote | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Okay, first of all: I'm sorry for not reporting back earlier.
Asides that, I still consider this as a bug and bad user experience, as we / the linux community strives to encourage people to secure their systems and encrypt or sign content.
Shortly after I reported in September I had no better solution than to reinstall the whole system, because there was no bootable kernel left in the grub menu.
I've installed the desktop same as before and as advised to the public:
- full disk encrypted
- automatic updates enabled
Some time after that I ran into the same problem, but this time I had some time to dig deeper AND I remembered from the installation procedure that there was a message about my enabled Secure Boot flag in the UEFI BIOS.
Given that I found out that there are installed kernel modules from the
- integrated Intel Graphics
- nVidia Graphics card
- Virtual Box Networking Modules
which are signed but not under the new kernel (apt-get dist-upgrade has run).
Temporary solution for me:
I found a guide to sign those modules with a self-signed certificate and enroll this within Secure Boot. Furthermore I hacked a script that looks for the currently installed and other available kernel versions and offers to sign all installed kernel modules ahead of rebooting the new kernel.
Possible solution for everyone affected:
Since my solution involves a manual task and self-signed certificates it is not that suitable to the "faint hearted" masses, that don't even get that close to any other solution than to disable SecureBoot at all (Numerous "hints" in the Ubuntu forums or StackExchange lead people to disable it, although there is a way to make it work.)
- I think a better approach whould be to force creation and presence of self-signed certificates during the installation phase or during kernel upgrades.
- Additionally post-kernel-upgrade installation steps should automatically look for a (default location/filename of) signature certificate and sign remaining kernel modules.
I know this approach might "white-label" kernel modules of unknown source, but I think this is the lesser pain than disabling secure boot at all.
Contrary the current state leaves users of full disk encryption and Secure Boot without any clue on what went wrong since the last shutdown or reboot.