Vous n'êtes pas identifié(e).
N'hésitez pas à me dire si un truc vous paraît anormal
Ça, c'est original :
GRUB installé dans le secteur d'amorce d'une partition NTFS... D'autant qu'il ne peut pas servir à grand-chose avec un amorçage EFI.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
GRUB installé dans le secteur d'amorce d'une partition NTFS... D'autant qu'il ne peut pas servir à grand-chose avec un amorçage EFI.
Oui c'est pas logique, d'autant que c'est une partition de réupération de windows.
Pourtant grub fonctionne bien puisque je démarre dessus.
C'est grave ?
Hors ligne
Il faut crée un point de montage pour accéder à la partition d'EFI
Inutile, la partition EFI est déjà montée sur /boot/efi par Debian. C'est nécessaire pour GRUB.
Pourtant grub fonctionne bien puisque je démarre dessus.
Ce n'est pas ce GRUB qui démarre, c'est celui installé dans la partition EFI. Le GRUB installé dans l'amorce de sda2 est 1) pour l'amorçage BIOS, 2) devrait être chaîné par un chargeur principal lancé par le BIOS, et 3) incomplet donc il s'arrêterait après avoir affiché seulement "GRUB".
C'est grave ?
Non. Aucune importance, les secteurs d'amorce ne sont pas utilisé avec l'UEFI.
Il vaut mieux montrer que raconter.
Hors ligne
Ce n'est pas ce GRUB qui démarre, c'est celui installé dans la partition EFI. Le GRUB installé dans l'amorce de sda2 est 1) pour l'amorçage BIOS, 2) devrait être chaîné par un chargeur principal lancé par le BIOS, et 3) incomplet donc il s'arrêterait après avoir affiché seulement "GRUB".
Bien vu ! C'est exacte qu'après que Ubuntu a cessé de fonctionner, il y a cet écran noir avec seulement grub et un invite de commande. J'ai alors fait un halt pour l'arrêter correctement. Mais il me semblait que c'était le même que le boot ubuntu quand j'ai lancé par erreur le boot override de celui ci. ça me dépasse
Merci beaucoup pour ces informations. ça me rassure. J'arrête pas d'ouvrir des onglets pour essayer de comprendre tout ça.
Hors ligne
après que Ubuntu a cessé de fonctionner, il y a cet écran noir avec seulement grub et un invite de commande.
Ah non, avec le peu qui reste de ce GRUB (pas de core image à l'emplacement spécifié), il n'y aurait même pas d'invite de commande "grub>", seulement le texte "GRUB" et plus rien qui marche à part ctrl+alt+suppr. Le GRUB d'Ubuntu qui te donnait l'invite de commande, c'est celui de la partition EFI.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par benbel (30-12-2020 22:00:52)
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Doit on marqué quelque par "résolu" ou un truc du genre ?
Oui :
Voir le tuto : C'est résolu ! Bravo mais il faut l'indiquer dans l'titre.
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
J'ai entendu deux raisons :
- Les mises à jour de Windows sont accusées de d'affecter l'amorçage. Ce n'est pas anormal, une mise à jour de GRUB dans Debian peut faire de même en réinstallant le chargeur d'amorçage.
- Les mises à jour de Windows pourraient échouer si on ne redémarre pas directement sous Windows, sans même passer par GRUB. J'avoue que je suis dubitatif, je me demande comment Windows fait pour savoir que l'amorçage est passé par GRUB.
C'est pourtant ce qu'il se passe sur mon ordi à chaque mise à jour de Windows qui nécessite plusieurs redémarrages: le menu de démarrage de Grub s'affiche et il suffit de choisir Windows pour que la mise à jour continue; et même si on oublie de choisir à temps Windows et que Grub démarre par défaut sur Linux, il suffit de redémarrer et de choisir à nouveau Windows pour que la mise à jour continue. Je l'ai fait des dizaines de fois sur mes deux ordis sans jamais connaître un plantage à ce niveau, ce qui n'empêche pas par contre l'échec assez fréquent des mises à jour de Windows mais ça n'est pas du tout lié à Linux et à son Grub
Dernière modification par capdefradeb (02-01-2021 13:14:28)
Hors ligne
Très sincèrement, je ne vois pas pourquoi il faudrait bloquer les mises à jour de Windows lorsqu'on est en double boot ? J'ai deux ordinateurs dans ce cas sur lesquels je fais très régulièrement les mises à jour de Windows 10 sans avoir rencontré de problème, sauf une amélioration des performances de la machine car, ça me fait mal au derche de devoir le reconnaître, mais Windows 10 s'est nettement amélioré depuis ses débuts...
Je suis obligé de conserver Windows pour pouvoir utiliser des logiciels de diagnostic pour la mécanique auto et moto ainsi que pour la gestion de GPS, montre connectée, etc pour lesquels Linux ne possède pas d'équivalents mais au quotidien, je n'utilise que Linux.
D'accord, mais cela m'est arrivé et je cherche à éviter que ça recommence. Tu l'as depuis combien de temps ce dual boot ?
J'ai eu ce problème sur un autre PC dans lequel j'avais utilisé Windows une fois, puis un mois après il était plus accessible pour avec des symptômes similaires. Cela est arrivé il y a un an et avec le dernier windows 10.
Pour l'instant le blocage des mises à jours est la seule solution rationnelle que j'ai eu. Si tu as d'autres solutions, diagnostiques ou informations, je suis preneur.
J'ai entendu deux raisons :
- Les mises à jour de Windows sont accusées de d'affecter l'amorçage. Ce n'est pas anormal, une mise à jour de GRUB dans Debian peut faire de même en réinstallant le chargeur d'amorçage.
- Les mises à jour de Windows pourraient échouer si on ne redémarre pas directement sous Windows, sans même passer par GRUB. J'avoue que je suis dubitatif, je me demande comment Windows fait pour savoir que l'amorçage est passé par GRUB.
Si tu trouve des infos dessus, je suis preneur aussi
Dernière modification par benbel (09-01-2021 20:39:21)
Hors ligne