Impossible de démarrer sans USB, échec de grub-install et boot-repair

Question

Mise à jour 4: Comme prévu, la réinitialisation de la commande de démarrage n'a pas fonctionné: Sudo efibootmgr -o 4,0,1,2 n'a rien fait.

Mise à jour # 3: voir en bas

Mise à jour n ° 2: Peut-être à cause du problème de HP. S'il vous plaît voir la réponse de Rod. Cette question reste en suspens.

Mise à jour: j'ai fait Boot-Repair et cela n'a pas fonctionné. Voir la section inférieure pour plus de détails.

Je viens d'installer Ubuntu 16.04.2 LTS sur un nouveau HP EliteBook 2017 avec une clé USB de démarrage Ubuntu. J'ai effacé Windows sous Ubuntu. Cependant, la startup (voir plus d'informations sur l'UEFI ci-dessous) n'a pas pu trouver de système d'exploitation à moins que je mette la clé USB.

Donc, basé sur cette réponse j'ai essayé:

Sudo grub-install /dev/sda

Mais j'ai eu l'erreur:

Installation pour la plate-forme i386-pc.
grub-install: error: échec de l'obtention du chemin canonique de `aufs '.

Alors j'ai essayé ne suggestion de cette réponse qui a donné la même erreur.

Sudo grub-install /dev/sda2

Parce que je voulais vraiment l'installer sur mon disque dur, identifié par:

Sudo fdisk -l Device ... Size Type /dev/sda1 512M EFI System /dev/sda2 208.1G Linux filesystem /dev/sda3 15G Linux swap

Mais je ne pouvais pas grep pour le démarrage dans Sudo fdisk -l.

Je pense que le problème pourrait venir de ma racine, /, est sur aufs, en fonction de cette commande:

> df Filesystem .. ... Mounted on udev /dev aufs /

Plus d'informations:

L'ordinateur portable dispose d'un SSD de 200 Go
Lorsque j'ai installé Ubuntu, il m'a averti que l'UEFI risquait d'endommager les systèmes d'exploitation du BIOS. J'ai quitté le démarrage en tant que démarrage hybride au lieu de Legacy, car si j'utilise Legacy, il ne reconnaît même pas le lecteur USB Ubuntu. Ensuite, je force l'installation UEFI lors de l'installation d'Ubuntu. (Sous Windows 10, il utilisait peut-être le BIOS, je ne pouvais pas obtenir de réponse définitive.)

Mise à jour: j'ai essayé boot-repair avec l'option "installer boot-repair dans Ubuntu", j'ai obtenu ceci paste2 , éteint, sorti mon périphérique USB, allumé et obtenu :

BootDevice Not Found Please install an operating system on your hard disk.

Qu'est-ce que je devrais faire maintenant?

Mise à jour # 3:

Voici les résultats de Sudo efibootmgr et df dans Essayez Ubuntu avec l’USB branché.

Des questions:

Il est clair que je devrais changer afin que la séquence d'amorçage ne passe pas d'abord sur USB et Ubuntu en dernier. Comment puis-je le déplacer?
S'il peut y avoir des problèmes avec le fichier .efi. Je ne comprends pas exactement ce que je devrais renommer et comment. Actuellement, mon USB de démarrage est montée sur/cdrom. Mais dans/cdrom/EFI, il n’ya que BOOT. Dans/cdrom/EFI/BOOT se trouvent les fichiers suivants:
```
BOOTx64.efi grubx64.efi 
```
2a. Devrais-je en quelque sorte changer le montage SUB de/cdrom à/mnt?

2b. Quel fichier dois-je renommer et dans quoi? Parce que ...

bfan1 dit "renommez le /EFI/ubuntu/shimx64.efi en /EFI/ubuntu/bootmgfw.efi

"En guise de solution de secours, que je recommande, configurez le chargeur de démarrage de disque, /EFI/Boot/bootx64.efi en tant que copie de /EFI/ubuntu/shimx64.efi. Étant donné que shimx64.efi a besoin de grubx64.efi dans le même répertoire, copie /EFI/ubuntu/grubx64.efi à /EFI/Boot/grubx64.efi

