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.
Le Sat, 03 Oct 2020 12:48:51 -0700, Christophe PEREZ a écrit :
PS : j'ai déjà posté plusieurs fois ce message ce matin, mais mon INN a refusé de le relayer, pour une autre raison obscure. En attendant de trouver la raison, je le poste par ce biais.
Désolé pour la ligne trop longue. Plus précisément c'est le serveur NNTP de free qui me le rejette pour "inconsistent line termination". Et il coupe la première ligne, quelque soit ce qu'elle contient... Ça fera l'objet d'une autre investigation.
Le Sat, 03 Oct 2020 12:48:51 -0700, Christophe PEREZ a écrit :
PS : j'ai déjà posté plusieurs fois ce message ce matin, mais mon INN a
refusé de le relayer, pour une autre raison obscure. En attendant de
trouver la raison, je le poste par ce biais.
Désolé pour la ligne trop longue.
Plus précisément c'est le serveur NNTP de free qui me le rejette pour
"inconsistent line termination". Et il coupe la première ligne, quelque
soit ce qu'elle contient... Ça fera l'objet d'une autre investigation.
Le Sat, 03 Oct 2020 12:48:51 -0700, Christophe PEREZ a écrit :
PS : j'ai déjà posté plusieurs fois ce message ce matin, mais mon INN a refusé de le relayer, pour une autre raison obscure. En attendant de trouver la raison, je le poste par ce biais.
Désolé pour la ligne trop longue. Plus précisément c'est le serveur NNTP de free qui me le rejette pour "inconsistent line termination". Et il coupe la première ligne, quelque soit ce qu'elle contient... Ça fera l'objet d'une autre investigation.
Pascal Hambourg
Le 03/10/2020 à 21:48, Christophe PEREZ a écrit :
J'avais composé ce post hier.
Et tu aurais dû le poster et attendre les commentaires.
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub- install me jette : :/# grub-install /dev/sda Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS. Soit tu as booté en mode BIOS/legacy, soit tu n'as pas chargé les modules/monté les systèmes de fichiers EFI qui vont bien dans ton chroot.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus. Peux-tu montrer la situation actuelle des partitions ?
On peut juste choisir l'ordre de boot entre External device, Internal device, DVD et Network. On peut activer/désactiver External device et Network. Et c'est évidemment totalement indépendant du mode de boot EFI/ Legacy. Donc si je parviens à booter sur clé en mode EFI, pourquoi je n'y parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du disque. Tu peux afficher un menu de boot et sélectionner le mode/périphérique d'amorçage ? Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Le 03/10/2020 à 21:48, Christophe PEREZ a écrit :
J'avais composé ce post hier.
Et tu aurais dû le poster et attendre les commentaires.
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub-
install me jette :
root@livecd:/# grub-install /dev/sda
Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS. Soit tu
as booté en mode BIOS/legacy, soit tu n'as pas chargé les modules/monté
les systèmes de fichiers EFI qui vont bien dans ton chroot.
grub-install: warning: this GPT partition label contains no BIOS Boot
Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus. Peux-tu
montrer la situation actuelle des partitions ?
On peut juste choisir l'ordre de boot entre External device, Internal
device, DVD et Network. On peut activer/désactiver External device et
Network. Et c'est évidemment totalement indépendant du mode de boot EFI/
Legacy. Donc si je parviens à booter sur clé en mode EFI, pourquoi je n'y
parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du
disque. Tu peux afficher un menu de boot et sélectionner le
mode/périphérique d'amorçage ? Tu as vérifié que ces clés bootent en
mode legacy sur une autre machine ?
Et tu aurais dû le poster et attendre les commentaires.
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub- install me jette : :/# grub-install /dev/sda Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS. Soit tu as booté en mode BIOS/legacy, soit tu n'as pas chargé les modules/monté les systèmes de fichiers EFI qui vont bien dans ton chroot.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus. Peux-tu montrer la situation actuelle des partitions ?
On peut juste choisir l'ordre de boot entre External device, Internal device, DVD et Network. On peut activer/désactiver External device et Network. Et c'est évidemment totalement indépendant du mode de boot EFI/ Legacy. Donc si je parviens à booter sur clé en mode EFI, pourquoi je n'y parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du disque. Tu peux afficher un menu de boot et sélectionner le mode/périphérique d'amorçage ? Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Christophe PEREZ
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Et tu aurais dû le poster et attendre les commentaires.
C'est sûr, mais la patience n'est pas ma qualité principale. Et en plus, avec les NG, on n'est jamais sur d'avoir une réponse, ni quand on l'aura. Donc j'ai tendance à continuer mes investigations. Et puis, je voulais être le complet possible. Le nombre de fois où j'ai trouvé la solution juste après avoir cliqué sur "envoyer" :)
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub- install me jette : :/# grub-install /dev/sda Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS.
Oui, ça, j'ai bien compris.
Soit tu as booté en mode BIOS/legacy,
Sûr que non.
soit tu n'as pas chargé les modules/monté les systèmes de fichiers EFI qui vont bien dans ton chroot.
Ça, c'est bien possible. Cependant, quand ça fonctionnait, je ne les avais pas plus montés... Mais peut-être était-ce en boot mode Legacy, quand les clés bootaient encore. Je ne peux plus rien affirmer.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
Peux-tu montrer la situation actuelle des partitions ?
# LANG=C fdisk -l /dev/sda Disk /dev/sda: 698.65 GiB, 750156374016 bytes, 1465149168 sectors Disk model: Hitachi HTS54757 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 705E99A4-620B-4C25-9D82-70A618FD6AEB Device Start End Sectors Size Type /dev/sda1 2048 534527 532480 260M Sony boot partition /dev/sda2 534528 35080191 34545664 16.5G Windows recovery environment /dev/sda3 35080192 35612671 532480 260M EFI System /dev/sda4 35612672 35874815 262144 128M Microsoft reserved /dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data /dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem /dev/sda7 428713984 445493247 16779264 8G Linux swap /dev/sda8 445493248 1257138175 811644928 387G Linux filesystem /dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem Sachant que les partitions 8 et 9 sont interverties suite à l'option "tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était pas dans l'ordre du disque. J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine. Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc comme ça.
Donc si je parviens à booter sur clé en mode EFI, pourquoi je n'y parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du disque.
Moi non plus, et je trouve ça particulièrement perturbant.
Tu peux afficher un menu de boot et sélectionner le mode/périphérique d'amorçage ?
A priori non. Les 2 options que j'ai au boot sont l'accès au bios (F2) ou au boot réseau (F12). Rien d'autre ne semble avoir d'effet, sauf erreur de ma part. Pour l'ordre de boot, la sélection, c'est forcément dans le bios.
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Non, je vais le faire de ce pas. Je préférais répondre avant, puisque seul mon PC me le permettra (boot USB en Legacy). 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é. Merci pour ton aide, une nouvelle fois.
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Et tu aurais dû le poster et attendre les commentaires.
C'est sûr, mais la patience n'est pas ma qualité principale. Et en plus,
avec les NG, on n'est jamais sur d'avoir une réponse, ni quand on l'aura.
Donc j'ai tendance à continuer mes investigations. Et puis, je voulais
être le complet possible.
Le nombre de fois où j'ai trouvé la solution juste après avoir cliqué sur
"envoyer" :)
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub-
install me jette :
root@livecd:/# grub-install /dev/sda Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS.
Oui, ça, j'ai bien compris.
Soit tu as booté en mode BIOS/legacy,
Sûr que non.
soit tu n'as pas chargé les modules/monté les systèmes de fichiers EFI
qui vont bien dans ton chroot.
Ça, c'est bien possible. Cependant, quand ça fonctionnait, je ne les
avais pas plus montés... Mais peut-être était-ce en boot mode Legacy,
quand les clés bootaient encore. Je ne peux plus rien affirmer.
grub-install: warning: this GPT partition label contains no BIOS Boot
Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
Peux-tu montrer la situation actuelle des partitions ?
Device Start End Sectors Size Type
/dev/sda1 2048 534527 532480 260M Sony boot partition
/dev/sda2 534528 35080191 34545664 16.5G Windows recovery
environment
/dev/sda3 35080192 35612671 532480 260M EFI System
/dev/sda4 35612672 35874815 262144 128M Microsoft reserved
/dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data
/dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem
/dev/sda7 428713984 445493247 16779264 8G Linux swap
/dev/sda8 445493248 1257138175 811644928 387G Linux filesystem
/dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem
Sachant que les partitions 8 et 9 sont interverties suite à l'option
"tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était
pas dans l'ordre du disque.
J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque
chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier
post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine.
Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type
dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc
comme ça.
Donc si je parviens à booter sur clé en mode EFI, pourquoi
je n'y parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du
disque.
Moi non plus, et je trouve ça particulièrement perturbant.
Tu peux afficher un menu de boot et sélectionner le
mode/périphérique d'amorçage ?
A priori non.
Les 2 options que j'ai au boot sont l'accès au bios (F2) ou au boot
réseau (F12). Rien d'autre ne semble avoir d'effet, sauf erreur de ma
part.
Pour l'ordre de boot, la sélection, c'est forcément dans le bios.
Tu as vérifié que ces clés bootent en mode legacy sur une autre
machine ?
Non, je vais le faire de ce pas. Je préférais répondre avant, puisque
seul mon PC me le permettra (boot USB en Legacy).
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é.
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Et tu aurais dû le poster et attendre les commentaires.
C'est sûr, mais la patience n'est pas ma qualité principale. Et en plus, avec les NG, on n'est jamais sur d'avoir une réponse, ni quand on l'aura. Donc j'ai tendance à continuer mes investigations. Et puis, je voulais être le complet possible. Le nombre de fois où j'ai trouvé la solution juste après avoir cliqué sur "envoyer" :)
Maintenant, en bootant en EFI avec clé USB, et chroot Ubuntu, le grub- install me jette : :/# grub-install /dev/sda Installing for i386-pc platform.
Ce message indique que grub-install va installer GRUB pour BIOS.
Oui, ça, j'ai bien compris.
Soit tu as booté en mode BIOS/legacy,
Sûr que non.
soit tu n'as pas chargé les modules/monté les systèmes de fichiers EFI qui vont bien dans ton chroot.
Ça, c'est bien possible. Cependant, quand ça fonctionnait, je ne les avais pas plus montés... Mais peut-être était-ce en boot mode Legacy, quand les clés bootaient encore. Je ne peux plus rien affirmer.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
Peux-tu montrer la situation actuelle des partitions ?
# LANG=C fdisk -l /dev/sda Disk /dev/sda: 698.65 GiB, 750156374016 bytes, 1465149168 sectors Disk model: Hitachi HTS54757 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 705E99A4-620B-4C25-9D82-70A618FD6AEB Device Start End Sectors Size Type /dev/sda1 2048 534527 532480 260M Sony boot partition /dev/sda2 534528 35080191 34545664 16.5G Windows recovery environment /dev/sda3 35080192 35612671 532480 260M EFI System /dev/sda4 35612672 35874815 262144 128M Microsoft reserved /dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data /dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem /dev/sda7 428713984 445493247 16779264 8G Linux swap /dev/sda8 445493248 1257138175 811644928 387G Linux filesystem /dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem Sachant que les partitions 8 et 9 sont interverties suite à l'option "tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était pas dans l'ordre du disque. J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine. Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc comme ça.
Donc si je parviens à booter sur clé en mode EFI, pourquoi je n'y parviens plus en mode Legacy ?
Aucune idée. En tout cas je ne vois pas le rapport avec le contenu du disque.
Moi non plus, et je trouve ça particulièrement perturbant.
Tu peux afficher un menu de boot et sélectionner le mode/périphérique d'amorçage ?
A priori non. Les 2 options que j'ai au boot sont l'accès au bios (F2) ou au boot réseau (F12). Rien d'autre ne semble avoir d'effet, sauf erreur de ma part. Pour l'ordre de boot, la sélection, c'est forcément dans le bios.
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Non, je vais le faire de ce pas. Je préférais répondre avant, puisque seul mon PC me le permettra (boot USB en Legacy). 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é. Merci pour ton aide, une nouvelle fois.
Christophe PEREZ
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Non, je vais le faire de ce pas
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). Bon, le problème initial ne provient évidemment pas de là puisque c'est quand elle n'a plus booté que je l'ai refaite. Et c'est quand je n'arrivais à rien que j'ai tenté avec une autre clé. Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ? J'ai d'abord pensé que c'était ma clé qui était en cause, mais je l'ai refaite tellement de fois de façons différentes, avec différentes ISO, que j'en était arrivé à penser que le problème n'était donc pas la clé. Mauvaise déduction. Celle qui fonctionnait, au début de tout ça, avait été faite avec unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps). J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y soit incorporé, sans plus de succès. J'ai un peu avancé : J'ai récupéré usbimager qui m'a généré la clé avec mon iso gentoo (récente) et qui boote bien en mode Legacy. J'ai chrooté Ubuntu. Lancé (chroot) :/# grub-install /dev/sda Installing for i386-pc platform. grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub-install: error: will not proceed with blocklists. J'ai alors changé le type de /dev/sda3 en "BIOS Boot" avec cfdisk. (chroot) :/# cfdisk /dev/sda Syncing disks. (chroot) :/# grub-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. J'ai un peu bidouillé la config grub et j'en suis presque revenu au point original, si ce n'est que ma gentoo ne boote toujours pas (https://ibb.co/ Jm3d8LK), mais là, c'est sans doute une question de config grub dans ubuntu (je crois que le grub-install m'écrase /dev/sda3, que je ne peux plus monter "wrong fs type"). Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être n'ai-je pas spécialement d'intérêt à y corriger sa config.
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine
?
Non, je vais le faire de ce pas
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).
Bon, le problème initial ne provient évidemment pas de là puisque c'est
quand elle n'a plus booté que je l'ai refaite. Et c'est quand je
n'arrivais à rien que j'ai tenté avec une autre clé.
Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ?
J'ai d'abord pensé que c'était ma clé qui était en cause, mais je l'ai
refaite tellement de fois de façons différentes, avec différentes ISO,
que j'en était arrivé à penser que le problème n'était donc pas la clé.
Mauvaise déduction.
Celle qui fonctionnait, au début de tout ça, avait été faite avec
unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps).
J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à
trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y
soit incorporé, sans plus de succès.
J'ai un peu avancé :
J'ai récupéré usbimager qui m'a généré la clé avec mon iso gentoo
(récente) et qui boote bien en mode Legacy.
J'ai chrooté Ubuntu.
Lancé
(chroot) root@livecd:/# grub-install /dev/sda
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot
Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.
J'ai alors changé le type de /dev/sda3 en "BIOS Boot" avec cfdisk.
(chroot) root@livecd:/# cfdisk /dev/sda
Syncing disks.
(chroot) root@livecd:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
J'ai un peu bidouillé la config grub et j'en suis presque revenu au point
original, si ce n'est que ma gentoo ne boote toujours pas (https://ibb.co/
Jm3d8LK), mais là, c'est sans doute une question de config grub dans
ubuntu (je crois que le grub-install m'écrase /dev/sda3, que je ne peux
plus monter "wrong fs type").
Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être
n'ai-je pas spécialement d'intérêt à y corriger sa config.
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
Non, je vais le faire de ce pas
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). Bon, le problème initial ne provient évidemment pas de là puisque c'est quand elle n'a plus booté que je l'ai refaite. Et c'est quand je n'arrivais à rien que j'ai tenté avec une autre clé. Ça vient de l'iso utilisée ou de la façon de l'installer sur la clé ? J'ai d'abord pensé que c'était ma clé qui était en cause, mais je l'ai refaite tellement de fois de façons différentes, avec différentes ISO, que j'en était arrivé à penser que le problème n'était donc pas la clé. Mauvaise déduction. Celle qui fonctionnait, au début de tout ça, avait été faite avec unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps). J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y soit incorporé, sans plus de succès. J'ai un peu avancé : J'ai récupéré usbimager qui m'a généré la clé avec mon iso gentoo (récente) et qui boote bien en mode Legacy. J'ai chrooté Ubuntu. Lancé (chroot) :/# grub-install /dev/sda Installing for i386-pc platform. grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub-install: error: will not proceed with blocklists. J'ai alors changé le type de /dev/sda3 en "BIOS Boot" avec cfdisk. (chroot) :/# cfdisk /dev/sda Syncing disks. (chroot) :/# grub-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. J'ai un peu bidouillé la config grub et j'en suis presque revenu au point original, si ce n'est que ma gentoo ne boote toujours pas (https://ibb.co/ Jm3d8LK), mais là, c'est sans doute une question de config grub dans ubuntu (je crois que le grub-install m'écrase /dev/sda3, que je ne peux plus monter "wrong fs type"). Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être n'ai-je pas spécialement d'intérêt à y corriger sa config.
Christophe PEREZ
Le Sat, 03 Oct 2020 23:20:21 +0000, Christophe PEREZ a écrit :
Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être n'ai-je pas spécialement d'intérêt à y corriger sa config.
J'ai tenté le grub-install /dev/sda depuis le chroot gentoo, puis génération du grub.cfg. Pas d'erreur, mais au reboot, c'est reboot en boucle, en affichant très brièvement GRUB loading ou loader, difficile à voir. Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Le Sat, 03 Oct 2020 23:20:21 +0000, Christophe PEREZ a écrit :
Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être
n'ai-je pas spécialement d'intérêt à y corriger sa config.
J'ai tenté le grub-install /dev/sda depuis le chroot gentoo, puis
génération du grub.cfg. Pas d'erreur, mais au reboot, c'est reboot en
boucle, en affichant très brièvement GRUB loading ou loader, difficile à
voir.
Une question qui est peut-être la clé/mon erreur : sur partitionnement
DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec
GPT ?
Le Sat, 03 Oct 2020 23:20:21 +0000, Christophe PEREZ a écrit :
Mais comme mon ambition est justement de m'absoudre de ubuntu, peut-être n'ai-je pas spécialement d'intérêt à y corriger sa config.
J'ai tenté le grub-install /dev/sda depuis le chroot gentoo, puis génération du grub.cfg. Pas d'erreur, mais au reboot, c'est reboot en boucle, en affichant très brièvement GRUB loading ou loader, difficile à voir. Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Christophe PEREZ
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Je crois que tout mon problème vient/venait de l'incompréhension de ces notions. J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile. Et j'ai pu installer et configurer grub à partir de Gentoo. Je devrais pouvoir virer Ubuntu après toutes les vérifications d'usage. Tout ça pour ça :D Merci pour votre attention, et particulièrement à Pascal dont l'aide et les conseils sont toujours aussi précieux.
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement
DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec
GPT ?
Je crois que tout mon problème vient/venait de l'incompréhension de ces
notions.
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Et j'ai pu installer et configurer grub à partir de Gentoo.
Je devrais pouvoir virer Ubuntu après toutes les vérifications d'usage.
Tout ça pour ça :D
Merci pour votre attention, et particulièrement à Pascal dont l'aide et
les conseils sont toujours aussi précieux.
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Je crois que tout mon problème vient/venait de l'incompréhension de ces notions. J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile. Et j'ai pu installer et configurer grub à partir de Gentoo. Je devrais pouvoir virer Ubuntu après toutes les vérifications d'usage. Tout ça pour ça :D Merci pour votre attention, et particulièrement à Pascal dont l'aide et les conseils sont toujours aussi précieux.
Pascal Hambourg
Le 04/10/2020 à 06:02, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Qu'appelles-tu "partition de boot" ? Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée), alors c'est indépendant du type de table de partition et cela peut être n'importe quel type de système de fichiers supporté par GRUB. Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en GPT et ne contient pas de système de fichiers mais seulement la core image de GRUB écrite directement, comme en faisant cat core.img > /dev/sdaX
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ? Je n'ai pas vu de partition /boot dans ta table de partition. La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand elle ne l'est pas elle reste fortement recommandée, et son absence exige de forcer l'installation de GRUB avec l'option --force de grub-install. Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi, elle ne sert à rien pour l'amorçage BIOS/legacy.
Le 04/10/2020 à 06:02, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement
DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec
GPT ?
Qu'appelles-tu "partition de boot" ?
Si c'est la partition où se trouve le contenu du répertoire /boot
(racine ou partition /boot séparée), alors c'est indépendant du type de
table de partition et cela peut être n'importe quel type de système de
fichiers supporté par GRUB.
Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en
GPT et ne contient pas de système de fichiers mais seulement la core
image de GRUB écrite directement, comme en faisant
cat core.img > /dev/sdaX
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ?
Je n'ai pas vu de partition /boot dans ta table de partition.
La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur
quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand
elle ne l'est pas elle reste fortement recommandée, et son absence exige
de forcer l'installation de GRUB avec l'option --force de grub-install.
Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi,
elle ne sert à rien pour l'amorçage BIOS/legacy.
Le Sat, 03 Oct 2020 23:44:50 +0000, Christophe PEREZ a écrit :
Une question qui est peut-être la clé/mon erreur : sur partitionnement DOS, la partition de boot peut être en ext2, mais est-ce aussi vrai avec GPT ?
Qu'appelles-tu "partition de boot" ? Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée), alors c'est indépendant du type de table de partition et cela peut être n'importe quel type de système de fichiers supporté par GRUB. Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en GPT et ne contient pas de système de fichiers mais seulement la core image de GRUB écrite directement, comme en faisant cat core.img > /dev/sdaX
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ? Je n'ai pas vu de partition /boot dans ta table de partition. La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand elle ne l'est pas elle reste fortement recommandée, et son absence exige de forcer l'installation de GRUB avec l'option --force de grub-install. Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi, elle ne sert à rien pour l'amorçage BIOS/legacy.
Pascal Hambourg
Le 03/10/2020 à 23:35, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
(...)
Device Start End Sectors Size Type /dev/sda1 2048 534527 532480 260M Sony boot partition /dev/sda2 534528 35080191 34545664 16.5G Windows recovery environment /dev/sda3 35080192 35612671 532480 260M EFI System /dev/sda4 35612672 35874815 262144 128M Microsoft reserved /dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data /dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem /dev/sda7 428713984 445493247 16779264 8G Linux swap /dev/sda8 445493248 1257138175 811644928 387G Linux filesystem /dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem
Comme je disais : pas de partition de type "BIOS boot". /dev/sda3 a le type "système EFI" qui ne convient pas pour l'installation de GRUB en mode BIOS/legacy.
Sachant que les partitions 8 et 9 sont interverties suite à l'option "tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était pas dans l'ordre du disque.
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.
J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine. Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc comme ça.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS. 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.
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 ?
Le 03/10/2020 à 23:35, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
(...)
Device Start End Sectors Size Type
/dev/sda1 2048 534527 532480 260M Sony boot partition
/dev/sda2 534528 35080191 34545664 16.5G Windows recovery
environment
/dev/sda3 35080192 35612671 532480 260M EFI System
/dev/sda4 35612672 35874815 262144 128M Microsoft reserved
/dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data
/dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem
/dev/sda7 428713984 445493247 16779264 8G Linux swap
/dev/sda8 445493248 1257138175 811644928 387G Linux filesystem
/dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem
Comme je disais : pas de partition de type "BIOS boot". /dev/sda3 a le
type "système EFI" qui ne convient pas pour l'installation de GRUB en
mode BIOS/legacy.
Sachant que les partitions 8 et 9 sont interverties suite à l'option
"tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était
pas dans l'ordre du disque.
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.
J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque
chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier
post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine.
Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type
dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc
comme ça.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS.
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.
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é.
Le Sat, 03 Oct 2020 22:36:30 +0200, Pascal Hambourg a écrit :
Donc la partition BIOS boot affichée par fdisk n'existe plus.
Ben pourtant...
(...)
Device Start End Sectors Size Type /dev/sda1 2048 534527 532480 260M Sony boot partition /dev/sda2 534528 35080191 34545664 16.5G Windows recovery environment /dev/sda3 35080192 35612671 532480 260M EFI System /dev/sda4 35612672 35874815 262144 128M Microsoft reserved /dev/sda5 35874816 240674815 204800000 97.7G Microsoft basic data /dev/sda6 240674816 428713983 188039168 89.7G Linux filesystem /dev/sda7 428713984 445493247 16779264 8G Linux swap /dev/sda8 445493248 1257138175 811644928 387G Linux filesystem /dev/sda9 1257138176 1465147391 208009216 99.2G Linux filesystem
Comme je disais : pas de partition de type "BIOS boot". /dev/sda3 a le type "système EFI" qui ne convient pas pour l'installation de GRUB en mode BIOS/legacy.
Sachant que les partitions 8 et 9 sont interverties suite à l'option "tri" de cfdisk qui (comme fdisk) me signalait que les partitions n'était pas dans l'ordre du disque.
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.
J'ai beaucoup touché à sda3, mais je pense (à moins qu'il y ait quelque chose que je ne vois pas) l'avoir remise dans l'état initial. Mon premier post indiquait Amorçage BIOS, mais ce n'est pas ce qui était d'origine. Il était question d'EFI, et je n'ai trouvé que "EFI System" comme type dans fdisk. J'avais l'impression d'avoir mémorisé "Boot EFI" ou un truc comme ça.
Une partition EFI ne sert à rien pour l'amorçage en mode BIOS. 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.
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 ?
Pascal Hambourg
Le 04/10/2020 à 01:20, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
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).
Original. Habituellement en mode EFI+legacy c'est l'amorçage EFI qui a la priorité. Que se passe-t-il exactement ?
Ç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. 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.
Celle qui fonctionnait, au début de tout ça, avait été faite avec unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps). J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y soit incorporé, sans plus de succès.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé avec les images ISO hybrides de Debian.
(je crois que le grub-install m'écrase /dev/sda3, que je ne peux plus monter "wrong fs type").
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. Note : la core image de GRUB fait moins de 100 ko, une partition BIOS boot de 260 Mo est donc largement disproportionnée. Habituellement on crée une partition BIOS boot de 1 Mio car c'est la taille minimale si on respecte l'alignement standard sur des blocs de 1 Mio. Plutôt que transformer la partition EFI en BIOS boot, tu aurais pu soit la réduire légèrement pour avoir la place de créer une partition BIOS boot, soit créer une partition BIOS boot dans un petit espace libre comme celui qui existe au début du disque entre la table de partition et la première partition. Elle ne sera pas alignée mais ça n'a aucune importance. 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.
Le 04/10/2020 à 01:20, Christophe PEREZ a écrit :
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine
?
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).
Original. Habituellement en mode EFI+legacy c'est l'amorçage EFI qui a
la priorité.
Que se passe-t-il exactement ?
Ç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.
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.
Celle qui fonctionnait, au début de tout ça, avait été faite avec
unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps).
J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à
trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y
soit incorporé, sans plus de succès.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé
avec les images ISO hybrides de Debian.
(je crois que le grub-install m'écrase /dev/sda3, que je ne peux
plus monter "wrong fs type").
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.
Note : la core image de GRUB fait moins de 100 ko, une partition BIOS
boot de 260 Mo est donc largement disproportionnée. Habituellement on
crée une partition BIOS boot de 1 Mio car c'est la taille minimale si on
respecte l'alignement standard sur des blocs de 1 Mio. Plutôt que
transformer la partition EFI en BIOS boot, tu aurais pu soit la réduire
légèrement pour avoir la place de créer une partition BIOS boot, soit
créer une partition BIOS boot dans un petit espace libre comme celui qui
existe au début du disque entre la table de partition et la première
partition. Elle ne sera pas alignée mais ça n'a aucune importance.
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.
Le Sat, 03 Oct 2020 21:35:48 +0000, Christophe PEREZ a écrit :
Tu as vérifié que ces clés bootent en mode legacy sur une autre machine ?
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).
Original. Habituellement en mode EFI+legacy c'est l'amorçage EFI qui a la priorité. Que se passe-t-il exactement ?
Ç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. 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.
Celle qui fonctionnait, au début de tout ça, avait été faite avec unetbootin, et une ISO gentoo (que j'ai supprimée depuis lgtps). J'ai donc fait avec une ISO gentoo récente, sans succès. J'ai réussi à trouver des ISO de 2017/2018, qui pourraient dater d'avant que l'EFI n'y soit incorporé, sans plus de succès.
Je ne sais pas qu'il en est pour Gentoo, mais Unetbootin est déconseillé avec les images ISO hybrides de Debian.
(je crois que le grub-install m'écrase /dev/sda3, que je ne peux plus monter "wrong fs type").
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. Note : la core image de GRUB fait moins de 100 ko, une partition BIOS boot de 260 Mo est donc largement disproportionnée. Habituellement on crée une partition BIOS boot de 1 Mio car c'est la taille minimale si on respecte l'alignement standard sur des blocs de 1 Mio. Plutôt que transformer la partition EFI en BIOS boot, tu aurais pu soit la réduire légèrement pour avoir la place de créer une partition BIOS boot, soit créer une partition BIOS boot dans un petit espace libre comme celui qui existe au début du disque entre la table de partition et la première partition. Elle ne sera pas alignée mais ça n'a aucune importance. 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.
Christophe PEREZ
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
Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée), alors c'est indépendant du type de table de partition et cela peut être n'importe quel type de système de fichiers supporté par GRUB. Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en GPT et ne contient pas de système de fichiers mais seulement la core image de GRUB écrite directement, comme en faisant
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.
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ?
Quand j'ai enfin compris que "BIOS boot partition" n'est pas "Boot partition", et qu'il fallait donc que j'arrête d'écraser ce que faisait grub-install en mettant mes données de partition de boot par dessus, d'autant que cette partition de boot séparée est totalement inutile dans mon cas, alors, tout s'est éclairé :D
Je n'ai pas vu de partition /boot dans ta table de partition.
Toi tu ne l'as pas vue, mais moi, je ne voyais que ça en /dev/sda3 :)
La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand elle ne l'est pas elle reste fortement recommandée, et son absence exige de forcer l'installation de GRUB avec l'option --force de grub-install.
Voilà, c'est tout ça que j'ai compris, par la force des choses et de l'expérimentation.
Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi, elle ne sert à rien pour l'amorçage BIOS/legacy.
Ben oui, ça aussi j'ai fini par le comprendre.
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
Si c'est la partition où se trouve le contenu du répertoire /boot
(racine ou partition /boot séparée), alors c'est indépendant du type de
table de partition et cela peut être n'importe quel type de système de
fichiers supporté par GRUB.
Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en
GPT et ne contient pas de système de fichiers mais seulement la core
image de GRUB écrite directement, comme en faisant
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.
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ?
Quand j'ai enfin compris que "BIOS boot partition" n'est pas "Boot
partition", et qu'il fallait donc que j'arrête d'écraser ce que faisait
grub-install en mettant mes données de partition de boot par dessus,
d'autant que cette partition de boot séparée est totalement inutile dans
mon cas, alors, tout s'est éclairé :D
Je n'ai pas vu de partition /boot dans ta table de partition.
Toi tu ne l'as pas vue, mais moi, je ne voyais que ça en /dev/sda3 :)
La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur
quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand
elle ne l'est pas elle reste fortement recommandée, et son absence exige
de forcer l'installation de GRUB avec l'option --force de grub-install.
Voilà, c'est tout ça que j'ai compris, par la force des choses et de
l'expérimentation.
Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi,
elle ne sert à rien pour l'amorçage BIOS/legacy.
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
Si c'est la partition où se trouve le contenu du répertoire /boot (racine ou partition /boot séparée), alors c'est indépendant du type de table de partition et cela peut être n'importe quel type de système de fichiers supporté par GRUB. Si tu parles de la partition de type "BIOS boot", elle n'existe qu'en GPT et ne contient pas de système de fichiers mais seulement la core image de GRUB écrite directement, comme en faisant
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.
J'ai arrêté de m'évertuer à avoir une partition de boot bien inutile.
Quelle partition ?
Quand j'ai enfin compris que "BIOS boot partition" n'est pas "Boot partition", et qu'il fallait donc que j'arrête d'écraser ce que faisait grub-install en mettant mes données de partition de boot par dessus, d'autant que cette partition de boot séparée est totalement inutile dans mon cas, alors, tout s'est éclairé :D
Je n'ai pas vu de partition /boot dans ta table de partition.
Toi tu ne l'as pas vue, mais moi, je ne voyais que ça en /dev/sda3 :)
La partition "BIOS boot" peut être obligatoire en GPT (cela dépend sur quoi /boot est situé, par exemple en RAID, LVM ou Btrfs) mais même quand elle ne l'est pas elle reste fortement recommandée, et son absence exige de forcer l'installation de GRUB avec l'option --force de grub-install.
Voilà, c'est tout ça que j'ai compris, par la force des choses et de l'expérimentation.
Quant à la partition EFI en FAT traditionnellement montée sur /boot/efi, elle ne sert à rien pour l'amorçage BIOS/legacy.
