Comment réinstaller GRUB2 EFI?

Après une mise à jour réussie de mon bios, une erreur s'est produite et j'ai fini par placer un curseur clignotant dans le coin supérieur gauche d'un écran noir. Pas d'erreurs, pas de rien. Le bios ne listait plus qu’une SATA: <disc name>option de démarrage à la place de celle d’UEFI habituelle ubuntu. J'utilise un schéma de partitionnement GPT.

J'ai finalement trouvé que la solution de travail consistait à réinstaller correctement grub-efi-amd64. Alors, comment je fais ça?

PS: En fait, j’ai réussi à réinstaller GRUB2 EFI par moi-même et je posterai ma réponse ici, j’ai été incapable de trouver un tutoriel complet à ce sujet.

• Démarrez votre ordinateur avec un live-USB / CD en mode UEFI . J'avais deux options de démarrage <flash_drive>et UEFI: <flash_drive>la seconde est nécessaire pour exposer les variables efi /sys/firmware/efi/afin de efibootmgrne pas échouer plus tard. Amorcer avec la première option me donne l'erreur suivante:

  Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
  Try 'modprobe efivars' as root.
  

  modprobe efivars ça n'a pas marché pour moi.

• chroot dans le système cassé (similaire à l' aide ubuntu grub2 mais avec des spécificités efi):

  sudo mount /dev/sda2 /mnt #sda2 is the root partition
  sudo mount /dev/sda1 /mnt/boot/efi #sda1 is the efi partition
  for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
  sudo cp /etc/resolv.conf /mnt/etc/ #makes the network available after chrooting
  modprobe efivars # make sure this is loaded
  sudo chroot /mnt
  

• En fonction de votre distribution linux, vous faites maintenant différentes choses.

  • Pour Ubuntu / Debian :

    apt-get install --reinstall grub-efi-amd64
    

    Ou bien:

    apt-get install --reinstall grub-efi
    update-grub
    

    Si ce qui précède vous donne une bouffe, mais pas une bootable
    
    

  • Pour Fedora (jusqu’à 16 ans, peut fonctionner pour d’autres):

    yum reinstall grub-efi
    

    Dans la commande suivante, vous devez remplacer sdX par le périphérique contenant la partition EFI à partir de laquelle vous voulez démarrer. Dans --part Yvous devez remplacer le Y avec le numéro de la partition EFI (comme dans /dev/sdXY).

    efibootmgr -c --disk /dev/sdX --part Y
    efibootmgr -v # verify a new record called Linux is there
    

• Maintenant, tapez Ctrl + D pour quitter chroot, démontez tout et redémarrez:

  for i in /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
  sudo umount /mnt/boot/efi #please do this. Corrupted efi partitions are not nice
  sudo umount /mnt
  sudo reboot
  

Vous devrez peut-être adapter cela à vos besoins (table de partition différente, partition / boot séparée, etc.) et ce n'est peut-être pas la seule option, mais cela a parfaitement fonctionné pour moi.

Un système en direct approprié pour réparer les objets est le grml . Il existe également un guide complet sur la configuration d'un périphérique USB amorçable, dont la section Mac est la plus utile (créer une partition FAT32, copier les fichiers, redémarrer, c'est fait).

Comme simplification potentielle de la première méthode, il est possible d’amorcer directement le système sur le disque dur, en utilisant uniquement le fichier grub du live CD. Testé sur xubuntu 13.10 avec le live CD xubuntu 13.10.

Assurez-vous que le démarrage sécurisé est désactivé dans votre BIOS. Insérez le live CD et démarrez-le via UEFI. Le menu GRUB du CD s’affiche. Appuyez sur "c" pour accéder à la ligne de commande.

configfile (hd0,gpt1)/EFI/ubuntu/grub.cfg

Adaptez la commande grub ci-dessus si vous avez une partition système EFI différente.

Une fois que votre système a démarré à partir du disque dur, il devrait suffire de réinstaller grub sur la partition système EFI et de l’enregistrer avec le micrologiciel via grub-install.

sudo grub-install

Comme avec Maxine, mes paramètres UEFI dans le BIOS ont été endommagés et ma machine ne démarre pas.

Dans mon cas, il s’agit d’un Lenovo ThinkServer RD430 avec Linux Mint Debian et tout ce que je ferais si je mettais à jour update ou grub ou que changer les disques durs du serveur l’empêcherait de démarrer. Le système d'exploitation dans mon cas est linuxmint-201403-mate-dvd-64bit installé via USB. (Voir ci-dessous pour une description complète des événements qui pourraient empêcher l'UEFI de fonctionner.)

