Contrôler les Mises à jour provoquant : update-grub

Demande d'aide : c'est ici.
Répondre
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1263
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

06 juin 2021, 12:14

Bonjour, :006:

Comme j'ai déjà évoqué dans un précédent sujet : Problème de détection des OS par grub/os-prober
j'ai à présent 2 systèmes Debian (bullseye = futur stable) installés pour dual-boot sur des volumes dédiés chiffrés LUKS.

En usage normal, seul le volume "racine" de l'OS en cours est déchiffré,
l'autre racine restant inaccessible.


Le problème :

Avec cette configuration,
si une mise à jour concerne au moins 1 paquet "trigger" de update-grub,
typiquement linux-image-* et linux-headers-*
....mais pas seulement => c'est là le problème !


Dans ce cas il faut donc que le volume chiffré portant le 2d OS soit ouvert avant d'effectuter la MàJ qui déchenchera la mise à jour de GRUB
afin que os-prober le trouve.


Solutions envisagées


Piste N°1

Ma 1ère idée (simple) un script gérant les mises à jour
et
qui compare la liste des paquets candidats à la mise à jour avec une liste pré-établie de paquets à surveiller.

Si un de ces paquets est candidat, le script propose luksOpen

Cette méthode est la plus accessible pour moi,
mais je ne sais pas :

Comment obtenir la liste des paquets capables de déclencher update-grub ?


J'ai demandé hier sur IRC #debian si une commande pouvait fournir cette liste de paquets triggers de grub => pas de réponse immédiate :(


Donc pour le moment, à part compléter ma liste a posteriori,
je n'ai pas de solution.



Piste N°2

Sur IRC on m'a mis sur une piste qui semble contourner la liste précédente.


Utiliser un "hook" de GRUB pour qu'il fasse le job automatiquement.

il s'agirait de modifier : /etc/grub.d/30_os-prober
pour y insérer la commande luksOpen appropriée avant l'exécution de os-prober

ou

une variante consistant en la création d'un nouveau "hook" spécialement pour cela,
mais on ne m'a pas précisé comment :(

L'idée de modifier /etc/grub.d/30_os-prober semble excellente.
Mais :
  1. Je ne sais pas trop comment car ce script va au-delà de mon entendement.
  2. Même si je savais où placer ma commande, je ne vois pas trop comment cela pourrait se passer au niveau du mot de passe qu'il faudra bien fournir à un moment.
  3. J'ai pas envie de tout casser

Merci pour vos avis sur la question.


REMARQUE: ce sujet vient en complément de : Mise à jour : Surveillance/Alerte sur certains paquets
Debian testing/stable - XFCE
Avatar du membre
vv222
Modérateur
Modérateur
Messages : 442
Enregistré le : 18 avr. 2016, 20:14
Localisation : Bretagne
Contact :
Status : Hors ligne

06 juin 2021, 15:24

La solution que je conseille est de poser un nouveau hook, /etc/grub.d/25_custom_luks-open, qui s’exécutera donc avant /etc/grub.d/30_os-prober.

Je ne connais pas le fonctionnement de ces hooks, mais il semble que ce ne soit rien d’autre que de bêtes scripts shell.
PascalHambourg
Contributeur
Contributeur
Messages : 495
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

06 juin 2021, 17:32

dezix a écrit : 06 juin 2021, 12:14 si une mise à jour concerne au moins 1 paquet "trigger" de update-grub,
typiquement linux-image-* et linux-headers-*
Tu es sûr pour linux-headers-* ? Je ne vois pas pourquoi cela déclencherait update-grub.
En ce qui concerne linux-image-*, cela passe par un script zz-update-grub déposé dans /etc/kernel/postinst.d/ et /etc/kernel/postrm.d/. Il est possible d'ajouter d'autres scripts qui vont s'exécuter avant et après (avec l'ordre lexical, par exemple z-open-luks et zzz-close-luks.
Mais ces scripts ne s'exécuteront pas en cas de mise à jour du paquet grub-pc (si BIOS) ou grub-efi-amd64 (si UEFI), qui exécute aussi update-grub. Ni en cas d'exécution manuelle de update-grub, mais c'est moins gênant car c'est toi qui contrôles dont tu peux aussi ouvrir et fermer le volume chiffré.