"Vous avez trouvé exactement la même configuration utilisée sur le support d’installation - le fichier /cdrom/EFI/BOOT/BOOTx64.efi est en fait une copie de shimx64.efi. C’est ainsi que le support d’installation démarre à l’aide de son chargeur de démarrage par défaut en mode UEFI.

et

Rod Smith a déclaré dans un commentaire "vous devez examiner la solution de rechange fastidieuse consistant à renommer votre chargeur de démarrage principal ou votre fichier de gestionnaire de démarrage en tant que EFI/BOOT/bootx64.efi".

Je suis confus

Rod Smith · Answer

Sudo grub-install /dev/sda

Mais j'ai eu l'erreur:

Installing for i386-pc platform. grub-install: error: failed to get canonical path of `aufs'.

Que vous le sachiez ou non, transmettre le périphérique /dev/sda à grub-install implique l'installation de la version en mode BIOS de GRUB. (Bien entendu, vous avez peut-être réussi cette option par erreur.) De même, la réponse que GRUB tente d’installer pour le i386-pc platform implique également un mode BIOS GRUB installation. Je ne sais pas ce que le message failed to get canonical path ofaufs'` signifie. La version de GRUB en mode BIOS est cependant critique, car ....

Sudo fdisk -l Device ... Size Type /dev/sda1 512M EFI System /dev/sda2 208.1G Linux filesystem /dev/sda3 15G Linux swap

La présence d'une partition système EFI (ESP) implique que le disque est configuré pour démarrer en mode EFI et non en mode BIOS. (Remarque: vous avez clairement coupé les lignes de sortie de votre commande fdisk. Vous ne devriez pas le faire lorsque vous demandez de l'aide. Ces lignes peuvent vous aider à diagnostiquer votre problème, bien qu'elles probablement redondant dans ce cas particulier.)

La grande majorité des nouveaux ordinateurs actuellement livrés sont configurés pour démarrer en mode EFI par défaut. Vous pouvez activer la prise en charge du BIOS/CSM/mode hérité dans le micrologiciel, et certaines instructions d'installation Ubuntu et Linux vous le recommandent. Cependant, dans la plupart des cas, c'est un mauvais conseil. Voir ma page sur le sujet pour plus d'informations. On ignore si vous avez apporté ces modifications vous-même. la présence apparente de la version en mode BIOS de GRUB dans votre installation Ubuntu suggère que vous avez été installé en mode BIOS; Cependant, le partitionnement du disque suggère que vous avez installé en mode EFI.

Comme il s’agit d’une nouvelle installation, ma recommandation est de configurer votre microprogramme pour qu’il ne démarre que en mode EFI, puis d’installer un chargeur de démarrage en mode EFI. Il y a plusieurs façons de le faire. Les trois plus faciles sont:

EDIT:

Dans votre sortie Boot Repair, vous trouverez quelques indices sur la cause du problème:

File system: vfat Boot sector type: FAT32 Boot sector info: No errors found in the Boot Parameter Block. Operating System: Boot files: /EFI/Boot/bootx64.efi /EFI/ubuntu/MokManager.efi /EFI/ubuntu/fwupx64.efi /EFI/ubuntu/grubx64.efi /EFI/ubuntu/shimx64.efi /EFI/Microsoft/Boot/bootmgfw.efi /EFI/Microsoft/Boot/bootx64.efi

Notez en particulier la présence de fichiers de démarrage Microsoft (/EFI/Microsoft/Boot/bootmgfw.efi et /EFI/Microsoft/Boot/bootx64.efi). Ces fichiers suggèrent que vous n'avez pas supprimé l'ESP, donc les fichiers du chargeur de démarrage Windows semblent se cacher à côté de votre installation Ubuntu. Vérifiez également la sortie efibootmgr:

