Bonjour,
 
J'avais un petit SSD SATA 64 Go sur ma config Ryzen 3600 et MSI B450 Gaming Plus. Et W10 était installé dessus.
 
Puis je me suis acheté un SSD Nvme 500Go.
 
Et j'ai installé W10 dessus avec une clé USB.
 
Je ne me servais plus de l'ancien système une fois le nouveau finalisé et les données importées de l'ancien.
 
Tout marchait bien malgré l'écran de choix du système de boot à chaque démarrage et qui ne durait que 5 sec.
 
Maintenant je voudrais récupérer l'ancien SSD SATA pour le mettre sur un portable, mais quand je le vire de l'ordi ce dernier ne trouve plus rien pour booter et l'ordi est du coup inutilisable. Pourtant dans le setup je spécifie bien en priorité de booter sur le SSD en Nvme.
 
J'ai remis le vieux SSD et tout remarche comme avant.
 
Ya-t-il un moyen de virer le vieux SSD de l'ordi sans devoir réinstaller le W10 du SSD Nvme ?
 
Merci,

bonjour,
 
envoie une capture écran du gestionnaire de disque pour info,
 
certainement les fichiers de boot sur l'ancien ssd.

Merci.
 
Comment on poste une image ? Le site fait hébergeur ?
 

Oui c'est ça tu as le bootloader sur le SSD sata
 
Tu peux essayer de débrancher ton SSD sata, booter sur la cle USB de windows 10 et faire une réparation du démarrage

https://reho.st/

Quand tu as installé Windows 10 sur le SSD de 500Go, tu as probablement laissé l'autre branché.
Or c'est lui qui contenait la partition contenant le bootloader.
C'est pour ça qu'il faut toujours ne laisser que le disque qui accueillera Windows de branché lors de l'installation.
 
Pour maintenant, il faut réparer le bootloader.
C'est faisable en bootant sur l'iso d'installation de Windows et en allant dans le menu de Réparation.

 
OK je teste vos manips !

Je vire le petit SATA.
 
Je boote sur la clé d'install W10.
 
Bon ben la réparation ne peut pas se faire qu'il dit...

Ton W10 est installé en mode MBR (je ne vois pas de partition fat32)
Dans ce mode on peut faire démarrer directement sur la partition C:
Démarre en laissant l'ancien SSD branché (sinon ça démarre pas... )
lancer une invite de commande en tant qu'administrateur (clic droit).
taper la commande suivante:
bcdboot c:\windows  /s c:
Si la commande passe bien aller dans la gestion des disques et rendre la partition C: active.
Sélection partition c: menu Action, toutes les taches, marquer la partition comme active.
Arrête le PC et débranche l'ancien SSD.
Redemarre le PC.

Edit: modification de la commande

L'invite de commande me renvoie la syntaxe de cette commande mais ne semble rien faire d'autre.

Si tu as bien lancé l'invite en tant qu'administrateur (clic droit sur invite de commande et clic sur exécuter en tant qu'administrateur) elle s'exécute et effectivement tu ne vois rien d'autre que le prompt.
Supprime le /f
ne tape que bcdboot c:\windows /s c:
Tu devrais voir dans la racine de C: un dossier recovery il me semble.
ensuite il faut marquer la partition comme active.
J'ai plusieurs PC en W10 qui tournent comme ça.
Il y a longtemps que je n'ai plus fait ces manips...

L'installation est bien en uefi la partition EFI est située part 2 du ssd 64.
il faut créer cette partition sur le ssd disque 2, tu as de l'espace non alloué sur ce disque.
a créer via diskpart , je cherche la suite...

J'ai tapé cmd dans recherche, puis fait un clic droit sur cmd.exe exécuter en tant qu'administrateur.
Ça me donne une fenêtre sombre avec le prompt C:\Windows\system32>
Je tape bcdboot c:\windows /s c: /f
Et ça me renvoie la syntaxe de la commande bcdboot, il doit donc y avoir une erreur de syntaxe.

Cet espace non alloué correspond à l'Overprovisionning que Samsung Magician m'a incité à créer sur ce SSD.

Loriot a raison, la partition EFI existe sur l'ancien, je ne l’avais pas vue.
La commande semble devoir traiter aussi l'UEFI avec le paramètre /f UEFI
voir la liste des paramètres en tapant simplement bcdboot.
Je ne l'ai jamais fait en UEFI, peut-être que ça crée la partition en mangeant un peu du fond de C: comme il fait pour la partition de récupération.

Effectivement en rajoutant UEFI à la fin de la commande initiale ça marche et l'ordi arrive enfin à booter sur le SSD Nvme seul.
 
Sans même avoir eu à aller modifier le setup.
 
Vous êtes des cracks les gars, merci !
 

Pour ma culture, est-ce qu'il a créé une ou deux partitions de plus sur le nvme ? ou bien il n'y a toujours que c: ?

Toujours que C: et la partie non allouée de l'overprovisioning.
 
Il a créé sur C: un dossier "EFI" qui contient 2 dossiers "Boot" et "Microsoft".  
Dans "boot" ya "bootx64.efi"
Dans "Microsoft" ya 2 dossiers "Boot" et "Recovery" puis des trucs dedans ;-)

