Installation Debian/Btrfs/Luks et problème au redémarrage

Support Debian
#5

Alors en fait j’ai crée les volumes chiffrés avec l’interface graphique en passant l’écriture de zéros jusqu’à l’entrée des mots de passe. Ce n’est qu’une fois les partitions créees et chiffrées que j’ai délaissé l’installation graphique pour le shell, pour pouvoir créer mes sous-volumes et monter le tout convenablement dans target aux bons chemins et construire le fichier fstab pour les différents points de montage car l’installateur ne sait pas encore faire ça pour un système de fichiers btrfs. Et une fois fait, je reviens sur l’installateur graphique pour faire l’installation de base, la config des paquets et l’installation de GRUB…

Mais l’installation de GRUB échoue alors je retourne dans le shell pour l’installer à la main avec un chroot sur /target.

Normalement cryptsetup devrait être installé car sinon quel est le programme qui au tout début du démarrage me demande d’entrer le mdp pour déchiffrer le “master key…”?
Enfin je vais quand même aller vérifier et je reviens. :smiley:

#6

C’est GRUB, pour pouvoir charger ses fichiers complémentaires, puis le noyau et l’initramfs depuis un volume chiffré. Pour preuve, si j’ai bien compris ton message initial, cela se passe avant l’affichage du menu de GRUB.

Dans le shell de l’initramfs, tu peux vérifier si la commande cryptsetup est présente. Si oui, tu devrais pouvoir ouvrir les volumes chiffrés et poursuivre le démarrage.

#7

Bon en fait je ne suis pas sur le shell de l’initramfs actuellement mais sur celui de l’installateur Debian, et je suis repassé en chroot du système installé sur /target pour vérifier si cryptsetup était installé : effectivement il ne l’est pas :smiley:
Le hic maintenant c’est que je ne sais pour quelle raison “dpkg” se plaint de ne pas trouver <> dans la variable $PATH etc etc… :grimacing:

#8

Une fois dans le chroot as-tu monté tous les sous-volumes btrfs définis dans /etc/fstab ?

#9

absolument, je rentre dans le chroot et je fais un mount -a si c’est à ça que tu penses.

#10

Bon… Après environ 10 jours passés dessus, j’ai enfin réussi à monter mon système test en VM comme suit :

/dev/sda (table au format msdos ; 34.4GB)
     |
     |---- /dev/sda1  (conteneur LUKS chiffré)
     |          |
     |          |---- /dev/mapper/sda1_crypt  (partition swap ; 4.4GB)
     |  
     |
     |---- /dev/sda2  (conteneur LUKS chiffré)
                |
                |---- /dev/mapper/sda2_crypt  (partition btrfs ; 30GB)
                           |
                           |----  Debian (subvolume)
                                     |
                                     |---- Root (subvolume ; monté sur / dans fstab)
                                     |---- Home (subvolume ; monté sur /home dans fstab)
                                     |---- Usr  (subvolume ; monté sur /usr dans fstab)
                                     |---- Srv  (subvolume ; monté sur /srv dans fstab)
                                     |---- Var  (subvolume ; monté sur /var dans fstab)
                                     |---- Tmp  (subvolume ; monté sur /tmp dans fstab)

Non sans mal bien évidemment étant donné que l’installateur Debian ne fait pas encore ça nativement, il a fallu bidouiller entre l’installateur graphique en mode expert pour la 1ère partie, puis passer dans un shell pour construire l’arborescence des subvolumes, les fichiers fstab et crypttab, et monter le tout correctement sur /target, puis revenir à l’installation graphique pour installer le système…

Pour le problème de démarrage à cause du chiffrement de disque entier, il a fallu revenir sous l’installateur et faire un chroot pour installer quelques paquets comme cryptsetup et btrfs-tools qui ne se sont pas installés automatiquement, modifier le fichier “/etc/default/grub” ainsi que rajouter quelques modules relatifs à cryptsetup dans “/etc/modules” et “/etc/initramfs-tools/modules”, suivi d’un “update-initramfs” et “update-grub”.

