Secure Boot Violation - Debian13

Pfffff :man_facepalming: pas concentré le type…
Mais j’ai le même retour de commande si je tape

sudo sbverify --list /dev/sdb1/EFI/boot/bootx64.efi
sudo sbverify --list /dev/sdb1/EFI/boot/grubx64.efi

Parfois je me demande si je vais y arriver… :wink:

Sur quel point de montage as-tu mis la clé ?

mount | grep sdb1

Quand je dis « chemin de la clé USB » ci-dessus, c’est le chemin dans le point de montage, et non le chemin du device. Probablement un truc du genre :

ls /media/truc(...)/EFI/boot/bootx64.efi

Je n’ai pas tout lu donc je suis peut être à coté de la plaque mais il me semble que le mécanisme de vérification consiste à

  • vérification de shimx64.efi et délégation de la vérification à celui là
  • shimx64 vérifie avec les clefs de debian la signature du grubx64 puis du noyau (grub fait appel à lui)
    et là ça boute.
    Donc il devrait y avoir un shimx64.efi que je n’ai vu évoquer que par Thierz.

En fait je pense que shim64.efi est renommé en bootx64.efi car la norme UEFI cherche un fichier de ce nom-là pour booter sur un volume amovible.

Eh ben t’as raison et je ne m’en étais as aperçu:

Donc je suis à coté de la plaque :slight_smile:

Dans certains cas shim peut garder son nom shimx64.efi, par exemple si on a un boot manager entre l’UEFI et shim, typiquement rEFInd.

Ces fichiers ne sont pas chiffrés. Seul shim et éventuellement Linux*.efi ou debian.efi suivant le type d’installation.
A noter que grub n’est aps très simple pour faire du chiffré. Mieux vaut systemd-boot ou unify.

Non

On ne veut pas faire de chiffrement dans ce sujet, on ne parle que de signatures pour le secure boot.

Si : UEFI Specification Version 2.11 (released December 2024) , §3.5. Boot Mechanisms, page 85

J’utilise systemd-boot, ayant abandonné grub pas assez fiable et trop problématique avec son installation.
Avec systemd-boot pas besoin de recopie sur bootx64.efi. Idem avec Unify d’ailleurs.

Je comprends. Pour l’ami @Mokjf je pense qu’on peut apporter une solution plus « sur étagère », moi je pense qu’il devrait suivre le conseil donné ici càd partir d’une iso netinst stable (donc signée), copiée sur sa clé USB bootée en secure boot standard… Là on est en train de l’aider à avancer dans une solution pas super viable.

systemd-boot est une solution sur étagère justement :slight_smile: et qui ne nécessite pas autant de configuration que grub.

Moi j’ai installé par une live, donc mon expérience à l’install est limitée, j’imagine qu’avec la netinst on a grub par défaut, mais on peut peut-être le changer dès l’installation ?

non désormais il y a trois options:

  • Grub
  • Systemd-boot
  • Pas d’installation
1 J'aime

La clef est bien montée sur

/dev/sdb1 

Je pense que je vais refaire une installation avec le iso-dvd plus adapté avant d’aller plus loin.
Je trouve la proposition de systemd-boot de Zargos intéressante mais j’ai peur avec mon niveau d’être vite débordé, vu que je suis tout démuni dés que j’ai un retour de commande qui ne fonctionne pas :wink:
Malheureusement je ne pourrai faire ça que quand j’aurai terminé le chantier surprise, sinon les ordi risquent de se retrouver sans façade ni toit pour les protéger.

1 J'aime

Donne-nous toute la ligne stp ?

Sage décision. N’aie pas peur ça va bien se passer :wink:

/dev/sdb1 on /media/thomasc/d-live 13.6.0 kd amd64 type iso9660 (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=1000,dmode=500,fmode=400,iocharset=utf8,uhelper=udisks2)

Le point de montage est /media/thomasc/d-live, donc :

sudo sbverify --list /media/thomasc/d-live/EFI/boot/bootx64.efi