Deb i386 (/boot chiffré) sur disque usb: problème avec l'install de GRUB

Support Debian
#1

Bonsoir.

Je viens d’installer sur un disque externe une Debian pour un système nomade.
J’ai installé une version i386 depuis un ordi amd64.
L’installation a 4 partition type LVM et chiffrée:
la racine /
le /home
la partition d’échange swap
et une partition /boot

a la fin de l’installation, GRUB ne s’installe pas. Normale…
je retourne en console avec un Ctrl F2 pour exécuter:
echo "GRUB_ENABLE_CRYPTODISK=y >>/target/etc/default/grub

Mais le problème est au niveau du choix par l’installateur du type d’architecture pour GRUB que je pense que ça foire.
Après ré-essais de l’installation de ce dernier… l’écran rouge m’affiche que « grub-efi-amd64 » n’a pu être installé.

Ne me faut-il pas « grub-efi » propre a une architecture 32bits?

Que dois je faire? Comment booter mon système par installer dans le /boot le bon GRUB.

Puis je depuis mon ordinateur hôte (amd64) monter la partition de boot de mon disuqye externe ou il y vient d’avoir l’install en question. Y installer GRUB2 … Editer une config qui devrait être pris en compte …
ou un truc du style

J’ai trouvé cette commande sur le web … mais est-elle bien appropriée …? :
# grub-install --target=i386-efi --efi-directory=/boot/efi --removable --boot-directory=/boot/efi/EFI --bootloader-id=grub /dev/sdX
que j’appliquerais donc de l’ordi amd64 …

merci
… a ++ …

#2

Tu veux dire 4 volumes logiques ?

Si /boot est dans LVM alors je ne vois pas l’intérêt de le mettre dans un volume logique séparé de la racine.

Ça dépend sur quoi tu veux pouvoir booter. Si c’est sur un PC avec firmware UEFI 64 bits (le plus courant), alors il faut bien grub-efi-amd64. Si c’est sur un PC avec firmware UEFI 32 bits (beaucoup plus rare) alors il faut grub-efi-ia32. Et il faudra l’installer dans le « chemin de support amovible » (option disponible en baissant la priorité des questions de debconf à « low » ou en mode expert) pour pouvoir booter sur un autre PC que celui ayant servi à l’installation. Et bien entendu il faut une partition de type « système EFI » hors de LVM.
Si tu veux booter en mode BIOS/legacy, c’est grub-pc qu’il faut installer (avec une partition de type « BIOS boot »).

#3

Si c’est une machine UEFI, il te faut une partition /boot/efi extérieure à LVM (boot peut lui s’y trouver).
si c’est une machine legacy alors /boot doit etre externe à LVM.

#4

Non, pas plus qu’en UEFI. Le mode d’amorçage n’impose pas de contrainte particulière sur la position de /boot.
Tu ne confondrais pas avec la partition « BIOS boot » nécessaire dans le cas d’un partitionnement GPT ?

#5

Bien (bonjour) …
Merci puis, vais tenter de répondre aux questions mais je pense que la terminologie, effetivement, pour m’exprimer n’est pas au point. Veuillez d’avance m’en excuser.

Lors de l’installation, j’ai créer un container luks dans un premier temps (je pense… ou déjà les définitions me font défaut ?) en tout cas une partition destiné au chiffrage (de 100Go sur les 256 du disque).
Pour acceuillir les quatre « partitions » (?) :
/boot; /, swap et /home.

Ma machine hôte est effectivement en UEFI.
Mais mon disque est destiné à être utiliser sur quelques autres ordinateurs que je peux définir (ce sont les miens mais pourquoi pas voir plus garnd) : old mac mini 2012, old ordi a mon sens EFI mais je dois encore le réparer pour le certifié. Y a ce UEFI asus E200H… puis un dernier HP, un truc aussi ancien … A oui, j’ai récupéré aussi un Optiplex (?? heu - je l’ai pas sous les yeux, mais c’est vraiment un « vieux bazar »). Tout ça pour dire qu’une solution la plus « général » me serrait bien sûr la plus adapté. (Générale : qui pourrait s’adapter au mieux, à multiple situations de démarage).

  • oui, je pense bien que c’est ainsi que j’aurais du m’exprimer.

Moui … j’avoue … J’y avais pas pensé … j’ai suivit les indications du site web cité dans mon premier message, plus précissement:
Installateur Debian - Chiffrage partitions racine, home et boot par la méthode lvm chiffré
jusque là, je m’étais pas posé la question de pourquoi …

