Re: Fresh-installed Debian 10 (UEFI, LUKS&LVM) not accessible through Secure Boot
I don't know exactly why but the following did the trick:
grub-installInstalling for x86_64-efi platform.Installation finished. No error reported.[...manual reboot and Secure Boot activation in ThinkPad Setup...]mokutil --sb-stateSecureBoot enabled
Many thanks :)
Best regards,
l0f4r0
3 janv. 2020 à 18:46 de didier.gaumet@gmail.com:
> Le vendredi 3 janvier 2020 17:10:04 UTC+1, l0f...@tuta.io a écrit :
> [...]
>
>> I've used https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso
>>
>
> Good.
>
> I would verify shim* packages are installed and well configured (State/Error flags "ii" at the beginning of the lines);
> didier@hp-notebook14:~$ sudo dpkg -l shim*
> Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
> | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
> |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
> ||/ Nom Version Architecture Description
> +++-=========================-============================-============-================================================================
> un shim <aucune> <aucune> (aucune description n'est disponible)
> ii shim-helpers-amd64-signed 1+15+1533136590.3beb971+7 amd64 boot loader to chain-load signed boot loaders (signed by Debian)
> ii shim-signed:amd64 1.33+15+1533136590.3beb971-7 amd64 Secure Boot chain-loading bootloader (Microsoft-signed binary)
> ii shim-signed-common 1.33+15+1533136590.3beb971-7 all Secure Boot chain-loading bootloader (common helper scripts)
> ii shim-unsigned 15+1533136590.3beb971-7 amd64 boot loader to chain-load signed boot loaders under Secure Boot
>
> then I would verify if what I think is necessary is present : a third party Microsoft tool (but perhaps I am wrong):
> didier@hp-notebook14:~$ sudo mokutil --db | grep -i issuer
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
> CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
> CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
> Issuer: C=US, O=Hewlett-Packard Company, CN=Hewlett-Packard Printing Device Infrastructure CA
> didier@hp-notebook14:~$ sudo mokutil --kek | grep -i issuer
> Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
> CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
> Issuer: C=US, O=Hewlett-Packard Company, CN=Hewlett-Packard Printing Device Infrastructure CA
>
> I reach there my limitations to understand clearly how SecureBoot and UEFI work, but on my laptop, the Microsoft Thir Party thing seems to be enabled when enrolling something called "HP factory keys" or something of the same kind (I have forgotten the exact name) in the HP UEFI interface. But perhaps on your Lenovo you have ton confirm (by entering a code prompted by the UEFI, for example) at boot time that you really want to enroll keys that the shim is trying to install.
>
> So I would try this:
> sudo dpkg-reconfigure shim-helpers-amd64-signed shim-signed:amd64 shim-signed-common shim-unsigned
>
> and then reboot and see if the UEFI ask me to confirm any change and verify if SecureBoot is really on:
>
> didier@hp-notebook14:~$ sudo mokutil --sb-state
> SecureBoot disabled !(in my case that is volontary)
>
>
>
>> efibootmgr [...]
>>
>
> I am persuaded that efibootmgr/efivar & al may present perfect informations but are sometimes superseded by the manufacturer implementation of the UEFI standard
>
Reply to: