Jessie : erreurs au démarrage. EFI ?

On Mon, Sep 14, 2015 at 04:12:40PM +0200, steve wrote:

Bonjour,

o/

Le 14-09-2015, à 15:24:13 +0200, Alain Rpnpif a écrit :

[…] ce que je trouve plus embêtant, c'est que ma Debian apparaît directement,
alors qu'avant la mise à niveau, c'est OSX qui apparaissait directement, ce
qui va probablement me demander de fournir quelques explications à un
douanier curieux…).

Contre la curiosité des douaniers, tu pourrais essayer de modifier
l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
depuis l'interface de ton firmware, d'ailleurs).

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------

Le 14-09-2015, à 16:22:45 +0200, Alexandre Hoïde a écrit :

Contre la curiosité des douaniers, tu pourrais essayer de modifier
l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
depuis l'interface de ton firmware, d'ailleurs).

Hum… pas sûr de savoir comment faire. Il n'y a pas d'entrée OSX dans
Grub, alors que la sortie de 'efibootmgr -v' donne
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* debian
HD(1,28,64000,e7d5ef86-1c9a-495d-bfe4-9d29ed9d963b)File(EFIdebiangrubx64.efi)
Boot0080* Mac OS X
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0081* Mac OS X
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0082*
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
BootFFFF*
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(2,64028,e066090,0000510a-5a72-0000-5510-0000477d0000)File(SystemLibraryCoreServicesboot.efi)

Une idée ?

On Mon, Sep 14, 2015 at 04:32:24PM +0200, steve wrote:

Le 14-09-2015, à 16:22:45 +0200, Alexandre Hoïde a écrit :

> Contre la curiosité des douaniers, tu pourrais essayer de modifier
>l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
>l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
>depuis l'interface de ton firmware, d'ailleurs).
Hum… pas sûr de savoir comment faire. Il n'y a pas d'entrée OSX dans
Grub, alors que la sortie de 'efibootmgr -v' donne
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* debian HD(1,28,64000,e7d5ef86-1c9a-495d-bfe4-9d29ed9d963b)File(EFIdebiangrubx64.efi)
Boot0080* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0081* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0082* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
BootFFFF* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(2,64028,e066090,0000510a-5a72-0000-5510-0000477d0000)File(SystemLibraryCoreServicesboot.efi)

Une idée ?

(Moi non. J'ignore tout de Grub+OSX. Ma réponse était limitée à l'ordre de chargement par ton firmware)

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------

Le 14-09-2015, à 16:38:26 +0200, Alexandre Hoïde a écrit :

On Mon, Sep 14, 2015 at 04:32:24PM +0200, steve wrote:

Le 14-09-2015, à 16:22:45 +0200, Alexandre Hoïde a écrit :

> Contre la curiosité des douaniers, tu pourrais essayer de modifier
>l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
>l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
>depuis l'interface de ton firmware, d'ailleurs).
Hum… pas sûr de savoir comment faire. Il n'y a pas d'entrée OSX dans
Grub, alors que la sortie de 'efibootmgr -v' donne
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* debian HD(1,28,64000,e7d5ef86-1c9a-495d-bfe4-9d29ed9d963b)File(EFIdebiangrubx64.efi)
Boot0080* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0081* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0082* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
BootFFFF* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(2,64028,e066090,0000510a-5a72-0000-5510-0000477d0000)File(SystemLibraryCoreServicesboot.efi)

Une idée ?

