Virer Grub

Tags: #<Tag:0x00007f4e31709578> #<Tag:0x00007f4e31709410>

Bonjour à tous, j’avais installé rEFInd avant même d’avoir Linux, en prévision d’un dual boot. Quand j’ai installé Trixie, Grub s’est installé avec (je n’ai pas dû voir l’option pour ne pas l’installer). Du coup je me suis retrouvé avec Grub au démarrage. Je l’ai enlevé à la mano croyant que je n’en entendrais plus parler (suppression de /boot/efi/EFI/debian et tout son contenu), et pendant un moment ça s’est très bien passé, j’avais rEFInd.

Mais dès le apt upgrade suivant, j’ai vu que je mettais à jour les paquets Grub (hé oui :grinning:), et je me suis retrouvé à nouveau avec Grub au démarrage. J’ai réfléchi, et je me suis dit que j’aurais dû virer les paquets Grub afin qu’il ne se mette plus à jour.

Si je vire les paquets suivants, est-ce suffisant ?

$ apt list grub* --installed
grub-common/stable,now 2.12-9+deb13u1 amd64 [installé]
grub-efi-amd64-bin/stable,now 2.12-9+deb13u1 amd64 [installé, automatique]
grub-efi-amd64-signed/stable,now 1+2.12+9+deb13u1 amd64 [installé, automatique]
grub-efi-amd64-unsigned/stable,now 2.12-9+deb13u1 amd64 [installé, automatique]
grub-efi-amd64/stable,now 2.12-9+deb13u1 amd64 [installé]
grub2-common/stable,now 2.12-9+deb13u1 amd64 [installé, automatique]

Mais surtout : est-ce la bonne façon de faire ? Je ne voudrais pas supprimer un truc crucial pour le démarrage de Debian.

Merci d’avance pour votre aide !

Bonjour,
à priori il n’y a pas d’impact si tu supprime grub:

~$ apt depends refind
refind
  Dépend: debconf
  Dépend: efibootmgr
    efibootmgr:i386
  Dépend: gawk
    gawk:i386
  Dépend: gdisk
  Dépend: mokutil
    mokutil:i386
  Dépend: openssl
    openssl:i386
 |Dépend: debconf (>= 0.5)
  Dépend: <debconf-2.0>
    cdebconf
    debconf
  Recommande: python3
  Recommande: sbsigntool
    sbsigntool:i386
1 J'aime

Apparemment certains paquets ne sont pas désinstallables ?

$ sudo apt purge grub-efi-amd64-signed
SUPPRESSION :                                   
  grub-efi-amd64-signed*

ATTENTION : Les paquets essentiels suivants vont être enlevés.
Vous NE devez PAS faire cela, à moins de savoir exactement ce
que vous êtes en train de faire.
  grub-efi-amd64-signed

Sommaire :
  Mise à niveau de : 0. Installation de : 0Supprimé : 1. Non mis à jour : 0
  Espace libéré : 9 720 kB

Erreur : Enlever des paquets critiques du système étiquetés « Essentiel » n'est pas permis. Cela pourrait casser votre système.

Oh purée, dans quoi je me suis lancé encore… Désinstaller grub installe d’autres trucs qui m’ont saturé ma partition EFI…

# df
(...)
/dev/nvme0n1p1         98304    98303          1 100% /boot/efi
(...)

Et comme elle est trop petite, en première position avant Windows sur le disque, si je veux l’étendre je dois déplacer tout ce qui suit !

/boot/efi# du -sk *
64104   438cbdaea7a340e4bebb6d7f26ad0981
7       db
13      dbx
34167   EFI
4       KEK
6       loader
1       PK

La désinstallation de grub échoue car Debian installe des trucs dans /boot/efi/438cbdaea7a340e4bebb6d7f26ad0981 qui sont super gros :

# ls -l 438cbdaea7a340e4bebb6d7f26ad0981/6.12.73+deb13-amd64/
total 64102
-rwx------ 1 root root 53530624 18 mars  17:50 initrd.img-6.12.73+deb13-amd64
-rwx------ 1 root root 12109760 18 mars  17:50 linux

Alors, voici ce qui m’arrive… Quand je désinstalle grub, apt m’installe systemd-boot : il doit partir du principe que c’est obligatoire d’avoir un boot loader. Le problème, c’est que systemd-boot copie trop de trucs dans la partition EFI et me la sature.

J’ai tenté une désinstallation de systemd-boot : apt me réinstalle grub, retour au problème précédent. Je soupçonne que, ayant installé rEFInd avant d’avoir Linux (manuellement), Debian n’en a pas connaissance et refuse de me laisser sans boot loader.

