Journal Migrer Windows 10 d'un disque BIOS/MBR, vers un SSD en mode UEFI/GPT avec des logiciels libres

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
14
17
juin
2018

Sommaire

Introduction

Ce tutoriel vous guide pas à pas pour migrer votre installation de
Windows qui est actuellement sur un disque dur de votre PC vers un
nouveau disque, en l'occurrence un SSD. A vrai dire, vous pouvez aussi
bien migrer vers un autre HDD.

La spécificité de ce tutoriel est qu'elle utilise les outils fournis par
Microsoft avec Windows ainsi que des logiciels libres (Clonezilla
principalement, mais si quelque chose devait mal tourner vous pouvez avoir
besoin d'utiliser fdisk, gdisk ou testdisk pour ne citer qu'eux). Quand
j'ai voulu faire cette migration je n'ai pas trouvé de tutoriel
expliquant de bout en bout comment faire cette migration juste avec les
outils de Microsoft et des logiciels libres.

Typiquement, vous pouvez avoir envie/besoin de faire cela car vous avez
acheté un nouveau disque pour remplacer l'ancien (par exemple car
l'ancien montre des signes de faiblesse, ou vous voulez améliorer la
réactivité de votre système).

En plus de la migration du système d'exploitation, ce tutoriel vous
explique comment passer d'un démarrage en mode BIOS/MBR à un démarrage
en mode UEFI/GPT.

Succinctement la démarche est la suivante, d'abord installer le nouveau
disque dans le PC, et initialiser la table de partition selon les normes
Microsoft. Puis cloner/dupliquer la partition contenant le système
d'exploitation à l'aide de Clonezilla. Ensuite et avant de redémarrer
dans le clone de Windows sur le SSD, faire quelques modifications dans
le registre pour que la lettre de lecteur C: pointe vers la bonne
partition et éventuellement modifier le mode SATA en AHCI si vous le
modifiez aussi dans le UEFI/BIOS. Après cela, on va préparer la
partition système EFI/ESP pour que le PC puisse démarrer dessus et qu'il
démarre sur le Windows du SSD. Finalement, une fois dans le Windows du
SSD, on va réactiver l'"environnement de récupération de Windows".

Mise en garde : Faites une sauvegarde de vos données avant toute
opération. Personne n'est à l'abri d'une mauvaise manipulation ou d'une
erreur.

Prérequis

Compétences

Niveau de difficulté : Difficile.

Vous devez être à l'aise au niveau de l'utilisation de la ligne de
commande dans Windows, mais aussi assez à l'aise pour gérer les
partitions de votre disque. Savoir modifier le paramétrage de votre
Firmware UEFI/BIOS et aussi nécessaire. Ce tutoriel guide pas à pas pour
la majorité des opérations. Certaines n'ont pas été détaillées par souci
de simplicité et d'efficacité.

Matériel

Le PC où vous voulez installer le SSD. Il faut qu'il soit en état de
marche. De plus il doit avoir un firmware UEFI. S'il n'a que un BIOS
standard, sans UEFI, ce tutoriel n'est pas adapté.

Clé(s) USB ou plusieurs CD/DVD sur lequel vous aurez mis
Clonezilla, System rescue
CD
et un environnement de démarrage
Windows PE, ou Windows RE, ou le DVD/Disque d'installation de Windows.

Le disque SSD (testé avec Samsung SSD 860 EVO 250GB). Il doit avoir une
taille suffisante pour contenir votre partition de Windows. Dans tous
les cas, la taille de la partition qui contiendra Windows sur le SSD
doit être au moins égale à la taille de la partition Windows du HDD que
vous voulez cloner. Au besoin, pour remplir ce critère, réduisez la
taille de votre partition Windows avec le gestionnaire de disque de
Windows par exemple (ou un autre outil de gestion de partition, comme
gparted, sur le System Rescue CD). Cherchez sur internet si vous ne
savez pas comment faire.

Logiciel

Windows 10 installé (en version 64 bits) (testé avec Win10 v1709)

