{RESOLU} / commande DD - passage HDD 240GB vers 500GB

d33p · 25-08-2017 09:15:44

Hello,

Avant de m'aventurer la dedans, j'aimerais être rassuré... ou pas

Je compte migrer mon OS, debian buster, d'un SSD SATA 240GB vers un SSD m2 500GB.
Je pensais faire un DD du 240GB vers le 500GB.
Apres, je suppose, que je devrais detruire mes partitions à l'aide de fdisk ou gdisk, puis les resizer en fonction du nouveau disque.
En suivant ceci par exemple:
https://debian-facile.org/atelier:chant … a-demonter

C'est aussi simple que ça, ou je risque des problemes? (je pense surtout au fait de passer de sata à m2?)

Si quelqu'un a une idée je suis preneur...
Si besoin de plus d'info, n'hesitez pas...

merci.

d33p

Dernière modification par d33p (21-09-2017 05:32:15)

smolski · 25-08-2017 09:35:15

Le M.2, également connu sous le sigle de NGFF (pour Next Generation Form Factor), est un connecteur permettant de brancher sur une carte mère différentes sortes de cartes filles, telles que des cartes Wi-Fi, WWAN, USB, PCIe, ou des SSD de petit format basés sur la norme SATA1 (La dernière génération de SSD M.2 se connecte directement en PCIe afin de permettre des débits plus élevés. D'où la présence sur certaines Carte mères de ports distincts M.2 SATA et M.2 PCIe ou Ultra M.2). Sa conception est destinée aux appareils mobiles tels que les Ultrabooks ou les tablettes.

Ce format est une amélioration du mSATA.

https://fr.wikipedia.org/wiki/M.2

d33p · 25-08-2017 09:42:52

je pensais à des potentiels problemes avec les UUID etc... par exemple, comme je change de port & d'interface... voire au boot...
ou meme avec une histoire de pilotes, comme l'os est deja installé, peut etre que ce ne sera pas optimisé pour le nouveau disque?

raleur · 25-08-2017 09:50:03

Tu as plusieurs façons de transférer le contenu d'un disque dans un autre disque plus grand, chacune avec ses avantages et ses inconvénients.

1) Copie bloc à bloc du disque entier avec dd
Simple.
Copie le chargeur d'amorçage situé dans le MBR et la zone réservée.
Copie même les blocs non utilisés, qu'il faudra libérer ensuite avec fstrim.
Plus long que nécessaire si l'espace disque réellemement occupé est faible.
Aucune partition du disque source ne doit être utilisée en lecture-écriture pendant la copie.
Si la table de partition est au format GPT, il faudra la corriger pour tenir compte de la nouvelle taille.
L'espace libre non partitionné sera à la fin du nouveau disque, donc il sera plus compliqué d'agrandir les partitions situées au début car il faut déplacer les suivantes. Le seul programme courant qui le fait est Gparted.

2) Copie bloc à bloc des partitions avec dd
Il faut d'abord créer une table de partition et les partitions sur le nouveau disque.
On peut créer des partitions plus grandes que les originales pour agrandir leur contenu ensuite avec resizefs ou programme équivalent.
Copie même les blocs non utilisés, qu'il faudra libérer ensuite avec fstrim.
Plus long que nécessaire si l'espace disque réellemement occupé est faible.
Aucune partition du disque source ne doit être utilisée en lecture-écriture pendant la copie.
Il faudra réinstaller le chargeur d'amorçage.

3) Copie du disque ou des partitions avec clonezilla, partclone ou partimage
Ne copie que les blocs occupés (pour les types de données gérés par le programme)
Aucune partition du disque source ne doit être utilisée en lecture-écriture pendant la copie.
Avec clonezilla, je ne sais pas s'il est possible d'agrandir les partitions en meme temps.
Il faut peut-être réinstaller le chargeur d'amorçage.

4) Copie des fichiers avec cp, rsync
Il faut créer la table de partition, les partitions, et les formater.
Les nouvelles partitions peuvent être plus grandes.
Ne copie que les blocs occupés, forcément.
Supprime la fragmentation des systèmes de fichiers sources, mais pas très pertinent avec des SSD.
Il faut faire correspondre les UUID ou étiquettes entre les partitions et le fstab et autres fichiers (hibernation).
Il faut réinstaller le chargeur d'amorçage.

Si tu veux agrandir les partitions au passage, je pense que la méthode 1 n'est pas la bonne.
En amorçage BIOS, il faudra probablement réinstaller le chargeur d'amorçage avec les méthodes 2 et 3, à coup sûr avec la méthode 4.
En amorçage EFI, il faudra réinstaller ou réenregistrer le chargeur d'amorçage avec les méthodes 2, 3 et 4.

