J'ai un probl=C3=A8me avec grub2, que je ne parviens pas =C3=A0 r=C3=A9soud=
re. Il est=20
question de Bios, EFI, GPT.
La situation actuelle :
Sur un PC (portable) sur lequel est install=C3=A9 Windows (que je souhaite=
=20
gard=C3=A9) a =C3=A9t=C3=A9 install=C3=A9 ubuntu (que je voudrais virer).
A partir de cet ubuntu, j'ai install=C3=A9 Gentoo (que je veux conserver).
Pour booter sous Windows, il faut passer en le bios au boot, et mettre le=
=20
boot en mode "EFI". L=C3=A0, windows d=C3=A9marre directement, sans aucun c=
hoix.
Pour booter sous Linux (ubuntu ou gentoo), il faut, dans le bios,=20
s=C3=A9lectionner "Legacy", et l=C3=A0, j'ai acc=C3=A8s au grub configur=C3=
=A9 par le biais=20
de Ubuntu.
Certes, j'aurais pr=C3=A9f=C3=A9r=C3=A9 pouvoir =C3=A9viter de passer par l=
a s=C3=A9lection du=20
mode dans le Bios, mais ce n'est pas non plus dramatique si =C3=A7a reste=
=20
comme =C3=A7a.
Ubuntu est install=C3=A9e avec /boot non s=C3=A9par=C3=A9e.
Pour l'instant, =C3=A0 chaque modif d'une option de boot, ou de noyau, je d=
ois=20
chrooter dans ubuntu, y faire mes modifs et mon grub-mkconfig.
C'est lourd.
Et je ne parviens =C3=A0 rien avec grub dans Gentoo (et tout mon probl=C3=
=A8me est=20
l=C3=A0).
# fdisk -l /dev/sda
Disque /dev/sda=C2=A0: 698,65 GiB, 750156374016=C2=A0octets, 1465149168=C2=
=A0secteurs
Mod=C3=A8le de disque=C2=A0: Hitachi HTS54757
Unit=C3=A9s=C2=A0: secteur de 1 =C3=97 512 =3D 512=C2=A0octets
Taille de secteur (logique / physique)=C2=A0: 512=C2=A0octets / 512=C2=A0oc=
tets
taille d'E/S (minimale / optimale)=C2=A0: 512=C2=A0octets / 512=C2=A0octets
Type d'=C3=A9tiquette de disque=C2=A0: gpt
Identifiant de disque=C2=A0: 705E99A4-620B-4C25-9D82-70A618FD6AEB
P=C3=A9riph=C3=A9rique D=C3=A9but Fin Secteurs Taille Type
/dev/sda1 2048 534527 532480 260M Partition d'amor=C3=A7a=
ge=20
Sony
/dev/sda2 534528 35080191 34545664 16,5G Environnement de=20
r=C3=A9cup=C3=A9ration Windows
/dev/sda3 35080192 35612671 532480 260M Amor=C3=A7age BIOS
/dev/sda4 35612672 35874815 262144 128M R=C3=A9serv=C3=A9 Micro=
soft
/dev/sda5 35874816 240674815 204800000 97,7G Donn=C3=A9es de base=20
Microsoft
/dev/sda6 240674816 428713983 188039168 89,7G Syst=C3=A8me de fichier=
s=20
Linux
/dev/sda7 428713984 445493247 16779264 8G Partition d'=C3=A9chang=
e=20
Linux
/dev/sda8 1257138176 1465147391 208009216 99,2G Syst=C3=A8me de fichier=
s=20
Linux
/dev/sda9 445493248 1257138175 811644928 387G Syst=C3=A8me de fichier=
s=20
Linux
Les entr=C3=A9es de la table de partitions ne sont pas dans l'ordre du disq=
ue.
la partition /dev/sda3 =C3=A9tait en type Boot EFI, c'est moi qui viens de=
=20
changer. L'id=C3=A9al pour moi serait que ce soit elle ma partition de boot=
,=20
afin de pouvoir supprimer /dev/sda9.
/dev/sda6 c'est Gentoo
/dev/sda8 /home de gentoo.
Quand je tente d'installer grub :
# LANG=3DC grub-install /dev/sda3
Installing for i386-pc platform.
grub-install: warning: File system `fat' doesn't support embedding.
grub-install: warning: Embedding is not possible. GRUB can only be=20
installed in this setup by using blocklists. However, blocklists are=20
UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SUITE =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
J'avais compos=C3=A9 ce post hier. Et pour le compl=C3=A9ter d'un max d'inf=
os, j'ai=20
fait des manips interm=C3=A9diaires, qui se sont r=C3=A9v=C3=A9l=C3=A9es pl=
ut=C3=B4t d=C3=A9sastreuses.
J'en suis m=C3=AAme arriv=C3=A9 =C3=A0 ne plus rien avoir de bootable, que =
ce soit en EFI=20
ou Windows passait en mode repair, mais je ne voulais pas qu'il =C3=A9crase=
le=20
reste en se r=C3=A9installant, ou que ce soit en Legacy ou j'ai eu un momen=
t=20
un grub actif, mais qui ne boutait plus la gentoo (mais je crois avoir=20
compris pourquoi depuis. J'avais refaire/format=C3=A9 la partition /dev/sda=
3=20
et le grub ubuntu est configur=C3=A9 pour utiliser l'UUID, donc il ne la=20
trouvait plus puisque j'ai une config custom pour gentoo).
D'un coup, mes cl=C3=A9s USB se sont mises =C3=A0 ne plus booter en mode Le=
gacy.
J'ai boot=C3=A9 en EFI avec ma cl=C3=A9 USB gentoo, chroot dans la partitio=
n=20
Ubuntu, grub-install (qui n'est pas un grub legacy) et par miracle (pour=20
moi) Windows est =C3=A0 nouveau pr=C3=A9sent au boot.
MAIS, en Legacy, je n'ai plus rien. Et quand je dis plus rien, c'est=20
vraiment plus rien. Ecran noir, curseur clignotant. Et le pire, c'est=20
qu'il ne voit m=C3=AAme plus du tout les cl=C3=A9s usb au boot.
J'ai essay=C3=A9 avec d'anciennes ISO non EFI, rien n'y change, et je ne=20
comprends absolument pas ce qui peut faire =C3=A7a.
Maintenant, en bootant en EFI avec cl=C3=A9 USB, et chroot Ubuntu, le grub-
install me jette :
root@livecd:/# grub-install /dev/sda
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot=20
Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be=20
installed in this setup by using blocklists. However, blocklists are=20
UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
J'ai du changer quelque chose sur les partitions GPT, mais quoi...
En plus, ce mod=C3=A8le de portable semble tr=C3=A8s peu r=C3=A9f=C3=A9renc=
=C3=A9 sur le net.
Sony VAIO SVS15116GAB
Le BIOS est des plus restreints. Aucune notion de secure boot.
On peut juste choisir l'ordre de boot entre External device, Internal=20
device, DVD et Network. On peut activer/d=C3=A9sactiver External device et=
=20
Network. Et c'est =C3=A9videmment totalement ind=C3=A9pendant du mode de bo=
ot EFI/
Legacy. Donc si je parviens =C3=A0 booter sur cl=C3=A9 en mode EFI, pourquo=
i je n'y=20
parviens plus en mode Legacy ?
J'ai laiss=C3=A9 toute la premi=C3=A8re partie pour =C3=A9clairer, mais =C3=
=A0 l'heure=20
actuelle, mon probl=C3=A8me est bien en amont de pouvoir mettre grub =C3=A0=
partir=20
de gentoo au lieu d'ubuntu.
En clair, je suis tr=C3=A8s emb=C3=AAt=C3=A9 et ne sais plus du tout dans q=
uelle=20
direction aller.
Si quelqu'un y comprend quelque chose et =C3=A0 une id=C3=A9e...
Merci d'avance, et surtout d'avoir eu le courage d'arriver l=C3=A0.
PS : j'ai d=C3=A9j=C3=A0 post=C3=A9 plusieurs fois ce message ce matin, mai=
s mon INN a refus=C3=A9 de le relayer, pour une autre raison obscure. En at=
tendant de trouver la raison, je le poste par ce biais.
Pour booter sous Windows, il faut passer en le bios au boot, et mettre le boot en mode "EFI". Là, windows démarre directement, sans aucun choix. Pour booter sous Linux (ubuntu ou gentoo), il faut, dans le bios, sélectionner "Legacy", et là, j'ai accès au grub configuré par le biais de Ubuntu. Certes, j'aurais préféré pouvoir éviter de passer par la sélection du mode dans le Bios, mais ce n'est pas non plus dramatique si ça reste comme ça.
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir démarrer Windows depuis GRUB, il est encore temps (à condition que le firmware UEFI ne soit pas bridé sur Windows). En résumé : - Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de boot EFI) donc probablement via un système live+chroot. - Monter la partition de boot Sony sur /boot/efi. - Installer les fichiers nécessaires à l'installation de GRUB pour EFI x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle grub-efi-amd64-bin, sais pas dans Gentoo). - Exécuter grub-install --target=x86_64-efi Si ça dit que les services EFI ne sont pas disponibles, il faut peut-être charger les modules efivars et efivarfs et/ou monter le système de fichiers virtuel de type efivarfs sur /sys/firmware/efi/efivars.
Le 03/10/2020 à 21:48, Christophe PEREZ a écrit :
Pour booter sous Windows, il faut passer en le bios au boot, et mettre le
boot en mode "EFI". Là, windows démarre directement, sans aucun choix.
Pour booter sous Linux (ubuntu ou gentoo), il faut, dans le bios,
sélectionner "Legacy", et là, j'ai accès au grub configuré par le biais
de Ubuntu.
Certes, j'aurais préféré pouvoir éviter de passer par la sélection du
mode dans le Bios, mais ce n'est pas non plus dramatique si ça reste
comme ça.
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir
démarrer Windows depuis GRUB, il est encore temps (à condition que le
firmware UEFI ne soit pas bridé sur Windows).
En résumé :
- Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de
boot EFI) donc probablement via un système live+chroot.
- Monter la partition de boot Sony sur /boot/efi.
- Installer les fichiers nécessaires à l'installation de GRUB pour EFI
x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle
grub-efi-amd64-bin, sais pas dans Gentoo).
- Exécuter grub-install --target=x86_64-efi
Si ça dit que les services EFI ne sont pas disponibles, il faut
peut-être charger les modules efivars et efivarfs et/ou monter le
système de fichiers virtuel de type efivarfs sur /sys/firmware/efi/efivars.
Pour booter sous Windows, il faut passer en le bios au boot, et mettre le boot en mode "EFI". Là, windows démarre directement, sans aucun choix. Pour booter sous Linux (ubuntu ou gentoo), il faut, dans le bios, sélectionner "Legacy", et là, j'ai accès au grub configuré par le biais de Ubuntu. Certes, j'aurais préféré pouvoir éviter de passer par la sélection du mode dans le Bios, mais ce n'est pas non plus dramatique si ça reste comme ça.
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir démarrer Windows depuis GRUB, il est encore temps (à condition que le firmware UEFI ne soit pas bridé sur Windows). En résumé : - Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de boot EFI) donc probablement via un système live+chroot. - Monter la partition de boot Sony sur /boot/efi. - Installer les fichiers nécessaires à l'installation de GRUB pour EFI x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle grub-efi-amd64-bin, sais pas dans Gentoo). - Exécuter grub-install --target=x86_64-efi Si ça dit que les services EFI ne sont pas disponibles, il faut peut-être charger les modules efivars et efivarfs et/ou monter le système de fichiers virtuel de type efivarfs sur /sys/firmware/efi/efivars.
Christophe PEREZ
Le Sun, 04 Oct 2020 10:42:32 +0200, Pascal Hambourg a écrit :
Et bien non, sur mon PC, en mode Legacy+EFI, elle ne boote pas, alors qu'elle boote en EFI seul (je n'ai pas de Legacy seul).
Que se passe-t-il exactement ?
Et bien le boot passait au directement au disque, comme s'il n'y avait pas de clé branchée.
Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ?
Ça peut venir des deux. Beaucoup d'images ISO bootables récentes sont dites "hybrides" car elles sont conçues pour être amorçables directement sur une clé USB. Elles contiennent une table de partition, un secteur de boot pour l'amorçage BIOS/legacy et/ou une partition EFI pour l'amorçage UEFI. Il suffit d'écrire leur contenu directement dans la clé /dev/sdX non montée.
Justement, ce n'est pas ce que fait unetbootin. Au moins, il copie les données dans un système monté. Après, fait-il autre chose sur la clé, je n'en sais rien.
Les images ISO "pures" non hybrides ne sont amorçables directement que sur un disque optique (format El Torito). Pour créer une clé USB amorçable, il faut utiliser divers outils (Rufus, Unetbootin...) qui ne copient pas directement l'image mais transforment son contenu. Cette méthode n'est pas recommandée avec les images ISO hybrides.
Et bien c'est sans doute parce que mon ISO gentoo datait beaucoup, mais quand j'avais fait la clé, c'est avec unetbootin que je l'avais fait, et elle fonctionnait/bootait en legacy.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé avec les images ISO hybrides de Debian.
Je comprends ;)
Si /dev/sda3 a le type "BIOS boot", elle n'est pas censée contenir un système de fichiers ni être montée. grub-install y écrit directement la core image de GRUB, écrasant tout contenu antérieur. Si le montage de cette partition est inscrit dans /etc/fstab, ça va coincer.
C'est ça. J'ai détaillé ma confusion dans un autre post.
Note : la core image de GRUB fait moins de 100 ko, une partition BIOS boot de 260 Mo est donc largement disproportionnée.
C'est ce que j'ai compris aussi. Mais bon, sur un disque de 750Go, je ne vais pas plus m'embêter.
Autre note : il semble que la partition "Sony boot partition" est une variante de la partition EFI, donc en principe il n'est pas nécessaire de créer une seconde partition EFI pour démarrer en mode UEFI.
Je crois que c'est l'installateur ubuntu qui a du la faire. J'ai du accepter n'y comprenant pas grand chose.
Le Sun, 04 Oct 2020 10:42:32 +0200, Pascal Hambourg a écrit :
Et bien non, sur mon PC, en mode Legacy+EFI, elle ne boote pas, alors
qu'elle boote en EFI seul (je n'ai pas de Legacy seul).
Que se passe-t-il exactement ?
Et bien le boot passait au directement au disque, comme s'il n'y avait
pas de clé branchée.
Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ?
Ça peut venir des deux.
Beaucoup d'images ISO bootables récentes sont dites "hybrides" car elles
sont conçues pour être amorçables directement sur une clé USB. Elles
contiennent une table de partition, un secteur de boot pour l'amorçage
BIOS/legacy et/ou une partition EFI pour l'amorçage UEFI. Il suffit
d'écrire leur contenu directement dans la clé /dev/sdX non montée.
Justement, ce n'est pas ce que fait unetbootin. Au moins, il copie les
données dans un système monté. Après, fait-il autre chose sur la clé, je
n'en sais rien.
Les images ISO "pures" non hybrides ne sont amorçables directement que
sur un disque optique (format El Torito). Pour créer une clé USB
amorçable, il faut utiliser divers outils (Rufus, Unetbootin...) qui ne
copient pas directement l'image mais transforment son contenu. Cette
méthode n'est pas recommandée avec les images ISO hybrides.
Et bien c'est sans doute parce que mon ISO gentoo datait beaucoup, mais
quand j'avais fait la clé, c'est avec unetbootin que je l'avais fait, et
elle fonctionnait/bootait en legacy.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé
avec les images ISO hybrides de Debian.
Je comprends ;)
Si /dev/sda3 a le type "BIOS boot", elle n'est pas censée contenir un
système de fichiers ni être montée. grub-install y écrit directement la
core image de GRUB, écrasant tout contenu antérieur. Si le montage de
cette partition est inscrit dans /etc/fstab, ça va coincer.
C'est ça. J'ai détaillé ma confusion dans un autre post.
Note : la core image de GRUB fait moins de 100 ko, une partition BIOS
boot de 260 Mo est donc largement disproportionnée.
C'est ce que j'ai compris aussi. Mais bon, sur un disque de 750Go, je ne
vais pas plus m'embêter.
Autre note : il semble que la partition "Sony boot partition" est une
variante de la partition EFI, donc en principe il n'est pas nécessaire
de créer une seconde partition EFI pour démarrer en mode UEFI.
Je crois que c'est l'installateur ubuntu qui a du la faire. J'ai du
accepter n'y comprenant pas grand chose.
Le Sun, 04 Oct 2020 10:42:32 +0200, Pascal Hambourg a écrit :
Et bien non, sur mon PC, en mode Legacy+EFI, elle ne boote pas, alors qu'elle boote en EFI seul (je n'ai pas de Legacy seul).
Que se passe-t-il exactement ?
Et bien le boot passait au directement au disque, comme s'il n'y avait pas de clé branchée.
Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ?
Ça peut venir des deux. Beaucoup d'images ISO bootables récentes sont dites "hybrides" car elles sont conçues pour être amorçables directement sur une clé USB. Elles contiennent une table de partition, un secteur de boot pour l'amorçage BIOS/legacy et/ou une partition EFI pour l'amorçage UEFI. Il suffit d'écrire leur contenu directement dans la clé /dev/sdX non montée.
Justement, ce n'est pas ce que fait unetbootin. Au moins, il copie les données dans un système monté. Après, fait-il autre chose sur la clé, je n'en sais rien.
Les images ISO "pures" non hybrides ne sont amorçables directement que sur un disque optique (format El Torito). Pour créer une clé USB amorçable, il faut utiliser divers outils (Rufus, Unetbootin...) qui ne copient pas directement l'image mais transforment son contenu. Cette méthode n'est pas recommandée avec les images ISO hybrides.
Et bien c'est sans doute parce que mon ISO gentoo datait beaucoup, mais quand j'avais fait la clé, c'est avec unetbootin que je l'avais fait, et elle fonctionnait/bootait en legacy.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé avec les images ISO hybrides de Debian.
Je comprends ;)
Si /dev/sda3 a le type "BIOS boot", elle n'est pas censée contenir un système de fichiers ni être montée. grub-install y écrit directement la core image de GRUB, écrasant tout contenu antérieur. Si le montage de cette partition est inscrit dans /etc/fstab, ça va coincer.
C'est ça. J'ai détaillé ma confusion dans un autre post.
Note : la core image de GRUB fait moins de 100 ko, une partition BIOS boot de 260 Mo est donc largement disproportionnée.
C'est ce que j'ai compris aussi. Mais bon, sur un disque de 750Go, je ne vais pas plus m'embêter.
Autre note : il semble que la partition "Sony boot partition" est une variante de la partition EFI, donc en principe il n'est pas nécessaire de créer une seconde partition EFI pour démarrer en mode UEFI.
Je crois que c'est l'installateur ubuntu qui a du la faire. J'ai du accepter n'y comprenant pas grand chose.
Christophe PEREZ
Le Sun, 04 Oct 2020 10:22:26 +0200, Pascal Hambourg a écrit :
Attention avec la renumérotation des partitions. Dans certaines conditions, GRUB peut identifier la partition contenant /boot par son numéro lors de son installation, et l'amorçage finira en "grub rescue" si le numéro change ensuite.
Oui, bien sûr, et je n'ai fait cette modif que parce que justement ça ne touchait à rien correspondant au boot.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS.
Certes, mais ça, c'était quand j'avais encore l'espoir de booter ma Gentoo en EFI.
Au moins certains installateurs (Debian) exécutent grub-install avec l'option --force qui permet dans certains cas d'installer GRUB pour BIOS sans partition BIOS boot, mais ce n'est pas d'une fiabilité absolue.
J'avais bien compris ça.
Autre détail, quand je boote avec la clé USB Ubuntu, en mode EFI, et que je tente l'install, ou le test sans install, j'ai à chaque fois l'erreur : 9.944515] Couldn't get size : 0x800000000000000e 9.944537] MODSIGN: Couldn't get UEFI db list 9.958977] Couldn't get size : 0x800000000000000e sur écran noir, et bloqué.
A quel moment ? Au lancement du noyau ?
Et bien difficile de dire précisément quand. C'est après le choix dans le menu de Grub, puis écran noir, puis cette erreur puis (je crois me souvenir) retour à Grub après quelques secondes. Ceci dit, ma clé Ubuntu ayant été (re)faite également par unetbootin, elle est sujette à caution.
Le Sun, 04 Oct 2020 10:22:26 +0200, Pascal Hambourg a écrit :
Attention avec la renumérotation des partitions. Dans certaines
conditions, GRUB peut identifier la partition contenant /boot par son
numéro lors de son installation, et l'amorçage finira en "grub rescue"
si le numéro change ensuite.
Oui, bien sûr, et je n'ai fait cette modif que parce que justement ça ne
touchait à rien correspondant au boot.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS.
Certes, mais ça, c'était quand j'avais encore l'espoir de booter ma
Gentoo en EFI.
Au moins certains installateurs (Debian) exécutent grub-install avec
l'option --force qui permet dans certains cas d'installer GRUB pour BIOS
sans partition BIOS boot, mais ce n'est pas d'une fiabilité absolue.
J'avais bien compris ça.
Autre détail, quand je boote avec la clé USB Ubuntu, en mode EFI, et
que je tente l'install, ou le test sans install, j'ai à chaque fois
l'erreur :
9.944515] Couldn't get size : 0x800000000000000e 9.944537] MODSIGN:
Couldn't get UEFI db list 9.958977] Couldn't get size :
0x800000000000000e sur écran noir, et bloqué.
A quel moment ? Au lancement du noyau ?
Et bien difficile de dire précisément quand. C'est après le choix dans le
menu de Grub, puis écran noir, puis cette erreur puis (je crois me
souvenir) retour à Grub après quelques secondes.
Ceci dit, ma clé Ubuntu ayant été (re)faite également par unetbootin,
elle est sujette à caution.
Le Sun, 04 Oct 2020 10:22:26 +0200, Pascal Hambourg a écrit :
Attention avec la renumérotation des partitions. Dans certaines conditions, GRUB peut identifier la partition contenant /boot par son numéro lors de son installation, et l'amorçage finira en "grub rescue" si le numéro change ensuite.
Oui, bien sûr, et je n'ai fait cette modif que parce que justement ça ne touchait à rien correspondant au boot.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS.
Certes, mais ça, c'était quand j'avais encore l'espoir de booter ma Gentoo en EFI.
Au moins certains installateurs (Debian) exécutent grub-install avec l'option --force qui permet dans certains cas d'installer GRUB pour BIOS sans partition BIOS boot, mais ce n'est pas d'une fiabilité absolue.
J'avais bien compris ça.
Autre détail, quand je boote avec la clé USB Ubuntu, en mode EFI, et que je tente l'install, ou le test sans install, j'ai à chaque fois l'erreur : 9.944515] Couldn't get size : 0x800000000000000e 9.944537] MODSIGN: Couldn't get UEFI db list 9.958977] Couldn't get size : 0x800000000000000e sur écran noir, et bloqué.
A quel moment ? Au lancement du noyau ?
Et bien difficile de dire précisément quand. C'est après le choix dans le menu de Grub, puis écran noir, puis cette erreur puis (je crois me souvenir) retour à Grub après quelques secondes. Ceci dit, ma clé Ubuntu ayant été (re)faite également par unetbootin, elle est sujette à caution.
Christophe PEREZ
Le Sun, 04 Oct 2020 16:00:59 +0200, Pascal Hambourg a écrit :
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir démarrer Windows depuis GRUB, il est encore temps (à condition que le firmware UEFI ne soit pas bridé sur Windows).
Et ça c'est la condition dont je doute fortement.
En résumé : - Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de boot EFI) donc probablement via un système live+chroot. - Monter la partition de boot Sony sur /boot/efi. - Installer les fichiers nécessaires à l'installation de GRUB pour EFI x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle grub-efi-amd64-bin, sais pas dans Gentoo). - Exécuter grub-install --target=x86_64-efi Si ça dit que les services EFI ne sont pas disponibles, il faut peut-être charger les modules efivars et efivarfs et/ou monter le système de fichiers virtuel de type efivarfs sur /sys/firmware/efi/efivars.
J'avais fait ce genre de choses quand j'ai tout cassé. J'en étais même à modifier manuellement (avec efibootmgr) les entrées du boot EFI, mais à chaque boot qui m'envoyait directement sur le système de maintenance de Windows, les valeurs que je trouvais ensuite dans efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows Boot Manager" Est-ce ce que ferait le "secure boot" ? Quand j'ai été persuadé que tout ce que je faisais ne servait à rien, j'ai abandonné l'idée.
Le Sun, 04 Oct 2020 16:00:59 +0200, Pascal Hambourg a écrit :
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir
démarrer Windows depuis GRUB, il est encore temps (à condition que le
firmware UEFI ne soit pas bridé sur Windows).
Et ça c'est la condition dont je doute fortement.
En résumé :
- Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de
boot EFI) donc probablement via un système live+chroot.
- Monter la partition de boot Sony sur /boot/efi.
- Installer les fichiers nécessaires à l'installation de GRUB pour EFI
x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle
grub-efi-amd64-bin, sais pas dans Gentoo).
- Exécuter grub-install --target=x86_64-efi Si ça dit que les services
EFI ne sont pas disponibles, il faut peut-être charger les modules
efivars et efivarfs et/ou monter le système de fichiers virtuel de type
efivarfs sur /sys/firmware/efi/efivars.
J'avais fait ce genre de choses quand j'ai tout cassé.
J'en étais même à modifier manuellement (avec efibootmgr) les entrées du
boot EFI, mais à chaque boot qui m'envoyait directement sur le système de
maintenance de Windows, les valeurs que je trouvais ensuite dans
efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée
correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows
Boot Manager"
Est-ce ce que ferait le "secure boot" ?
Quand j'ai été persuadé que tout ce que je faisais ne servait à rien,
j'ai abandonné l'idée.
Le Sun, 04 Oct 2020 16:00:59 +0200, Pascal Hambourg a écrit :
Pour revenir là-dessus, si tu veux éviter cette gymnastique et pouvoir démarrer Windows depuis GRUB, il est encore temps (à condition que le firmware UEFI ne soit pas bridé sur Windows).
Et ça c'est la condition dont je doute fortement.
En résumé : - Amorcer Linux en mode EFI (nécessaire pour enregistrer l'entrée de boot EFI) donc probablement via un système live+chroot. - Monter la partition de boot Sony sur /boot/efi. - Installer les fichiers nécessaires à l'installation de GRUB pour EFI x86_64 si ce n'est pas déjà fait (dans Debian le paquet s'appelle grub-efi-amd64-bin, sais pas dans Gentoo). - Exécuter grub-install --target=x86_64-efi Si ça dit que les services EFI ne sont pas disponibles, il faut peut-être charger les modules efivars et efivarfs et/ou monter le système de fichiers virtuel de type efivarfs sur /sys/firmware/efi/efivars.
J'avais fait ce genre de choses quand j'ai tout cassé. J'en étais même à modifier manuellement (avec efibootmgr) les entrées du boot EFI, mais à chaque boot qui m'envoyait directement sur le système de maintenance de Windows, les valeurs que je trouvais ensuite dans efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows Boot Manager" Est-ce ce que ferait le "secure boot" ? Quand j'ai été persuadé que tout ce que je faisais ne servait à rien, j'ai abandonné l'idée.
Pascal Hambourg
Le 04/10/2020 à 16:00, Christophe PEREZ a écrit :
Le Sun, 04 Oct 2020 10:13:13 +0200, Pascal Hambourg a écrit :
Qu'appelles-tu "partition de boot" ?
Je parlais de /dev/sda2 dans cette doc (par exemple) https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/ fr#What_is_the_BIOS_boot_partition.3F
Je trouve que ce document n'est pas très clair sur ce point et contient des incohérences.
Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée)
(...)
Si tu parles de la partition de type "BIOS boot"
(...)
Et justement, je crois que mon problème est que j'ai fait une énorme confusion entre ces 2 partitions, voire même avec la partition EFI en plus.
C'est l'inconvénient d'utiliser une dénomination imprécise comme "partition de boot" pouvant qualifier n'importe lesquel de ces trois types de partition qui sont impliqués dans l'amorçage. C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de la partition montée sur /boot, j'écris "partition /boot". Quand je parle de la partition système EFI ou "BIOS boot", je le mentionne explicitement.
Le 04/10/2020 à 16:00, Christophe PEREZ a écrit :
Le Sun, 04 Oct 2020 10:13:13 +0200, Pascal Hambourg a écrit :
Qu'appelles-tu "partition de boot" ?
Je parlais de /dev/sda2 dans cette doc (par exemple)
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/
fr#What_is_the_BIOS_boot_partition.3F
Je trouve que ce document n'est pas très clair sur ce point et contient
des incohérences.
Si c'est la partition où se trouve le contenu du répertoire /boot
(racine ou partition /boot séparée)
(...)
Si tu parles de la partition de type "BIOS boot"
(...)
Et justement, je crois que mon problème est que j'ai fait une énorme
confusion entre ces 2 partitions, voire même avec la partition EFI en
plus.
C'est l'inconvénient d'utiliser une dénomination imprécise comme
"partition de boot" pouvant qualifier n'importe lesquel de ces trois
types de partition qui sont impliqués dans l'amorçage.
C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de
la partition montée sur /boot, j'écris "partition /boot". Quand je parle
de la partition système EFI ou "BIOS boot", je le mentionne explicitement.
Le Sun, 04 Oct 2020 10:13:13 +0200, Pascal Hambourg a écrit :
Qu'appelles-tu "partition de boot" ?
Je parlais de /dev/sda2 dans cette doc (par exemple) https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/ fr#What_is_the_BIOS_boot_partition.3F
Je trouve que ce document n'est pas très clair sur ce point et contient des incohérences.
Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée)
(...)
Si tu parles de la partition de type "BIOS boot"
(...)
Et justement, je crois que mon problème est que j'ai fait une énorme confusion entre ces 2 partitions, voire même avec la partition EFI en plus.
C'est l'inconvénient d'utiliser une dénomination imprécise comme "partition de boot" pouvant qualifier n'importe lesquel de ces trois types de partition qui sont impliqués dans l'amorçage. C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de la partition montée sur /boot, j'écris "partition /boot". Quand je parle de la partition système EFI ou "BIOS boot", je le mentionne explicitement.
Christophe PEREZ
Le Sun, 04 Oct 2020 18:21:22 +0200, Pascal Hambourg a écrit :
Je trouve que ce document n'est pas très clair sur ce point et contient des incohérences.
Sans me chercher d'excuse, cela a du participer à mon incompréhension.
C'est l'inconvénient d'utiliser une dénomination imprécise comme "partition de boot" pouvant qualifier n'importe lesquel de ces trois types de partition qui sont impliqués dans l'amorçage.
C'est clair.
C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de la partition montée sur /boot, j'écris "partition /boot". Quand je parle de la partition système EFI ou "BIOS boot", je le mentionne explicitement.
Et tu as bien raison. Au moins, cette aventure m'aura un peu éclairé sur le sujet. Même si l'EFI reste encore assez abscons pour moi. Il faut dire, qu'à moins d'en avoir une utilisation particulière, on touche relativement peu souvent à ces "choses". Du coup, ce que l'on a pu comprendre, au moins partiellement à un moment, peut s'estomper avec le temps, et quand on en a à nouveau besoin bien plus tard, les souvenirs sont profondément enfouis ;) Ce qui n'aide pas non plus ce sont les BIOS, tous différents, chacun son appellation pour les options communes. Certains même n'ont aucun détail d'explication pour les options. Il faut deviner à quoi ça sert. Du coup, dès le départ on peut avoir des doutes sur la configuration BIOS adoptée, et ça n'aide pas au diagnostic.
Le Sun, 04 Oct 2020 18:21:22 +0200, Pascal Hambourg a écrit :
Je trouve que ce document n'est pas très clair sur ce point et contient
des incohérences.
Sans me chercher d'excuse, cela a du participer à mon incompréhension.
C'est l'inconvénient d'utiliser une dénomination imprécise comme
"partition de boot" pouvant qualifier n'importe lesquel de ces trois
types de partition qui sont impliqués dans l'amorçage.
C'est clair.
C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de
la partition montée sur /boot, j'écris "partition /boot". Quand je parle
de la partition système EFI ou "BIOS boot", je le mentionne
explicitement.
Et tu as bien raison.
Au moins, cette aventure m'aura un peu éclairé sur le sujet. Même si l'EFI
reste encore assez abscons pour moi.
Il faut dire, qu'à moins d'en avoir une utilisation particulière, on
touche relativement peu souvent à ces "choses". Du coup, ce que l'on a pu
comprendre, au moins partiellement à un moment, peut s'estomper avec le
temps, et quand on en a à nouveau besoin bien plus tard, les souvenirs
sont profondément enfouis ;)
Ce qui n'aide pas non plus ce sont les BIOS, tous différents, chacun son
appellation pour les options communes. Certains même n'ont aucun détail
d'explication pour les options. Il faut deviner à quoi ça sert. Du coup,
dès le départ on peut avoir des doutes sur la configuration BIOS adoptée,
et ça n'aide pas au diagnostic.
Le Sun, 04 Oct 2020 18:21:22 +0200, Pascal Hambourg a écrit :
Je trouve que ce document n'est pas très clair sur ce point et contient des incohérences.
Sans me chercher d'excuse, cela a du participer à mon incompréhension.
C'est l'inconvénient d'utiliser une dénomination imprécise comme "partition de boot" pouvant qualifier n'importe lesquel de ces trois types de partition qui sont impliqués dans l'amorçage.
C'est clair.
C'est pourquoi je n'emploie jamais cette dénomination. Quand je parle de la partition montée sur /boot, j'écris "partition /boot". Quand je parle de la partition système EFI ou "BIOS boot", je le mentionne explicitement.
Et tu as bien raison. Au moins, cette aventure m'aura un peu éclairé sur le sujet. Même si l'EFI reste encore assez abscons pour moi. Il faut dire, qu'à moins d'en avoir une utilisation particulière, on touche relativement peu souvent à ces "choses". Du coup, ce que l'on a pu comprendre, au moins partiellement à un moment, peut s'estomper avec le temps, et quand on en a à nouveau besoin bien plus tard, les souvenirs sont profondément enfouis ;) Ce qui n'aide pas non plus ce sont les BIOS, tous différents, chacun son appellation pour les options communes. Certains même n'ont aucun détail d'explication pour les options. Il faut deviner à quoi ça sert. Du coup, dès le départ on peut avoir des doutes sur la configuration BIOS adoptée, et ça n'aide pas au diagnostic.
Pascal Hambourg
Le 04/10/2020 à 16:18, Christophe PEREZ a écrit :
mais à chaque boot qui m'envoyait directement sur le système de maintenance de Windows,
Qu'est-ce que le système de maintenance de Windows, et dans quelles circonstances le boot aboutit-il directement dessus ?
les valeurs que je trouvais ensuite dans efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows Boot Manager"
As-tu essayé le dernier recours consistant à dire à Windows de déclarer GRUB à la place de son propre gestionnaire d'amorçage avec une commande bcdedit (dont j'ai oublié les détails) ?
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui n'est pas signé avec la bonne clé. Au moins ta situation actuelle a un avantage : ni Windows ni le firmware UEFI ne peuvent casser l'amorçage legacy de Gentoo. Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy (à condition de ne pas transformer la partition "BIOS boot" en partition EFI).
Le 04/10/2020 à 16:18, Christophe PEREZ a écrit :
mais à chaque boot qui m'envoyait directement sur le système de
maintenance de Windows,
Qu'est-ce que le système de maintenance de Windows, et dans quelles
circonstances le boot aboutit-il directement dessus ?
les valeurs que je trouvais ensuite dans
efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée
correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows
Boot Manager"
As-tu essayé le dernier recours consistant à dire à Windows de déclarer
GRUB à la place de son propre gestionnaire d'amorçage avec une commande
bcdedit (dont j'ai oublié les détails) ?
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui
n'est pas signé avec la bonne clé.
Au moins ta situation actuelle a un avantage : ni Windows ni le firmware
UEFI ne peuvent casser l'amorçage legacy de Gentoo. Tu peux même essayer
d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage
BIOS/legacy (à condition de ne pas transformer la partition "BIOS boot"
en partition EFI).
mais à chaque boot qui m'envoyait directement sur le système de maintenance de Windows,
Qu'est-ce que le système de maintenance de Windows, et dans quelles circonstances le boot aboutit-il directement dessus ?
les valeurs que je trouvais ensuite dans efibootmgr étaient réinitialisées. Il n'y avait plus que l'entrée correspondante à ma Clé EFI sur laquelle je bootais, et l'entrée "Windows Boot Manager"
As-tu essayé le dernier recours consistant à dire à Windows de déclarer GRUB à la place de son propre gestionnaire d'amorçage avec une commande bcdedit (dont j'ai oublié les détails) ?
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui n'est pas signé avec la bonne clé. Au moins ta situation actuelle a un avantage : ni Windows ni le firmware UEFI ne peuvent casser l'amorçage legacy de Gentoo. Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy (à condition de ne pas transformer la partition "BIOS boot" en partition EFI).
Christophe PEREZ
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Qu'est-ce que le système de maintenance de Windows, et dans quelles circonstances le boot aboutit-il directement dessus ?
Oh tu sais, je n'y connais pas grand chose. C'est juste que j'avais "cassé" le boot windows, et qu'au démarrage, après un long écran Windows, il aboutissait sur son système de restauration intégré, où il semblait me dire qu'il allait tout virer pour remettre windows (mais il me proposait quand même de faire des backups avant), ce qui ne m'intéressait évidemment pas. Je n'ai pas du tout été plus loin. Je crois que ce sont mes tentatives de modif du boot EFI (par efibootmgr) qui ont rétabli la situation, mais je ne testais pas le boot windows à chaque modif, donc je n'en sais pas plus.
As-tu essayé le dernier recours consistant à dire à Windows de déclarer GRUB à la place de son propre gestionnaire d'amorçage avec une commande bcdedit (dont j'ai oublié les détails) ?
Non, du tout. Je n'y connais rien, et n'ai pas du tout eu l'envie de m'y aventurer. Je crois que si j'avais du en arriver là, je l'aurais carrément virer.
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui n'est pas signé avec la bonne clé.
Bon et bien je ne sais pas.
Au moins ta situation actuelle a un avantage : ni Windows ni le firmware UEFI ne peuvent casser l'amorçage legacy de Gentoo.
C'est un peu ce que je me suis dit. Les 2 étant indépendants, au moins, çe permet de cloisonner.
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant en Legacy ? Ou alors par boot sur la clé USB et en chrootant gentoo ?
(à condition de ne pas transformer la partition "BIOS boot" en
partition EFI). Je vais essayer de ne plus du tout toucher à /dev/sda3 :)
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Qu'est-ce que le système de maintenance de Windows, et dans quelles
circonstances le boot aboutit-il directement dessus ?
Oh tu sais, je n'y connais pas grand chose.
C'est juste que j'avais "cassé" le boot windows, et qu'au démarrage,
après un long écran Windows, il aboutissait sur son système de
restauration intégré, où il semblait me dire qu'il allait tout virer pour
remettre windows (mais il me proposait quand même de faire des backups
avant), ce qui ne m'intéressait évidemment pas. Je n'ai pas du tout été
plus loin.
Je crois que ce sont mes tentatives de modif du boot EFI (par efibootmgr)
qui ont rétabli la situation, mais je ne testais pas le boot windows à
chaque modif, donc je n'en sais pas plus.
As-tu essayé le dernier recours consistant à dire à Windows de déclarer
GRUB à la place de son propre gestionnaire d'amorçage avec une commande
bcdedit (dont j'ai oublié les détails) ?
Non, du tout. Je n'y connais rien, et n'ai pas du tout eu l'envie de m'y
aventurer.
Je crois que si j'avais du en arriver là, je l'aurais carrément virer.
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui
n'est pas signé avec la bonne clé.
Bon et bien je ne sais pas.
Au moins ta situation actuelle a un avantage : ni Windows ni le firmware
UEFI ne peuvent casser l'amorçage legacy de Gentoo.
C'est un peu ce que je me suis dit. Les 2 étant indépendants, au moins, çe
permet de cloisonner.
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de
casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant
en Legacy ?
Ou alors par boot sur la clé USB et en chrootant gentoo ?
(à condition de ne pas transformer la partition "BIOS boot" en
partition EFI).
Je vais essayer de ne plus du tout toucher à /dev/sda3 :)
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Qu'est-ce que le système de maintenance de Windows, et dans quelles circonstances le boot aboutit-il directement dessus ?
Oh tu sais, je n'y connais pas grand chose. C'est juste que j'avais "cassé" le boot windows, et qu'au démarrage, après un long écran Windows, il aboutissait sur son système de restauration intégré, où il semblait me dire qu'il allait tout virer pour remettre windows (mais il me proposait quand même de faire des backups avant), ce qui ne m'intéressait évidemment pas. Je n'ai pas du tout été plus loin. Je crois que ce sont mes tentatives de modif du boot EFI (par efibootmgr) qui ont rétabli la situation, mais je ne testais pas le boot windows à chaque modif, donc je n'en sais pas plus.
As-tu essayé le dernier recours consistant à dire à Windows de déclarer GRUB à la place de son propre gestionnaire d'amorçage avec une commande bcdedit (dont j'ai oublié les détails) ?
Non, du tout. Je n'y connais rien, et n'ai pas du tout eu l'envie de m'y aventurer. Je crois que si j'avais du en arriver là, je l'aurais carrément virer.
Est-ce ce que ferait le "secure boot" ?
Pas que je sache ; le secure boot refuse d'exécuter un chargeur qui n'est pas signé avec la bonne clé.
Bon et bien je ne sais pas.
Au moins ta situation actuelle a un avantage : ni Windows ni le firmware UEFI ne peuvent casser l'amorçage legacy de Gentoo.
C'est un peu ce que je me suis dit. Les 2 étant indépendants, au moins, çe permet de cloisonner.
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant en Legacy ? Ou alors par boot sur la clé USB et en chrootant gentoo ?
(à condition de ne pas transformer la partition "BIOS boot" en
partition EFI). Je vais essayer de ne plus du tout toucher à /dev/sda3 :)
Pascal Hambourg
Le 04/10/2020 à 23:45, Christophe PEREZ a écrit :
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant en Legacy ?
Non, les services EFI ne sont pas disponibles quand on boote en legacy. D'autre part efibootmgr sert seulement à manipuler les variables de boot EFI, ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Oui, comme je l'ai indiqué deux messages avant.
Le 04/10/2020 à 23:45, Christophe PEREZ a écrit :
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de
casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant
en Legacy ?
Non, les services EFI ne sont pas disponibles quand on boote en legacy.
D'autre part efibootmgr sert seulement à manipuler les variables de boot
EFI, ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Le Sun, 04 Oct 2020 18:49:54 +0200, Pascal Hambourg a écrit :
Tu peux même essayer d'ajouter l'amorçage EFI sur Gentoo sans risque de casser l'amorçage BIOS/legacy
Par quel biais ? efibootmgr à partir de gentoo ? J'y ai accès en bootant en Legacy ?
Non, les services EFI ne sont pas disponibles quand on boote en legacy. D'autre part efibootmgr sert seulement à manipuler les variables de boot EFI, ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Oui, comme je l'ai indiqué deux messages avant.
Christophe PEREZ
Le Mon, 05 Oct 2020 21:21:34 +0200, Pascal Hambourg a écrit :
ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ça c'est déjà fait.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Oui, comme je l'ai indiqué deux messages avant.
Je croyais que tu parlais d'encore autre chose (méthode/moyen) en disant : "Tu peux même essayer d'ajouter..." Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de perdre mon boot windows ?
Le Mon, 05 Oct 2020 21:21:34 +0200, Pascal Hambourg a écrit :
ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ça c'est déjà fait.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Oui, comme je l'ai indiqué deux messages avant.
Je croyais que tu parlais d'encore autre chose (méthode/moyen) en
disant : "Tu peux même essayer d'ajouter..."
Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de
perdre mon boot windows ?
Le Mon, 05 Oct 2020 21:21:34 +0200, Pascal Hambourg a écrit :
ce qu'il faut c'est installer la variante de GRUB pour EFI.
Ça c'est déjà fait.
Ou alors par boot sur la clé USB et en chrootant gentoo ?
Oui, comme je l'ai indiqué deux messages avant.
Je croyais que tu parlais d'encore autre chose (méthode/moyen) en disant : "Tu peux même essayer d'ajouter..." Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de perdre mon boot windows ?
