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(\EFI\debian\grubx64.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.