Windows 10 PE ou support d'installation de Windows 10 (clé USB ou DVD) -
En Version 64 bits (testé avec un support d'installation de Win10 v1804)

System rescue CD (version 5.2.2 par
exemple)

Clonezilla installé sur une clé ou un CD.
Bien vérifier avant que votre système arrive à démarrer dessus. (Testé
avec Clonezilla 2.5.5-38)

Nomenclature

SSD : désigne le nouveau SSD

HDD : désigne votre disque actuel, sur lequel est installé Windows

WinPE : un environnement de démarrage Windows PE, ou Windows RE, ou le
DVD/Disque d'installation de Windows. Il doit être sur un support
amovible (USB, CD ou DVD)

S: La lettre de lecteur affectée à la partition Système EFI qui sera sur
le nouveau SSD (parfois appelée ESP, EFI_System_Partition ou encore
SYSTEM, ou EFI)

N: Le clone de Windows, sur le SSD

O: Le Windows cloné, sur le HDD

C: La partition dans laquelle est installée Windows, lorsqu'on est dans
Windows (que ce soit le windows cloné, ou le clone)

Les commandes doivent être lancées en tant qu'administrateur.

Procédure de base

  • Fixer et brancher le SSD dans l’ordinateur

  • Désactiver Windows FastStart (cf votre moteur de recherche préféré)

  • Initialiser et partitionner le disque à l'aide de Windows

    • Démarrer sur le Windows installé ou WinPE
    • Pour initialiser le disque, d'abord créer une table de partition, puis partitionner le disque. Pour ce faire :
      • Suivre les instructions de partitionnement UEFI/GPT selon Microsoft. Ci-dessous mon exemple, mais peut-être avez-vous besoin d'une partition "recovery" aussi, ou votre configuration nécessite quelques aménagements. Dans ce cas, voir les instructions de Microsoft et adapter pour vos besoins.
      • Par exemple: une partition EFI de 260Mo, une partition Microsoft Reserved (MSR) de 16Mo, une partition pour Windows (taille au moins égale à la taille de la partition de Windows à cloner). Pour informations, dans diskpart, les tailles que vous donnez en MB/Mo sont en réalité des MiB/Mio (220 = 10242 octets).
        • Ouvrir une invite de commande en mode administrateur et lancer diskpart . Et une fois dans diskpart :
          • list disk pour lister les disques et connaître le n° du SSD.
          • select disk # avec le numéro du SSD à la place de #
          • clean Supprime le contenu du disque / l'initialise
          • convert gpt Définit que le disque aura une table de partition GPT
          • create partition efi size=260 Crée une partition EFI de 260MiB
          • format quick fs=fat32 label="System" Formater la partition EFI au format FAT32
          • assign letter="S" Lui donner la lettre S
          • create partition msr size=16 Créer une partition Microsoft Reserved de 16MiB
          • create partition primary Créer la partition pour Windows (l'équivalent du C: )
          • format quick fs=ntfs label="Windows" Formater la partition pour Windows au format NTFS
          • assign letter="N" Lui donner la lettre N
          • list volume Liste les volumes. Permet de voir la table de partition.
          • exit Quitte diskpart
  • Cloner le Windows installé sur le HDD. Ceci sera fait à l'aide de
    Clonezilla

    • Redémarrer dans Clonezilla
    • Une fois dans clonezilla, et si vous êtes confortable avec les lignes de commande Linux, éventuellement supprimer de la partition Windows du HDD les fichiers pagefile.sys , hyberfil.sys (désactiver windows faststart avant), swapfile.sys .
    • Cloner la partition Windows du HDD vers le SSD (de préférence, partition de même taille, et de toutes façons, la partition de destination doit être plus grande que la source. Si ce n'est pas le cas, réduisez d'abord la taille de votre partition Windows depuis Windows). Dans clonezilla, utiliser le mode Partition vers Partition, et en mode Export. Utiliser les options -e1 auto (automatically adjust file system geometry for a ntfs boot partition if exists) -e2 (sfdisk uses CHS of hard drive from EDD (for non grub loader) -r (resize filesystem to fit partition size of target) -m (do NOT clone boot loader) -v (verbose)
    • Optionnellement cacher la partition contenant le windows source de la table de partition du disque source (si vous ne savez pas à quoi ça sert, passez votre chemin). Pour cela modifier le type de partition de la partition NTFS de windows (en principe, NTFS a un id de « 7 ». On peut utiliser id 17 pour la partition cachée : 17 correspond à « IFS Hidden »). Utiliser cfdisk ou fdisk pour faire ce changement (ce sont des programmes linux).
  • Dans le Firmware UEFI (ou BIOS-UEFI), on peut en profiter pour passer
    du mode SATA "IDE" vers "AHCI". Windows n'aime pas ce changement et
    il faut donc faire une opération dans le registre qui est
    détaillée ci-dessous. Tant que vous ne le faites pas, vous aurez un
    écran de plantage bleu de windows au démarrage (BSOD).

  • Si vous voulez être sûr de ne pas faire de bêtise dans le Windows que
    vous venez de cloner, je vous conseille d'éteindre l’ordinateur & de
    débrancher l’ancien disque. Ainsi vous ne risquez pas de modifier le
    mauvais fichier de registre (en l'occurrence celui de votre Windows
    sur le HDD)

  • Effectuer quelques opérations sur le Windows de destination (celui
    sur le SSD) avant qu'on ne démarre dessus. En particulier corriger le
    registre pour affecter la lettre de lecteur C: à la bonne partition,
    et si le paramétrage du Firmware UEFI (BIOS-UEFI) a été modifié pour
    passer de SATA Mode PCI vers AHCI, on va aussi faire ce changement
    pour que ca fonctionne.

    • Redémarrer dans WinPE (en Mode UEFI, pas MBR !)
      • Tout d'abord déterminer la lettre de lecteur affectée au clone de Windows, celui qui est sur le SSD. Ou, s'il n'y a pas de lettre affectée, lui en donner une, par exemple N: (lettre utilisée dans les exemples qui suivent)
        • Pour cela, lancer dans diskpart
          • list volume
            Ce qui retourne la liste des volumes avec la lettre de lecteur qui a été affectée à chacun.
        • Si aucune lettre de lecteur n'est affectée, il faut alors lui en affecter une. Pour cela, lancer dans diskpart
          • select volume # (avec # étant le numéro du volume qui contient le nouveau windows)
          • assign letter=N
            S'il n'est pas possible d'utiliser select volume alors faire comme ceci
          • list disk
          • select disk # (# étant le numéro affecté au SSD)
          • list partition
          • select partition # (# étant le numéro affecté à la partition de Windows sur le SSD, probablement 3)
          • assign letter=N
      • Faire un CHKDSK /F sur la lettre du nouveau Win
      • Pour que la partition C: utilisée par Windows soit celle du SSD et pas celle de l’ancien disque, modifier une clé de registre du nouveau Windows :
        • Lancer REGEDIT et dans le registre HKEY_LOCAL_MACHINE monter la ruche N:\Windows\System32\Config\SYSTEM . Lui donner le nom "NewWin" On s’intéresse à HKEY_LOCAL_MACHINE\NewWin\MountedDevices . Ce sont là les valeurs qui sont dans le registre " HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices " lorsqu'on est dans l'installation de Windows.
          • Dans HKEY_LOCAL_MACHINE\NewWin\MountedDevices modifier la lettre de lecteur C: en renommant \DosDevices\C: par \DosDevices\O: (car la valeur fait référence à la partition de l'ancien Windows sur le HDD et on ne veut pas, en démarrant, utiliser cette partition mais celle de son clone qui est sur le SSD). Ainsi, lorsqu'on démarrera dans le nouveau Windows, la partition contenant le Windows sur le HDD aura la lettre O:, et la partition contenant le Windows sur le SSD aura la lettre C:
          • Créer une nouvelle valeur binaire nommée \DosDevices\C: et lui donner comme contenu celui de \DosDevices\N: qui est renseignée dans le registre WinPE, c'est-à-dire là HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ( C: étant la lettre qu'utilisait le Windows du HDD comme partition où il y a le dossier \Windows )
          • ATTENTION: Bien vérifier que la copie a fonctionné et qu'il y a les bonnes valeurs, car dans mes essais, j'ai du m'y reprendre à 2 fois car le 1er "coller" ne collait pas ce que je voulais.
          • En principe c'est tout. Mais d'après certaines sources, il y aurait une clé \\?\Volume{GUID} ayant le même contenu que le \DosDevices\O: qu’on vient de modifier. Chez moi ce n'était pas le cas. Si vous avez une telle valeur, alors il faut lui donner le contenu de \DosDevices\N: depuis le registre WinPE
      • Si en même temps que la migration on veut aussi passer du mode SATA IDE vers AHCI alors il faut encore faire ceci. Cela a été repris du site tomshardware.co.uk
        • Toujours dans REGEDIT avec la ruche montée en HKEY_LOCAL_MACHINE\NewWin
        • Aller à HKEY_LOCAL_MACHINE\NewWin\ControlSet000\Services\storahci\StartOverride
        • Changer la valeur DWORD de 3 à 0.
        • Au redémarrage, si ça n'a pas été fait, changer la paramétrage du contrôleur SATA de IDE à AHCI. Au redémarrage, Windows devrait directement démarrer correctement et sans plantage (BSOD).
      • Rendre le disque bootable en installant les outils EFI de microsoft et configurant le Magasin BCD (BCD Store)
        • D'abord assigner une lettre de lecteur à la partition ESP
          • MOUNTVOL S: /S
            Si ca n'a pas fonctionné, faire comme ceci dans diskpart
          • list disk
          • select disk # (# est le numero du SSD retourné par list disk)
          • list partition
          • select partition # (# est probablement 1)
          • assign letter=S
        • Puis lancer bcdboot N:\windows /l fr-fr /s S: /f UEFI
          • N:\Windows est le répertoire contenant le clone de Windows sur le SSD)
          • S: = partition EFI
  • Redémarrer, et avant le lancement de Windows vérifier votre UEFI
    (ou BIOS-UEFI). Il faut qu'il soit configuré pour démarrer par défaut
    en mode UEFI et pas en mode BIOS. Penser aussi à corriger le
    paramétrage SATA si cela a été modifié dans le registre de Windows.

    Le paramétrage du démarrage avec
    bcdboot N:\windows /l fr-fr /s S: /f UEFI a normalement créé le
    magasin BCD, mis tous les fichiers EFI sur la partition SYSTEME (ESP,
    partiton EFI, la 1ère du SSD) et dit au firmware UEFI qu'il doit
    automatiquement démarrer avec le gestionnaire de démarrage
    (boot manager) de Windows.

  • Une fois qu’on a réussi à démarrer dans la copie de Windows

    • Réactiver le "FastBoot"
    • Réactiver l'environnement de récupération de Windows en lançant, depuis une ligne de commande avec les droits administrateur, la commande reagentc.exe /enable . Vérifier avec reagentc.exe /info . Et s'il y a une erreur essayer avec reagentc.exe /enable /setreimage /path C:\Recovery\WindowsREC:\Recovery\WindowsRE est le dossier où se trouve le fichier Winre.wim
    • Vérifier que tout est en ordre. Eventuellement donner un nouveau nom à votre partition C: (pour la différencier de celle sur le HDD) en lançant: LABEL [drive:][label]
    • Redémarrer encore une fois en laissant le processus de démarrage se faire tout seul pour vérifier que tout est ok.
  • Réinsérer l'ancien disque dur.

  • Normalement, il devrait être possible de redémarrer dans l'ancien
    Windows, du moment que vous savez comment booter en MBR, et sous
    réserve de ne pas avoir modifié le mode SATA dans le UEFI/BIOS. SI
    c'est le cas, vous pouvez envisager de modifier le registre du
    Windows du HDD, ou de modifier le paramétrage du UEFI/BIOS.

    Si vous avez aussi Linux d'installé sur le HDD, il devrait toujours
    être possible de le démarrer en mode BIOS

  • On peut diminuer/augmenter la taille de la partition C: du SSD (Pour
    un SSD TLC ou VNAND, on peut par exemple laisser de l’espace libre à
    la fin ~10 % de la capacité du disque d'après le logiciel Samsung
    Magician, pour un SSD 860 EVO)

  • En principe, puisqu’on boot en EFI on peut enlever sur le clone
    Windows sur le SSD les fichiers \bootmgr et \Boot\BCD puisque ce
    sont ceux qui étaient utilisés pour un boot en mode BIOS/MBR et que
    désormais on est en EFI. Vous pouvez d'abord les renommer et vérifier
    que ca ne change rien au prochain boot, plutôt que de les supprimer
    tout de suite.

Quelques pistes si ça ne fonctionne pas…

  • Faire un chkdsk sur la nouvelle partition
  • Recréer le bootsector du NTFS avec testdisk (dispo sur System Rescue CD, mais peut être aussi dans Clonezilla ? Je n'ai pas vérifié)
  • Vérifier le BCD:
  • Vérifier que la partition EFI est bien initialisée (présence des fichiers \EFI , \EFI\Boot\ , \EFI\Microsoft\ …) Si ce n'est pas le cas, il y a eu un problème avec bcdboot N:\windows /l fr-fr /s S: /f UEFI
  • Vérifier le boot manager du bios (démarrage en UEFI ou MBR ? Gestionnaire de démarrage par défaut ? Présence du gestionnaire de démarrage de Windows ?)
  • A priori, pas utile : Commandes à lancer dans WinPE
    • Pour recréer le boot sector de la partition systeme (EFI): bootrec /fixboot
    • Pour chercher les OS sur le disque et les mettre dans le bootloader bootrec /scanos
  • Quelques commandes de bcdedit pour modiser la valeur de certains éléments du magasin BCD. Inutile car le BCD Store qui est utilisé lorsqu'on démarre en mode EFI n'est pas le même que celui utilisé dans un démarrage en mode MBR. Donc, pas besoin de chercher à modifier le BCD. Je garde pour info : les lettres sont celles telles que définies dans le système où on est (WinPE par ex). Doc BCDEDIT
    • bcdedit /set {bootmgr} device \Device\HarddiskVolume1
    • bcdedit /set {default} device \Device\HarddiskVolume3
    • bcdedit /set {default} osdevice \Device\HarddiskVolume3
    • Ou à la place de \Device\HarddiskVolume1 mettre les lettres de lecteur :
    • bcdedit /set {bootmgr} device partition=S:
    • bcdedit /set {default} device partition=C:
    • bcdedit /set {default} osdevice partition=C:

Documentation, pour aller plus loin…

A propos du EFI/UEFI:

A propos de l'entrée MountedDevices du registre:
http://diddy.boot-land.net/firadisk/files/mounteddevices.htm

Si on veut y accéder, par défaut les fichiers du BCD sont cachés. Pour
les rendre visibles:

  • attrib bcd -s -h -r
  • mv bcd bcd.bak
  • bootrec /rebuildbcd

Documentation bcdedit:

MBR Partition ID

A propos des disk ID (=Disk signatures):

Si besoin de supprimer du registre les entrées de disques qui ne sont
pas connectés ou sans lettre assignée lancer: mountvol /R. Ce
programme permet aussi de lister les lettres de volumes avec leur GUID
(GUID pour ce système uniquement, il n’est pas stocké dans la partition,
ni ailleurs sur le disque, il est assigné par windows pour un couple
(signature de disque/partition offset) dans une instance de windows
alors que dans une autre instance de windows la même partition sur le
même disque aura ce GUID différent)

Changer le label du volume: commande LABEL [drive:][label]

Historique de révisions

  • Vous trouverez la dernière version de ce tutoriel sur ma page perso
    de tutoriels informatique
    .
    Vous y trouverez aussi la version HTML, PDF et TXT.

  • 2018-06-17 : Ajout d'une note indiquant que ce tutoriel utilise des
    logiciels libres

  • 2018-06-11 : Correction de la forme et de fautes d'orthographe

  • 2018-05-28

  • # Les joies du logiciel privateur

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 17 juin 2018 à 16:31.

    (ici de temps)…

    Et dire qu'un simple coup de dd suffit à faire le travail (ou l'essentiel) pour les système où ce n'est pas l'utilisateur le produit…

    PS : merci pour les infos. Ça peut toujours servir pour dépanner quelqu'un.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Les joies du logiciel privateur

      Posté par  . Évalué à 5.

      LOL…

      C'est quand même amusant comment tu rejettes constamment ta profonde ignorance de ce système sur Microsoft… Difficile à ce point d'assumer ton ignorance ?

      Allez… https://www.digitaltrends.com/computing/how-to-move-windows-10-to-an-ssd/

      J'ai mis exactement 5 secondes à le trouver ce lien hein. C'était le 1er lien sur Google.

      • [^] # Re: Les joies du logiciel privateur

        Posté par  (site web personnel) . Évalué à -1.

        « C'est quand même amusant comment tu rejettes constamment ta profonde ignorance de ce système sur Microsoft…

        En fait, je ne la rejette pas, je l'assume, je m'en pare, j'en suis fier, je la cultive, la met bien en exergue, et la porte en étendard ! Je ne souhaites pas participer du culte ignoble du profit dont mirosoft est l'un des porte étendard. En revanche c'est bien malgré moi que cela me donne l'air d'un prosélyte du logiciel libre. Simplement je m'oppose à cette morale que brandissent M. Gate et consorts qu'on pourrait résumer ainsi : « tout est bon pourvu que cela conduise au profit. »

        Nos points de vue sont si orthogonaux… Juste à titre de curiosité lesquelles des logiciels que propose votre lien sont des logiciels libres ? Quelles sont les raisons techniques qui les rendent indispensables ? Pourquoi une simple copie d'image disque ne peut suffire à déplacer une installation widows ? Comme vous le soulignez à raison je suis totalement ignorant de ce domaine. Nonobstant je suppute que remonter le fil des réponses de chacune des questions de ce paragraphe nous ramènerait invariablement à la maxime qui conclue le premier.

        Me détromperez-vous ; vous dont l'expertise technique n'est plus à démontrer ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Les joies du logiciel privateur

          Posté par  . Évalué à 0.

          Et sinon c'est interdit de gagner de l'argent en développant des applications ?
          Car oui effectivement dans son lien il y a des logiciels fermés et payants, et donc ? Oui il y a des gens qui les développent et assurent un sav derrière. Et tu ne vas pas me croire mais ils ne vivent pas d'amour et d'eau fraîche ;)

          D'ailleurs ces mêmes personnes grâce à leur métier de développeur de méchants logiciels fermés et payants (et donc grâce à leurs revenus stables), on la possibilité d'occuper leur temps libre pour participer à une communauté du monde libre qui sait ? Tu le sais toi qui fait de la poésie dans tes réponses ? Tu vis d'amour et d'eau fraîche ? Tu ne fais pas payer ton travail de tous les jours ?

          • [^] # Re: Les joies du logiciel privateur

            Posté par  (site web personnel) . Évalué à -2.

            « […] c'est interdit de gagner de l'argent en développant des applications ? »

            Homme de paille ou quiproquo ? Quoiqu'il en soit, la réponse est de toute évidence : en aucun cas. Mais ne paraît-il pas préférable de le faire avec une activité qui bénéficie à l'humanité plutôt qu'elle lui nuise ; dans la limite où l'on puisse en juger bien entendu ?

            « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Les joies du logiciel privateur

          Posté par  . Évalué à 0.

          En fait, je ne la rejette pas, je l'assume, je m'en pare, j'en suis fier, je la cultive, la met bien en exergue, et la porte en étendard !

          Tu portes donc l'ignorance comme une fierté…. Bravo.

          C'est dans l'ère du temps, remarque. T'es pile dans le thème, avec les anti-vaccins, les partisans de la Terre plate, et ceux qui nient le réchauffement climatique.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Les joies du logiciel privateur

          Posté par  . Évalué à 2.

          a) Juste à titre de curiosité lesquelles des logiciels que propose votre lien sont des logiciels libres ?

          Question stupide. Je n'ai aucune idée de quel soft est libre ou pas. Si ils ne te plaisent pas, écris en un libre toi-même. C'est ça la liberté !

          b) Quelles sont les raisons techniques qui les rendent indispensables ?

          Ou as tu vu qu'ils sont indispensables ? Ils sont une aide. Si tu prèferes faire des étapes à la main libre à toi.

          c) Pourquoi une simple copie d'image disque ne peut suffire à déplacer une installation widows ?

          Parce que sur plein de Linux cela ne fonctionne pas non plus. Parce que le système s'attend à ce que le HW sous lui ne change pas abruptement sans qu'il en soit informé.

          • [^] # Re: Les joies du logiciel privateur

            Posté par  (site web personnel) . Évalué à 4.

            Parce que sur plein de Linux cela ne fonctionne pas non plus.

            Ca c'est juste du foutage de gueule, à part des cas très particuliers, tu peux déplacer n'importe qu'elle Linux avec juste cette commande: tar.

            Au boulot, pas de RAID matériel pour cette raison là, j'ai un serveur qui lâche, il faut qu'il tourne et je ne peux pas attendre DELL, je prend les disques de mon serveur, je les balance dans n'importe quel PC et ça juste boot. Certes les performances sont dégradées mais je suis pas sur qu'un Windows ferait la même chose.

            • [^] # Re: Les joies du logiciel privateur

              Posté par  (site web personnel) . Évalué à 2.

              Ca c'est juste du foutage de gueule, à part des cas très particuliers, tu peux déplacer n'importe qu'elle Linux avec juste cette commande: tar.

              Je confirme, pour avoir utilisé (et abusé ?) de cette facilité au boulot : étant le plus expérimenté le l’équipe concernant Linux, je maintenais mon PC portable attitré dans un état propre et bien géré. Puis, à chaque fois qu’un nouveau développeur arrivait dans l’équipe avec son ordi portable, ce dernier était intégré en quelques étapes simples :

              1. Dans Windows, réduire la partition pour faire de la place à Linux et faire les chkdsk adéquats.
              2. LiveCD sur le nouveau PC, création des partitions swap, / et /home montées sous /mnt, puis lancement de sshd (root autorisé).
              3. LiveCD sur mon PC, montage de mes partitions sous /mnt, puis # tar -C /mnt -czf - . | ssh -Tx root@new-PC 'tar -C /mnt -xpzf -'
              4. Sur le nouveau PC, chroot /mnt, quelques réglages (hostname, install boot-loader), puis reboot et c’est fini !
            • [^] # Re: Les joies du logiciel privateur

              Posté par  . Évalué à 6.

              tu peux déplacer n'importe qu'elle Linux avec juste cette commande: tar.

              Tu exagères un peu : il faut partitionner (et éventuellement remettre les même UUID de partitions), puis dé-tar, puis faire un chroot pour réinstaller GRUB, puis éventuellement modifier /etc/fstab si les UUID ont changés.

              C'est fiable, propre, et rapide. Par contre il faut s'y connaître un peu.

      • [^] # Re: Les joies du logiciel privateur

        Posté par  . Évalué à 8.

        Allez… https://www.digitaltrends.com/computing/how-to-move-windows-10-to-an-ssd/
        J'ai mis exactement 5 secondes à le trouver ce lien hein. C'était le 1er lien sur Google.

        Le journal parle d'outils libres. Il y zéro outil libre dans ce que tu proposes.
        Vouloir utiliser du libre (ou du gratuit, ou du propriétaire, etc) c'est un choix. Discutable, comme tous les choix, mais ça reste un choix. Donc proposer un truc super-facile qui ne respecte pas ce choix, ce n'est pas une solution.

        De plus, j'utilise souvent les outils de chez AOMEI et EaseUS cités dans ton lien : il ne sont pas fiables. Ça fonctionne pour les choses basiques, et le reste c'est selon l'humeur du jour. Alors qu'avec dd, partimage, etc, je n'ai jamais (jamais comme dans jamais-jamais) eu de mauvaise surprise.

        • [^] # Re: Les joies du logiciel privateur

          Posté par  . Évalué à 7.

          Discutable, comme tous les choix, mais ça reste un choix. Donc proposer un truc super-facile qui ne respecte pas ce choix, ce n'est pas une solution.

          Rien à voir. On a une personne qui pointe du doigt l'OS pour la complexité de la marche à suivre dictée ici. Je lui montre très simplement que migrer l'OS est extrêmement simple si on utilise le bon outil et qu'il ne sait pas de quoi il parle.

          Ensuite que les outils soient libre ou pas, c'est une autre histoire, l'OS n'a rien à voir là dedans.

    • [^] # Re: Les joies du logiciel privateur

      Posté par  . Évalué à 3.

      Et dire qu'un simple coup de dd suffit à faire le travail (ou l'essentiel) pour les système où ce n'est pas l'utilisateur le produit…

      De manière à simplifier la vie des utilisateurs de serveurs beaucoup de distributions utilisent de UUID de type : UUID=aba14cd9-97d5-4bc5-8ae9-3bfc3a2b2f2e

      Du coup, si tu changes un disque dur avec dd, ton système ne boutera plus du tout …

      Du coup, il faut soit brancher son disque et faire un :
      sudo lsblk -o name,mountpoint,size,type,ro,label,uuid
      ou blkid
      de manière à récupérer les infos et ensuite changer le fstab, installer le disque et rebooter, changer le bootloader dans /boot/grub/grub.cfg mettre à jour grub

      Soit sur un PC portable il faut booter sur une clef et changer le fstab et changer le boot loader, chrooter et mettre à jour grub.

      Et encore ça fait un bail que je ne l'ai pas fait, j'oublie peut être des trucs

      Franchement, ce n'est plus si simple ce que tu dis …

      • [^] # Copie brute

        Posté par  . Évalué à 3.

        De manière à simplifier la vie des utilisateurs de serveurs beaucoup de distributions utilisent de UUID de type : UUID=aba14cd9-97d5-4bc5-8ae9-3bfc3a2b2f2e

        Du coup, si tu changes un disque dur avec dd, ton système ne boutera plus du tout …

        En général, c’est l’UUID de la partition qui est utilisée, et avec une copie brute avec un outil comme dd (je conseillerais GNU ddrescue, même si le disque d’origine ne présente pas d’erreurs, il est plus rapide que dd), il est conservé.
        Note : on a fortement intérêt à ne pas se tromper entre la source et la destination.

        Du coup, on monte le SSD, on fait une copie brute dessus, on arrête le PC, on démonte le disque dur, on reboote, et ça doit fonctionner.

        Mais il semble à lire l’article que son auteur veut conserver le disque dur en plus du SSD. C’est là que ça se complique : deux partitions avec le même UUID, ça pose problème, surtout si c’est ce qu’on utilise pour monter le disque. En reformatant le disque dur juste après la copie sur SSD ou en changeant les UUID de ses partitions, ça doit éviter le souci.

        Bon, si on ne fait pas une copie brute de tout le disque, mais juste des partitions, il faut comme tu le dis plus loin démarrer sur clé USB et réinstaller GRUB, ce qui rend l’opération moins simple.
        Si GRUB « ne retrouve pas ses billes » avec le changement de disque, pour une raison ou pour une autre, on n’échappe pas non plus à sa réinstallation.

        Cela dit, la copie brute a des limites : il faut que le SSD soit assez grand, il faut aussi que le disque dur ait été partitionné relativement récemment (sinon l’alignement des partitions ne conviendra pas à un SSD).

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Copie brute

          Posté par  . Évalué à 2.

          C'est marrant, on l'avait fait à l'époque et cela n'avait pas conservé l'UUID …

          Après je ne sais pas si le fstab et grub.cfg prenaient l'UUID de la partition ou celle du disque …

          Peut être que les choses sont différentes maintenant ou peut être que cela dépend de la distribution non ?

        • [^] # Re: Copie brute

          Posté par  . Évalué à 8.

          Ou soit on utilise LVM et on peut migrer les volumes à chaud d'un HDD à l'autre sans s'arrêter de bosser :D

        • [^] # Re: Copie brute

          Posté par  (site web personnel) . Évalué à 3.

          je conseillerais GNU ddrescue, même si le disque d’origine ne présente pas d’erreurs, il est plus rapide que dd

          J'ai du mal à y croire. Avec quelles options ? Et tant qu'à mettre des options autant changer la taille des blocs sous dd, ça va beaucoup plus vite.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Les joies du logiciel privateur

        Posté par  (site web personnel) . Évalué à 2.

        Franchement, ce n'est plus si simple ce que tu dis …

        1) Faire un tar de l'OS à froid
        2) Extraire le tar sur l'autre machine
        3) Modifier le fstab
        4) Installer GRUB et mettre à jour sa conf

        c'est quand même pas la mort!

        • [^] # Re: Les joies du logiciel privateur

          Posté par  . Évalué à 3.

          c'est quand même pas la mort!

          Il me semble qu'à une époque udev foutait la grouille, genre il numérotait Slowlaris staÿle les interfaces réseau en fonction du nom du driver associé, et donc du coup, la reconnexion réseau se passait moins bien si le driver de la carte réseau changeait à la migration. Ça n'est plus vrai ?

  • # TLDR

    Posté par  . Évalué à -3.

    1- Tu sauvegardes tes données
    2- Tu télécharges une ISO de Windows (c'est gratuit) que tu installes sur une clé USB
    3- Tu installes Windows sur ton nouveau disque : rien de tel qu'une installation fraîche (compter 1 heure, y compris maj)
    4- Tu réinstalles tes progs et tes données (1 heure)
    En 2 ou 3 heures tu as un ordi tout neuf, sans te prendre la tête.

    • [^] # Re: TLDR

      Posté par  (site web personnel) . Évalué à 10.

      Dis-moi quel est ton problème, je te dirai comment t’en passer.

      À ce niveau t’aurais pu directement proposer d’installer Linux.

      ce commentaire est sous licence cc by 4 et précédentes

      • [^] # Re: TLDR

        Posté par  . Évalué à -2.

        Eh bien non, sa solution n'est compliquée que parce qu'il s'y prend mal.
        Tous ceux qui ont eu à gérer des parcs informatiques savent que la meilleure solution, à tous points de vue, c'est de réinstaller.
        Et réinstaller Windows est désormais beaucoup plus simple et rapide qu'il y a quelques années.
        Keep It Simple Stupid !
        Quant à proposer Linux… Je n'y avais pas songé, même si c'est ce que j'utilise au quotidien.

        • [^] # Re: TLDR

          Posté par  (site web personnel) . Évalué à 10.

          Tous ceux qui ont eu à gérer des parcs informatiques avec des clés logicielles complexes et introuvables, des installations de logiciels ultra-spécialisés bidouillées par la maintenance, voire de logiciels développés exprès dont on a perdu les copies et le développeur, … savent que cloner Windows est bien plus rapide et donne moins de crises de nerfs. ;-)

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: TLDR

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Ou même tout simplement un seul logiciel comme Oracle, qui demande 10 ans d'installation à lui tout seul pour une version de base sans réglage spécifique.

            La connaissance libre : https://zestedesavoir.com

            • [^] # Re: TLDR

              Posté par  (Mastodon) . Évalué à 3.

              Nous installons Oracle (les serveurs de DB) en quelques secondes sur nos serveurs linux. Tu parles de quel logiciel Oracle ?

              Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

              • [^] # Re: TLDR

                Posté par  (site web personnel, Mastodon) . Évalué à 4.

                Les SGBD. Même mon dernier essai en date avec la version Docker de Oracle 12cR2 m'a pris près de deux heures (et 15 Go). Si tu as effectivement une technique qui permet d'installer ça « en quelques secondes » et qu'elle n'est pas secrète, je suis preneur.

                La connaissance libre : https://zestedesavoir.com

                • [^] # Re: TLDR

                  Posté par  (Mastodon) . Évalué à 3.

                  On utilise puppet pour cela avec le module biemond/oradb. On l'utilise comme dépendance à un module qui configure plein de trucs interne chez nous (firewall, lvm, arborescence, sysctl, etc) et que je ne vais pas lister ici mais voici un extrait d'exemple :

                  (je passe l'initialisation des variables)

                    oradb::installdb{ '12.1.0.2_Linux-x86-64':                                                                                                                                                 
                   version                   => '12.1.0.2',                                                                                                                                                 
                   file                      => 'linuxamd64_12102_database',                                                                                                                                
                   database_type             => 'EE',                                                                                                                                                       
                   oracle_base               => $orabase,                                                                                                                                                   
                   oracle_home               => $orahome12,                                                                                                                                                 
                   bash_profile              => true,                                                                                                                                                       
                   user                      => $user,                                                                                                                                                      
                   group                     => $group,                                                                                                                                                     
                   group_install             => $installgroup,                                                                                                                                              
                   group_oper                => 'oper',                                                                                                                                                     
                   download_dir              => $download_dir,                                                                                                                                              
                   ora_inventory_dir         => $orainv,                                                                                                                                                    
                   zip_extract               => true,                                                                                                                                                       
                   remote_file               => true,                                                                                                                                                       
                   puppet_download_mnt_point => 'puppet:///largefiles/oracle', 
                  

                  }

                  Et on installe aussi les opatch de cette façon :

                     oradb::opatchupgrade{'122019_opatch_upgrade':                                                                                                                                              
                       oracle_home               => $orahome12,                                                                                                                                                 
                       patch_file                => 'p6880880_121010_Linux-x86-64.zip',                                                                                                                         
                       opversion                 => '12.2.0.1.9',                                                                                                                                               
                       user                      => $user,                                                                                                                                                      
                       group                     => $installgroup,                                                                                                                                              
                       download_dir              => $download_dir,                                                                                                                                              
                       puppet_download_mnt_point => 'puppet:///largefiles/oracle',                                                                                                                              
                       require                   =>  Oradb::Installdb['12.1.0.2_Linux-x86-64'],                                                                                                                 
                     }    
                  

                  Ainsi que la config du listener, la création d'une base vide juste pour tester, etc, etc. En gros la seule partie qui n'est pas automatisée c'est le rappatriement des fichiers zip d'installation et de patchs qu'on va chercher manuellement sur le site de support et qu'on héberge sur nos serveurs.

                  Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

      • [^] # Re: TLDR

        Posté par  (Mastodon) . Évalué à 2.

        En dehors de ça passer par une étape réinstall/restauration des données/applications cela reste un très bon exercice.

        La première fois ça peut éventuellement se passer dans la douleurs si on a des backups pas complets, qu'on n'a pas capable d'automatiser les installation des applis et les récupérations de configs, mais sur le long terme ça peut permettre d'avoir une procédure disaster/recovery aux petits oignons en cas de panne.

        Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: TLDR

      Posté par  . Évalué à 3.

      Il me semble que la nouvelle install de Windows va réclamer une clef d'activation tôt ou tard et je doute qu'il soit possible de l'extraire de l'install précédente… mais ça me serait très utile d'avoir tort à condition que tu détailles la procédure !

      • [^] # Re: TLDR

        Posté par  . Évalué à 0.

        Un ordi qui tourne sous Windows10 n'a plus besoin de clé d'activation : Microsoft connaît l'ordi.
        Pour les systèmes antérieurs la clé est sur l'étiquette Windows.

        • [^] # Re: TLDR

          Posté par  . Évalué à 2.

          Non. La clé d'activation existe toujours, sauf qu'elle est dans les tables ACPI.

          C'est d'ailleurs un problème quand tu détaxes un PC la licence est toujours dedans et on ne peut l'enlever.
          Risque légal de s'activer automatiquement si qqu'un installe un windows par la suite.

          • [^] # Re: TLDR

            Posté par  . Évalué à 0.

            Et donc, pour répondre à l'interrogation de calandoa : Windows ne réclamera pas de clé d'activation.

            • [^] # Re: TLDR

              Posté par  (site web personnel) . Évalué à 1.

              Étrange… J’ai récemment installé 2 fois Windows 10 Pro (2 PC différents), et à chaque fois, ça a demandé une clef d’activation.

              L’explication est peut-être dans le fait que ce sont des PC nus (assemblés) sur lesquels Windows est ensuite ajouté, à l’opposé d’un ordinateur pré-installé…

              • [^] # Re: TLDR

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Pour avoir installé les deux, je confirme : les ordinateurs pré-installés ont la clé enregistrée directement dans le BIOS. Ça marche tellement bien que si tu réinstalles Windows sur une clé USB sur un ordinateur avec Windows pré-installé, ça détecte directement la licence.

                Mais évidemment sur les PC nus, ça ne fonctionne pas.

                Ce que je ne sais pas, c'est ce qui se passe si tu reinstalles Windows sur un PC assemblé, mais sans formater la partition EFI : est-ce qu'il te redemande ta licence ?

                La connaissance libre : https://zestedesavoir.com

                • [^] # Re: TLDR

                  Posté par  . Évalué à 0.

                  Si ton PC est assemblé par tes soins de toute façon ton hdd sera vierge donc en aucun cas tu auras déjà une partition EFI et donc encore moins des clés de licence Windows.

          • [^] # Re: TLDR

            Posté par  . Évalué à 2. Dernière modification le 21 juin 2018 à 12:23.

            Non. La clé d'activation existe toujours, sauf qu'elle est dans les tables ACPI.

            TIL.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: TLDR

        Posté par  (site web personnel) . Évalué à 2.

        Il y a 2 possibilités :
        Si le PC est livré sous Windows 10, la clé est dans une table ACPI, le PC la détecte et l'utilise.
        Si le PC a été migré d'un ancien Windows vers Windows 10, c'est une licence numérique stockée chez Microsoft, elle est récupérée automatiquement lors de la première connexion à internet.

        Donc si tu as déjà un Windows 10 activé sur ta machine, lors du reformatage tu ne rentres pas de clé et normalement Windows retrouve ses petits.

        Pour la licence numérique, j'imagine que Windows fait une tambouille avec différents composants du PC (au moins l'UUID de la carte mère, le CPUID du proc et l'adresse Mac, car je devais garder les même pour reformater une VM et garder l'activation) et l'envoie aux serveurs MS qui lui renvoie sa licence/son activation.

        S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

  • # Eh bin , heureusement que je n'ai pas de windows 10

    Posté par  (Mastodon) . Évalué à -1. Dernière modification le 17 juin 2018 à 19:53.

    ni de 1 jusqu'à 9 d'ailleurs …

  • # Merci

    Posté par  . Évalué à 4.

    Merci pour ce tuto bien détaillé, je le mets sous le coude, il pourrait servir.

    • [^] # Re: Merci

      Posté par  . Évalué à 1.

      N’étant pas très a l’aise avec Windows, je te remercie pour tous le travail que tu viens de nous mâcher, je le garde sous le coude.

      Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Pas très contagieux

    Posté par  . Évalué à 8.

    Je n'aurais jamais cru que ce soit si compliqué de faire passer un virus d'un disque à un autre…

    [ OK je sors… ]

  • # Garder la licence OEM

    Posté par  (Mastodon) . Évalué à 8. Dernière modification le 18 juin 2018 à 11:02.

    Récemment j'ai été très étonné à quel point il était facile de garder sa licence OEM en changeant de disque (ordi portable où j'ai changé le HDD par un SSD).

    Pour rappel, la licence OEM est une licence associée à un ordi, pas à une personne. Reste donc à connaître la définition d'un ordi, puisque potentiellement en changeant composant par composant, on pourrait trimballer cette licence à vie… et bien c'est presque le cas !

    Dès qu'on change un composant simple comme la carte graphique, ou qu'on rajoute de la RAM, aucun soucis, rien ne se passe, la licence est toujours reconnue. Par contre des changements lourds comme la carte-mère (ou le CPU il me semble), il faut passer par un coup de fil au support Microsoft qui apparemment est super ouvert, et vous réactivera la licence sans vous emmerder plus que ça.

    Reste le cas du disque, qui est un composant "simple", mais qui demande une réinstallation.

    Et bien ça se fait facilement, en se créant un compte Microsoft.

    • Sur l'ancien ordi, se créer un compte Microsoft
    • Associer la licence OEM à ce compte (je sais plus comment ça se fait, mais cette procédure est très facile à trouver)
    • Télécharger l'image d'install Windows10 et le mettre sur une clé USB
    • Mettre le nouveau disque
    • Lors de l'install, remettre son compte Microsoft
    • Vérifier que l'activation a bien eu lieu

    Voilà, un ordi acheté il y a 5 ou 6 ans sous Windows8 a été entretemps upgradé RAM+SSD, et possède une licence reconnue Windows10 (j'avais fait l'upgrade gratuite Win8->Win10 à la sortie de Win10).

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.