En résumé, est-ce que tu risques des problèmes ? Oui, et pas (ou pas seulement) à cause du passage de SATA à M.2.

Dernière modification par raleur (25-08-2017 10:24:47)

smolski · 25-08-2017 10:02:44

Super !
Mis dans le wiki ici :
https://debian-facile.org/doc:systeme:p … s-le-forum

Merci les compères de ce post

d33p · 25-08-2017 10:32:09

ah raleur... comme d'hab merci pour ces eclairages.

En amorçage EFI, il faudra réinstaller ou réenregistrer le chargeur d'amorçage avec les méthodes 2, 3 et 4.

je sens que je vais encore pleurer avec grub...

Aucune partition du disque source ne doit être utilisée en lecture-écriture pendant la copie.

je vais faire ceci à l'aide d'un live sur usb alors, merci de m'avoir prevenu.

je vais tester lorsque j'ai un moment, je reviendrais ici donner le retour de ce que j'ai fait et comment ça s'est passé. (surement semaine prochaine)
je pense que je vais partir sur ta proposition numero 2) DD par partition, ça m'a l'air pas mal pour ce que je vais faire.

merci

d33p

Dernière modification par d33p (25-08-2017 10:32:47)

nono47 · 25-08-2017 10:41:00

Salut,

raleur a écrit :

Avec clonezilla, je ne sais pas s'il est possible d'agrandir les partitions en meme temps.

Ça date un peu, mais il m'avait fallu faire une partition de la même taille que celle d'origine pour que clonezilla fonctionne .
et ensuite, je m'étais occupé de la taille des partitions ( sans clonezilla )

mais peut être c'est différent avec une nouvelle version .

Dernière modification par nono47 (25-08-2017 10:41:58)

raleur · 25-08-2017 10:45:44

nono47 a écrit :

je vais faire ceci à l'aide d'un live sur usb alors

On peut aussi le faire en démarrant en mode rescue et en remontant les partitions en lecture seule, mais c'est moins confortable.

nono47 a écrit :

Ça date un peu, mais il m'avait fallu faire une partition de la même taille que celle d'origine pour que clonezilla fonctionne

Si c'est toujours le cas, il faut voir s'il est possible d'espacer les partitions de destination pour leur laisser de la place pour s'agrandir sans devoir tout déplacer.

d33p · 20-09-2017 15:17:47

hello,

j ai commence et ............. termine je n ai plus d OS bootable
j ai essaye ces methodes .> https://doc.ubuntu-fr.org/tutoriel/comm … aurer_grub
j ai essaye des manip avec chroot ca ne fonctionne pas je recois ceci

/usr/sbin/grub-mkconfig: 105: /usr/sbin/grub-mkconfig: fgrep: not found

/usr/sbin/grub-mkconfig: 251: /usr/sbin/grub-mkconfig: rm: not found

raleur · 20-09-2017 15:48:02

Quelle méthode de clonage as-tu appliquée ?

Tu as chrooté vers où ? 'rm' non trouvé est anormal, c'est une commande de base, à moins que le $PATH soit incomplete.

Caribou22 · 20-09-2017 15:54:46

Bonjour,

Je ne sais pas si ça aide, mais j'ai fait ça avec ddrescue d'un HDD en fin de vie à un autre HDD du même volume. Ça a filé comme une lettre à la poste

d33p · 20-09-2017 16:22:19

hello
j ai fait DD par partition,

DD if=source of=destination bs=4096 conv=noerror