Je ne recommande pas de modifier le fichier /etc/grub.d/30_os-prober car il appartient au paquet grub-common et est géré en conffile donc sera soit écrasé soit pas mis à jour en cas de mise à jour du paquet. L'ajout de scripts avant et après pour ouvrir et fermer le volume chiffré me semble une meilleure idée. Attention à vérifier si le volume est déjà ouvert, et dans ce cas il ne faut pas l'ouvrir une deuxième fois ni le fermer.

Autre possibilité : ne pas utiliser os-prober pour ajouter l'autre installation. Via /etc/grub.d/40_custom tu peux ajouter une entrée de menu qui va simplement charger le fichier /grub/grub.cfg (commande configfile) dans la partition /boot de l'autre installation Ainsi pas besoin d'ouvrir le volume chiffré, et autre avantage, pas besoin d'exécuter update-grub dans l'OS principal pour prendre en compte une mise à jour de noyau dans l'OS secondaire. Inconvénient : la sélection de l'OS secondaire dans GRUB se fera en deux temps.
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1263
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

08 juin 2021, 14:24

Une fois encore vous m'avez apporté une aide précieuse, MERCI ! :good:


@vv222

100% dans le vrai !


PascalHambourg a écrit : 06 juin 2021, 17:32 Tu es sûr pour linux-headers-* ? Je ne vois pas pourquoi cela déclencherait update-grub.
Après vérification... tu as raison => C'est corrigé !


J'ai testé sur une VBox les 2 solutions :



Solution 1

Script qui ouvre le volume LUKS portant la racine de l'autre OS ; ici -> sda3

Suivant le conseil de :
PascalHambourg a écrit : 06 juin 2021, 17:32 Attention à vérifier si le volume est déjà ouvert, et dans ce cas il ne faut pas l'ouvrir une deuxième fois ni le fermer.

J'ai créé 2 scripts pour ouvrir puis refermer le volume chiffré en vérifiant sont état.

J'ai fait au plus simple,
mais dans mon cas ça devrait être fiable,
dans la mesure où c'est :
  • toujours le même volume : /dev/sda3
  • monté avec le même nom : sda3_crypt
Pour des cas plus complexes, il faudrait un script plus élaboré qui prenne en compte toutes les situations...

Ce qui donne :

Ouverture

Code : Tout sélectionner

# vim /etc/grub.d/25_extra_luksOpen

code
------------------------------------
#!/bin/bash
# Script additionnel pour Ouverture du Volume LUKS portant la racine de l'OS2
if [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] ;
	then cryptsetup luksOpen /dev/sda3 sda3_crypt ;
fi
------------------------------------

# chmod +x /etc/grub.d/25_extra_luksOpen


Fermeture

Code : Tout sélectionner

# vim /etc/grub.d/50_extra_luksClose

code
------------------------------------
#!/bin/bash
# Script additionnel pour Fermeture du Volume LUKS portant la racine de l'OS2
if ! [[ $(dmsetup ls --target crypt | grep sda3) == '' ]] ;
	then cryptsetup luksClose sda3_crypt ;
fi
------------------------------------

# chmod +x /etc/grub.d/50_extra_luksClose
J'ai testé en supprimant/installant des paquets linux-image-*
et
j'obtiens bien le prompt interactif pour fournir le MdP du volume LUKS :yahoo:


Il me reste à le tester en réel sur mon installation,
mais selon toute vraisemblance cela devrait fonctionner pile-poil !





Solution 2

Celle qui consiste à ajouter des entrées statiques dans /etc/grub.d/40_custom