Avez-vous une idée sur la marche à suivre ? J’imaginais installer rEFINd depuis Debian (le reconfigurer comme mon install manuelle précédente), en espérant que ensuite Debian me laisse désinstaller grub sans remettre systemd-boot… Ca peut marcher ?

J’ai soumis un bug car il doit y avoir un mécanisme de dépendance défaillant sur grub-common :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131281

# apt remove grub-common
Résolution des dépendances  ... Erreur !        
Certains paquets ne peuvent être installés. Cela peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation : 

Impossible de satisfaire les dépendances : 
 grub-efi-amd64-signed : Dépend: grub-common (= 2.12-9+deb13u1) mais ne sera pas installé
Erreur : Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
Erreur : The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. grub-common:amd64 is selected for removal
   2. grub-common:amd64 is selected for install because:
      1. grub-efi-amd64-signed:amd64 is selected for install
      2. grub-efi-amd64-signed:amd64 Dépend grub-common (= 2.12-9+deb13u1)

désormais il faut au moins avoir 512M dans une partition EFI.
Quand elle est dimensionné par Windows il faut comprendre que Windows ne considère le mon,de que pour lui même; le reste n’existe pas.
C’est pour cela qu’en cas de dual boot, mes installations linux disposent toujours de leur propre partition EFI,n’utilisant jamais celle de Windows.

Rebind s’appuie sur les bootloader, il n’est pas un bootloader lui-même.

Quand je virerai Windows (si j’y arrive un jour) je pourrai refaire proprement, là pour l’instant je dois faire avec ce que j’ai, en l’état… Systemd-boot est trop gourmand, grub non, mais pourtant j’arrive pas à le virer. En fait, je cherche une source documentaire qui m’explique ce mécanisme empêchant de juste virer grub sans mettre systemd-boot, je ne trouve rien.

Je pense que je comprends un peu mieux comment marchent les dépendances autour de Grub. Pour rappel, ma première désinstall de grub s’était mal passée parce que je n’avais pas tout bien lu apt avant de valider : il m’avait installé systemd-boot à la place, saturant ma partition EFI trop petite (cf. ci-dessus). Ceci est causé par la présence sur mon système du paquet shim-signed : ce paquet a une dépendance un peu particulière, il a besoin de soit grub, soit systemd-boot, cf. la page des détails du paquet.

Donc, tout naturellement, désinstaller grub sans désinstaller shim-signed déclenche l’installation de l’alternative à grub: systemd-boot. rEFInd n’est pas considéré ici.

Du coup, je voulais avoir votre avis éclairé : quel impact sur mon Debian si je vire le paquet shim-signed, afin de faire sauter cette dépendance, et ensuite enlever grub ?

Il faut surtout comprendre que Rfnd bn’est pas un bootloader.

juste une question de sécurité sur le lancement de ton système.

Mais pas plus qu’actuellement, j’imagine, puisque je boote sous rEFInd et non Grub ?

pas forcement si tu es en secure boot. car il y a un lien direct entre le secure boot et shim-signed

Ce que je vois dans le setup :
IMG_20260403_064704

Ce que je vois dans Trixie :

$ mokutil --sb-state
SecureBoot disabled

C’est plutôt bizarre, ou c’est normal ?

J’ai commencé à lire ton tuto sur le Secure Boot, très intéressant (mais aussi un peu compliqué).

oui je confirme. ce n’est pas une technologie très simple.

C’est en fait un autre exemple de la main mise de microsoft.

Pour etre en secure boot il faut activer Windows UEFI Mode. Ce qui laisse supposer que seul windows sait gérer uefi mais non, ça marche aussi avec Linux.

Ce qu’il faut comlprendre avec Secure Boot, c’est que ça ne peut marcher QUE si le système est en UEFI. Pas secure boot en legacy.

Ok, donc le plan long terme, ce serait de passer en Windows UEFI mode, si possible sans utiliser les clés Microsoft dans ma chaîne de boot Debian.

Ton Debian ne les utilise pas de toute façon.

Je n’aurai aucun souci à revenir en arrière, si, à but de test, j’active le Windows UEFI mode aujourd’hui juste pour voir comment mon rEFInd échoue à booter ?

Si ton système n’ pas été installé avec secure boot activé, il ne démarrera pas si tu actives le secure boot. Ce qui est le but d’ailleurs.

Oui ça j’ai bien compris, je voulais juste être sûr qu’il n’y aurait pas d’autres conséquences, et qu’en désactivant le secure boot je pourrais booter à nouveau sans avoir cassé ou brické quoi que ce soit.