web-dev-qa-db-fra.com

Grub ne peut pas détecter Windows 10 (UBUNTU INSTALLED FIRST)

J'ai un Lenovo Yoga 2 pro triple démarré avec deux Ubuntu (15.10, 14.04) et Windows 10. Au départ, j'ai essuyé le disque dur et installé Ubuntu. Pour installer Windows, j'ai reformaté le disque dur en GTP à l'aide de gdisk et installé Windows sur une partition ntfs.

(rien n'a pu démarrer initialement mais j'ai pu démarrer dans Windows en accédant au menu de démarrage à partir du bouton novo et en choisissant le chargeur de démarrage Windows (le chargeur de démarrage Ubuntu n'était pas présent ici et irait à l'écran noir avec un curseur clignotant si le disque dur était choisi) ))

Après le sauvetage du bootloader Grub à l'aide d'un cd ubuntu live, Windows n'apparaît pas. L'exécution de la réparation de démarrage détecte Windows, mais finit par gâcher grub, ce qui entraîne le redémarrage de l'ordinateur une fois qu'il essaie d'accéder au menu grub. Les résultats Pastebin de la réparation de démarrage peuvent être trouvés ici: http://paste.ubuntu.com/14692334/ .

L'exécution de l'environnement de réparation Windows à partir d'une clé USB ne peut pas résoudre le problème (la sélection de la réparation de démarrage entraîne la tentative de réparation du chargeur de démarrage par Windows mais finit par indiquer que la réparation a échoué).

La partition de démarrage Windows 100 Mib semble être là mais elle n'est pas détectée.

Parted -l donne la sortie suivante (en bas), et os-prober ne détecte que l'autre installation ubuntu. J'ai également essayé de modifier manuellement le fichier /etc/grub.d/40_custom en vain. Aussi Sudo update-grub ne donne aucun résultat (utile).

Basculer le démarrage vers UEFI à partir de Legacy ne permet pas de démarrer grub et ne détecte toujours pas le chargeur de démarrage Windows. Tout conseil est apprécié - Merci

** Notez que j'ai trouvé une situation similaire ici: Windows 8.1 n'apparaît pas dans GRUB2 mais n'a donné aucun résultat.

    Model: ATA SAMSUNG MZMTE256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name                          Flags
 1      1049kB  141GB  141GB   ext4            Linux filesystem
 2      141GB   192GB  50.9GB  ntfs            Microsoft basic data          msftdata
 3      192GB   192GB  472MB   ntfs            Basic data partition          hidden, diag
 4      192GB   193GB  105MB                   EFI system partition          boot, esp
 5      193GB   193GB  16.8MB  ntfs            Microsoft reserved partition  msftres
 7      193GB   203GB  10.2GB  ext4
 8      242GB   243GB  186MB   ext4                                          boot, esp
 6      248GB   256GB  8501MB  linux-swap(v1)  Linux swap


Model: SanDisk Cruzer Fit (scsi)
Disk /dev/sdb: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  16.0GB  16.0GB  primary  fat32        boot, lba
1
tlambros

Beaucoup de vos problèmes semblent se résumer à des problèmes avec votre EFI System Partition (ESP), qui dans votre cas est (ou devrait être) /dev/sda4. Le problème est que le script Boot Repair a (mis? -) identifié /dev/sda4 comme détenant le GRUB core.img fichier. OTOH, il est marqué dans la table de partition comme étant un ESP. Je soupçonne que deux choses se sont produites:

  • Lors de l'installation de Windows, /dev/sda4 a été utilisé comme ESP, mais l'emplacement de la partition coïncidait avec l'emplacement d'une suppression BIOS Boot Partition , qui contient GRUB 2 code for BIOS Si Windows n'a pas effacé correctement ces anciennes données, cela pourrait entraîner une mauvaise identification du système de fichiers par certains outils Linux, ce qui entraînerait le problème auquel vous êtes actuellement confronté.
  • À un moment donné après l'installation de Windows, vous ou un utilitaire de réparation avez écrit par erreur GRUB data "raw" to /dev/sda4. Le grub-install dans un démarrage BIOS/CSM/en mode hérité peut le faire, mais normalement uniquement si la partition a été marquée comme partition de démarrage BIOS, ce qui n'est pas le cas actuellement. Néanmoins, c'est une possibilité si les données GRUB ont été écrites ici d'une autre manière ou si le code de type de la partition a été changé en celui d'un ESP après la grub-install Erreur.

La première de ces explications est celle que vous devriez espérer, car cela signifie que les données du système de fichiers FAT doivent être intactes. Dans ce cas, la première étape de la récupération consiste à sauvegarder la partition (vous devrez peut-être spécifier explicitement son type de système de fichiers pour la monter dans Ubuntu, comme dans Sudo mount /dev/sda4 -t vfat /mnt), démontez-le, créez un nouveau système de fichiers FAT dessus (Sudo mkdosfs /dev/sda4), remontez-le et restaurez les fichiers sauvegardés. Cela devrait alors permettre à Boot Repair de fonctionner. Notez que vous pouvez faire tout cela dans à peu près n'importe quel système d'exploitation, bien que vous deviez d'abord monter le ESP si vous le faites sous Windows (voir ci-dessous).

Un autre chemin vers la récupération serait d'utiliser mon gestionnaire de démarrage rEFInd sur une clé USB ou un CD-R. Si le système de fichiers de l'ESP est lisible par le firmware, rEFInd devrait vous permettre de démarrer Windows ou Ubuntu. Vous pouvez ensuite créer un /etc/fstab entrée pour monter /dev/sda4 à /boot/efi et installez rEFInd via son paquet Debian ou PPA. (Vous pouvez également installer le grub-efi package et configurez-le vous-même.) En soi, cependant, cette approche laissera toujours des données confuses sur l'ESP, donc des outils comme Boot Repair continueront d'être moins qu'utiles; pour récupérer complètement , vous devez sauvegarder l'ESP, créer un nouveau système de fichiers dessus et le restaurer. Pour cette question, je ne suis pas tout à fait sûr que le script d'installation de rEFInd (utilisé dans les packages) fonctionnerait correctement étant donné l'erreur d'identification du système de fichiers, vous devrez donc peut-être résoudre ce problème même avec cette solution.

Si le système de fichiers sur /dev/sda4 est si gravement endommagé que vous ne pouvez pas récupérer ses fichiers, vous devrez créer un nouveau système de fichiers dessus, utiliser un disque de récupération Windows pour réinstaller le chargeur de démarrage Windows, puis récupérer Ubuntu pour démarrer en utilisant soit Boot Repair ou rEFInd.

Notez qu'il est concevable que le système de fichiers soit lisible dans un ou deux environnements mais pas dans les trois. (Les trois environnements étant l'EFI, Windows et Ubuntu.) Windows ne monte normalement pas l'ESP, vous devez donc le faire en tapant mountvol S: /S dans une fenêtre d'invite de commandes administrateur. (Vous pouvez changer S: à un autre identifiant de lecteur, si vous le souhaitez.) Bien sûr, votre sortie Boot Repair révèle déjà que certains outils Linux (comme blkid) ne voient pas de système de fichiers FAT sur le disque, mais cela pourrait quand même être lisible par le noyau si vous lui dites d'utiliser le pilote vfat, comme dans le mount /dev/sda4 -t vfat /mnt commande que j'ai présentée plus tôt.

2
Rod Smith