=================== efibootmgr -v BootCurrent: 0000 Timeout: 0 seconds No BootOrder is set; firmware will attempt recovery Boot0000* USB Hard Drive 1 - Generic Mass Storage BBS(HD,,0x900)....................................................................... Boot0001* Notebook Hard Drive BBS(HD,,0x0)....................................................................... Boot0002* Notebook Ethernet BBS(128,,0x0)....................................................................... Boot0003* Windows Boot Manager HD(1,GPT,2c19863f-1ed0-476e-a8e9-6d316ca2c4bb,0x800,0x32000)/File(EFIMicrosoftBootbootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................ Boot0004* ubuntu HD(1,GPT,17667422-8dfe-45ba-9baa-5458a67b71db,0x800,0x100000)/File(EFIubuntushimx64.efi)

L'entrée de démarrage de Windows y est toujours présente, ce qui n'est pas surprenant. Cependant, le bit vraiment foiré est le rapport que No BootOrder is set; firmware will attempt recovery. Une EFI qui fonctionne repose sur une variable appelée BootOrder pour identifier l’ordre dans lequel les chargeurs d’amorçage seront exécutés. Cette variable est absente sur votre ordinateur. J'ai constaté le même problème sur un ordinateur portable HP 6470b plutôt ancien que je possède et, quoi que j'essaye, je n'ai pas pu créer cette variable. Dans tous les cas, le résultat probable est que l'ordinateur tente de lancer le chargeur de démarrage de secours (EFI/BOOT/bootx64.efi) ou le chargeur de démarrage Microsoft (EFI/Microsoft/Boot/bootmgfw.efi). Si le chargeur de démarrage lancé est le chargeur de démarrage Microsoft d'origine, il s'effondrerait à ce stade, car Windows n'est pas installé. Si vous avez copié autre chose dans ces fichiers (consciemment ou non), il risque de s'effondrer si ses fichiers de support ne sont pas également présents.

Puisque vous dites que votre ordinateur est neuf, ma première recommandation est de le renvoyer au magasin pour obtenir un remboursement et d’acheter autre chose. Le problème peut être dû à un exemple de défaut (une puce NVRAM défectueuse, etc.) ou à un bogue du micrologiciel de HP. Dans le premier cas, une nouvelle version du même ordinateur pourrait fonctionner; mais si le firmware est bogué, un nouvel ordinateur ne fera rien. (OTOH, s’il s’agit d’un micrologiciel défectueux, il est peu probable qu’une mise à jour du micrologiciel corrige le problème. La réinitialisation des options du micrologiciel sur leurs valeurs par défaut pourrait également aider.) Si vous renvoyez l’ordinateur au magasin pour obtenir un remboursement, assurez-vous de le signaler à HP. vous l'avez fait et pourquoi. Les fabricants continueront à vendre des produits défectueux à moins d’être informés du fait qu’ils le font, et ils en éprouvent des difficultés (sous forme de retours).

Si vous refusez de vous procurer un ordinateur non endommagé, vous devez vous en occuper. Le meilleur moyen est de supprimer ces fichiers du chargeur de démarrage Windows du ESP et de copier GRUB vers le nom de fichier de secours de EFI/BOOT/bootx64.efi. (Il y a déjà un fichier à cet emplacement, mais il n'est pas clair s'il s'agit d'une autre copie de GRUB, d'une autre copie du chargeur de démarrage Windows ou de quelque chose d'autre.) Vous devrez copier grub.cfg et peut-être d'autres fichiers de EFI/ubuntu à EFI/BOOT, aussi. Si vous utilisez Boot Repair, sa page Advanced contient une option qui le fera de manière semi-automatique.

EDIT 2:

Vous pouvez modifier la séquence d'amorçage à l'aide de l'option -o en efibootmgr, comme dans:

Sudo efibootmgr -o 4,0,1,2

Cet exemple doit conserver les entrées de démarrage existantes affichées, mais ajouter l'entrée ubuntu au premier plan. En théorie, cela fera GRUB le programme de démarrage par défaut, et tout devrait alors commencer à fonctionner. Vous pouvez en savoir plus sur efibootmgr en tapant man efibootmgr. (La même astuce fonctionne pour d'autres commandes; par exemple, man ls vous indiquera la commande ls.)