Merci, ça ressemble un peu à ce qui se faisait en MBR quand des ringards de mon espèce tenaient à n'avoir qu'une seule partition C: et rien d'autre.
Je le faisais avec cette commande.
En UEFI j'avais un peu abdiqué, mais avec ta confirmation il se pourrait que je m'y remette.

Moi non plus je n'aime pas les partoches de 100Mo et consorts, et encore maintenant elles sont cachées, au début on y avait droit dans le poste de travail.
Il me semble qu'à l'installation j'arrivais à forcer une seule partoche et sans bidouiller.
Bon je passe à l'install de W10 avec la clé USB téléchargée chez Grosoft  sur ce portable Dell et avec le SSD 64, ça commence bien, sauf au boot... Mais j'arrive à le faire marcher tout de même, on verra plus tard !

Ça y est pour le portable il faut aussi mettre genre UEFI dans le setup et ça boote bien, je vais me faire un petit portable rapide et sympa de 64 Go avec ce SSD récupéré    
 
Encore merci !

Si tu arrives à booter ton w10 avec seulement ton ssd 465 Go c'est que ton ssd est initialisé en MBR , pour booter en UEFI il faut obligatoirement une part EFI en FAT32.
 
Dans ta config initiale avec les deux ssd tu devais booter via l'EFI part 2 ton ssd MBR disk 2.

C'était mon expérience ancienne en MBR.
On pouvait booter sans avoir la partition système de 100Mo.
Je ne pensais pas que c'était possible en UEFI (sans la partition fat32) mais après avoir lu la description de la commande bcdboot, et la réussite de son application avec le paramètre /f UEFI, il me semblait que c'était possible aussi, même si je trouvais ça bizarre.
Il faudrait creuser un peu le sujet pour en être certain, et voir si des effets de bord sont prévisibles si effectivement c'est possible.
En attendant, on peut voir dans le gestionnaire de disques si un disque est en MBR ou en GPT.
un clic droit sur le disque, dans la zone qui montre les partitions, propose de convertir le disque en MBR s'il est en GPT ou l'inverse selon le cas.
Même grisée cette indication est valable et permet de connaitre facilement l'état d'initialisation du disque.
Je n'ai pas l'expérience des NVME mais je suppose que c'est pareil.

Le nouvel aspect de gestion des disques :
 

un msinfo32 dans éxécuter, le retour du mode bios nous indiquera si uefi
ou hérité.

Mode BIOS ? MSINFO32 dit UEFI

c'est un cas d'école car pas de part efi pour booter , vraiment étrange,
 
un bcdedit en admin pour dernier test ?
 

"Impossible d'ouvrir le magasin des données de configuration de démarrage. Le périphérique système demandé est introuvable."
 
Je sors aux courses, à toute !

