Raspberry PI : transférer l’OS sur un disque SSD
Sur les derniers modèles de Raspberry PI ( PI 3 b+, PI 4 … ) il est désormais possible de booter directement sur un port USB. Ce qui n’est pas forcément le cas sur les anciennes versions du PI.
 |
On le sait tous, le principal défaut des Raspberry est sa carte SD. En effet, la carte SD n’a pas une vie éternelle. Une carte SD est un composant électronique qui est écrit et écrasé continuellement. Ce type de composant est soumis à un nombre de cycles d’écriture. Malheureusement, dans un Raspberry, les nombreux cycles répétés à la minute, voir à la seconde ont vite raison de la carte SD qui termine par se corrompre, mettant alors votre système en carafe. |
Voici donc une procédure pour transférer la partition / de la carte SD sur un support connecté sur un port USB et ainsi fiabiliser votre Raspberry. Dans mon cas il s’agit d’un Raspberry PI 2 B et d’un disque SSD.
Préparation
Dans un premier temps il faut mettre à jour le Raspberry. On se connecte donc en ssh avec les identifiants par défaut ( pi/raspberry ). On utilise ensuite les commandes suivantes :
# sudo apt update
# sudo apt full-upgrade
# sudo rpi-update
Ensuite lancer un reboot pour la prise en compte des mises à jour.
Transfert sur SSD
- /dev/mmcblk0p1 qui est monté sur « /boot ». Cette partition est de type FAT32 (donc accessible depuis Windows) et contient des fichiers qui vont servir à déterminer certains paramètres matériel et du noyau ainsi que lancer le démarrage du système (de Linux donc).
- /dev/mmcblk0p2 qui est monté sur « / » (root) et qui est formaté pour Linux (donc pas accessible depuis Windows) en général au format ext4. Root contient le système Linux avec toutes l’arborescence que vous connaissez (/home, /dev, /var, …). c’est donc cette partition que l’on va devoir transférer sur le SSD.
Première étape, connecter le disque SSD et vérifier qu’il n’est pas monté automatiquement avec la commande « mount ».
Il va maintenant falloir indiquer au noyau que le système ne se trouve plus sur la carte SD mais sur la partition /dev/sda1. Pour cela, éditez le fichier /boot/cmdline.txt et modifiez après le champ root pour avoir:
Voici ce que contient mon fichier:
Ce qui doit nous donner après modification :
console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
La dernière chose à faire, sera de modifier le fichier /etc/fstab qui indique au système quelles partitions sont à monter au démarrage. En effet, dans le fichier actuel, il est indiqué que la partition /dev/mmcblk0p2 doit être montée sur « / » (root). Maintenant, root devra être associé à /dev/sda1
Attention toutefois, à ce stade, d’éditer le bon fichier. Car si vous avez suivi cette procédure jusqu’ici, vous devriez toujours être avec un montage « / » qui est sur « /dev/mmcblk0p2 ». Donc si vous éditez « /etc/fstab », ce sera celui qui est dans la partition de la carte SD et pas celle qui est sur le disque SSD. Pour accéder au disque SSD, il va falloir le monter sur un répertoire. Par exemple:
sudo mount -t ext4 /dev/sda1 /media/ssd
sudo vi /media/ssd/etc/fstab
Commenter la ligne qui permet de monter l’ancienne partition et ajouter une ligne qui monte la nouvelle sur « / »:
PARTUUID=904b080b-01 /boot vfat defaults 0 2
/dev/sda1 / ext4 defaults,noatime 0 1
# PARTUUID=904b080b-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
Ensuite rebooter et vérifier que tout est bien monté en lançant la commande « mount ».
Vous devriez voir (entre autres) les lignes:
/dev/mmcblk0p1 on /boot type vfat ….
Finalisation
La dernière chose à faire va consister à étendre la partition à toute la taille du disque. Pour cela, lancez la commande:
Et vérifiez que l’espace disponible correspond bien à la taille du disque
Filesystem Size Used Avail Use% Mounted on
/dev/root 74G 1.6G 69G 3% /
devtmpfs 184M 0 184M 0% /dev
tmpfs 216M 0 216M 0% /dev/shm
tmpfs 216M 3.1M 213M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 216M 0 216M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 54M 199M 22% /boot
tmpfs 44M 0 44M 0% /run/user/1000
11 commentaires
Stéphane
· 8 janvier 2022 à 11 h 55 min
Bonjour,
Merci pour le tuto. Quand on débute dans ce monde obscure du SSH, c’est vraiment indispensable 😉
J’ai suivi la procédure et j’ai un problème :
Le système porté sur SDA est monté en read-only. Je cherche sans trouver pour le moment comment résoudre ce pb. J’ai refait le tuto, essayé d’autres manières de copier la carte SD, mais rien à faire…
Tpeltier
· 10 janvier 2022 à 12 h 50 min
A quel étape cela se produit t’il ? Une fois le disque copié et lorsque que vous démarrez dessus ?
jp3t
· 16 janvier 2022 à 10 h 31 min
Je vous remercie pour votre tuto. Je possède un raspberry pi4 sous buster avec une carte sd 32 Go et une clé zigbee CC2531. Le tout fonctionnant avec Domoticz des périphérique Tuya, Tasmota et zigbee 3 tels que Sonoff etc.. L’ensemble fonctionne très bien sur carte SD. J’ai donc transféré sur mon nouveau disque SSD 64 Go. Le disque SSD boot correctement les logiciels également mais les périphériques de type Zigbee ne réagissent plus du tout. Je ne sais pas ou je peux regarder et vérifier pourquoi j’ai ce problème. J’ai à ce jour tout essayé , j’ai remis ma carte Sd et tout remarche. J’avoue ne pas savoir pourquoi. Que dois faire à votre avis. Merci d’avance pour votre réponse.
jp3t
· 17 janvier 2022 à 8 h 59 min
Bonjour,
Merci de bien vouloir me répondre.
Tout d’abord j’ai reformatté le disque SSD avec Raspberry Pi en Fat32, puis j’ai cloner ma carte SSD avec balenaEtcher. Toutes ces opérations avec vérification se sont correctement déroulées.
J’utilise ce SSD
Transcend 64 Go SATA III 6 Go/s MSA230S mSATA SSD 230S Solid State Drive TS64GMSA230S
avec cet adaptateur LEAGY Adaptateur mSATA SSD vers USB 3.0, mini SATA.
Quand je boot sur la carte SD j’ai toutes mes fonctions en activité. Par contre dès que je boot sur mon SSd tout à l’air d’être correct avec Domoticz et Dashticz sauf mes capteurs et autres périphériques de type Zigbee 3.0 qui normalement sont activés par le dongle XTVTX CC2531 Sniffer USB Dongle Analyseur Protocole + Bluetooth 4.0 CC2540 Zigbee CC2531. Bien sur j’ai déplacé pour essai ce dongle eu USB 2. Même problème. j’utilise le protocle Zigbee2mqtt . L’ensemble de mes capteurs Tuya via Smart Life, Tasmota, Eps8266, Esp32 sont correctement activés. J’ai installé également Home assistant qui malheureusement fait idem que Domoticz. Toute ma domotique repose donc sur ma carte SD qui risque de se détériorer rapidement. Par où dois je commencer pour analyser ce problème ou bien dois je le copier avec d’autres logiciel. Merci d’avance.
Tpeltier
· 17 janvier 2022 à 9 h 14 min
J’imagine que suite au boot sur le disque SSD, le dongle est toujours bien reconnu par le système ?
Je ne connais pas trop la configuration de ce dongle mais à priori le fait de copier la partition de la carte SD vers le SDD ne devrait pas affecter le comportement de la clé puisque qu’il s’agit d’une copie complète du système, c’est donc une opération « transparente » pour l’OS.
La seule chose a laquelle je pense c’est une modification des chemins d’accès du disque puisque l’on remplace /dev/mmcblk0p1 par /dev/sda1 mais je vois pas en quoi cela peut influencer la configuration du dongle. Une autre piste, même si je n’y crois pas, serait l’alimentation des ports USB qui, une fois le SSD en place, ne serait plus assez forte pour alimenter le dongle USB …
jp3t
· 17 janvier 2022 à 9 h 46 min
Je viens de retrouver un ancien disque dur Western digital de 80 Go avec un adaptateur USB alimenté par son boitier. Je vais réaliser ce matin une copie. Je vous tiendrai au courant.
jp3t
· 17 janvier 2022 à 12 h 20 min
Je tiens encore une fois à vous remercier car votre aide m’a été très précieuse. En effet j’ai recopié l’ensemble des données sur le nouveau disque dur et comme par miracle tout refonctionnait à merveille.
Après avoir analyser ce manque de puissance de l’alimentation j’ai retiré de mon raspberry pi 4B le clavier USB et le connecteur bluetooth de ma souris. J’ai donc repris le clonage sur le disque SSD. Mon dongle a été placé en USB 2 et le Ssd en USB 3.0. Après redémarrage complet j’ai enfin ma configuration souhaitée. De plus j’ai maintenant deux sauvegardes, une sur carte SD l’autre sur disque dur 80 Go.(Au cas où). Petite remarque : Quelle différence de vitesse entre Ssd et disque dur classique.
Tpeltier
· 17 janvier 2022 à 13 h 24 min
Content pour vous que votre configuration fonctionne comme vous le souhaitiez !
Pour répondre à votre question, c’est difficile à dire. Le SSD est forcément beaucoup plus rapide qu’un disque Sata mais pas simple de mesurer le gain de performances. Plusieurs paramètres peuvent jouer, comme la vitesse du disque dur ( 5400 ou 7200 tr/mn ) mais aussi les performances du SSD par rapport à ce que peut supporter le port USB …
DEHLOUM
· 24 juillet 2022 à 17 h 19 min
Bonjour,
Merci pour cette approche non conventionnelle … J’ai un Raspberry 4 avec un boitier deskpi Pro dans lequel est installé un M2.SSD. J’ai suivi les différentes étapes que vous indiquez mais je ne vois pas la partie formatage du disque dur, faut-il le formater en ext4, FAT32 ou autre. J’ai essayé dans un premier temps de créer une partition en ext4 mais rien ne se passe lors de la commande
sudo dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=512. J’ai donc reformater ma partition sda1 en fat32 et toujours rien. J’ignore combien de temps prend la copie de la partition sur le disque où si la commande est plantée. Auriez-vous une idée de ce qui pourrait bloquer ?
Merci pour toutes suggestions.
DEHLOUM
· 24 juillet 2022 à 17 h 21 min
J’ai juste oublié de préciser que pour l’instant le M2.SSD est connecté en USB et qu’à terme, il devrait être intégré dans le boitier puisqu’un emplacement est prévu pour donc il ne sera pas connecté sur l’un des ports USB du RASP.
Cordialement.
Tpeltier
· 25 juillet 2022 à 10 h 51 min
La commande « dd » permet de cloner un disque par bloc donc pas besoin de formatage. L’utilisation de la commande dd avec la syntaxe précédente présente un petit inconvénient, elle ne donne pas d’informations. Lorsqu’elle est exécutée, l’invite du terminal reste immobile, donc on ne sait pas quoi est ce qui se passe et combien de temps il lui reste pour terminer son exécution, il faut donc attendre que la commande se termine.
Une recherche rapide sur le net donne cette solution mais je ne l’ai jamais testée => Cet inconvénient mineur peut être résolu en ajoutant la commande pv, (*) – qui agit comme un tube terminal qui mesure les données qui le traversent – à la syntaxe de la commande dd, de sorte que maintenant la syntaxe serait:
dd if=/dev/mmcblk0p2 |pv|dd of=/dev/sda1 bs=512