Lvm sur un seul disque = 2 partitions pour grub?

Support Debian
#1

bonjour,
ayant hérité d’un portable assez poussif avec W10 , en solo , j’ai voulu tester le couple debian/Xfce pour essayer de le rendre plus agréable à utiliser . J’en ai profité pour essayer l’installation de debian 11 avec LVM , option "manuel"pour le partitionnement .

Après avoir fait toutes les étapes sauf celle concernant la préparation d’un espace adéquat pour l’installation de grub et n’ayant aucune idée là-dessus , n’ayant pas trouvé de tutoriel qui s’occupe en détail de cette question , j’ai laissé la main à debian en revenant en arrière et en prenant l’option 100% installateur . Pas de problème tout est ok et le portable est presque devenu véloce .

j’ai ensuite vérifié le partitionnement du disque avec gparted :

  • sda1 512 Mio fat32 /boot/efi (boot , esp)
  • sda2 488 Mio ext2 /boot
  • sda3 930 Gio lvm2 pv mm-vg

auriez-vous un lien pour un bon tutoriel ou une bonne documentation qui entre dans le détail au sujet de l’installation de grub pour un OS linux , utilisant LVM , afin que je puisse comprendre comment l’installateur a réalisé l’opération et le pourquoi de deux partitions extérieures au volume physique ( enfin il me semble ) .

#2

La partition système EFI est nécessaire pour l’amorçage UEFI.
La partition /boot séparée n’est plus indispensable avec GRUB 2, c’est un reste du temps où les chargeurs d’amorçage (LILO, GRUB 1) ne savaient pas lire LVM.

#3

j’avais lu ça quand j’ai commencé à me documenter sur LVM mais j’avais cru comprendre que une seule partition extérieure à LVM , /boot , était nécessaire . Visiblement je n’ai pas tout saisi . Mais bon , ok pour ce point précis .

Mais il me semble , à tort ? , que sda1 qui héberge GRUB 2 est quand même en dehors du volume physique créé par LVM . Puisque cette version de GRUB sait lire LVM pourquoi ne pas le mettre dans le volume physique sur sda 3 ?

#4

Je ne sais pas si j’ai bien compris ce que tu demandes, mais GRUB peut lire le LVM, mais ce qui charge GRUB ne le peut pas, il faut donc mettre GRUB à l’extérieur du LVM.
Vu que tu es en UEFI (semble-t-il), tu as une partition pour l’amorçage UEFI (/boot/efi), GRUB sera dedans, mais tu peux mettre tout le reste dans ton LVM.
Si tu n’es pas en UEFI, GRUB s’installe dans un espace entre le MBR et la première partition (ou un truc du genre).

#5

OK … voilà le détail que je n’avais pas su voir lorsque je me suis documenté sur LVM .

note : ce portable un peu ancien avait les 2 modes d’amorçage disponibles : bios et uefi mais j’ai préféré forcer l’installation en mode uefi puisque le bios ne me sert plus à rien .

merci pour les réponses .

je vais continuer ma recherche d’un tutoriel détaillé à ce sujet car je n’ai pas su comment réaliser cette opération . Si quelqu’un a une bonne adresse , en ou fr , je suis preneur .

#6

Seulement dans le cas d’une table de partition au format DOS/MBR et quand cet espace est suffisant.
Une table de partition GPT occupe cet espace, dans ce cas GRUB peut s’installer dans une partition de type « BIOS boot » dédiée à cet usage.

Et l’UEFI, que t’apporte-t-il de plus que le BIOS ?

#7

rien je suppose mais comme j’ai pris l’habitude des installations avec EFI je m’en tiens là . Quand on ne maîtrise pas un sujet mieux vaut éviter la dispersion .

#8

en fait dans tous les cas, il te faut une partition exterieure au LVm car effectivement le lanceur de GRUB n’est pas capable de la faire si c’est sur le LVM.
C’est d’ailleurs ce qui rend impossible le chiffrage complet d’un disque en LVM over LUKS.
Car la partition Boot devra rester non chiffrée (en fait du fait de Argon2 au lieu de PKDF2)

#9