Cela dit, le fait que vous ayez une variable BootOrder inexistante au début me rend sceptique, cela fonctionnera; Je soupçonne que votre EFI a quelque chose de floconneux qui l’échouera. (L’installation initiale d’Ubuntu et la réparation de démarrage doivent avoir ajouté l’entrée ubuntu au début de la variable BootOrder, en supposant qu’elles ont été exécutées en mode EFI - et la sortie Boot Repair que vous avez montrée n'a révélé aucun chargeur de démarrage en mode BIOS sur votre disque, ce qui implique qu'ils ont été exécutés en mode EFI.)

Il y a deux partitions sur votre système EFI, ou des partitions qui remplissent cet objectif, et je pense que vous les confondez:

sur le disque dur - Le ESP de votre disque dur est /dev/sda1, en fonction du résultat de votre réparation de démarrage. Cette partition doit être montée à /boot/efi lorsque vous démarrez Ubuntu sur votre disque dur. mais lorsque vous utilisez le support d'installation Ubuntu en mode "essayer avant d'installer", il ne sera pas automatiquement monté ou il sera monté ailleurs, dans un sous-répertoire de /media, IIRC.
sur le support d'installation - Ce n'est pas techniquement un ESP, mais /dev/sdb1 sur votre support d'installation joue le même rôle. Il contient un répertoire EFI/BOOT avec divers fichiers de démarrage. L'ajustement de ces fichiers est au mieux inutile, du moins dans votre cas, car vous souhaitez que le système démarre à partir du système d'exploitation installé sans utiliser votre support d'installation.

Si vous démarrez avec le disque d'installation, la modification des fichiers sur votre disque dur ESP nécessite de monter le ESP puis de modifier ces fichiers. Vous feriez quelque chose comme ça:

Sudo mkdir -p /mnt/foo Sudo mount /dev/sda1 /mnt/foo cd /mnt/foo/EFI Sudo mv Boot Boot-old Sudo cp -r ubuntu BOOT Sudo mv BOOT/shimx64.efi BOOT/bootx64.efi

