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.
Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de perdre mon boot windows ?
Je ne vois pas pourquoi. Soit ça ne marche pas et c'est encore Windows qui boote. Soit ça marche et c'est GRUB pour EFI qui boote, et il pourra chaîner Windows. Pour cela il faudra soit que os-prober soit présent et update-grub/grub-mkconfig ait été exécuté après un boot EFI pour détecter Windows et l'intégrer au menu de GRUB, soit l'ajouter manuellement au menu.
Le 06/10/2020 à 06:24, Christophe PEREZ a écrit :
Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de
perdre mon boot windows ?
Je ne vois pas pourquoi.
Soit ça ne marche pas et c'est encore Windows qui boote.
Soit ça marche et c'est GRUB pour EFI qui boote, et il pourra chaîner
Windows. Pour cela il faudra soit que os-prober soit présent et
update-grub/grub-mkconfig ait été exécuté après un boot EFI pour
détecter Windows et l'intégrer au menu de GRUB, soit l'ajouter
manuellement au menu.
Mais en faisant ça, est-ce que je ne prends pas à nouveau le risque de perdre mon boot windows ?
Je ne vois pas pourquoi. Soit ça ne marche pas et c'est encore Windows qui boote. Soit ça marche et c'est GRUB pour EFI qui boote, et il pourra chaîner Windows. Pour cela il faudra soit que os-prober soit présent et update-grub/grub-mkconfig ait été exécuté après un boot EFI pour détecter Windows et l'intégrer au menu de GRUB, soit l'ajouter manuellement au menu.
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).
Résultats du suivi de la procédure : 1) avant de booter avec la clé en mode EFI, j'ai voulu vérifier que windows bootait toujours, mais ce n'est pas le cas. J'ai du re-casser le boot EFI à un moment, mais je ne sais pas du tout quand : Operating System Not Found (chroot) 06:28:47 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi' BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0001,0000 Boot0000* EFI USB Device Boot0001* Windows Boot Manager Mais rien de mieux au reboot. Je me suis dit que peut-être que rajouter le boot grub remettrait tout en place, donc j'ai 2) booté sur la clé USB en mode EFI Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1 puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en faisais une partition de /boot. Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je me retrouve avec /boot/EFI/EFI, normal ? J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI. Je suis donc revenu à : (chroot) 06:31:46 / # mount /dev/sda1 /boot/EFI (chroot) 06:31:52 / # grub-install /dev/sda Installation pour la plate-forme x86_64-efi. Installation terminée, sans erreur. Mais : (chroot) 10:34:59 ~ # grub-mkconfig -o grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.4.60-gentoo WARNING: Failed to connect to lvmetad. Falling back to device scanning. grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map.. Found memtest image: /boot/memtest86plus/memtest Found memtest image: /boot/memtest86plus/memtest.netbsd Found linux image: /boot/vmlinuz-5.4.60-gentoo Found linux image: /boot/vmlinuz-5.4.60-gentoo done Il ne trouve pas Windows lui non plus. Et au reboot, toujours le message d'erreur du 1) (chroot) 10:38:18 ~ # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0002,0001,0000 Boot0000* EFI USB Device Boot0001* Windows Boot Manager Boot0002* gentoo Et pour couronner le tout, j'ai des touches du clavier qui ne répondent plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque certaines me servent pour la saisie du passwd pour sshd, et que je mets toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas contigües. Bon, on verra ça plus tard :)
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).
Résultats du suivi de la procédure :
1) avant de booter avec la clé en mode EFI, j'ai voulu vérifier que
windows bootait toujours, mais ce n'est pas le cas.
J'ai du re-casser le boot EFI à un moment, mais je ne sais pas du tout
quand :
Operating System Not Found
(chroot) 06:28:47 root@livecd / # efibootmgr
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000
Boot0000* EFI USB Device
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé
USB en mode EFI):
(chroot) 06:28:53 root@livecd / # efibootmgr -c -g -d /dev/sda -p 1 -w -L
"Windows Boot Manager" -l 'EFIBootBootx64.efi'
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0001,0000
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Mais rien de mieux au reboot.
Je me suis dit que peut-être que rajouter le boot grub remettrait tout en
place, donc j'ai
2) booté sur la clé USB en mode EFI
Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1
puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en
faisais une partition de /boot.
Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je
me retrouve avec /boot/EFI/EFI, normal ?
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a
répondu :
grub-install : erreur : impossible de trouver le répertoire EFI.
Je suis donc revenu à :
(chroot) 06:31:46 root@livecd / # mount /dev/sda1 /boot/EFI
(chroot) 06:31:52 root@livecd / # grub-install /dev/sda
Installation pour la plate-forme x86_64-efi.
Installation terminée, sans erreur.
Mais :
(chroot) 10:34:59 root@livecd ~ # grub-mkconfig -o grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.60-gentoo
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
grub-probe : erreur : impossible de trouver un périphérique GRUB pour /
dev/sdb1. Vérifiez device.map..
Found memtest image: /boot/memtest86plus/memtest
Found memtest image: /boot/memtest86plus/memtest.netbsd
Found linux image: /boot/vmlinuz-5.4.60-gentoo
Found linux image: /boot/vmlinuz-5.4.60-gentoo
done
Et pour couronner le tout, j'ai des touches du clavier qui ne répondent
plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque
certaines me servent pour la saisie du passwd pour sshd, et que je mets
toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne
plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas
contigües.
Bon, on verra ça plus tard :)
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).
Résultats du suivi de la procédure : 1) avant de booter avec la clé en mode EFI, j'ai voulu vérifier que windows bootait toujours, mais ce n'est pas le cas. J'ai du re-casser le boot EFI à un moment, mais je ne sais pas du tout quand : Operating System Not Found (chroot) 06:28:47 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi' BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0001,0000 Boot0000* EFI USB Device Boot0001* Windows Boot Manager Mais rien de mieux au reboot. Je me suis dit que peut-être que rajouter le boot grub remettrait tout en place, donc j'ai 2) booté sur la clé USB en mode EFI Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1 puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en faisais une partition de /boot. Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je me retrouve avec /boot/EFI/EFI, normal ? J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI. Je suis donc revenu à : (chroot) 06:31:46 / # mount /dev/sda1 /boot/EFI (chroot) 06:31:52 / # grub-install /dev/sda Installation pour la plate-forme x86_64-efi. Installation terminée, sans erreur. Mais : (chroot) 10:34:59 ~ # grub-mkconfig -o grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.4.60-gentoo WARNING: Failed to connect to lvmetad. Falling back to device scanning. grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map.. Found memtest image: /boot/memtest86plus/memtest Found memtest image: /boot/memtest86plus/memtest.netbsd Found linux image: /boot/vmlinuz-5.4.60-gentoo Found linux image: /boot/vmlinuz-5.4.60-gentoo done Il ne trouve pas Windows lui non plus. Et au reboot, toujours le message d'erreur du 1) (chroot) 10:38:18 ~ # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0002,0001,0000 Boot0000* EFI USB Device Boot0001* Windows Boot Manager Boot0002* gentoo Et pour couronner le tout, j'ai des touches du clavier qui ne répondent plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque certaines me servent pour la saisie du passwd pour sshd, et que je mets toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas contigües. Bon, on verra ça plus tard :)
Pascal Hambourg
Le 06/10/2020 à 16:58, Christophe PEREZ a écrit :
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait pas avoir besoin d'entrée de boot EFI pour démarrer. Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1 puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en faisais une partition de /boot.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je me retrouve avec /boot/EFI/EFI, normal ?
Oui, sauf que dans mon expérience le point de montage est habituellement /boot/efi (en minuscule). Le répertoire "EFI" à la racine de la partition est en majuscules, mais ça doit être sans importance puisque FAT est censé être insensible à la casse.
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
(chroot) 10:34:59 ~ # grub-mkconfig -o grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.4.60-gentoo WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Message lié à un démon de LVM, sans importance.
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
Il ne trouve pas Windows lui non plus.
D'où ma question sur le contenu de la partition EFI.
Et pour couronner le tout, j'ai des touches du clavier qui ne répondent plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque certaines me servent pour la saisie du passwd pour sshd, et que je mets toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas contigües.
Tu as testé avec un clavier externe ?
Le 06/10/2020 à 16:58, Christophe PEREZ a écrit :
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé
USB en mode EFI):
(chroot) 06:28:53 root@livecd / # efibootmgr -c -g -d /dev/sda -p 1 -w -L
"Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait
pas avoir besoin d'entrée de boot EFI pour démarrer. Le chargeur
d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers
lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1
puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en
faisais une partition de /boot.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je
me retrouve avec /boot/EFI/EFI, normal ?
Oui, sauf que dans mon expérience le point de montage est habituellement
/boot/efi (en minuscule). Le répertoire "EFI" à la racine de la
partition est en majuscules, mais ça doit être sans importance puisque
FAT est censé être insensible à la casse.
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a
répondu :
grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
(chroot) 10:34:59 root@livecd ~ # grub-mkconfig -o grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.60-gentoo
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Message lié à un démon de LVM, sans importance.
grub-probe : erreur : impossible de trouver un périphérique GRUB pour /
dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans
/boot/grub/device.map. Sans importance, mais devrait être corrigé par
grub-mkdevicemap.
Il ne trouve pas Windows lui non plus.
D'où ma question sur le contenu de la partition EFI.
Et pour couronner le tout, j'ai des touches du clavier qui ne répondent
plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque
certaines me servent pour la saisie du passwd pour sshd, et que je mets
toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne
plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas
contigües.
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait pas avoir besoin d'entrée de boot EFI pour démarrer. Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Alors, déjà, je me rends compte que j'ai du bidouiller aussi /dev/sda1 puisque j'y trouve globalement le même contenu que /dev/sda3 quand j'en faisais une partition de /boot.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
Du coup, j'ai dedans /EFI. Alors si je monte /dev/sda1 sur /boot/EFI, je me retrouve avec /boot/EFI/EFI, normal ?
Oui, sauf que dans mon expérience le point de montage est habituellement /boot/efi (en minuscule). Le répertoire "EFI" à la racine de la partition est en majuscules, mais ça doit être sans importance puisque FAT est censé être insensible à la casse.
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
(chroot) 10:34:59 ~ # grub-mkconfig -o grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.4.60-gentoo WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Message lié à un démon de LVM, sans importance.
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
Il ne trouve pas Windows lui non plus.
D'où ma question sur le contenu de la partition EFI.
Et pour couronner le tout, j'ai des touches du clavier qui ne répondent plus (l, 9, ...). C'est forcément hard, et c'est très récent puisque certaines me servent pour la saisie du passwd pour sshd, et que je mets toujours le même passe, et que ça fonctionnait, et que ça ne fonctionne plus uniquement depuis aujourd'hui. En plus, les touches ne sont pas contigües.
Tu as testé avec un clavier externe ?
Pascal Hambourg
Le 06/10/2020 à 21:53, Pascal Hambourg a écrit :
Le 06/10/2020 à 16:58, Christophe PEREZ a écrit :
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait pas avoir besoin d'entrée de boot EFI pour démarrer.
A ce propos, tu peux installer une copie de GRUB dans cet emplacement (chemin de support amovible) avec : grub-install --removable Utile avec les firmwares UEFI buggés qui ne gèrent pas correctement les entrées de boot EFI. Cela écrasera un éventuel fichier EFIBootBootx64.efi déjà présent.
Le 06/10/2020 à 21:53, Pascal Hambourg a écrit :
Le 06/10/2020 à 16:58, Christophe PEREZ a écrit :
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé
USB en mode EFI):
(chroot) 06:28:53 root@livecd / # efibootmgr -c -g -d /dev/sda -p 1 -w -L
"Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait
pas avoir besoin d'entrée de boot EFI pour démarrer.
A ce propos, tu peux installer une copie de GRUB dans cet emplacement
(chemin de support amovible) avec :
grub-install --removable
Utile avec les firmwares UEFI buggés qui ne gèrent pas correctement les
entrées de boot EFI.
Cela écrasera un éventuel fichier EFIBootBootx64.efi déjà présent.
J'ai rajouté l'entrée à la main avec efibootmgr (après boot sur la clé USB en mode EFI): (chroot) 06:28:53 / # efibootmgr -c -g -d /dev/sda -p 1 -w -L "Windows Boot Manager" -l 'EFIBootBootx64.efi'
C'est le chemin du chargeur EFI de secours (par défaut), qui ne devrait pas avoir besoin d'entrée de boot EFI pour démarrer.
A ce propos, tu peux installer une copie de GRUB dans cet emplacement (chemin de support amovible) avec : grub-install --removable Utile avec les firmwares UEFI buggés qui ne gèrent pas correctement les entrées de boot EFI. Cela écrasera un éventuel fichier EFIBootBootx64.efi déjà présent.
Christophe PEREZ
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Ok. Déjà, quand je reboote, rien ne semble avoir été enregistré : (chroot) 12:24:24 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony "Sony boot partition" en anglais C'est compatible/équivalent à une partition EFI ça ? (chroot) 12:27:40 / # rmdir /boot/EFI/ (chroot) 12:27:54 / # mkdir /boot/efi (chroot) 12:28:00 / # mount /dev/sda1 /boot/efi/ (chroot) 12:28:14 / # mount | grep /boot /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask 22,dmask 22, codepageC7,iocharset=iso8859-1,shortname=mixed, errors=remount-ro) (chroot) 12:28:41 / # ll /boot/efi/ total 13512 drwxr-xr-x 5 root root 4096 6 oct. 06:32 EFI -rwxr-xr-x 1 root root 4209036 23 août 08:44 System.map-5.4.60-gentoo -rwxr-xr-x 1 root root 105991 23 août 08:44 config-5.4.60-gentoo drwxr-xr-x 7 root root 4096 6 oct. 10:36 grub drwxr-xr-x 2 root root 4096 23 mars 2018 memtest86plus -rwxr-xr-x 1 root root 9504128 23 août 08:44 vmlinuz-5.4.60-gentoo
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il était évident pour moi que c'est un pb hard, puisque même dans le bios les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec un clavier USB, ça fonctionne.
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est
EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI
"Windows Boot Manager" est censée pointer.
Ok.
Déjà, quand je reboote, rien ne semble avoir été enregistré :
(chroot) 12:24:24 root@livecd / # efibootmgr
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000
Boot0000* EFI USB Device
C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage
Sony
"Sony boot partition" en anglais
C'est compatible/équivalent à une partition EFI ça ?
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install
m'a répondu :
grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur
/boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour /
dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans
/boot/grub/device.map. Sans importance, mais devrait être corrigé par
grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il
était évident pour moi que c'est un pb hard, puisque même dans le bios
les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec
un clavier USB, ça fonctionne.
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Ok. Déjà, quand je reboote, rien ne semble avoir été enregistré : (chroot) 12:24:24 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony "Sony boot partition" en anglais C'est compatible/équivalent à une partition EFI ça ? (chroot) 12:27:40 / # rmdir /boot/EFI/ (chroot) 12:27:54 / # mkdir /boot/efi (chroot) 12:28:00 / # mount /dev/sda1 /boot/efi/ (chroot) 12:28:14 / # mount | grep /boot /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask 22,dmask 22, codepageC7,iocharset=iso8859-1,shortname=mixed, errors=remount-ro) (chroot) 12:28:41 / # ll /boot/efi/ total 13512 drwxr-xr-x 5 root root 4096 6 oct. 06:32 EFI -rwxr-xr-x 1 root root 4209036 23 août 08:44 System.map-5.4.60-gentoo -rwxr-xr-x 1 root root 105991 23 août 08:44 config-5.4.60-gentoo drwxr-xr-x 7 root root 4096 6 oct. 10:36 grub drwxr-xr-x 2 root root 4096 23 mars 2018 memtest86plus -rwxr-xr-x 1 root root 9504128 23 août 08:44 vmlinuz-5.4.60-gentoo
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il était évident pour moi que c'est un pb hard, puisque même dans le bios les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec un clavier USB, ça fonctionne.
Christophe PEREZ
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Ok. Déjà, quand je reboote, rien ne semble avoir été enregistré : (chroot) 12:24:24 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony "Sony boot partition" en anglais C'est compatible/équivalent à une partition EFI ça ? (chroot) 12:27:40 / # rmdir /boot/EFI/ (chroot) 12:27:54 / # mkdir /boot/efi (chroot) 12:28:00 / # mount /dev/sda1 /boot/efi/ (chroot) 12:28:14 / # mount | grep /boot /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask 22,dmask 22, codepageC7,iocharset=iso8859-1,shortname=mixed, errors=remount-ro) (chroot) 12:28:41 / # ll /boot/efi/ total 13512 drwxr-xr-x 5 root root 4096 6 oct. 06:32 EFI -rwxr-xr-x 1 root root 4209036 23 août 08:44 System.map-5.4.60-gentoo -rwxr-xr-x 1 root root 105991 23 août 08:44 config-5.4.60-gentoo drwxr-xr-x 7 root root 4096 6 oct. 10:36 grub drwxr-xr-x 2 root root 4096 23 mars 2018 memtest86plus -rwxr-xr-x 1 root root 9504128 23 août 08:44 vmlinuz-5.4.60-gentoo
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il était évident pour moi que c'est un pb hard, puisque même dans le bios les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec un clavier USB, ça fonctionne.
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est
EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI
"Windows Boot Manager" est censée pointer.
Ok.
Déjà, quand je reboote, rien ne semble avoir été enregistré :
(chroot) 12:24:24 root@livecd / # efibootmgr
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000
Boot0000* EFI USB Device
C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage
Sony
"Sony boot partition" en anglais
C'est compatible/équivalent à une partition EFI ça ?
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install
m'a répondu :
grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur
/boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour /
dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans
/boot/grub/device.map. Sans importance, mais devrait être corrigé par
grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il
était évident pour moi que c'est un pb hard, puisque même dans le bios
les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec
un clavier USB, ça fonctionne.
Le Tue, 06 Oct 2020 21:53:02 +0200, Pascal Hambourg a écrit :
Le chargeur d'amorçage normal de Windows est EFIMicrosoftBootbootmgfw.efi, vers lequel l'entrée de boot EFI "Windows Boot Manager" est censée pointer.
Ok. Déjà, quand je reboote, rien ne semble avoir été enregistré : (chroot) 12:24:24 / # efibootmgr BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000 Boot0000* EFI USB Device C'est un problème que j'évoquais déjà.
C'est-à-dire ? Quel est son système de fichiers et son contenu ?
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony "Sony boot partition" en anglais C'est compatible/équivalent à une partition EFI ça ? (chroot) 12:27:40 / # rmdir /boot/EFI/ (chroot) 12:27:54 / # mkdir /boot/efi (chroot) 12:28:00 / # mount /dev/sda1 /boot/efi/ (chroot) 12:28:14 / # mount | grep /boot /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask 22,dmask 22, codepageC7,iocharset=iso8859-1,shortname=mixed, errors=remount-ro) (chroot) 12:28:41 / # ll /boot/efi/ total 13512 drwxr-xr-x 5 root root 4096 6 oct. 06:32 EFI -rwxr-xr-x 1 root root 4209036 23 août 08:44 System.map-5.4.60-gentoo -rwxr-xr-x 1 root root 105991 23 août 08:44 config-5.4.60-gentoo drwxr-xr-x 7 root root 4096 6 oct. 10:36 grub drwxr-xr-x 2 root root 4096 23 mars 2018 memtest86plus -rwxr-xr-x 1 root root 9504128 23 août 08:44 vmlinuz-5.4.60-gentoo
J'ai bien essayé en montant /dev/sda1 sur /boot, mais là grub-install m'a répondu : grub-install : erreur : impossible de trouver le répertoire EFI.
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Message lié à un démon de LVM, sans importance.
Je me doute bien ;)
grub-probe : erreur : impossible de trouver un périphérique GRUB pour / dev/sdb1. Vérifiez device.map..
Je suppose que /dev/sdb est la clé USB, et ne figure pas dans /boot/grub/device.map. Sans importance, mais devrait être corrigé par grub-mkdevicemap.
N'existe pas dans mon grub, mais pas important non plus.
Tu as testé avec un clavier externe ?
Je viens de le faire pour ne pas répondre sans être certain, mais il était évident pour moi que c'est un pb hard, puisque même dans le bios les touches 8, 9, l, flèche droite et 2/3 autres sont inopérantes. Avec un clavier USB, ça fonctionne.
Pascal Hambourg
Le 07/10/2020 à 02:31, Christophe PEREZ a écrit :
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony "Sony boot partition" en anglais C'est compatible/équivalent à une partition EFI ça ?
Apparement. Elle pourrait contenir des utilitaires spécifiques pour la mahine. Sinon tu pourrais changer son type en EFI standard.
Visiblement elle a été utilisée comme partition /boot. C'est une possibilité quand on utilise le gestionnaire d'amorçage systemd-boot. Si ce n'est plus le cas, il vaudrait mieux supprimer tout ce qui est en doublon avec le contenu actuel de /boot pour éviter la confusion. Quel est le contenu (complet) du répertoire EFI ?
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
Le 07/10/2020 à 02:31, Christophe PEREZ a écrit :
/dev/sda1 2048 534527 532480 260M Partition d'amorçage Sony
"Sony boot partition" en anglais
C'est compatible/équivalent à une partition EFI ça ?
Apparement. Elle pourrait contenir des utilitaires spécifiques pour la
mahine. Sinon tu pourrais changer son type en EFI standard.
Visiblement elle a été utilisée comme partition /boot. C'est une
possibilité quand on utilise le gestionnaire d'amorçage systemd-boot.
Si ce n'est plus le cas, il vaudrait mieux supprimer tout ce qui est en
doublon avec le contenu actuel de /boot pour éviter la confusion.
Quel est le contenu (complet) du répertoire EFI ?
grub-install s'attend à ce que la partition EFI soit montée sur
/boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Visiblement elle a été utilisée comme partition /boot. C'est une possibilité quand on utilise le gestionnaire d'amorçage systemd-boot. Si ce n'est plus le cas, il vaudrait mieux supprimer tout ce qui est en doublon avec le contenu actuel de /boot pour éviter la confusion. Quel est le contenu (complet) du répertoire EFI ?
grub-install s'attend à ce que la partition EFI soit montée sur /boot/efi.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
Christophe PEREZ
Le Wed, 07 Oct 2020 07:18:38 +0200, Pascal Hambourg a écrit :
Apparement. Elle pourrait contenir des utilitaires spécifiques pour la mahine. Sinon tu pourrais changer son type en EFI standard.
Elle pourrait, mais visiblement, ça a du être écrasé par une de mes manipulations.
Si ce n'est plus le cas, il vaudrait mieux supprimer tout ce qui est en doublon avec le contenu actuel de /boot pour éviter la confusion.
Ok, mais si je me fie à ce que je vois, je vire tout :D
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça. J'aurais pu monter /dev/sda1 sur /boot au lieu de /boot/efi, et utiliser la directive --efi-directory=/boot pour mon grub-install. Ça ne change certes pas grand chose, mais quand même un peu puisque du coup tous les éléments de boot comme grub et noyau (voire memtest etc...) sont sur la partition EFI(et /boot) au lieu d'être dans le sytème dans /boot. Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais j'imagine que ça doit en avoir dans d'autres cas. Pour info, le grub-install --removable n'a eu aucun effet non plus sur le boot.
Le Wed, 07 Oct 2020 07:18:38 +0200, Pascal Hambourg a écrit :
Apparement. Elle pourrait contenir des utilitaires spécifiques pour la
mahine. Sinon tu pourrais changer son type en EFI standard.
Elle pourrait, mais visiblement, ça a du être écrasé par une de mes
manipulations.
Si ce n'est plus le cas, il vaudrait mieux supprimer tout ce qui est en
doublon avec le contenu actuel de /boot pour éviter la confusion.
Ok, mais si je me fie à ce que je vois, je vire tout :D
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça.
J'aurais pu monter /dev/sda1 sur /boot au lieu de /boot/efi, et utiliser
la directive --efi-directory=/boot pour mon grub-install. Ça ne change
certes pas grand chose, mais quand même un peu puisque du coup tous les
éléments de boot comme grub et noyau (voire memtest etc...) sont sur la
partition EFI(et /boot) au lieu d'être dans le sytème dans /boot.
Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais
j'imagine que ça doit en avoir dans d'autres cas.
Pour info, le grub-install --removable n'a eu aucun effet non plus sur le
boot.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça. J'aurais pu monter /dev/sda1 sur /boot au lieu de /boot/efi, et utiliser la directive --efi-directory=/boot pour mon grub-install. Ça ne change certes pas grand chose, mais quand même un peu puisque du coup tous les éléments de boot comme grub et noyau (voire memtest etc...) sont sur la partition EFI(et /boot) au lieu d'être dans le sytème dans /boot. Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais j'imagine que ça doit en avoir dans d'autres cas. Pour info, le grub-install --removable n'a eu aucun effet non plus sur le boot.
Pascal Hambourg
Le 07/10/2020 à 13:49, Christophe PEREZ a écrit :
Le Wed, 07 Oct 2020 07:18:38 +0200, Pascal Hambourg a écrit :
il vaudrait mieux supprimer tout ce qui est en doublon avec le contenu actuel de /boot pour éviter la confusion.
Ok, mais si je me fie à ce que je vois, je vire tout :D
(...) Ça ressemble au contenu normal d'une partition EFI dans laquelle Windows et Gentoo ont installé leurs chargeurs respectifs. Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça.
Parce que ça crée des complications (il faut forcer le chemin) et aucun avantage en contre-partie.
Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais j'imagine que ça doit en avoir dans d'autres cas.
Dans les rares cas où on voudrait un /boot séparé sans créer une partition supplémentaire dédiée.
Pour info, le grub-install --removable n'a eu aucun effet non plus sur le boot.
Pas étonnant puisqu'il y avait déjà un fichier EFI/boot/bootx64.efi mis en place par Windows et qu'il n'était pas pris en compte. Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony en EFI standard pour voir si ça change quelque chose.
Le 07/10/2020 à 13:49, Christophe PEREZ a écrit :
Le Wed, 07 Oct 2020 07:18:38 +0200, Pascal Hambourg a écrit :
il vaudrait mieux supprimer tout ce qui est en
doublon avec le contenu actuel de /boot pour éviter la confusion.
Ok, mais si je me fie à ce que je vois, je vire tout :D
Ça ressemble au contenu normal d'une partition EFI dans laquelle Windows
et Gentoo ont installé leurs chargeurs respectifs.
Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce
qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça.
Parce que ça crée des complications (il faut forcer le chemin) et aucun
avantage en contre-partie.
Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais
j'imagine que ça doit en avoir dans d'autres cas.
Dans les rares cas où on voudrait un /boot séparé sans créer une
partition supplémentaire dédiée.
Pour info, le grub-install --removable n'a eu aucun effet non plus sur le
boot.
Pas étonnant puisqu'il y avait déjà un fichier EFI/boot/bootx64.efi mis
en place par Windows et qu'il n'était pas pris en compte.
Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony
en EFI standard pour voir si ça change quelque chose.
(...) Ça ressemble au contenu normal d'une partition EFI dans laquelle Windows et Gentoo ont installé leurs chargeurs respectifs. Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je suppose que j'aurais pu/du utiliser --efi-directory=/boot
Cela n'a pas d'intérêt avec GRUB.
J'ai du mal à comprendre pourquoi tu dis ça.
Parce que ça crée des complications (il faut forcer le chemin) et aucun avantage en contre-partie.
Dans mon cas, ça n'a effectivement pas spécialement d'intêret, mais j'imagine que ça doit en avoir dans d'autres cas.
Dans les rares cas où on voudrait un /boot séparé sans créer une partition supplémentaire dédiée.
Pour info, le grub-install --removable n'a eu aucun effet non plus sur le boot.
Pas étonnant puisqu'il y avait déjà un fichier EFI/boot/bootx64.efi mis en place par Windows et qu'il n'était pas pris en compte. Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony en EFI standard pour voir si ça change quelque chose.
Christophe PEREZ
Le Wed, 07 Oct 2020 22:03:06 +0200, Pascal Hambourg a écrit :
Ok, mais si je me fie à ce que je vois, je vire tout :D
Seulement ce qui est en dehors du répertoire EFI.
Fait.
Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je l'ai pensé, mais j'attendais ton sentiment.
Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony en EFI standard pour voir si ça change quelque chose.
Alors je l'ai fait. Puis j'ai booté en EFI sur clé. A nouveau grub-install, et j'ai constaté que efibootmgr avait à nouveau une entrée "Windows Boot Manager". Par contre, os-prober ne voit toujours pas Windows. Et quand je boote, pas de choix, Windows se lance, et m'envoie sur son système de restauration VAIO, qui me permet de restaurer le système d'origine, en écrasant tout. Mais ce n'est pas le but.
Le Wed, 07 Oct 2020 22:03:06 +0200, Pascal Hambourg a écrit :
Ok, mais si je me fie à ce que je vois, je vire tout :D
Seulement ce qui est en dehors du répertoire EFI.
Fait.
Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce
qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je l'ai pensé, mais j'attendais ton sentiment.
Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony
en EFI standard pour voir si ça change quelque chose.
Alors je l'ai fait. Puis j'ai booté en EFI sur clé.
A nouveau grub-install, et j'ai constaté que efibootmgr avait à nouveau
une entrée "Windows Boot Manager".
Par contre, os-prober ne voit toujours pas Windows.
Et quand je boote, pas de choix, Windows se lance, et m'envoie sur son
système de restauration VAIO, qui me permet de restaurer le système
d'origine, en écrasant tout. Mais ce n'est pas le but.
Le Wed, 07 Oct 2020 22:03:06 +0200, Pascal Hambourg a écrit :
Ok, mais si je me fie à ce que je vois, je vire tout :D
Seulement ce qui est en dehors du répertoire EFI.
Fait.
Peut--être qu'os-prober n'a pas détecté le chargeur de Windows parce qu'il ne regarde que dans les partitions qui ont le type EFI standard.
Je l'ai pensé, mais j'attendais ton sentiment.
Je pense que ça vaudrait le coup d'essayer de changer le type EFI Sony en EFI standard pour voir si ça change quelque chose.
Alors je l'ai fait. Puis j'ai booté en EFI sur clé. A nouveau grub-install, et j'ai constaté que efibootmgr avait à nouveau une entrée "Windows Boot Manager". Par contre, os-prober ne voit toujours pas Windows. Et quand je boote, pas de choix, Windows se lance, et m'envoie sur son système de restauration VAIO, qui me permet de restaurer le système d'origine, en écrasant tout. Mais ce n'est pas le but.