J’ai essayé de monter le même partitionnement au sein d’un LVM over LUKS, ça fonctionne de la même manière mais en beaucoup plus simple étant donné que l’installateur prend en charge ces opération hormis l’arborescence des subvolumes pour lesquels il faut passer par un shell, mais bon pour ce mode opératoire il existe déjà un tuto sur le net.

Sans compter bien sûr les déboires que j’ai eu avec les iso qui fonctionnaient une fois sur deux… :smiley:

Voilà, je vais maintenant essayer de faire la même chose mais avec un partitionnement GPT même si je doute que ca passe dans le cas d’une partition EFI présente…
Puis je vais essayer de pondre un tuto pour ceux que ça pourrait intéresser éventuellement, avec captures d’écran et tout… même si je suis pas doué pour les tutos…

P.S. : en ce qui concerne la partition swap, je n’ai aucune idée si l’hibernation fonctionne car bien sûr impossible d’hiberner une VM, mais en tous cas déjà sur le système duquel j’écris l’hibernation ne fonctionne pas pour un système sur BTRFS même lorsque swap est sur une partition et non pas un fichier, alors en installation chiffrée il va peut être pas trop falloir y compter non plus… Par contre le swap fonctionne bien lorsque la RAM se remplit.

Pb GRUB, Multi-Boot et sous-volumes BTRFS
#11

Je ne vois pas pourquoi ça ne passerait pas, ni le rapport avec la présence d’une partition EFI.

#12

Eh bien apparemment il faut que la partition EFI reste non chiffrée sinon ça ne marche pas, et j’ai essayé d’installer une VM avec GPT mais le grub me plante pour l’instant avec le message :

“cette étiquette de partition GPT ne contient pas de partition d’amorçage BIOS”

Y’a t’il des dispositions particulières à prendre dans le partitionnement GPT?

#13

Evidemment la partition système EFI ne peut être chiffrée, puisqu’elle doit être lisible par le firmware UEFI, tout comme l’amorce du chargeur d’amorçage en mode BIOS.

Par contre sauf erreur de ma part le message de grub-install que tu cites n’est pas relatif à la partition système EFI (pour y installer la core image en mode EFI) mais à l’absence de partition “BIOS boot” (pour y installer la core image en mode BIOS). Cette partition est spécifique à l’amorçage BIOS sur un disque au format GPT. Donc visiblement tu as installé grub-pc pour un amorçage en mode BIOS.

Tu peux forcer l’installation de la core image de grub-pc dans /boot/grub/ en utilisant les listes de blocs avec l’option--force à condition que /boot/grub ne soit pas chiffré, mais c’est moins fiable et déconseillé par les développeurs de GRUB. Si possible il vaut mieux créer une partition de type “BIOS boot” (bios_grub dans la terminologie de parted) non formatée (son contenu est écrasé par l’installation de la core image). Il suffit d’un tout petit espace libre de 100 ko, par exemple entre la fin de la table de partition et le début de la première partition, et elle n’a pas besoin d’être alignée.

#14

En effet c’est ce que j’ai cru comprendre en cherchant les docs disponibles sur le net qui traitent ce cas.

En fait si j’ai bien compris la partition EFI sert à contenir le chemin /boot/efi de manière non-chiffrée dans le cas où tout le reste du disque est lui chiffré. Eventuellement lui attribuer le flag “esp”.
Par contre, et tu as raison, le message n’est pas en rapport avec cette partition. En fait grub-install me réclame une partition d’amorçage BIOS, avec le flag “bios_grub” dans la terminologie de parted, certainement pour charger l’amorce dans ce secteur dans le cas d’un boot BIOS.
Alors effectivement j’ai installé (du moins je suppose) grub-pc pour un amorçage en mode BIOS, étant donné que le système hote est en mode BIOS (où bien ça n’a rien à avoir, et ça peut être lié à l’activation de l’option UEFI dans la configuration de la machine virtuelle sous Vbox?).

/boot/grub est chiffré, le schéma de partitionnement que j’ai réemployé pour ce deuxième test est identique au premier, à la seule différence que j’y ai ajouté une partition EFI en premier non-chiffrée, mais je n’ai pas pensé à mettre une autre partition de qq Mo pour le Bios_boot étant donné qu’ils n’en parlaient pas dans les tutos…