Notez que les erreurs de frappe (de ma part ou de votre part) peuvent empêcher ces commandes de fonctionner correctement, et une telle erreur pourrait même aggraver les choses. Si cela fonctionne, cette séquence de commandes copiera Shim (qui gère l'authentification Secure Boot) dans le nom de fichier de secours de EFI/BOOT/bootx64.efi. Shim lancera alors GRUB (grubx64.efi), qui poursuit le processus de démarrage. Si la commande efibootmgr -o que j'ai présentée précédemment ne fonctionne pas, cette séquence devrait permettre au système de démarrer.

Au-delà de cela, vous posez beaucoup de questions assez basiques, qui transforment cette question et ses réponses en un réseau enchevêtré. Je vous suggère de lire à l'extérieur:

Une fois que vous aurez compris certaines de ces bases, vous obtiendrez peut-être davantage de réponses, mais sachez que nous avons parcouru quelques impasses en raison d'informations initiales incomplètes et de suppositions incorrectes. Si vous avez toujours des problèmes après avoir lu au moins une partie de ce qui précède, je vous recommande de poser de nouvelles questions, ou d’amener la discussion à les forums Ubuntu, , qui sont mieux configurés pour les discussions en arrière-plan. (Ce site est destiné à répondre à des questions relativement simples, sans poursuivre de longues discussions.)

ubfan1 · Answer

Il semble que boot-repair ait ajouté l'entrée de démarrage d'ubuntu shimx64 en tant qu'article 0004 lors de la dernière exécution de efibootmgr dans votre lien de collage. 0004 était manquant dans les versions antérieures de efibootmgr (dans votre pâte).
Éditer VVVV
Votre dernière exécution manuelle de efibootmgr ne contient toutefois pas 0004 dans le bootorder, même si l’élément est répertorié. Ajoutez-le vous-même:

Sudo efibootmgr --bootorder 0004,0000,0001,0003,0002

Les zéros au début sont facultatifs, mais ce qui précède utilise les entrées telles qu'elles sont affichées.
Modifier ^^^^

Cependant, il s’agit d’un HP, avec quelques ajustements spécifiques à un fournisseur à UEFI qui brisent la configuration standard - en ajoutant en gros un nom approuvé spécifique que le chargeur de démarrage doit avoir (Windows Boot Loader). De plus, le nom du fichier du chargeur de démarrage doit être bootmgfw.efi. efibootmgr peut être utilisé pour renommer l'entrée du chargeur de démarrage:

Sudo efibootmgr -b 0004 -l /EFI/ubuntu/bootmgfw.efi -L "Windows Boot Loader"

et renommez le fichier /EFI/ubuntu/shimx64.efi en /EFI/ubuntu/bootmgfw.efi
éditer VVVV
Le renom est le fichier sur le disque dur. Votre df indique que le fichier EFI du disque dur, sda1, n'est monté nulle part. Par conséquent, tant que vous ne le montez pas, vous ne pouvez même pas voir le répertoire/EFI qui apparaîtra à l'emplacement de montage. Ne touchez rien dans le répertoire/cdrom.
modifier ^^^^

Cela devrait fonctionner (recherchez sur ce site les problèmes liés à HP UEFI, mais je pense que cela résume la solution).

Edit VVV Montez la partition EFI du disque dur sur/mnt

Sudo mount -tvfat /dev/sda1 /mnt

Maintenant, sous/mnt, vous devriez voir le répertoire EFI de la partition sda1 du disque dur. Toutes les modifications sont apportées à ces fichiers/mnt/EFI/ubuntu/... et/mnt/EFI/Boot/...
Modifier ^^^

Comme solution de rechange, que je recommande, configurez le chargeur de démarrage de disque, /mnt/EFI/Boot/bootx64.efi en tant que copie de /mnt/EFI/ubuntu/shimx64.efi. Puisque shimx64.efi a besoin de grubx64.efi dans le même répertoire, copiez /mnt/EFI/ubuntu/grubx64.efi dans /mnt/EFI/Boot/grubx64.efi.

Ce chargeur de démarrage de secours peut fonctionner indépendamment de l'entrée de démarrage de nvram et gardera votre démarrage opérationnel si quelque chose décide de modifier la liste de démarrage de nvram.

Auparavant, j’avais un hôte à double amorçage sécurisé avec ubuntu/shim comme première entrée nvram et, après avoir créé un support d’installation sur une clé USB, l’entrée shimx64 a été modifiée en grubx64.efi démarrer avec le démarrage sécurisé activé). UEFI rencontre d’autres problèmes plus graves lors de la création d’un support d’installation USB. J’ai donc finalement modifié mon système par défaut pour qu’il fonctionne en mode hérité.
Ce que vous avez trouvé sur le support d’installation, le fichier /cdrom/EFI/BOOT/BOOTx64.efi est en fait le fichier de démarrage de la clé USB. Ne le modifiez pas, car cela fonctionne. Notez que le fichier BOOTx64.efi n’est qu’une copie de shimx64.efi. Voici comment le support d'installation démarre à l'aide de son chargeur de démarrage par défaut en mode UEFI. Cette configuration exacte (ainsi, insensible à la casse) est ce que vous mettez sur le disque dur comme solution de secours.

Si Sudo mount/dev/sda1/mnt échoue car "il est déjà monté", utilisez df pour voir où, mais c'est étrange si vous ne l'avez pas fait. Ce n'est pas le répertoire/cdrom/EFI, c'est un répertoire (mais une autre source pour bootx64.efi et grubx64.efi à mettre sur le disque dur). Les disques ont peut-être été énumérés à nouveau et le disque dur est devenu sdb, laissant la sda à USB. Voyez ce que dit df et modifiez le montage en/dev/sdb1 si c'est le cas.