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

Support Debian
#1

Bonjour à tous,

Voilà je suis entrain de tester sous Virtualbox l’installation d’une distribution Debian sur un disque entièrement chiffré et formaté en btrfs…

N’ayant pas trouvé de tuto complet et spécifique à Debian, je me suis servi d’autres tutos trouvés ici et là, notamment pour Arch et Fedora, que j’ai adapté à Debian sur quelques détails. Jusque là tout va bien, et apparemment il n’est pas nécessaire non plus d’avoir une partition /boot séparée et non chiffrée lorsqu’on passe par BIOS et non UEFI, ce qui est mon cas…

J’ai donc lancé une installation dans une machine virtuelle en mode graphique expert, jusqu’au partitionnement des disques, puis je suis passé en console pour créer un partitionnement msdos avec deux conteneurs chiffrés LUKS : un pour le système racine, un pour le swap.
J’ai ensuite formaté le système racine au format btrfs, crée les sous-volumes, attribué les lignes qui conviennent au fstab de la future installation, et monté le tout dans /target comme il se doit…

Puis je suis revenu au mode graphique pour terminer l’installation, tout s’est bien déroulé jusqu’à l’installation de GRUB qui a échoué. J’ai donc du revenir dans le mode console de l’installateur, et faire un chroot dans /target pour installer GRUB sur /dev/sda à la main.

Seulement voilà quand l’installation est bien achevée et que je redémarre la machine virtuelle, j’ai une invite au début qui me demande d’entrer un mot de passe pour déchiffrer les conteneurs, puis je tombe sur GRUB qui trouve bien le noyau installé, mais après ecran noir et au bout de quelques secondes un shell s’affiche en disant que la partition contenant le système de fichiers racine “/dev/mapper/sda1_crypt” n’existe pas et je retombe sur une invite commençant par (initramfs)…

Quelqu’un a une idée?

#2

Personnellement, je pense que tu aurais dû laisser /boot en clair et à part … ext2 est largement suffisant, même si tu peux faire du 3, 4 …
Grub a besoin de lire facilement sur /boot …

Le reste, je laisse à d’autres te répondre … mon exp est trop minime sur ce coup.

PS : STP, après fait un tuto Debian :wink:

#3

Justement c’est à titre expérimental :wink:
Je ne comprends pas ce qui pose le souci car en fait comme je l’ai dit GRUB trouve le noyau à lancer, ce qui pose problème c’est le chargement de la partition mappée après l’ouverture du conteneur… en l’occurence :

  • /dev/mapper/sda1_crypt
  • /dev/mapper/sda2_crypt

Pour être plus précis, quand je tombe sur l’invite shell, dans je ne peux passer que très peu de commandes dont “ls” , et en lisant sur /dev il n’y a que sda, sda1 et sda2 comme si les conteneurs n’avaient pas été déchiffrés…
D’ailleurs il n’y a que très peu de dossiers également par rapport à ceux que l’on voit haibutellement à la racine, alors je suis incapable de déterminer s’ils correspondent à la racine ou à autre chose qui viendrait se charger en amont au démarrage avant le montage de la racine, mais je suppose que oui sinon je n’aurai pas le problème et mon système démarrerait…

Et pour l’histoire du /boot séparé, normalement (d’après les tutos que j’ai trouvés), GRUB est capable maintenant de gérer des systèmes entièrement chiffrés (/boot inclus), il suffit d’ajouter les bonnes lignes dans /etc/default/grub et faire un update-grub entre autres.

Pour le tuto, c’est bien mon intention, ça servira sans doute grandement à tous ceux qui comme moi souhaitent transiter vers BTRFS avec éventuellement un système chiffré sans forcément avoir une surcouche LVM. :wink:

#4

La racine que tu vois est celle de l’initramfs (système de fichiers racine initial en mémoire) contenu dans un fichier /boot/initrd* qui a pour rôle de réaliser les opérations nécessaires au montage de la “vraie” racine que le noyau ne fait plus lui-même (ou n’a jamais pu faire) : détection des périphériques, chargement des modules correspondants, assemblage des ensembles RAID, activation des volumes logiques LVM, ouverture des volumes chiffrés…

Comme tu n’as pas créé les volumes chiffrés avec l’interface normale de l’installateur, il se pourrait que les paquets cryptsetup* n’aient pas été installés ou inclus dans l’initramfs.

Tu peux relancer l’installateur en mode dépannage pour accéder à la racine et vérifier.

#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.