J’ai essayé également de modifier le flag de la partition EFI quitte à la sacrifier, en bios_grub, mais ça ne marche pas. J’ai aussi essayé d’activer l’option UEFI dans la config de la VM, ça ne marche pas non plus (mais peut-être faut-il réinstaller grub-pc, je vais faire un essai).

Finalement si je comprends bien, contrairement à un partitionnement msdos où il n’y pas nécessité de prévoir une partition d’amorçage en début, pour un partitionnement GPT il faut avoir au moins une partition EFI en début si on chiffre tout le reste et s’il s’agit d’un disque qui n’est pas vierge (qui contenait déjà un autre système auparavant ou autre…).
Dans le cas d’un disque vierge qu’on vient d’acheter par exemple (ce qui est symboliquement le cas avec une création de VM), il faut en plus prévoir une 2è partition d’amorçage en tout début avec le flag bio_grub.

Corriges moi s’il y a des erreurs.

#15

Bon alors finalement j’ai réussi à dépatouiller cette VM, en remaniant la première partition que j’avais crée pour EFI de 1Go, en deux partitions avec Gparted en chroot :

  • 1ère partition de 33Mo (Gparted n’autorise pas une partition plus petite) pour le fameux Bios_boot
  • 2è partition avec le reste des 1Go initialement, pour la partition EFI

Ce qui fait donc :

  • sda1 33Mo Bios_boot
  • sda4 927Mo EFI
  • sda2 4.4 Go Swap (chiffrée LUKS)
  • sda3 100% Btrfs (chiffrée LUKS)

Après avoir réinstallé grub-pc et grub-common j’ai pu démarrer la VM avec partitionnement GPT tout comme la précédente qui était en MBR.

Maintenant la question suivante est de savoir si je peux transformer cette dernière à tout moment pour un démarrage en mode UEFI, c’est pour ça que j’ai laissé volontairement la partition EFI. Il me suffirait alors de repasser en chroot avec une iso Debian, et d’installer grub-efi à la place de grub-pc et d’activer UEFI dans la config de la VM.
Mais ça n’a pas marché lors de l’étape précédente.

Alors les trois question sont les suivantes :

  • est ce qu’une VM guest peut démarrer en UEFI alors que le système hote est en BIOS_legacy?
  • est ce qu’à l’installation de l’OS sur la VM celui-ci est lié dès le départ au fait que ce soit Bios_legacy ou UEFI?
  • où bien ça n’a tout simplement pas marché la 1ère fois car même en UEFI, il faut que la 1ère partition Bios_boot soit présente même si UEFI ne s’en sert pas?
#16

Tu n’as pas compris à quoi sert la partition système EFI. On reprend.

La partition système EFI n’a rien à voir avec le chiffrement. Elle sert à l’amorçage en mode (U)EFI et ne peut être chiffrée. Et son identifiant “esp” n’est pas optionnel, c’est à ça qu’on la reconnaît. Par contre le chargeur d’amorçage peut être signé si le firmware UEFI supporte le “secure boot” pour empêcher ou du moins détecter son altération. Avec l’amorçage en mode BIOS, la partition système EFI ne sert à rien.

Tu supposes ? Tu peux bien savoir si c’est grub-pc ou grub-efi-* qui est installé, non ? Activer l’UEFI dans le firmware ne signifie pas que l’amorçage se fera obligatoirement dans ce mode. Il faut en plus qu’il y ait un chargeur EFI, déclaré explicitement ou présent dans l’emplacement par défaut de la partition système EFI. A défaut, l’amorçage peut se faire en mode BIOS.

Pour l’amorçage en mode BIOS, si /boot/grub est chiffré, alors une partition BIOS boot (non chiffrée) est obligatoire pour y installer la core image de GRUB. Sinon la boot image de GRUB installée dans le secteur d’amorce sera incapable de charger la core image de GRUB depuis un emplacement chiffré.

Qu’est-ce qui ne marche pas ?

Non, aucun rapport entre GPT, EFI et chiffrement.

#17

Si en fait c’est exactement ce que j’ai compris et ce que je voulais dire mais je me suis mal exprimé.
Pour le reste tu n’as pas dû lire mon dernier message où je me suis “auto-répondu” en quelque sorte. J’ai cerné la différence entre BIOS_legacy et UEFI, et j’ai réussi à faire démarrer cette installation de Debain sur le disque virtuel GPT en mode BIOS_legacy.