En suivant exactement les mêmes étapes sur un ThinkServer TS140, l’UEFI n’a pas perdu la mémoire une seule fois. J'ai consulté la page du pilote RD430 et mon bios a deux versions. Je n'ai jamais eu à mettre à jour le bios d'une carte mère, je ne suis donc pas du genre à le mettre à jour automatiquement lorsque de nouvelles versions sont disponibles. Après la mise à jour du bios, la réponse de Maxine ci-dessus a fonctionné, mais avec une torsion ...

# efibootmgr -c --disk /dev/sdX --part Y
# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0002,0000,0003,0001,0004
Boot0000* linuxmint HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\EFI\linuxmint\grubx64.efi)
Boot0001* LMDE Linux Mint Debian    HD(1,800,15d505800,934c598c-fe3c-fd43-84a1-fa38e4f72552)File(\EFI\linuxmint\grubx64.efi)
Boot0002* Linux HD(1,800,1f4000,829f6cc9-5b17-479c-b3ea-61e43faecbf7)File(\elilo.efi)
Boot0003* UEFI: Built-in EFI Shell  Vendor(5023b95c-db26-429b-a648-bd47664c8012,)AMBO
Boot0004* UEFI: VerbatimSTORE N GO 1.00 ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(4,0)HD(1,80,1d70780,00000000)AMBO
mint / # 

La efibootmgr -ccommande a ajouté deux entrées 0000et 0002!
L' Boot0002* Linux HDentrée en premier dans la séquence d'amorçage n'est pas correcte .
L' 0000entrée est correcte.

Pour tester cela, j'ai essayé de démarrer sans aucune interruption, qui est l' 0002entrée. Comme prévu, cela n'a pas fonctionné. J'ai donc redémarré le serveur, appuyé sur F12 et choisi linuxmint. Comme espéré, cela a démarré sur mon installation LMDE.

La manière de supprimer les entrées indésirables via efibootmgr est la suivante:

# efibootmgr -b 2 -B

J'ai utilisé cette commande pour supprimer des entrées 0001et 0002. Option 0001était l'une des dernières tentatives pour récupérer le système d'exploitation.

Notes UEFI

Si vous lisez ceci et que vous êtes aussi frustré par UEFI que vous êtes, voici quelques notes et ressources:
»Démarrer à partir du shell UEFI revient à utiliser un shell DOS.
»Intel a créé un manuel de référence PDF pour les commandes efi shell.
»Le document UEFI_on_TS430 de Lenovo est la seule ressource que j'aie vue qui explique l'utilisation du shell efi.
» Une autre référence shell UEFI du Guide de l' administrateur nPartition .
»Vous pouvez essayer de démarrer sur une partition à partir du shell efi en accédant au chargeur et en l'exécutant.
»UEFI veut que le disque ait une table de partitions GPT, pas une table de parties msdos.
»UEFI veut que la première partition de votre disque soit formatée fat32 ou vfat.
»Pour un démarrage" générique ", il doit y avoir un /EFI/bootrépertoire à la racine avec bootx64.efidedans.
»Certaines personnes copient leur grubx64.efiemplacement d'origine /EFI/boot/bootx64.efiet cette triche a fonctionné pour eux.
»Chaque fois que vous apportez des modifications, utilisez efibootmgr -vavant et après pour vous assurer que votre redémarrage est correct.

Mon expérience RD430

J'ai réinstallé le système d'exploitation plus de 10 fois la semaine dernière en essayant de résoudre ce problème et de configurer le serveur. Ma configuration est un SSD sur ce contrôleur RAID dans l'emplacement PCIe 2.0 sur lequel LMDE est installé. Contrôleur RAID AOC-S3008L-L8i ( en mode informatique ) dans le deuxième logement PCIe 3.0 avec 6 lecteurs de 3 To. RAM: 12 Go ECC (3x 4 Go).

Voici les modifications que
j'apporterais qui empêchaient mon système de démarrer: »Modifiez les emplacements pci S3008L-L8i (en laissant le SSD + carte seul).
»Désactivez l' invite du BIOS RAID du logiciel LSi pour le contrôleur intégré.
»Ajoutez mon ancienne carte HighPoint RocketRaid à un emplacement PCIe ouvert.
»Modifiez /etc/default/grubpuis exécutez update-grub.
( peutgrub-install - être besoin d'être exécuté aussi? )

Je voterais favorablement, mais apparemment, je n'ai pas assez de représentants sur SuperUser. Je suis heureux d'avoir enfin trouvé une réponse à cette question après des jours de lutte contre des clones qui ont fonctionné mais qui n'ont pas démarré. Je pense que tout se rapporte à l'UEFI et à une sorte de mécanisme de "démarrage sécurisé" ou quelque chose du genre.

Je travaille hors ligne, donc apt-get n'était pas une option. Ce que j’ai fait, c’est de mettre Ubuntu Desktop sur une clé USB, d’ajouter les packages grub-efiet les grub-efi-amd64packages à la racine de la clé USB (grub-efi_1.99 ~ rc1-13ubuntu3_amd64.deb et grub-efi-amd64_1.99 ~ rc1-13ubuntu3_amd64.deb pour Ubuntu 11.04 - changez en fonction de la distro et de l’architecture), et insérez également ce qui suit dans un script sur la clé USB:

#! /bin/bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
dir=`dirname $0`
sudo cp $dir/grub-efi*.deb /mnt/tmp
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt /bin/sh -c "dpkg -i /tmp/grub-efi*.deb"
sudo shutdown -r now

Démarrez la clé USB Live, ouvrez un terminal, exécutez la commande et le travail est bon! Le seul problème occasionnel est que l'UEFI a parfois été déplacé dans l'ordre de priorité de démarrage situé sous le disque dur. Vous devez alors accéder au BIOS et modifier l'ordre de démarrage pour arrêter le processus (et l'échec) SATA: drive.