DD de la partiton EFI, DD de la partition / ** et un cp du /home ** (car le home etait ' la base sur un autre disque, j-ai tout ramene sur mon ssd m2)
pour le chroot, je suis en live cd fedora j ai que ca sous la main...
j ai suivi ceci > https://askubuntu.com/questions/145241/ … m-a-livecd
j ai aussi essaye de bricoler ici >

mais rien de concluant

ps desole pour l ecriture j ai un clavier masque anglais...

d33p · 20-09-2017 16:51:11

Caribou22 a écrit :

Bonjour,

Je ne sais pas si ça aide, mais j'ai fait ça avec ddrescue d'un HDD en fin de vie à un autre HDD du même volume. Ça a filé comme une lettre à la poste

je voulais le faire a la mano avec des outils de base... snif

raleur · 20-09-2017 17:11:59

Il y a 4 disques ?
Bizarrement, GRUB ne voit aucune partition sur aucun des disques.
Les tables de partition de l'ancien et du nouveau disque sont à quel format, DOS/MBR ou GPT ?
Le GRUB qui s'est lancé
- est en EFI
- cherche une partition n° 2 sur le même disque que la partition EFI, au format DOS/MBR.
Si le disque est au format GPT, il ne peut pas la trouver.

Pour le chroot, tu n'aurais pas plutôt une copie de l'installateur Debian sous la main ?

Dernière modification par raleur (20-09-2017 19:14:40)

d33p · 20-09-2017 17:22:24

Il y a 4 disques ?

non, il n-y a que la cle usb fedora live et le ssd m2, j ai vire tout le reste pour pas m embrouiller

[root@localhost-live root]# lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

sdf           8:80   1  28.8G  0 disk 

├─sdf3        8:83   1  11.4M  0 part 

├─sdf1        8:81   1   1.4G  0 part /run/initramfs/live

└─sdf2        8:82   1   5.2M  0 part 

loop1         7:1    0   6.5G  1 loop 

├─live-base 253:1    0   6.5G  1 dm   

└─live-rw   253:0    0   6.5G  0 dm   /

loop2         7:2    0   512M  0 loop 

└─live-rw   253:0    0   6.5G  0 dm   /

loop0         7:0    0   1.3G  1 loop 

sda           8:0    0 489.1G  0 disk 

├─sda2        8:2    0 459.1G  0 part /mnt/525/part2

├─sda3        8:3    0    29G  0 part [SWAP]

└─sda1        8:1    0   953M  0 part /mnt/525/part1

ca c est le new ssd m2

Disk /dev/sda: 489.1 GiB, 525112713216 bytes, 1025610768 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: gpt

Disk identifier: D73CF5ED-2FCA-4C46-96F4-E1B72203D485

Device         Start        End   Sectors   Size Type

/dev/sda1       2048    1953791   1951744   953M EFI System

/dev/sda2    1953792  964691967 962738176 459.1G Linux filesystem

/dev/sda3  964691968 1025610734  60918767    29G Linux swap

ca t aide ?

Dernière modification par d33p (20-09-2017 17:23:34)

raleur · 20-09-2017 17:37:38

Pourtant GRUB, donc le BIOS, voyait 4 disques...

Le SSD M2 est en GPT, comme je pensais. Je suppose que l'ancien disque était au format DOS/MBR ?
Donc il faut chrooter et réinstaller GRUB pour qu'il prenne en compte le format GPT.

d33p a écrit :

et un cp du /home ** (car le home etait ' la base sur un autre disque, j-ai tout ramene sur mon ssd m2)

Il n'y a pas de partition séparée pour /home, donc tout dans la racine. C'est voulu ?

Dernière modification par raleur (20-09-2017 17:37:59)

d33p · 20-09-2017 17:50:43

Il n'y a pas de partition séparée pour /home, donc tout dans la racine. C'est voulu ?

oui j ai voulu juste l avoir dans le repertoire home dans / on perd moins de place et c est moins fige

Je suppose que l'ancien disque était au format DOS/MBR ?

aucune idee

Donc il faut chrooter et réinstaller GRUB pour qu'il prenne en compte le format GPT.

le chroot ne fonctionnait pas

d33p · 20-09-2017 18:07:44

Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present

on voit ca dans gdisk / fdisk

raleur · 20-09-2017 19:13:41

C'est le nouveau SSD, ça. Je sais déjà qu'il est en GPT, la sortie de fdisk que tu as fournie l'indiquait.
Tu n'as plus l'ancien pour regarder ? De toute façon, ce n'est pas bien utile.

Par contre, avec gdisk tu peux convertir le disque au format DOS/MBR. Ainsi il ne serait pas nécessaire de réinstaller GRUB. Jusqu'à 4 partitions et 2 To, le format GPT n'est pas indispensable.
Commandes "r" pour passer en mode recovery/transformation et "g" pour convertir en MBR/DOS. Conserver l'ordre des partitions.

Sinon, pour la réinstallation de GRUB, tu n'as vraiment pas une version quelconque de l'installateur Debian ? Son mode rescue est très pratique pour chrooter un système et effectuer toutes sortes d'opérations.

Comment as-tu fait exactement pour chrooter avec Fedora live ?
rm et fgrep sont des commandes standard qui se trouvent dans /bin, donc elles sont forcément présentes et accessibles si le contenu de la variable d'environnement $PATH est correct.

Dernière modification par raleur (20-09-2017 19:17:56)

d33p · 20-09-2017 19:34:40

Comment as-tu fait exactement pour chrooter avec Fedora live ?

j'avais monté la partition / dans mnt puis lancé le grub update. et cela me renvoyait ces erreurs...

mais en fait, je suis passé par un autre plan:
https://wiki.debian.org/GrubEFIReinstall
-J'ai créé une clé usb de *rEFInd rescue media*
-J'ai rebooté.
-Il a trouvé mon debian.
-Je suis entré dans ma session.
-J'ai fait un

apt-get install --reinstall grub-efi

 

-ensuite

grub-install /dev/sda

-puis

update-grub

-un reboot et c'est reparti!

la je vais me pencher sur la swap, lorsque je veux la resizer, il me met ceci

resize2fs: Bad magic number in super-block while trying to open /dev/sda3

Couldn't find valid filesystem superblock.

je suis vraiment moisi lol... comme je galere...

Merci raleur

Dernière modification par d33p (20-09-2017 19:35:57)

raleur · 20-09-2017 19:52:15

d33p a écrit :

j'avais monté la partition / dans mnt puis lancé le grub update.

Je ne vois pas de chroot là dedans.

rEFInd, c'est une solution de facilité pour petits joueurs.

La réinstallation du paquet grub-efi était totalement inutile, d'autant que ce n'est pas ce paquet qui contient les fichiers permettant d'installer le chargeur, c'est grub-efi-amd64-bin.

Un swap n'est pas un système de fichiers et ne se redimensionne pas avec resize2fs qui ne marche qu'avec les systèmes de fichiers ext*.
Il faut le désactiver avec swapoff, redimensionner ou supprimer et recréer la partition avec son outil préféré, et réinitialiser le swap avec mkswap en forçant le même UUID qu'avant qui est dans /etc/fstab sinon le système ne le retrouvera pas.

d33p · 20-09-2017 20:33:28

Je ne vois pas de chroot là dedans.

apres avoir monté / dans /mnt, j'avais fait un chroot /mnt...

rEFInd, c'est une solution de facilité pour petits joueurs.

je suis desolé chui vert vraiment, j'vais essayer de m'ameliorer avec les annees mais la j'avais trouvé que ça...

Un swap n'est pas un système de fichiers et ne se redimensionne pas avec resize2fs qui ne marche qu'avec les systèmes de fichiers ext*.
Il faut le désactiver avec swapoff, redimensionner ou supprimer et recréer la partition avec son outil préféré, et réinitialiser le swap avec mkswap en forçant le même UUID qu'avant qui est dans /etc/fstab sinon le système ne le retrouvera pas.

ok, merci :-)
je pouvais encore essayer longtemps.

raleur · 20-09-2017 21:00:46

d33p a écrit :

apres avoir monté / dans /mnt, j'avais fait un chroot /mnt...

Le $PATH de Fedora était peut-être différent et ne contenait pas /bin. Il me semble que Fedora a effectué la fusion d'/usr et de la racine, et que tout le contenu de /bin, /sbin... se trouve dans /usr donc le $PATH n'a plus besoin de contenir /bin ni /sbin. A vérifier à l'occasion si tu démarres à nouveau cette Fedora live, avec la commande suivante.

echo $PATH

Dernière modification par raleur (20-09-2017 21:01:08)

d33p · 20-09-2017 22:03:59

je me souviens avoir meme fait un ls et il ne connaissait pas la commande, c'est surement lié à ce que tu dis.

d33p · 21-09-2017 05:31:38

d33p a écrit :

apres avoir monté / dans /mnt, j'avais fait un chroot /mnt...

Le $PATH de Fedora était peut-être différent et ne contenait pas /bin. Il me semble que Fedora a effectué la fusion d'/usr et de la racine, et que tout le contenu de /bin, /sbin... se trouve dans /usr donc le $PATH n'a plus besoin de contenir /bin ni /sbin. A vérifier à l'occasion si tu démarres à nouveau cette Fedora live, avec la commande suivante.
echo $PATH

[liveuser@localhost-live ~]$ echo $PATH

/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

[liveuser@localhost-live ~]$

voici raleur

encore merci pour tout, a bientot

d33p

Debian-facile

#1 25-08-2017 09:15:44

{RESOLU} / commande DD - passage HDD 240GB vers 500GB

#2 25-08-2017 09:35:15

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#3 25-08-2017 09:42:52

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#4 25-08-2017 09:50:03

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#5 25-08-2017 10:02:44

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#6 25-08-2017 10:32:09

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#7 25-08-2017 10:41:00

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#8 25-08-2017 10:45:44

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#9 20-09-2017 15:17:47

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#10 20-09-2017 15:48:02

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#11 20-09-2017 15:54:46

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#12 20-09-2017 16:22:19

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#13 20-09-2017 16:51:11

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#14 20-09-2017 17:11:59

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#15 20-09-2017 17:22:24

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#16 20-09-2017 17:37:38

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#17 20-09-2017 17:50:43

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#18 20-09-2017 18:07:44

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#19 20-09-2017 19:13:41

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#20 20-09-2017 19:34:40

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#21 20-09-2017 19:52:15

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#22 20-09-2017 20:33:28

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#23 20-09-2017 21:00:46

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#24 20-09-2017 22:03:59

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

#25 21-09-2017 05:31:38

Re : {RESOLU} / commande DD - passage HDD 240GB vers 500GB

Pied de page des forums