[Crosspost sans suivi que je laisse à votre discrétion]
Bonjour,
A deux reprises j'ai rencontré un problème que je voudrais bien comprendre.
Soient deux PC en dual boot Windows (7 ou plus) et Linux avec amorçage
BIOS par GRUB sur le même disque. Windows a été installé en premier puis
Linux ensuite, avec le chargeur d'amorçage GRUB dans le MBR pour la
gestion du multiboot. Tout fonctionnait parfaitement, Windows et Linux
démarraient correctement depuis le menu de GRUB.
Sur l'un, on m'a demandé de supprimer Linux. Pour pouvoir supprimer la
partition contenant la seconde partie de GRUB (/boot/grub), j'ai
remplacé l'amorce de GRUB dans le MBR (core image) par un programme
d'amorce qui tient entièrement dans le MBR (avec la commande install-mbr
du paquet mbr pour ceux que ça intéresse).
Sur l'autre, on m'a demandé de supprimer la première partition logique
Linux, inutilisée, et de redimensionner la partition étendue contenant
les partitions Linux afin d'agrandir la partition primaire Windows
adjacente. J'ai dû réinstaller GRUB car la suppression de la partition
logique a renuméroté la partition logique racine de Linux qui était
après. Suite à cela, GRUB et Linux fonctionnaient correctement.
Dans les deux cas j'ai fait les modifications depuis Linux et je n'ai
touché qu'aux partitions de Linux et au MBR, pas aux partitions de Windows.
Au redémarrage, le chargeur de Windows se lance mais affiche un message
d'erreur que je n'ai pas noté mais qui disait quelque chose comme le
système est introuvable. J'ai donc booté avec un DVD d'installation de
Windows et choisi "réparer une installation". Il a trouvé un problème et
proposé de le corriger. J'ai accepté, ça a pris moins d'une seconde, et
au redémarrage, Windows s'est lancé normalement (toujours via GRUB dans
le second cas).
Je ne connais plus le processus de démarrage de Windows depuis le
passage de ntldr à bootmgr opéré avec Windows Vista, et je voudrais bien
comprendre ce qui s'est passé. Des idées ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel__D
Bobjour Le 24/11/2019 à 12:41, Pascal Hambourg a écrit :
[Crosspost sans suivi que je laisse à votre discrétion] Bonjour, A deux reprises j'ai rencontré un problème que je voudrais bien comprendre. Soient deux PC en dual boot Windows (7 ou plus) et Linux avec amorçage BIOS par GRUB sur le même disque. Windows a été installé en premier puis Linux ensuite, avec le chargeur d'amorçage GRUB dans le MBR pour la gestion du multiboot. Tout fonctionnait parfaitement, Windows et Linux démarraient correctement depuis le menu de GRUB. Sur l'un, on m'a demandé de supprimer Linux. Pour pouvoir supprimer la partition contenant la seconde partie de GRUB (/boot/grub), j'ai remplacé l'amorce de GRUB dans le MBR (core image) par un programme d'amorce qui tient entièrement dans le MBR (avec la commande install-mbr du paquet mbr pour ceux que ça intéresse). Sur l'autre, on m'a demandé de supprimer la première partition logique Linux, inutilisée, et de redimensionner la partition étendue contenant les partitions Linux afin d'agrandir la partition primaire Windows adjacente. J'ai dû réinstaller GRUB car la suppression de la partition logique a renuméroté la partition logique racine de Linux qui était après. Suite à cela, GRUB et Linux fonctionnaient correctement. Dans les deux cas j'ai fait les modifications depuis Linux et je n'ai touché qu'aux partitions de Linux et au MBR, pas aux partitions de Windows. Au redémarrage, le chargeur de Windows se lance mais affiche un message d'erreur que je n'ai pas noté mais qui disait quelque chose comme le système est introuvable. J'ai donc booté avec un DVD d'installation de Windows et choisi "réparer une installation". Il a trouvé un problème et proposé de le corriger. J'ai accepté, ça a pris moins d'une seconde, et au redémarrage, Windows s'est lancé normalement (toujours via GRUB dans le second cas).
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
Je ne connais plus le processus de démarrage de Windows depuis le passage de ntldr à bootmgr opéré avec Windows Vista, et je voudrais bien comprendre ce qui s'est passé. Des idées ?
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Bobjour
Le 24/11/2019 à 12:41, Pascal Hambourg a écrit :
[Crosspost sans suivi que je laisse à votre discrétion]
Bonjour,
A deux reprises j'ai rencontré un problème que je voudrais bien comprendre.
Soient deux PC en dual boot Windows (7 ou plus) et Linux avec amorçage BIOS par GRUB sur le même
disque. Windows a été installé en premier puis Linux ensuite, avec le chargeur d'amorçage GRUB dans
le MBR pour la gestion du multiboot. Tout fonctionnait parfaitement, Windows et Linux démarraient
correctement depuis le menu de GRUB.
Sur l'un, on m'a demandé de supprimer Linux. Pour pouvoir supprimer la partition contenant la
seconde partie de GRUB (/boot/grub), j'ai remplacé l'amorce de GRUB dans le MBR (core image) par un
programme d'amorce qui tient entièrement dans le MBR (avec la commande install-mbr du paquet mbr
pour ceux que ça intéresse).
Sur l'autre, on m'a demandé de supprimer la première partition logique Linux, inutilisée, et de
redimensionner la partition étendue contenant les partitions Linux afin d'agrandir la partition
primaire Windows adjacente. J'ai dû réinstaller GRUB car la suppression de la partition logique a
renuméroté la partition logique racine de Linux qui était après. Suite à cela, GRUB et Linux
fonctionnaient correctement.
Dans les deux cas j'ai fait les modifications depuis Linux et je n'ai touché qu'aux partitions de
Linux et au MBR, pas aux partitions de Windows.
Au redémarrage, le chargeur de Windows se lance mais affiche un message d'erreur que je n'ai pas
noté mais qui disait quelque chose comme le système est introuvable. J'ai donc booté avec un DVD
d'installation de Windows et choisi "réparer une installation". Il a trouvé un problème et proposé
de le corriger. J'ai accepté, ça a pris moins d'une seconde, et au redémarrage, Windows s'est lancé
normalement (toujours via GRUB dans le second cas).
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à
l'offset 0x1B8 ) a été modifié ?
Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
Je ne connais plus le processus de démarrage de Windows depuis le passage de ntldr à bootmgr opéré
avec Windows Vista, et je voudrais bien comprendre ce qui s'est passé. Des idées ?
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et
début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Bobjour Le 24/11/2019 à 12:41, Pascal Hambourg a écrit :
[Crosspost sans suivi que je laisse à votre discrétion] Bonjour, A deux reprises j'ai rencontré un problème que je voudrais bien comprendre. Soient deux PC en dual boot Windows (7 ou plus) et Linux avec amorçage BIOS par GRUB sur le même disque. Windows a été installé en premier puis Linux ensuite, avec le chargeur d'amorçage GRUB dans le MBR pour la gestion du multiboot. Tout fonctionnait parfaitement, Windows et Linux démarraient correctement depuis le menu de GRUB. Sur l'un, on m'a demandé de supprimer Linux. Pour pouvoir supprimer la partition contenant la seconde partie de GRUB (/boot/grub), j'ai remplacé l'amorce de GRUB dans le MBR (core image) par un programme d'amorce qui tient entièrement dans le MBR (avec la commande install-mbr du paquet mbr pour ceux que ça intéresse). Sur l'autre, on m'a demandé de supprimer la première partition logique Linux, inutilisée, et de redimensionner la partition étendue contenant les partitions Linux afin d'agrandir la partition primaire Windows adjacente. J'ai dû réinstaller GRUB car la suppression de la partition logique a renuméroté la partition logique racine de Linux qui était après. Suite à cela, GRUB et Linux fonctionnaient correctement. Dans les deux cas j'ai fait les modifications depuis Linux et je n'ai touché qu'aux partitions de Linux et au MBR, pas aux partitions de Windows. Au redémarrage, le chargeur de Windows se lance mais affiche un message d'erreur que je n'ai pas noté mais qui disait quelque chose comme le système est introuvable. J'ai donc booté avec un DVD d'installation de Windows et choisi "réparer une installation". Il a trouvé un problème et proposé de le corriger. J'ai accepté, ça a pris moins d'une seconde, et au redémarrage, Windows s'est lancé normalement (toujours via GRUB dans le second cas).
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
Je ne connais plus le processus de démarrage de Windows depuis le passage de ntldr à bootmgr opéré avec Windows Vista, et je voudrais bien comprendre ce qui s'est passé. Des idées ?
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Otomatic
Michel__D écrivait :
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Pour le multi boot, même entre Windows et Linux, depuis des lustres j'utilise une partition de boot, la seule principale et active, de petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les systèmes. -- Un ordinateur résout des problèmes que nous n'aurions pas sans lui Technique aéronautique : http://aviatechno.net
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et
début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Pour le multi boot, même entre Windows et Linux, depuis des lustres
j'utilise une partition de boot, la seule principale et active, de
petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les
systèmes.
--
Un ordinateur résout des problèmes que nous n'aurions pas sans lui
Technique aéronautique : http://aviatechno.net
A partir de Vista (loader bootmgr et magasin de démarrage BCD) les infos (signature du disque et début de partition) sont stockées au niveau du BCD ( BootBCD ) situé sur la partition active.
Pour le multi boot, même entre Windows et Linux, depuis des lustres j'utilise une partition de boot, la seule principale et active, de petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les systèmes. -- Un ordinateur résout des problèmes que nous n'aurions pas sans lui Technique aéronautique : http://aviatechno.net
Pascal Hambourg
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans
le MBR et débutant à l'offset 0x1B8 ) a été modifié ?
Si c'est le cas c'est normal que le gestionnaire de boot windows ne
retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je
ferai plus attention la prochaine fois.
Du coup je viens de tester les programmes que j'ai utilisés (fdisk,
install-mbr, grub-install) et a priori aucun ne modifie la
signature/identifiant du MBR.
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Pascal Hambourg
Le 24/11/2019 à 17:15, Otomatic a écrit :
Pour le multi boot, même entre Windows et Linux, depuis des lustres j'utilise une partition de boot, la seule principale et active, de petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les systèmes.
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Le 24/11/2019 à 17:15, Otomatic a écrit :
Pour le multi boot, même entre Windows et Linux, depuis des lustres
j'utilise une partition de boot, la seule principale et active, de
petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les
systèmes.
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant.
S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le
secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour
ne pas être fiable.
Pour le multi boot, même entre Windows et Linux, depuis des lustres j'utilise une partition de boot, la seule principale et active, de petite taille et EasyBCD (Sous Windows) pour gérer les boot sur les systèmes.
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Michel__D
Re, Le 24/11/2019 à 19:40, Pascal Hambourg a écrit :
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR. Il suffit de regarder s'il y a des doublons au niveau des déclarations dans : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMMountedDevices] "??Volume{d0af3eb2-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 00,00,00,00,00 "??Volume{d0af3eb3-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 80,02,00,00,00 "??Volume{74a01491-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 00,00,00,00,00 "??Volume{74a01492-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 80,02,00,00,00 Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b et hex:57,b0,6a,9a ) mais avec des débuts de partitions (en octets) identiques ( 0x100000 et 0x 0x280100000 )
Re,
Le 24/11/2019 à 19:40, Pascal Hambourg a écrit :
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à
l'offset 0x1B8 ) a été modifié ?
Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la
prochaine fois.
Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a
priori aucun ne modifie la signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR.
Il suffit de regarder s'il y a des doublons au niveau des déclarations dans :
Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b et hex:57,b0,6a,9a )
mais avec des débuts de partitions (en octets) identiques ( 0x100000 et 0x 0x280100000 )
Re, Le 24/11/2019 à 19:40, Pascal Hambourg a écrit :
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR. Il suffit de regarder s'il y a des doublons au niveau des déclarations dans : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMMountedDevices] "??Volume{d0af3eb2-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 00,00,00,00,00 "??Volume{d0af3eb3-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 80,02,00,00,00 "??Volume{74a01491-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 00,00,00,00,00 "??Volume{74a01492-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 80,02,00,00,00 Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b et hex:57,b0,6a,9a ) mais avec des débuts de partitions (en octets) identiques ( 0x100000 et 0x 0x280100000 )
Pascal Hambourg
Le 24/11/2019 à 20:20, Michel__D a écrit :
Le 24/11/2019 à 19:40, Pascal Hambourg a écrit :
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR. Il suffit de regarder s'il y a des doublons au niveau des déclarations dans : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMMountedDevices] "??Volume{d0af3eb2-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 00,00,00,00,00 "??Volume{d0af3eb3-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 80,02,00,00,00 "??Volume{74a01491-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 00,00,00,00,00 "??Volume{74a01492-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 80,02,00,00,00 Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b et hex:57,b0,6a,9a ) mais avec des débuts de partitions (en octets) identiques ( 0x100000 et 0x 0x280100000 )
C'est de cette façon que Windows identifie les partitions ? Je pensais qu'il se basait sur l'identifiant de système de fichiers NTFS ou autre. Je n'ai plus les deux PC sous la main. Si l'un d'eux revient, je regarderai. Merci pour les infos.
Le 24/11/2019 à 20:20, Michel__D a écrit :
Le 24/11/2019 à 19:40, Pascal Hambourg a écrit :
Le 24/11/2019 à 16:55, Michel__D a écrit :
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue
dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ?
Si c'est le cas c'est normal que le gestionnaire de boot windows ne
retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je
ferai plus attention la prochaine fois.
Du coup je viens de tester les programmes que j'ai utilisés (fdisk,
install-mbr, grub-install) et a priori aucun ne modifie la
signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR.
Il suffit de regarder s'il y a des doublons au niveau des déclarations
dans :
Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b
et hex:57,b0,6a,9a )
mais avec des débuts de partitions (en octets) identiques ( 0x100000
et 0x 0x280100000 )
C'est de cette façon que Windows identifie les partitions ? Je pensais
qu'il se basait sur l'identifiant de système de fichiers NTFS ou autre.
Je n'ai plus les deux PC sous la main. Si l'un d'eux revient, je
regarderai. Merci pour les infos.
Pour les 2 cas la signature du disque (valeur sur 4 octets contenue dans le MBR et débutant à l'offset 0x1B8 ) a été modifié ? Si c'est le cas c'est normal que le gestionnaire de boot windows ne retrouve pas ses petits.
J'ignorais ce détail aussi je n'ai pas pensé à vérifier ce point. Je ferai plus attention la prochaine fois. Du coup je viens de tester les programmes que j'ai utilisés (fdisk, install-mbr, grub-install) et a priori aucun ne modifie la signature/identifiant du MBR.
Si c'est lié à la signature du disque cela a laissé des traces dans la BDR. Il suffit de regarder s'il y a des doublons au niveau des déclarations dans : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMMountedDevices] "??Volume{d0af3eb2-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 00,00,00,00,00 "??Volume{d0af3eb3-9a49-11e2-9e08-806e6f6e6963}"=hex:57,b0,6a,9b,00,00,10, 80,02,00,00,00 "??Volume{74a01491-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 00,00,00,00,00 "??Volume{74a01492-9a52-11e2-b980-806e6f6e6963}"=hex:57,b0,6a,9a,00,00,10, 80,02,00,00,00 Dans cet exemple 2 signatures de disques différentes ( hex:57,b0,6a,9b et hex:57,b0,6a,9a ) mais avec des débuts de partitions (en octets) identiques ( 0x100000 et 0x 0x280100000 )
C'est de cette façon que Windows identifie les partitions ? Je pensais qu'il se basait sur l'identifiant de système de fichiers NTFS ou autre. Je n'ai plus les deux PC sous la main. Si l'un d'eux revient, je regarderai. Merci pour les infos.
Otomatic
Pascal Hambourg écrivait :
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes du disque SSD Volume0 Linux Mint est installé sur un autre disque SSD Volume1 Vu avec EasyBCD : Entrée #3 Nom : Linux Mint Identifiant BCD : {9c911b01-ac56-11e8-a328-d81bde9fa2c5} Périphérique : DeviceHarddiskVolume1 Chemin du chargeur d'amorçage : NSTAutoNeoGrub0.mbr
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant.
S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le
secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour
ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes
du disque SSD Volume0
Linux Mint est installé sur un autre disque SSD Volume1
Vu avec EasyBCD :
Entrée #3
Nom : Linux Mint
Identifiant BCD : {9c911b01-ac56-11e8-a328-d81bde9fa2c5}
Périphérique : DeviceHarddiskVolume1
Chemin du chargeur d'amorçage : NSTAutoNeoGrub0.mbr
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes du disque SSD Volume0 Linux Mint est installé sur un autre disque SSD Volume1 Vu avec EasyBCD : Entrée #3 Nom : Linux Mint Identifiant BCD : {9c911b01-ac56-11e8-a328-d81bde9fa2c5} Périphérique : DeviceHarddiskVolume1 Chemin du chargeur d'amorçage : NSTAutoNeoGrub0.mbr
Pascal Hambourg
Le 25/11/2019 à 08:59, Otomatic a écrit :
Pascal Hambourg écrivait :
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes du disque SSD Volume0 Linux Mint est installé sur un autre disque SSD Volume1
Donc solution valable seulement avec plusieurs disques.
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant.
S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le
secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour
ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes
du disque SSD Volume0
Linux Mint est installé sur un autre disque SSD Volume1
Donc solution valable seulement avec plusieurs disques.
On peut amorcer Linux nativement depuis bootmgr ? Ce serait étonnant. S'il faut chaîner GRUB, cela implique d'installer ce dernier dans le secteur d'amorce d'une partition au lieu du MBR, ce qui est connu pour ne pas être fiable.
Windows 10 et Windows 7 sont installés dans des partitions différentes du disque SSD Volume0 Linux Mint est installé sur un autre disque SSD Volume1
Donc solution valable seulement avec plusieurs disques.