ok … mais la Debian installé a une architecture i386 (qui me permettrais d’être aussi utilisé avec un ordi hôte qui serait amd64… en réalité, i386, d’après ce que je pensais, pourrait être plus adapté à un système nomade en usb … et que donc vu que l’hôte serrait possiblement avec une architecture 32bit … tout ce qui appartenait au 64 était exclus - j’ai l’impression donc de me tromper – juste que j’essayais de m’adapter à un max de possibilités et que le 32bit pouvant être installé ou utilisé par une Arch. 64, c’était don une bonne idée – ?)

bon… merci. Je vais cependant tout de même un peu mieux/plus lire sur le sujet.
je vous empêche pas de répondre lol
mais j’avoue que je suis peut-être pas à même de bien porter ce fil de discution.
enfin, voilà c’est fait… je vous tiens au jus

#6

Il y a eu des Mac Intel avec firmware UEFI 32 bits.

Dans ce cas il faut prendre en charge les trois modes d’amorçage : BIOS, EFI 32 bits te EFI 64 bits. En théorie, c’est simple :

  • on partitionne le disque en GPT ou MSDOS

  • si GPT, on crée une un partition de type « BIOS boot » (bios_grub) non formatée non montée

  • on crée une partition de type « système EFI » formatée en FAT montée sur /boot/efi

  • puis on installe les trois variantes de GRUB :

    apt-get install grub-pc-bin grub-efi-amd64-bin grub-efi-ia32-bin
grub-install --target=i386-pc /dev/sdX # remplacer "sdX" par le périphérique du disque USB
grub-install --target=x86_64-efi --no-nvram --force-extra-removable
grub-install --target=i386-efi --no-nvram --force-extra-removable

Mais en pratique ça peut se compliquer à cause des contraintes imposées par les différents BIOS et firmwares UEFI, en violation des standards et parfois contradictoires. Exemples :

  1. Sur Dell Optiplex et divers HP : l’amorçage en mode BIOS n’est possible que si une entrée de partition du MBR (qui peut être celle de la partition de protection GPT) a l’attribut « boot » (pmbr_boot dans parted).
  2. Sur certains HP : à l’inverse l’amorçage en mode EFI n’est pas possible si l’entrée de l’entrée de la partition de protection GPT du MBR a l’attribut « boot » (« partition active »).
  3. Il paraît que l’amorçage EFI avec certains firmwares ne fonctionnerait qu’avec le format GPT, mais je n’ai jamais été confronté à cette limitation.

Solutions pour concilier les deux exigences 1 et 2 :

  • Partitionner le disque au format MSDOS (mais incompatible avec l’exigence 3 et non adapté aux disques de plus de 2 Tio)
  • Activer l’attribut « boot » dans une autre entrée de la table de partition du MBR protecteur (faisable avec sfdisk mais non conforme au standard GPT et effacé par les éditeurs de table de partition)

L’intérêt principal d’un système de fichiers /boot séparé de la racine est lorsque le système de fichiers racine n’est pas accessible par le chargeur d’amorçage pour diverses raisons. Si /boot et / sont dans le même volume physique LVM, cet argument ne tient pas.

Tu as vraiment encore des machines avec un processeur 32 bits ? Il faut remonter avant 2007 pour en trouver.

Le chargeur d’amorçage est un cas particulier dans le sens où c’est lui qui démarre le système au lieu d’être lancé par lui. Un chargeur UEFI 64 bits peut démarrer un noyau 32 bits et vice versa. Par contre l’architecture du chargeur doit correspondre avec celle du firmware UEFI.

1 J'aime
#7

Pour répondre à ta question

Cette commande contient plusieurs défauts montrant l’incompétence de son auteur.

  • /dev/sdx est ignoré avec --target=i386-efi
  • –bootloader-id est ignoré avec --removable
  • le chemin spécifié dans --efi-directory est déjà le chemin par défaut
  • le chemin spécifié dans --boot-directory n’a pas de sens car le répertoire /EFI de la partition système EFI est réservé à l’installation d’exécutables EFI, ce qui n’est pas le cas du contenu du chemin spécifié par --boot-directory. Si on veut que ce contenu soit dans la partition EFI (pour quelle raison ?), il aurait mieux valu spécifier /boot/efi et il faut y mettre en plus un fichier grub.cfg pour ouvrir le volume chiffré et charger le fichier /boot/grub/grub.cfg.
1 J'aime
#8

Possible en GPT legacy.
mais sinon, après plus d’un millier d’essai en deux ans, j’ai toujours du laisser /boot en dehors de LVm ou /boot/efi