grub rescue

Babdu89 · Le 04/02/2019, à 01:04

J'ai édité le post#24...

jamesbad000 a écrit;
- De plus j'ai installé des boot mixtes UEFI/legacy sur clef usb aussi bien que sur disque dur, et ça fonctionne très bien.

Avec quel type de table de partition? .
Moi, je n'ai testé çà, uniquement, sur clé usb avec table de partition GPT .

@+. Babdu89 .

Dernière modification par Babdu89 (Le 04/02/2019, à 01:08)

jamesbad000 · Le 04/02/2019, à 01:20

Babdu89 a écrit :

J'en reviens à mon post#5, où l'on voit cette signature pour grub; grub2, signed grub-pc grub-efi

Oui j'ai noté la remarque, sans savoir quelle conclusion en tirer faute de savoir ce qu'il y a d'habitude.
Maintenant j'en déduis qu'il y a certainement les 2 versions de grub qui cohabitent sur l'installation.

C'est étonnant, mais pour autant ce n'est pas censé être rédhibitoire, puisque je suis moi même dans cette situation. Grâce à quoi je peux faire booter sur un live cd un pc du réseau via PXE en mode UEFI ou legacy...

ii  grub-common           2.02-2ubuntu8.10         amd64        GRand Unified Bootloader (common files)
ii  grub-efi-amd64        2.02-2ubuntu8.10         amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin    2.02-2ubuntu8.10         amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 binaries)
ii  grub-efi-amd64-signed 1.93.11+2.02-2ubuntu8.10 amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version, signed)
ii  grub-pc-bin           2.02-2ubuntu8.10         amd64        GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii  grub2-common          2.02-2ubuntu8.10         amd64        GRand Unified Bootloader (common files for version 2)

Edit: quoique moi c'est seulement grub-pc-bin que j'ai. grub-pc tout cours étant mutuellement exclusif avec grub-efi-amd64
Edit2 : je n'ai pas non plus grub-efi tout cours. Donc en fait pas certain que ce soit des vrais noms de paquets qui apparaissent dans cette liste.
edit3: description du paquet grub-efi "This is a dummy transitional package that depends on either grub-efi-ia32 or grub-efi-amd64, depending on the architecture."
(grub-PC étant dans tout les cas du code 16 bits)

Dernière modification par jamesbad000 (Le 04/02/2019, à 01:46)

ikewdu · Le 04/02/2019, à 09:24

Salut,

Je me permets une incursion et j'en profite pour donner un conseil. Effacer le disque complet, refaire la table de partitions proprement pour l'uefi, réinstaller intégralement Ubuntu, et en cas d'échec, refaire un rapport boot-info (sans faire la réparation). A ce stade, j'ignore même si le problème rencontré est toujours le même qu'au début car GRUB semble bien détecté en NVram et que c'est après que le problème se pose. Et comme Ubuntu est seul, le menu ne s'affiche pas, et rien n'interdit de penser maintenant que c'est un problème de reconnaissance de carte graphique qui a pris le relais.

Pour être franc, aucune des pistes évoquées ne me convainc. Le secure-boot ne doit pas poser problème avec shimx64.efi, et la présence d'un GRUB-pc dans le mbr non plus. On voit ici plein de cas fonctionnant très bien ainsi.

Dernière modification par ikewdu (Le 04/02/2019, à 09:29)

jamesbad000 · Le 04/02/2019, à 10:08

ikewdu a écrit :

rien n'interdit de penser maintenant que c'est un problème de reconnaissance de carte graphique qui a pris le relais.

Cette hypothèse est à vérifier. Mais si c'est le cas, refaire l'installation ne va rien régler du tout.
Celà dit, s'il plante lors du lancement du kernel, le fonctionnement normal c'est qu'au démarrage suivant sur le disque il devrait afficher automatiquement le menu grub

@ddlinux tu peux indiquer si sur une nouvelle tentative de démarrage le menu grub s'affiche ou pas ?
Dans le cas contraire, tenter de forcer l'affichage du menu en tapotant sur la touche maj juste après l'écran de démarrage du bios

ikewdu · Le 04/02/2019, à 11:51

Re,

La remise à zéro du partitionnement, c'est juste un moyen d'être sûr qu'il ne reste pas de trace dans le mbr, tout en virant les merdouilles ajoutées par boot-repair, et aussi ce grub-pc qui ne devrait pas être là, etc. Repasser à une base propre, pour ainsi dire.

Après, le reste est effectivement hypothétique, mais une chose est sûre : la NVram est correcte et GRUB est bel et bien placé en priorité. La problème se manifeste lors du lancement de GRUB, ou après.

malbo · Le 04/02/2019, à 16:21

Babdu89 a écrit :

J'en reviens à mon post#5, où l'on voit cette signature pour grub; grub2, signed grub-pc grub-efi

C'est une bizarrerie des installations en mode UEFI de la version 18.04.1 64 bits : voir mon post #5 sur le sujet
Par contre pour les installations plus anciennes de la version 18.04 64 bits (toujours en mode UEFI), il n'y a pas de grub-pc : post #6

Dernière modification par malbo (Le 04/02/2019, à 16:22)

Babdu89 · Le 04/02/2019, à 22:25

Bonsoir.

Merci malbo pour l'explication.

@+. Babdu89 .

ddlinux · Le 05/02/2019, à 00:31

Bonsoir,
Merci beaucoup pour votre intérêt. Je n'ai pas pu avancer sur le problème aujourd'hui, il me fallait absolument un ordi fonctionnel.
Je m'y remet demain.
Bonne nuit

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 04/02/2019, à 01:04

Re : grub rescue

#27 Le 04/02/2019, à 01:20

Re : grub rescue

#28 Le 04/02/2019, à 09:24

Re : grub rescue

#29 Le 04/02/2019, à 10:08

Re : grub rescue

#30 Le 04/02/2019, à 11:51

Re : grub rescue

#31 Le 04/02/2019, à 16:21

Re : grub rescue

#32 Le 04/02/2019, à 22:25

Re : grub rescue

#33 Le 05/02/2019, à 00:31

Re : grub rescue

Pied de page des forums