Maintenant je voudrais le faire démarrer en mode UEFI, et donc pour ça j’ai activé l’option EFI dans la config système de la VM, je suis passé en chroot installateur pour désinstaller grub-pc et installer grub-efi à la place, fait un update-grub et grub-install, tout s’est déroulé comme il faut et au redémarrage je tombe sur le Shell EFI.
Pourtant quand je rentre dans les options de démarrage du BIOS EFI j’ai bien “Debian” qui est listé en 1er dans l’ordre de boot (bon disque, bonne partition, chemin \EFI\debian\x86_64-efi)…

Mais il ne veut pas le lancer… J’ai vérifié l’une de mes question précédentes sur le net, on peut démarrer une VM en UEFI sous VBOX sur un hote qui est en BIOS_legacy.
D’où viendrait le problème?

#18

Aucune idée. Jamais essayé. C’est de l’émulation, donc je suppose que oui.

Oui. Mais on peut le changer. J’ai quelques installations capables de booter indifféremment en mode EFI ou BIOS. Jusqu’à Wheezy il fallait bricoler mais depuis Jessie on peut installer simultanément plusieurs variantes de grub. Il est plus simple d’ajouter GRUB BIOS sur un système installé initialement en EFI que l’inverse.

Non. L’amorçage en mode EFI n’utilise pas la partition BIOS boot.

Oui. Une fois la partition système EFI montée sur /boot/efi, installer grub-efi-amd64 pour un firmware UEFI 64 bits ou grub-efi-ia32 pour un firmware UEFI 32 bits et demander d’installer le chargeur “dans le chemin de périphérique amovible” lors de la configuration du paquet, initiale ou avec dpkg-reconfigure. Ou bien, manuellement
grub-install --target=x86_64-efi --removable # si 64 bits
grub-install --target=i386-efi --removable # si 32 bits

#19

Oui voilà c’est exactement ce que je cherche à faire avec cette VM eu guise d’expérimentation on va dire… J’aurai du le dire tout de suite mais bon encore une fois je me suis mal exprimé ou pas assez…

Ca c’est exactement ce que j’ai fait, hormis le fait que je ne comprends pas pourquoi “–removable”?
je l’ai passé comme suit :

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck

#20

--removable installe le chargeur dans l’emplacement par défaut, qui n’a pas besoin d’être déclaré dans le firmware. C’est avec un chargeur à cet emplacement que les supports amovibles sont amorçables, d’où le nom.

Certains firmwares UEFI buggés sont parfois incapables d’amorcer un chargeur pourtant déclaré, alors qu’ils amorcent le chargeur par défaut.

#21

D’accord ça je comprends bien, mais dans mon esprit chargeur amovible fait référence à un support extérieur comme une clé USB ou autre sur laquelle on installerait GRUB…
Serait-ce le cas également lorsqu’on l’installe sur une partition autre que celle contenant le système de fichiers racine comme ici sur la partition EFI?

Je vais essayer comme tu l’as cité en ligne de commande de réinstaller grub.

#22

Ben ouais, l’appellation n’est pas très explicite et n’est en rien spécifique aux supports amovibles. Moi-même je n’ai pas compris sa signification la première fois que l’installateur m’a posé la question. Je trouverais plus clair que ça s’appelle “l’emplacement du chargeur par défaut”, mais c’est comme ça.

Je ne comprends pas cette question.
Le cas de quoi ? Lorsqu’on installe quoi hors de la racine ?

#23

Tu m’as répondu dans la 1ère réponse en fait, sur la compréhension de l’expression “support amovible”.
Lorsqu’on installe GRUB sur une partition qui n’est pas celle qui contient le système de fichiers racine, en l’occurence ici la partition EFI.

#24

La question n’a pas de sens et je ne comprends pas où tu veux en venir. Le chargeur (core image) de GRUB EFI doit être installé dans une partition système EFI. Cette partition ne peut être la racine et vice versa, donc la core image de GRUB EFI ne peut pas être installée dans la racine. Si tu fais référence à /boot/grub, qui ne contient pas la core image, ça peut être n’importe où.