Migration système HDD vers SSD

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut tout le monde,

Je devrais recevoir dans la journée mon SSD de 1 To. Je souhaite migrer tout mon système depuis mon HDD (de 1 To également) vers ce nouveau SSD. J’en ai payé un aussi gros pour ne pas trop m’embêter, justement, à la migration.

Ma question, du coup, c’est est-ce qu’il y a des manipulations particulières à prévoir ? Ou bien est-ce que je peux juste faire un coup de dd entre les deux, virer le HDD pour le reformater plus tard, et ensuite régler le fstab par rapport aux spécificités du SSD ?

Pour précision, je suis sous Archlinux et pour le démarrage je crois que j’utilise UEFI directement, je sais plus ><

+0 -0
Auteur du sujet

Ah tiens, c’est vrai que c’est une bonne remarque ça. Je vais installer une image d’installation d’Arch au cas où. J’ai trouvé le le lien du wiki qui a l’air d’indiquer quand même qu’il va falloir réinstaller le bootloader, il va donc falloir que je me souvienne comment mon PC démarre. À moins que dd ne préserve également le nommage des disques ?

+0 -0

Cette réponse a aidé l’auteur du sujet

Pour savoir comment tu bootes, regardes si tu as un dossier du style /boot/EFI et ce qu’il contient. Tu trouveras des info sur ton booloader.

Si tu utilises un boot manager comme Grub il faudra surement relancer sa config mais un fois que ton as généré le fstab avec les nouveau UUID ça ne devrait pas être un problème.

Si tu utilises un bootloader un peu plus manuel, tu devras peut être copier un UUID selon comment tu l’as configuré. Si tu as utilisé les noms des devices comme /dev/sda1, tu n’auras rien à faire. Ce que tu peux faire par précaution, c’est conserver l’ancien /etc/fstab pour référence et vérifier que tout est cohérent entre l’ancienne et la nouvelle.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+1 -0
Auteur du sujet

J’ai un '/boot/EFI/systemd/systemd-bootx64.ef' et un /boot/EFI/BOOT/BOOTX64.EFI’, ce qui a l’air de correspondre à l’utilisation de systemd pour le démarrage. Je retrouve également le hook de mise à jour dans les hooks de pacman. Je pense donc que c’est du systemd-boot, c’est mon autre PC qui utilise EFISTUB ^^ Il faudra que je corrige l’UUID de la partition et que je relance la configuration des lanceurs UEFI du coup.

Edit : Pour résumer, je devrai :

  • Faire un dd de préférence depuis un live USB
  • Faire un chroot, genfstab et vérifier le fstab
  • Réinstaller systemd-boot sur l’EFI pour qu’il cherche la bonne partition /boot ?
  • Modifier l’UUID dans la config de systemd-boot

Édité par Phigger

+0 -0

Cette réponse a aidé l’auteur du sujet

Petit détail concernant dd: si le ssd est légèrement plus petit que le hdd ça va tronquer la copie et tu vas perdre ce qui se trouve à la fin du disque. Autant la table de backup gpt devrait pouvoir être recréé facilement, autant la dernière partition de ton disque risque de pas trop apprécier de se faire tronquer. Si tu commence d’abord par rétrécir la dernière partition pour que ça passe niveau taille, ça devrait être bon.

Dans le cas inverse (plus de place sur le ssd que sur le hdd), tu vas potentiellement recevoir un avertissement que la table de backup gpt n’est pas à la fin du disque la prochaine fois que tu utilises un outil de partitionnement. C’est quelque chose qui se répare facilement et qui te permettra ensuite d’agrandir la dernière partition du disque pour l’utiliser pleinement.

+1 pour la remarque de @sgble de faire le dd seulement lorsque le hdd n’est pas utilisé. Il n’y a certes aucun risque pour les données sur le hdd, mais si ton système commence à écrire des trucs pendant la copie, ton sdd risque de se retrouver avec certains fichiers corrompus.

+0 -0
Auteur du sujet

Hello hello,

J’ai fait la migration hier et tout s’est bien passé. Un coup de DD, 1h30 d’attente, et je crois bien qu’il n’y a en fait rien d’autre à faire. Les UUID ont été préservés. J’ai réinstallé systemd-boot, mais je crois bien que ce n’était même pas nécessaire. Le fstab généré était identique. Le seul truc, c’est que quand j’ai booté mon système j’ai dû checker mes partitions, ça avait démarré sur la partition /boot du HDD mais chargé la partition root et le swap de mon SSD, donc juste monté la bonne partition avant d’effacer le disque dur.

Puis ensuite, lancer le service de trim pour la gestion du SSD, et c’est tout.

À noter, mon ssd n’est pas monté en /dev/sdb mais /dev/nvme0n1 ^^

+0 -0

À noter, mon ssd n’est pas monté en /dev/sdb mais /dev/nvme0n1 ^^

Phigger

C’est normal, sd* c’est pour les disques attachés en SATA, SAS, ou autre interface du genre, tandis que /nvme* c’est pour les disques en NVMe ;)

La nomenclature semble se baser sur le type de bus utilisé (et donc le module Linux sous-jacent qui le gère), et non pas sur la technologie du disque en soi. Ainsi, un disque SSD attaché SATA aurait été sd* aussi.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte