J'ai un nouveau pc (occasion, mais garanti) avec efi, pour des
questions de sav je garde la partition windows (que j'ai déjÍ réduite a
son minimum)
J'installe bullseye depuis une clef usb (en mode graphique), tout ce
passe bien jusqu’Í l'installation de grub.
(de mémoire)
grub-install: error: embedding is not possible, but this is required
for RAID and LVM install.
Pour info (de mémoire)
gpt1,1 => vfat boot
gpt1,2 => truc windows ("partition réservé")
gpt1,3 => truc windows (l'os ?)
gpt1,4 => truc windows (recovery ?)
gpt1,5 => ma debian (avec le /boot) : luks, lvm2
Du coup reboot, j'ajoute depuis le bios, des entrées efi
* debian avec grubx64
* debian avec bootx64
(j'ai vu cela au hasard de mes recherches, c'est ptet pas hyper
cohérent...)
je reboot ma clef usb en Rescue mode : cela me détecte bien ma
partition chiffrée (il me demande bien la passphrase)
je monte en bind dev dev/pts proc sys run sur le chroot de mon install
Dans mon chroot
je monte /dev/mapper/vol1{home|tmp|var} dans /{home|tmp|var}
j'ajoute dans /etc/default/grub/grub.d/toto.cfg
GRUB_ENABLE_CRYPTODISK=y
GRUB_PRELOAD_MODULES="cryptodisk luks lvm"
après quelques centaines de lignes (stroboscopiques)
ça se termine par du truc du genre
copying /boot/grub/x86_64-efi/load.cfg -> /boot/efi/EFI/BOOTgrub.cfg
"installation finished. No error reported"
Je reboot (je test mes 2 entrées debian) sans succès, j'arrive direct
sur
grub>
j'ai tenté insmod cryptodisk , lvm
et je ne sais plus quoi pour "monter" mon cryptodisk
==> pas de demande de passphrase
############# c'est a ce moment que je sèche ###########
Note : dans le chroot : systemctl start ssh , ne fonctionne pas (a
priori ce truc n'aime pas le chroot), avec /etc/init.d/openssh-server
start , lance quelques chose, mais je trouve pas les logs pour voir ce
qui deconne pour me connecter
Le 23/10/2022 Í 14:34, Étienne Mollier a écrit : [...]
(Note : je n'ai pas vérifié si grub 2.06 disponible depuis peu dans bullseye permet de démarrer sur des conteneurs luks avec en-tête en version 2 ; ça peut peut-être marcher tout en étant potentiellement un peu vert.)
[...] je n'ai pas vérifié non plus mais par contre j'ai regardé deux installations virtualisées récentes de Fedora 36 et Opensuse Tumbleweed que j'ai faites (Fedora c'est toujours des trucs récents et Tumblewwed c'est la branche rolling release d'Opensuse): dans les deux cas c'est de l'installation standard non-bricolée et chiffrée, dans les deux cas c'est du grub 2.06, pour Fedora c'est du chiffrage LUKS2 mais /boot non-chiffré, pour Opensuse c'est du LUKS2 sauf pour /boot en LUKS1. A priori le problème serait toujours d'actualité et résiderait plus précisément dans grub-install mais une bonne Í¢me aurait trouvé un contournement: https://github.com/dmoulding/grub-luks2-install
Le 23/10/2022 Í 14:34, Étienne Mollier a écrit :
[...]
(Note : je n'ai pas vérifié si grub 2.06 disponible depuis peu
dans bullseye permet de démarrer sur des conteneurs luks avec
en-tête en version 2Â ; ça peut peut-être marcher tout en étant
potentiellement un peu vert.)
[...]
je n'ai pas vérifié non plus mais par contre j'ai regardé deux
installations virtualisées récentes de Fedora 36 et Opensuse Tumbleweed
que j'ai faites (Fedora c'est toujours des trucs récents et Tumblewwed
c'est la branche rolling release d'Opensuse): dans les deux cas c'est de
l'installation standard non-bricolée et chiffrée, dans les deux cas
c'est du grub 2.06, pour Fedora c'est du chiffrage LUKS2 mais /boot
non-chiffré, pour Opensuse c'est du LUKS2 sauf pour /boot en LUKS1.
A priori le problème serait toujours d'actualité et résiderait plus
précisément dans grub-install mais une bonne Í¢me aurait trouvé un
contournement:
https://github.com/dmoulding/grub-luks2-install
Le 23/10/2022 Í 14:34, Étienne Mollier a écrit : [...]
(Note : je n'ai pas vérifié si grub 2.06 disponible depuis peu dans bullseye permet de démarrer sur des conteneurs luks avec en-tête en version 2 ; ça peut peut-être marcher tout en étant potentiellement un peu vert.)
[...] je n'ai pas vérifié non plus mais par contre j'ai regardé deux installations virtualisées récentes de Fedora 36 et Opensuse Tumbleweed que j'ai faites (Fedora c'est toujours des trucs récents et Tumblewwed c'est la branche rolling release d'Opensuse): dans les deux cas c'est de l'installation standard non-bricolée et chiffrée, dans les deux cas c'est du grub 2.06, pour Fedora c'est du chiffrage LUKS2 mais /boot non-chiffré, pour Opensuse c'est du LUKS2 sauf pour /boot en LUKS1. A priori le problème serait toujours d'actualité et résiderait plus précisément dans grub-install mais une bonne Í¢me aurait trouvé un contournement: https://github.com/dmoulding/grub-luks2-install
k6dedijon
Bonjour, J'ai eu aussi beaucoup de difficultés installer Linux en UEFI. Il m'a été difficile de comprendre comment fonctionnait l'UEFI. Certains sites expliquent qu'il faut un espace vierge non formaté tout de suite après la table de partition GPT. (Les tailles varient) D'autres sites ne parlent pas de cet espace et annoncent de faire une partition EFI en Fat16 ou 32 avec l'étiquette ESP. LÍ aussi les tailles varient. Après avoir vu sur ubuntu.fr qu'ils conseillaient 100 Mo et que leur installateur ne fonctionne pas avec cela et qu'il demande 300 Mo, je me suis fait ma sauce. Actuellement, j'installe mes postes de travail avec : - 512 Mo d'espace libre non formaté - 512 Mo de partition EFI formaté en fat32 avec l'étiquette ESP et le drapeau boot - 768 Mo pour la partition Boot en ext4 avec les dapeaux boot et boot-grub Pour le reste comme vous avez l'habitude Cela fonctionne avec Debian, Kubuntu, Unbuntu studio et Manjaro Een espérant vous être utile. Bon courage Cassis ----- Mail d'origine ----- De: À: Envoyé: Sun, 23 Oct 2022 11:57:35 +0200 (CEST) Objet: bullseye : install grub install en echec Hello, J'ai un nouveau pc (occasion, mais garanti) avec efi, pour des questions de sav je garde la partition windows (que j'ai déjÍ réduite a son minimum) J'installe bullseye depuis une clef usb (en mode graphique), tout ce passe bien jusqu’Í l'installation de grub. (de mémoire) grub-install: error: embedding is not possible, but this is required for RAID and LVM install. Pour info (de mémoire) gpt1,1 => vfat boot gpt1,2 => truc windows ("partition réservé") gpt1,3 => truc windows (l'os ?) gpt1,4 => truc windows (recovery ?) gpt1,5 => ma debian (avec le /boot) : luks, lvm2 Du coup reboot, j'ajoute depuis le bios, des entrées efi * debian avec grubx64 * debian avec bootx64 (j'ai vu cela au hasard de mes recherches, c'est ptet pas hyper cohérent...) je reboot ma clef usb en Rescue mode : cela me détecte bien ma partition chiffrée (il me demande bien la passphrase) je monte en bind dev dev/pts proc sys run sur le chroot de mon install Dans mon chroot je monte /dev/mapper/vol1{home|tmp|var} dans /{home|tmp|var} j'ajoute dans /etc/default/grub/grub.d/toto.cfg GRUB_ENABLE_CRYPTODISK=y GRUB_PRELOAD_MODULES="cryptodisk luks lvm" grub-install --verbose --removable --efi-directory=/boot/efi --bootloader-id=BOOT1 --target=x86_64-efi /dev/sda après quelques centaines de lignes (stroboscopiques) ça se termine par du truc du genre copying /boot/grub/x86_64-efi/load.cfg -> /boot/efi/EFI/BOOTgrub.cfg "installation finished. No error reported" Je reboot (je test mes 2 entrées debian) sans succès, j'arrive direct sur grub> j'ai tenté insmod cryptodisk , lvm et je ne sais plus quoi pour "monter" mon cryptodisk ==> pas de demande de passphrase ############# c'est a ce moment que je sèche ########### Note : dans le chroot : systemctl start ssh , ne fonctionne pas (a priori ce truc n'aime pas le chroot), avec /etc/init.d/openssh-server start , lance quelques chose, mais je trouve pas les logs pour voir ce qui deconne pour me connecter
Bonjour,
J'ai eu aussi beaucoup de difficultés installer Linux en UEFI.
Il m'a été difficile de comprendre comment fonctionnait l'UEFI.
Certains sites expliquent qu'il faut un espace vierge non formaté tout de suite après la table de partition GPT. (Les tailles varient)
D'autres sites ne parlent pas de cet espace et annoncent de faire une partition EFI en Fat16 ou 32 avec l'étiquette ESP. LÍ aussi les tailles varient.
Après avoir vu sur ubuntu.fr qu'ils conseillaient 100 Mo et que leur installateur ne fonctionne pas avec cela et qu'il demande 300 Mo, je me suis fait ma sauce.
Actuellement, j'installe mes postes de travail avec :
- 512 Mo d'espace libre non formaté
- 512 Mo de partition EFI formaté en fat32 avec l'étiquette ESP et le drapeau boot
- 768 Mo pour la partition Boot en ext4 avec les dapeaux boot et boot-grub
Pour le reste comme vous avez l'habitude
Cela fonctionne avec Debian, Kubuntu, Unbuntu studio et Manjaro
Een espérant vous être utile.
Bon courage
Cassis
----- Mail d'origine -----
De: debian-user-french@lists.debian.org
À: debian-user-french@lists.debian.org
Envoyé: Sun, 23 Oct 2022 11:57:35 +0200 (CEST)
Objet: bullseye : install grub install en echec
Hello,
J'ai un nouveau pc (occasion, mais garanti) avec efi, pour des
questions de sav je garde la partition windows (que j'ai déjÍ réduite a
son minimum)
J'installe bullseye depuis une clef usb (en mode graphique), tout ce
passe bien jusqu’Í l'installation de grub.
(de mémoire)
grub-install: error: embedding is not possible, but this is required
for RAID and LVM install.
Pour info (de mémoire)
gpt1,1 => vfat boot
gpt1,2 => truc windows ("partition réservé")
gpt1,3 => truc windows (l'os ?)
gpt1,4 => truc windows (recovery ?)
gpt1,5 => ma debian (avec le /boot) : luks, lvm2
Du coup reboot, j'ajoute depuis le bios, des entrées efi
* debian avec grubx64
* debian avec bootx64
(j'ai vu cela au hasard de mes recherches, c'est ptet pas hyper
cohérent...)
je reboot ma clef usb en Rescue mode : cela me détecte bien ma
partition chiffrée (il me demande bien la passphrase)
je monte en bind dev dev/pts proc sys run sur le chroot de mon install
Dans mon chroot
je monte /dev/mapper/vol1{home|tmp|var} dans /{home|tmp|var}
j'ajoute dans /etc/default/grub/grub.d/toto.cfg
GRUB_ENABLE_CRYPTODISK=y
GRUB_PRELOAD_MODULES="cryptodisk luks lvm"
après quelques centaines de lignes (stroboscopiques)
ça se termine par du truc du genre
copying /boot/grub/x86_64-efi/load.cfg -> /boot/efi/EFI/BOOTgrub.cfg
"installation finished. No error reported"
Je reboot (je test mes 2 entrées debian) sans succès, j'arrive direct
sur
grub>
j'ai tenté insmod cryptodisk , lvm
et je ne sais plus quoi pour "monter" mon cryptodisk
==> pas de demande de passphrase
############# c'est a ce moment que je sèche ###########
Note : dans le chroot : systemctl start ssh , ne fonctionne pas (a
priori ce truc n'aime pas le chroot), avec /etc/init.d/openssh-server
start , lance quelques chose, mais je trouve pas les logs pour voir ce
qui deconne pour me connecter
Bonjour, J'ai eu aussi beaucoup de difficultés installer Linux en UEFI. Il m'a été difficile de comprendre comment fonctionnait l'UEFI. Certains sites expliquent qu'il faut un espace vierge non formaté tout de suite après la table de partition GPT. (Les tailles varient) D'autres sites ne parlent pas de cet espace et annoncent de faire une partition EFI en Fat16 ou 32 avec l'étiquette ESP. LÍ aussi les tailles varient. Après avoir vu sur ubuntu.fr qu'ils conseillaient 100 Mo et que leur installateur ne fonctionne pas avec cela et qu'il demande 300 Mo, je me suis fait ma sauce. Actuellement, j'installe mes postes de travail avec : - 512 Mo d'espace libre non formaté - 512 Mo de partition EFI formaté en fat32 avec l'étiquette ESP et le drapeau boot - 768 Mo pour la partition Boot en ext4 avec les dapeaux boot et boot-grub Pour le reste comme vous avez l'habitude Cela fonctionne avec Debian, Kubuntu, Unbuntu studio et Manjaro Een espérant vous être utile. Bon courage Cassis ----- Mail d'origine ----- De: À: Envoyé: Sun, 23 Oct 2022 11:57:35 +0200 (CEST) Objet: bullseye : install grub install en echec Hello, J'ai un nouveau pc (occasion, mais garanti) avec efi, pour des questions de sav je garde la partition windows (que j'ai déjÍ réduite a son minimum) J'installe bullseye depuis une clef usb (en mode graphique), tout ce passe bien jusqu’Í l'installation de grub. (de mémoire) grub-install: error: embedding is not possible, but this is required for RAID and LVM install. Pour info (de mémoire) gpt1,1 => vfat boot gpt1,2 => truc windows ("partition réservé") gpt1,3 => truc windows (l'os ?) gpt1,4 => truc windows (recovery ?) gpt1,5 => ma debian (avec le /boot) : luks, lvm2 Du coup reboot, j'ajoute depuis le bios, des entrées efi * debian avec grubx64 * debian avec bootx64 (j'ai vu cela au hasard de mes recherches, c'est ptet pas hyper cohérent...) je reboot ma clef usb en Rescue mode : cela me détecte bien ma partition chiffrée (il me demande bien la passphrase) je monte en bind dev dev/pts proc sys run sur le chroot de mon install Dans mon chroot je monte /dev/mapper/vol1{home|tmp|var} dans /{home|tmp|var} j'ajoute dans /etc/default/grub/grub.d/toto.cfg GRUB_ENABLE_CRYPTODISK=y GRUB_PRELOAD_MODULES="cryptodisk luks lvm" grub-install --verbose --removable --efi-directory=/boot/efi --bootloader-id=BOOT1 --target=x86_64-efi /dev/sda après quelques centaines de lignes (stroboscopiques) ça se termine par du truc du genre copying /boot/grub/x86_64-efi/load.cfg -> /boot/efi/EFI/BOOTgrub.cfg "installation finished. No error reported" Je reboot (je test mes 2 entrées debian) sans succès, j'arrive direct sur grub> j'ai tenté insmod cryptodisk , lvm et je ne sais plus quoi pour "monter" mon cryptodisk ==> pas de demande de passphrase ############# c'est a ce moment que je sèche ########### Note : dans le chroot : systemctl start ssh , ne fonctionne pas (a priori ce truc n'aime pas le chroot), avec /etc/init.d/openssh-server start , lance quelques chose, mais je trouve pas les logs pour voir ce qui deconne pour me connecter