(Moi non. J'ignore tout de Grub+OSX. Ma réponse était limitée à
l'ordre de chargement par ton firmware)

C'est bien ce que je me disais, merci quand même. Peut-être quelqu'un
d'autre ? Ce n'est pas vraiment important, tout fonctionne sinon,
c'est juste que j'aime bien quand c'est joliment poli.

On Mon, Sep 14, 2015 at 04:42:34PM +0200, steve wrote:

Le 14-09-2015, à 16:38:26 +0200, Alexandre Hoïde a écrit :

>On Mon, Sep 14, 2015 at 04:32:24PM +0200, steve wrote:
>>Le 14-09-2015, à 16:22:45 +0200, Alexandre Hoïde a écrit :
>>
>>> Contre la curiosité des douaniers, tu pourrais essayer de modifier
>>>l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
>>>l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
>>>depuis l'interface de ton firmware, d'ailleurs).
>> Hum… pas sûr de savoir comment faire. Il n'y a pas d'entrée OSX dans
>>Grub, alors que la sortie de 'efibootmgr -v' donne
>>BootCurrent: 0000
>>Timeout: 5 seconds
>>BootOrder: 0000,0080
>>Boot0000* debian HD(1,28,64000,e7d5ef86-1c9a-495d-bfe4-9d29ed9d963b)File(EFIdebiangrubx64.efi)
>>Boot0080* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
>>Boot0081* Mac OS X ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
>>Boot0082* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
>>BootFFFF* ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(2,64028,e066090,0000510a-5a72-0000-5510-0000477d0000)File(SystemLibraryCoreServicesboot.efi)
>>
>> Une idée ?
>
> (Moi non. J'ignore tout de Grub+OSX. Ma réponse était limitée à l'ordre
>de chargement par ton firmware)
C'est bien ce que je me disais, merci quand même. Peut-être quelqu'un
d'autre ? Ce n'est pas vraiment important, tout fonctionne sinon, c'est
juste que j'aime bien quand c'est joliment poli.

Ofèt, j'en sais toujours pas plus sur Grub+OSX, mais au cas où ça
serait impossible : tu peux rajouter la couche rEFInd¹ (gestionnaire de
démarrage EFI) qui est compatible avec OSX. Petit inconvénient : si tu
restes en configuration Debian standard, Grub va se remettre en première
position en nvram à chaque [ré]installation (je suppose qu'il est
possible de configurer Grub pour l'empêcher de toucher à l'ordre… ou
pour exécuter un script post-grub-install qui remette rEFInd en première
position, mais je sais pas comment ^^). À toi de polir.

¹ http://www.rodsbooks.com/refind/

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------

Avertissement : je ne connais strictement *rien* au Mac. Je n'ai tâté
que de l'UEFI sur PC.

steve a écrit :

Le 14-09-2015, à 16:22:45 +0200, Alexandre Hoïde a écrit :

Contre la curiosité des douaniers, tu pourrais essayer de modifier
l'ordre de chargement stocké dans la nvram de ton firmware, à l'aide de
l'utilitaire 'efibootmgr' (ce qui devrait également pouvoir se faire
depuis l'interface de ton firmware, d'ailleurs).

Hum... pas sûr de savoir comment faire. Il n'y a pas d'entrée OSX dans
Grub, alors que la sortie de 'efibootmgr -v' donne
BootCurrent: 0000
Timeout: 5 seconds
BootOrder: 0000,0080
Boot0000* debian
HD(1,28,64000,e7d5ef86-1c9a-495d-bfe4-9d29ed9d963b)File(EFIdebiangrubx64.efi)
Boot0080* Mac OS X
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0081* Mac OS X
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
Boot0082*
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(3,8d61ae8,135f20,ced2687e-3575-4697-b564-34b9a786fc15)
BootFFFF*
ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(2,64028,e066090,0000510a-5a72-0000-5510-0000477d0000)File(SystemLibraryCoreServicesboot.efi)

On voit bien une entrée d'amorçage pour Debian avec le numéro 0000, et
des entrées pour MacOS identiques avec les numéro 0080 à 0082. Ça
ressemble à du boot UEFI classique, à part les doublons et la forme
inhabituelle - pour moi - des entrées d'amorçage pour MacOS. Je ne sais
pas à quoi sert la dernière entrée de numéro FFFF.

L'ordre de priorité défini dans BootOrder est 0000 (Debian) en premier,
et 0080 (1e entrée MacOS) en second. Normal : quand grub-install
installe son chargeur, il crée ou met à jour l'entrée d'amorçage
"debian" et la met en premier dans l'ordre de priorité de BootOrder.

La modification suivant de BootOrder grâce à efibootmgr devrait inverser
les priorités - SANS GARANTIE :

efibootmgr --bootorder 0080,0000

Autre possibilité, si elle est supportée par le firmware : utiliser
l'option --bootnext pour spécifier la prochaine entrée à démarrer. Cela
permettra de booter sur MacOS une fois, juste pour le douanier.