Tout indique que le SSD est en GPT, et le Windows en EFI, et qu'il n'y a pas de partition fat32.
Le nécessaire doit être dans les dossiers créés sur C: par la commande bcdboot citée plus haut (comme en MBR mais avec l'option /f UEFI).
Il faudra voir si Microsoft assume bien cette manière de faire, en particulier lors des mises à jour.
Toutes les recherches dans ce domaine m'ont envoyé vers des pages "comment rétablir la partition EFI fat32"

Les gens, vous vous pendriez pas un peu trop la tête pour rien, là ? Je veux dire : si l’UEFI de sa carte-mère peut démarrer sur du NTFS, il n’y a donc pas besoin d’avoir une partition FAT32 juste pour mettre les fichiers de démarrage de l’OS. Toutes n’ont peut-être pas cette capacité, mais si c’est le cas de la sienne, vu que tout le reste est conforme UEFI (disques en GPT, BCD configuré en mode UEFI), y a juste qu’à laisser les choses tourner, vu qu’elles tournent bien. Inutile de chercher à tout prix à réparer ce qui n’est pas cassé.

Il n'est pas question de réparer ce qui n'est pas cassé, tu n'as pas du relire le tout...
La réparation du non démarrage a été faite, on est simplement curieux de voir que la possibilité de démarrage sans partition EFI existerait aussi en mode GPT/UEFI comme c'est le cas en MBR.
On discute de ce cas un peu exotique, C'est interdit sur HFR ?

Ne pars pas sur la défensive comme ça. C’est pas comme si je venais te piquer ton jouet préféré, quand même.
 
Je dis que vous avez assez prouvé comme ça que le bousin peut démarrer en UEFI sur un disque GPT sans avoir fait de partition de démarrage en FAT32 séparée. Pas besoin d’aller pousser plus loin. D’accord, ça sort du « dogme » qui veut qu’on fasse cette partition dans cette configuration, mais voilà, on est face à un cas qui montre que c’est pas parce qu’on a toujours fait d’une certaine manière qu’on ne peut pas faire d’une autre et que ça fonctionne quand même.
Les choses évoluent, les connaissances doivent évoluer aussi en conséquence.
 
On notera donc que la partition EFI séparée n’est pas indispensable si l’UEFI est capable de démarrer sur sur NTFS (sur d’autres systèmes de fichiers comme l’EXT ou le Btrfs, c’est moins sûr). Ça contentera les amoureux de la partition unique pour le système.

Ben moi aussi je veux savoir, c'est tout.  Plus on a d'infos, mieux c'est

Ton post était un peu à coté de la plaque, mais ça aurait pu être pire, j'en connais ici qui auraient dit "formate et réinstalle".
J'aimerais quand même trouver un site qui explique qu'effectivement on peut procéder comme on a fait et qu'il n'y a pas (trop) d'effets secondaires.

J'ai installé les fichiers de boot efi sur une part démarrée w10 mais en MBR via :
 
bcdboot c:\windows /l fr-fr /s c: /f uefi  
 
et j'arrive à booter en uefi confirmé msinfo32 , j'ai même rendu ma petite part système permettant le boot en mbr inactive pour tester et je boote bien en UEFI.
Vraiment étrange de pouvoir booter un disk MBR directement en UEFI sans passer par une part EFI au préalable, ce que je faisais pour test via un disk GPT part EFi .
 
Par contre le bcdedit ne fonctionne qu'en spécifiant bien le chemin:
bcdedit /store c:\efi\microsoft\boot\bcd /v
 
Gestionnaire de démarrage Windows
---------------------------------
identificateur          {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=C:
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  fr-FR
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {7f442157-cb88-11ea-bdc2-1cb72cb1b482}
resumeobject            {7f442156-cb88-11ea-bdc2-1cb72cb1b482}
displayorder            {7f442157-cb88-11ea-bdc2-1cb72cb1b482}
                        {51ce97d7-cbf1-11ea-bdc7-1cb72cb1b482}
                        {6c1234dd-cbf4-11ea-bdc7-1cb72cb1b482}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30
displaybootmenu         Yes
 
Chargeur de démarrage Windows
-----------------------------
identificateur          {7f442157-cb88-11ea-bdc2-1cb72cb1b482}
device                  partition=C:
path                    \windows\system32\winload.efi
description             Windows 10 ssd  
locale                  en-us
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \windows
resumeobject            {7f442156-cb88-11ea-bdc2-1cb72cb1b482}
nx                      OptIn
bootmenupolicy          Standard
 
 
Mon disque C est bien un disque initialisé MBR et pourtant cela boote !!
 
Reste à tester le démarrage après avoir éffacé le bootloader en mbr sur les premiers secteurs du disk mbr...

Dans system32 ils sont là en réserve parce qu'il y a moyen de transformer une installation MBR en GPT UEFI.
De plus il n'y a qu'un seul Windows, UEFI ou pas, tout est présent.
j'ai  fait la conversion MBR--> GPT / UEFI sur ce PC il y a quelques mois (un peu acrobatique dans mon cas).
La manip de conversion MBR to GPT que j'ai citée:
https://forum.hardware.fr/forum2.ph [...] 0#t3350564

Attention l'initialisation en GPT crée tout de même un secteur 0 compatible MBR avec une table de partition type MBR qui couvre tout le disque.
https://fr.wikipedia.org/wiki/GUID_ [...] BR_(LBA_0)

Attention à l'organisation des premiers secteurs, tu risques de tout casser...
https://fr.wikipedia.org/wiki/GUID_ [...] BR_(LBA_0)

Je voulais parler plutôt du bootstrap situé sur le premier secteur du disque MBR de 0h à 1B7h ,
si je mets tout le code à 0 cela indique obligatoirement que le bios ne le lance pas ,
on est donc en uefi en passant par \EFI\Microsoft\Boot\bootmgfw.efi.
Pour résumer il est donc possible de démarrer un disque MBR ou GPT en UEFI sans passer par la part EFI.
Tout ceci est de la bidouille mais c'est bon à savoir et comme tu le signales plus haut rien ne dit que les mises à jour du système se fassent sans problème.
 
A titre info j'ai trouvé un très bon éditeur hexa en freeware avec pas mal d'infos dispo sur les secteurs disques MBR ou GPT :
 
https://www.disk-editor.org/index.html#overview
 
pour les curieux avertis !!

J'utilise HxD
https://mh-nexus.de/en/
si j'en ai l'occasion je me souviendrai du tien.
Il me semble que c'est le 55AA dans les deux derniers octets qui dit que le boot est présent dans le secteur 0.
ça suffit peut-être pour interdire un boot éventuel (je fais pas ça tous les jours... ).