Je ne vais pas détailler ce que j'ai testé,
il suffit p.ex de copier dans /boot/grub/grub.cfg du système à rajouter,
les sections menuentry qui nous intéressent,
se trouvant sous :

### BEGIN /etc/grub.d/10_linux ###

et de les ajouter à la fin de : /etc/grub.d/40_custom

Puis un coup de :

Code : Tout sélectionner

# update-grub
# grub-install /dev/sdx
pour avoir ces nouvelles entrées au bas du Menu GRUB.


L'inconvénient majeur de cette solution est que les mises à jour des versions du noyau ne se font pas (statique).

Il faudra donc :
soit éditer manuellement 40_custom
soit écrire un script qui le fera pour nous.



Voilà, pour ma part,
je vais commencer par configurer la Solution 1 sur mon installation,
et
je reviendrai peut-être ICI pour un éventuellement retour...

:006:
Debian testing/stable - XFCE
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1263
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

08 juin 2021, 17:32

Et bien ça n'a pas tardé... je suis déjà de retour :040:

À la relecture de :
PascalHambourg a écrit : 06 juin 2021, 17:32 Autre possibilité : ne pas utiliser os-prober pour ajouter l'autre installation. Via /etc/grub.d/40_custom tu peux ajouter une entrée de menu qui va simplement charger le fichier /grub/grub.cfg (commande configfile) dans la partition /boot de l'autre installation Ainsi pas besoin d'ouvrir le volume chiffré, et autre avantage, pas besoin d'exécuter update-grub dans l'OS principal pour prendre en compte une mise à jour de noyau dans l'OS secondaire. Inconvénient : la sélection de l'OS secondaire dans GRUB se fera en deux temps.

Je me rends comptes que j'avais tout compris de travers :blush:
et que cela ne correspond pas DU TOUT à ma Solution 2


Je comprends à présent que la commande configfile de GRUB sert à insérer un autre fichier de configuration grub,
en l’occurrence, celui de l'autre OS.


Dans mon exemple,
/dev/sda2 est la partition montée sur /boot du system2

Donc dans 40_custom
ça donne :

Code : Tout sélectionner

configfile (hd0,msdos2)/grub/grub.cfg
Cette méthode fonctionne aussi.

La seule chose un peu étrange,
le système secondaire est placé en haut du Menu GRUB

Ce n'est pas vraiment gênant,
mais il faudrait pouvoir différentier clairement les 2 systèmes
(sans que se soit écrasé à la prochaine MàJ)
car dans mon cas, ce sont 2x la même version de Debian.
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 495
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

08 juin 2021, 18:36

Commentaire sur ton script /etc/grub.d/50_extra_luksClose : il ferme systématiquement le volume chiffré s'il est monté (ce qui est normalement le cas puisqu'il a été ouvert par le script /etc/grub.d/50_extra_luksOpen si besoin), alors qu'en toute rigueur il ne devrait le fermer que si c'est /etc/grub.d/50_extra_luksOpen qui l'a ouvert. Ce qui nécessite de passer une information d'état entre les deux scripts.

dezix a écrit : 08 juin 2021, 17:32 configfile (hd0,msdos2)/grub/grub.cfg
Il serait plus sûr d'utiliser l'UUID car rien ne garantit que que (hd0) est le bon disque.

dezix a écrit : 08 juin 2021, 17:32 La seule chose un peu étrange,
le système secondaire est placé en haut du Menu GRUB
C'est normal puisqu'il s'agit du menu de GRUB du système secondaire.
Tu peux faire la même manip sur le système secondaire pour pouvoir revenir au menu primaire, désactiver os-prober devenu inutile sur les deux systèmes, et pour les distinguer, sur chacun d'eux,
- personnaliser l'entrée Linux en modifiant la valeur de GRUB_DISTRIBUTOR dans /etc/default/grub
- libeller l'entrée ajoutée par 40_custom de façon explicite

Par exemple "Debian primaire" et "Debian secondaire".
Répondre