Par contre je ne vois pas comment amorçer MacOS depuis GRUB s'il n'y a
pas de fichier *.efi correspondant dans la partition système EFI.

Alain Rpnpif a écrit :

Je n'ai pas de partition réservée à l'EFI.

La core image de GRUB est forcément amorcée depuis quelque part.
La partition est identifiable à partir de l'entrée d'amorçage EFI de
Debian, affichée avec la commande (en root) :

efibootmgr -v

Ensuite comparer l'UUID figurant dans l'entrée "debian" avec les valeurs
de PARTUUID affichés par la commande (en root) :

blkid

La partition UEFI est-elle indispensable ?

Si on parle de l'identifiant de type de "partition système EFI", je
soupçonne que non, sinon le firmware UEFI ne s'embêterait pas à stocker
la position, taille et UUID de la partition contenant le chargeur dans
l'entrée d'amorçage EFI. Mais il faut que ce soit un système de fichiers
que le firmware UEFI comprenne, donc FAT.

De même il n'est pas indispensable que cette partition soit montée en
permanence sur /boot/efi. Ça l'est seulement pour y installer un
chargeur d'amorçage EFI. De même qu'il n'est pas nécessaire que /boot
soit montée en permanence.

Erreur de ma part : les messages arrivent après la sélection du noyau
de démarrage mais avant son chargement. Donc GRUB pourrait être
concerné (aussi ?).

Comment ça, "aussi" ? Evidemment que GRUB et lui seul est concerné, dans
tous les cas.

Le 15 septembre 2015, Pascal Hambourg a écrit :

Alain Rpnpif a écrit :
>
> Je n'ai pas de partition réservée à l'EFI.

La core image de GRUB est forcément amorcée depuis quelque part.
La partition est identifiable à partir de l'entrée d'amorç age EFI de
Debian, affichée avec la commande (en root) :

efibootmgr -v

Ensuite comparer l'UUID figurant dans l'entrée "debian" avec les val eurs
de PARTUUID affichés par la commande (en root) :

blkid

> La partition UEFI est-elle indispensable ?

Si on parle de l'identifiant de type de "partition système EFI", je
soupçonne que non, sinon le firmware UEFI ne s'embêterait pas à stocker
la position, taille et UUID de la partition contenant le chargeur dans
l'entrée d'amorçage EFI. Mais il faut que ce soit un systè me de fichiers
que le firmware UEFI comprenne, donc FAT.

De même il n'est pas indispensable que cette partition soit montà ©e en
permanence sur /boot/efi. Ça l'est seulement pour y installer un
chargeur d'amorçage EFI. De même qu'il n'est pas nécessair e que /boot
soit montée en permanence.


> Erreur de ma part : les messages arrivent après la sélection du noyau
> de démarrage mais avant son chargement. Donc GRUB pourrait êt re
> concerné (aussi ?).


Comment ça, "aussi" ? Evidemment que GRUB et lui seul est concernà ©, dans
tous les cas.

Popopo ! je m'aperçois que j'ai beaucoup tardé à répond re. Trop occupé.
Désolé.

À Alexandre.Oui
En essayant de te répondre, j'ai enfin trouvé la partition EFI ! Oui
elle existe. Elle se trouvait cachée parmi les 7 partitions de mon
disque sdb alors que je ne cherchais bêtement que sur sda.

sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sda: 390721968 sectors, 186.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6069C482-58B9-4E3E-9D5B-07AEA39467DE
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 390721934
Partitions will be aligned on 2048-sector boundaries
Total free space is 6110 sectors (3.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 39733247 18.9 GiB 8300 Linux
filesystem 2 39737344 42969087 1.5 GiB 8200 Linux
swap 3 42969088 147826687 50.0 GiB 8300 Linux
filesystem 4 147826688 390721967 115.8 GiB 8300 Linux
filesystem

Je n'utilise jamais gdisk car je ne connaissais pas. il me dit que mon
disque sda est anormalement partitionné (?).

sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 259DC8EC-A5B7-5B44-9C79-086F56E69E6A
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2029 sectors (1014.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 188827648 192923647 2.0 GiB 8200
2 192923648 385845247 92.0 GiB 0700
3 385845248 578766847 92.0 GiB 0700
4 578766848 771688447 92.0 GiB 0700
5 771688448 976773119 97.8 GiB 0700
6 2048 77823 37.0 MiB EF00
7 77824 188827647 90.0 GiB 0700 System

sudo fdisk -l /dev/sdb
...
Type d'étiquette de disque : gpt
...
Device Start End Sectors Size Type
/dev/sdb1 188827648 192923647 4096000 2G Linux swap
/dev/sdb2 192923648 385845247 192921600 92G Microsoft basic data
/dev/sdb3 385845248 578766847 192921600 92G Microsoft basic data
/dev/sdb4 578766848 771688447 192921600 92G Microsoft basic data
/dev/sdb5 771688448 976773119 205084672 97,8G Microsoft basic data
/dev/sdb6 2048 77823 75776 37M EFI System
/dev/sdb7 77824 188827647 188749824 90G Microsoft basic data

Par contre, je crois me souvenir avoir partitionné avec gparted et je
n'ai jamais déclaré ce type "Microsoft basic data" !? Le disque e st en
GPT volontairement. Toutes les partitions de sdb2 à sdb5 et sdb7 sont en
ext4. Ce serait fdisk qui est perdu avec GPT ?

sdb6 ne contient que
ls -a EFI/*
. .. grubx64.efi

sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0005,0004
Boot0000* debian
HD(6,800,12800,3f8e8876-07aa-bbfa-9d54-53b22b0f51c1)File(EFIdebiangrubx6 4.efi)
Boot0001* Hard Drive
BIOS(2,0,00)..GO..NO........o.S.T.5.0.0.D.M.0.0.2.-.1.B.D.1.4.2............ ........A...........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .2.S.K.A.V.B.C.Q........BO
Boot0004* UEFI: Built-in EFI Shell
Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* CD/DVD Drive
BIOS(3,0,00)..GO..NO........u.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.5.2.8.0.S ....................A...........................D..Gd-.;.A..MQ..L.O.p .t.i.a.r.c. .D.V.D. .R.W. .A.D.-.5.2.8.0.S........BO

Ça sent un peu le bogue ! Que vient faire le binaire dans cette
commande ?

Boot0000 correspond à la partition sdb6. Boot0001, euh, je ne sais pas,
sans doute l'ancien sda qui contient 4 partitions.

Mon partitionnement est compliqué mais fonctionne sauf ces messages
incompréhensibles au démarrage, oui Pascal ;), de Grub. Je suspec tais un
petit peu au départ un message issu d'une ROM d'une carte PCIE, mais
non.

Au vu de tout ça, blkid est-elle bien utile ?

--
Alain Rpnpif

Alain Rpnpif a écrit :

En essayant de te répondre, j'ai enfin trouvé la partition EFI ! Oui
elle existe. Elle se trouvait cachée parmi les 7 partitions de mon
disque sdb alors que je ne cherchais bêtement que sur sda.

A la bonne heure.

sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present

(...)

Je n'utilise jamais gdisk car je ne connaissais pas. il me dit que mon
disque sda est anormalement partitionné (?).

Non, il dit juste que /dev/sda a une table de partition au format
traditionnel MSDOS (dans le MBR). Gdisk est un outil réservé aux tables
de partition GPT, ou pour convertir une table au format MSDOS en GPT (ce
qu'il propose quand on l'exécute sur un disque au format MSDOS). Il ne
permet pas de gérer les tables de partition MSDOS.

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 976773168 sectors, 465.8 GiB

(...)

6 2048 77823 37.0 MiB EF00

Voilà notre partition système EFI avec le code caractéristique affiché
par gdisk (ouais, faut le savoir car le véritable identifiant de type
est un GUID qui n'a rien à voir). On la retrouve sous une forme un peu
différente (plus lisible) affichée par fdisk :

/dev/sdb6 2048 77823 75776 37M EFI System

Par contre, je crois me souvenir avoir partitionné avec gparted et je
n'ai jamais déclaré ce type "Microsoft basic data" !? Le disque est en
GPT volontairement. Toutes les partitions de sdb2 à sdb5 et sdb7 sont en
ext4. Ce serait fdisk qui est perdu avec GPT ?

Non. Avant Jessie, le type "Microsoft basic data" était utilisé par
défaut pour les partitions Linux avant qu'elles n'aient leur propre
identifiant de type. C'est sans importance.

sdb6 ne contient que
ls -a EFI/*
. .. grubx64.efi

J'aurais aimé voir la date du fichier.
Tu as vraiment copié toute la sortie ? Le fichier grubx64.efi, qui est
la core image de GRUB EFI 64 bits, devrait être dans un sous-répertoire
EFI/debian, comme on peut le voir dans l'entrée d'amorçage "debian"
affichée par efibootmgr :

sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0005,0004
Boot0000* debian
HD(6,800,12800,3f8e8876-07aa-bbfa-9d54-53b22b0f51c1)File(EFIdebiangrubx64.efi)
Boot0001* Hard Drive
BIOS(2,0,00)..GO..NO........o.S.T.5.0.0.D.M.0.0.2.-.1.B.D.1.4.2...
Boot0004* UEFI: Built-in EFI Shell
Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* CD/DVD Drive
BIOS(3,0,00)..GO..NO........u.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.5.2.8.0.S...
Ça sent un peu le bogue !

En quoi ?

Que vient faire le binaire dans cette commande ?

Quel binaire ? Le texte des entrées EFI est encodé en UTF16, avec deux
octets par caractère, donc un est le code ASCII classique pour les
caractères courants. C'est ce qui donne ces points entre chaque
caractère à l'affichage.

On peut deviner, en plus de l'entrée pour Debian, des entrées pour
l'amorçage en mode BIOS sur un disque dur ST500DM002 (Seagate ?) et un
lecteur de DVD Optiarc.

Boot0000 correspond à la partition sdb6.

Logique, c'est la partition système EFI qui contient la core image du
chargeur GRUB.

Boot0001, euh, je ne sais pas,

sans doute l'ancien sda qui contient 4 partitions.

Oui, probablement.

Au vu de tout ça, blkid est-elle bien utile ?

Non, puisque la partition système EFI est identifiée. Maintenant, il
faut vérifier si cette partition /dev/sdb6 est montée sur /boot/EFI en
vrai avec mount ou df et dans /etc/fstab.

Mon hypothèse, c'est que le fichier de configuration /boot/grub/grub.cfg
a été généré pour la version de GRUB de Jessie mais que le chargeur
actif est encore la version précédente de GRUB de Wheezy, la core image
du chargeur de Jessie n'ayant pu être installée correctement si la
partition système EFI n'est pas montée comme il faut.

On Wed, Sep 16, 2015 at 08:35:39PM +0200, Pascal Hambourg wrote:

Alain Rpnpif a écrit :
> À Alexandre. Oui.
> En essayant de te répondre, j'ai enfin trouvé la partition EFI ! Oui
> elle existe. Elle se trouvait cachée parmi les 7 partitions de mon
> disque sdb alors que je ne cherchais bêtement que sur sda.

A la bonne heure.

Je dirais même plus : à la bonne heure.

> Au vu de tout ça, blkid est-elle bien utile ?

Non, puisque la partition système EFI est identifiée. Maintenant, il
faut vérifier si cette partition /dev/sdb6 est montée sur /boot/EFI en
vrai avec mount ou df et dans /etc/fstab.

Mon hypothèse, c'est que le fichier de configuration /boot/grub/grub.cfg
a été généré pour la version de GRUB de Jessie mais que le chargeur
actif est encore la version précédente de GRUB de Wheezy, la core image
du chargeur de Jessie n'ayant pu être installée correctement si la
partition système EFI n'est pas montée comme il faut.

Pascal a couvert toutes tes questions, y compris où j'aurais eu un
petit doute. Je conclurai simplement avec l'évidence (histoire d'être
crédité aussi, dans ta biographie) : une fois que ton /dev/sdb6 sera
monté sur /boot/EFI, tu pourras enfin re-« $ sudo grub-install »…
(probablement) sans erreur.

Je sais, c'est peu, mais c'est la seule brêche qu'il restait ^^

--
 ___________________
| $ post_tenebras ↲ |       waouh !
| GNU         /    |      /
|          -- * --  |     o
| $ who ↲    /     |_-- ~_|
| Alexandre Hoïde   |  _/| |
 -------------------