Vous pouvez également utiliser à la dpkg-reconfigureplace de dpkg -i, mais cela pose quelques questions au chargeur de démarrage.

[modifier] Je n'ai pas non plus assez de représentants pour commenter, donc ce que je pensais être un commentaire sur une réponse s'avère être une réponse.

Sur mon Ubuntu 14.10 32 bits sur Lenovo Yoga 2 Pro, j'ai changé pour le démarrage en UEFI comme ceci:

• créer le dossier

  sudo su
  mkdir /boot/efi
  

• monter la partition "EFI System" dans /etc/fstab

  fdisk -l|grep EFI
  

  cela a montré: /dev/sda2 2050048 2582527 532480 260M EFI System

  echo "/dev/sda2 /boot/efi   vfat    defaults,sync   0   0">>/etc/fstab
  

  monter cette partition

  mount /boot/efi
  

• installer grub-efi-amd64-binet désinstallergrub-efi-ia32-bin

  aptitude install grub-efi-amd64-bin grub-efi-ia32-bin_
  
  grub-install --target=x86_64-efi
  

• redémarrer Ubuntu en mode efi

  update-grub
  

• tester si ça marche bien, puis-je installé grub-efi-amd64et désinstallé grub-pc grub-gfxpayload-listsavec

  aptitude install grub-efi-amd64 grub-pc_ grub-gfxpayload-lists_
  

J'ai choisi de ne pas supprimer / boot lorsque demandé.

Peut-être que j'ai compliqué les choses et que cela aurait bien fonctionné:

apt-get install --reinstall grub-efi
update-grub

Cette entrée va plus dans le sens de la préparation de votre ordinateur à la réinstallation des entrées efi. C'est aussi ce que vous pourriez trouver comme un moyen simple et efficace de créer un disque de secours après l'installation du système sur un support interne (SSD, HDD).

Avec Linux Mint Tara (une variante Linux étroitement liée à Ubuntu Bionic Beaver), cette méthode a borké mon installation et permis de la sauvegarder ultérieurement. Cela tenait au fait que je souhaitais avoir une persistance sur une clé USB en direct, et puisque le temps d'installer un utilitaire comme Unetbootin pour une installation persistante est à peu près identique à une nouvelle installation, j'ai simplement utilisé la même distribution en direct pour effectuer une installation sur la clé USB. a été utilisé pour installer le système d'exploitation sur le SSD interne.

Bien sûr, rien de tout cela n’est RAID ou toute autre configuration spécialisée, mais cela nécessitait une partition de volume préparée sur le lecteur USB et une installation effectuée sur cet USB en utilisant la méthode disponible de la distribution, contournant le lecteur interne pour une installation sur un seul périphérique. le montage racine (/) de la partition.

C’est là que la nouvelle installation de grub se mêle au lecteur interne. Lorsque j'ai redémarré sur la clé USB, les entrées de fichier UEFI internes semblaient avoir disparu, ne laissant que le menu Grub lorsque vous essayez de sélectionner le lecteur à l'aide des entrées du menu BIOS.

Au lieu de cela, l’initialisation à partir de la clé USB a montré que la méthode de la distribution avait généré un menu prêt à l'emploi, avec une liste pour le répertoire / dev / sda2, la partition contenant le montage / boot / efi. Dans la plupart des lecteurs internes principaux, le nom de grub de la partition est hd0, gpt1.

Entrant dans «avancé», plus d'un sauvetage de noyau était disponible. A partir de là, lancez l'utilitaire grub puis démarrez normalement.

À partir de ce moment, exécutez le système d'exploitation sur le lecteur interne qui était auparavant inaccessible, débranchez le périphérique USB, puis exécutez-le sudo grub-install.

Lorsque vous redémarrez sans clé USB, vous devriez pouvoir y revenir. À ce stade, la clé USB est configurée pour lancer le lecteur interne en mode normal ou en mode de secours et le lecteur dispose de son propre menu.