Tient donc ? ne pas confondre une partion pour l’efi boot et la partition boot.

GRUB_PRELOAD_MODULES="lvm"

C’est encore autre chose, il n’est pas question ici de chiffrer des partitions.

#10

Et comment tu mets ça dans l’installer?
Ou bien tu le fait après une fois installé et tu déplaces le répertoire?
car actuellement, après quelques 100aines de tests, je n’ai jamais réussi à avoir un système en LVM avec le /boot sur LVM directement à l’installation.

#11

Non, pas dans tous les cas. Pour l’amorçage EFI bien sûr il faut une partition système EFI en dehors de LVM. Pour l’amorçage BIOS sur GPT avec GRUB dans le MBR et /boot dans LVM il faut une partition BIOS boot. Mais pour l’amorçage BIOS sur DOS/MBR, pas besoin de partition supplémentaire si l’espace après le MBR est suffisant (généralement 1 Mo donc largement suffisant).

Non, rien à voir. Ce qui rend impossible le chiffrement complet (j’ai bien dit complet), c’est l’incapacité du firmware à prendre en charge le format LUKS. Mais je me suis laissé dire que certains firmwares libres du genre libreboot ou coreboot pouvaient le prendre en charge.

Je vais essayer de préciser un peu (corrigez-moi si je me trompe).

  • Depuis buster, cryptsetup supporte un nouveau format LUKS2 et c’est le format par défaut.
  • L’installateur Debian ne permet pas de choisir le format et utilise le format par défaut (donc LUKS2).
  • Les versions de GRUB antérieures à 2.06 (incluant la version 2.04 de bullseye) ne supportent que le format LUKS1.
  • Le format LUKS2 supporte un nouvel algorithme de dérivation de clé Argon2 et cryptsetup utilise cet algorithme par défaut avec LUKS2.
  • GRUB 2.06 qui est inclus dans bookworm (actuelle testing) supporte le format LUKS2 mais pas l’algorithme Argon2 car la bibliothèque de chiffrement qu’il utilise ne le prend pas en charge, et les développeurs de GRUB on choisi de ne pas l’implémenter directement dans le code de GRUB. Néanmoins il est possible de convertir ou ajouter une passphrase au format traditionnel PBKDF2 supporté par GRUB.
  • L’installateur Debian n’a jamais pris en charge le chiffrement de /boot. Il existe diverses méthode pour le réaliser, soit pendant soit après l’installation, qui doivent être mises à jour en fonction des changements intervenus dans les différentes versions de Debian. Un exemple : Full disk encryption, including /boot: Unlocking LUKS devices from GRUB

Ce serait plus facile de ne pas confondre si « partition boot » était moin ambigu.
Si tu parles de la partition /boot (montée sur /boot), alors il faut savoir que contrairement à GRUB qui s’attend à ce que la partition EFI soit montée sur /boot/efi, d’autres chargeurs d’amorçage comme systemd-boot s’attendent plutôt à ce que la partition EFI soit montée sur /boot.

Ce n’est normalement pas utile. grub-mkimage (invoqué par grub-install) est censé détecter et inclure dans la core image les modules nécessaires pour lire /boot/grub. Quant à la core image de GRUB EFI signée pour le secure boot qui est installée par défaut pour l’amorçage EFI, comme elle n’est pas modifiable et ne peut pas charger de modules supplémentaires, elle inclut déjà un grand nombre de modules en dur donc ce paramètre est sans objet.

Pourtant j’ai déjà fait plusieurs installations de Debian (les deux dernières avec bullseye) avec /boot inclus dans la racine en LVM non chiffré sans difficulté ni rien faire de particulier, juste choisir le partitionnement manuel comme toujours.

2 J'aime
#12

Après quelques recherches en effet un patch est en approche pour la pleine prise en compte de Argon2, mais pas de traces pour l’instant d’un rétroportage ou d’une apprition de la 2.11 dans SID … donc wait and see

Among the features being talked about for GRUB 2.11 are Argon2 support for LUKS2, OSProber support for LUKS2, and other (U)EFI related enhancements. As always, as any interesting changes hit GRUB Git we’ll be sure to call them out on Phoronix.