Comment déplacer l'OS du Raspberry Pi 5 sur un SSD NVMe

Jusqu'à présent, j'ai un Pi fonctionnel dont l'OS tourne sur une clé USB. Dans votre cas, il se peut qu'il soit sur une carte SD. Le plan maintenant est de déplacer l'OS sur le SSD, ce qui n'a pas été si simple. La raison principale est bien sûr que le SSD est plus rapide, plus durable et aussi, comme je n'utilise pas de carte SD dans ma configuration, c'était vraiment mon seul disque. Cependant, Raspberry Pi Imager ne propose pas cette option, et j'ai dû copier manuellement l'OS sur le SSD. Laissez-moi vous expliquer comment faire et les écueils que j'ai rencontrés.

La migration se compose de quatre parties :

1. partitionner et formater le NVMe
2. copier l'OS en cours d'exécution de l'USB vers le NVMe
3. mettre à jour la configuration de démarrage pour que Linux monte le système de fichiers racine du NVMe
4. changer l'ordre de démarrage de l'EEPROM pour que le Pi privilégie le NVMe

Étape 1 : Quelques vérifications

Premièrement, assurez-vous que votre Pi 5 dispose du dernier firmware, qui inclut le support de démarrage NVMe le plus récent.

1. Ouvrez un terminal ssh et exécutez :

sudo apt update && sudo apt full-upgrade -y

2. Mettez à jour l'EEPROM (bootloader) de votre Pi :

sudo rpi-eeprom-update -a

3. Redémarrez votre Pi :

sudo reboot

Ensuite, nous devons vérifier ce que le système voit, exécutez ceci :

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
sudo blkid

Dans une configuration typique :

• le disque système USB apparaît comme sda
• le NVMe apparaît comme nvme0n1

Ensuite, nous devons nous assurer que nous avons correctement configuré le port PCIe sur le Pi. Exécutez cette commande :

sudo nano /boot/firmware/config.txt

Et ajoutez ces lignes après [all] si elles ne sont pas présentes.

[all]
dtparam=pciex1
dtparam=pciex1_gen=3

Étape 2 : Partitionner et formater le NVMe

Premièrement, supprimez l'ancien schéma de partitionnement du SSD et initialisez le disque avec GPT (GUID Partition Table, pas le modèle d'IA !) :

sudo parted -s /dev/nvme0n1 mklabel gpt

Ensuite, créez une partition de démarrage d'environ 512 Mio :

sudo parted -s /dev/nvme0n1 mkpart primary fat32 1MiB 513MiB

Pourquoi commencer à 1 Mio au lieu de 0 ? Cela permet de maintenir la partition correctement alignée. Un bon alignement améliore la compatibilité et les performances.

Nous devons également définir un drapeau de partition système EFI (liée au démarrage) pour que le BIOS la reconnaisse comme une partition de démarrage :

sudo parted -s /dev/nvme0n1 set 1 esp on

Ensuite, créez la partition Linux principale qui contiendra le système de fichiers racine :

sudo parted -s /dev/nvme0n1 mkpart primary ext4 513MiB 100%

Ensuite, formatez la partition 1 en FAT32 pour les fichiers de démarrage et la partition 2 en ext4 pour le système Linux principal :

sudo mkfs.vfat -F 32 /dev/nvme0n1p1
sudo mkfs.ext4 -F /dev/nvme0n1p2

Cette disposition reflète le schéma normal de Raspberry Pi OS : une partition de démarrage plus un système de fichiers racine séparé, la racine étant ensuite référencée par PARTUUID. Quant aux différents systèmes de fichiers, le firmware du Raspberry Pi ne peut généralement pas démarrer directement depuis une partition de démarrage ext4, donc FAT32 est un choix sûr. Cependant, vous ne pouvez pas utiliser FAT32 pour Linux car il lui manque les permissions Unix et d'autres fonctionnalités de système de fichiers essentielles attendues par Linux.

Étape 3 : Copier l'OS en cours d'exécution de l'USB vers le NVMe

D'abord, créez des points de montage temporaires et montez-y les partitions du SSD. Une fois montés, ces chemins exposent le contenu des partitions NVMe, ce qui facilite la copie du système dessus.

Créez les dossiers :

sudo mkdir -p /mnt/nvmeroot
sudo mkdir -p /mnt/nvmeroot/boot/firmware

Montez les partitions dessus :

sudo mount /dev/nvme0n1p2 /mnt/nvmeroot
sudo mount /dev/nvme0n1p1 /mnt/nvmeroot/boot/firmware

Ensuite, nous copions l'OS en utilisant rsync avec /mnt/nvmeroot comme cible afin de préserver les permissions, la propriété, les ACLs, les xattrs et les liens symboliques, tout en évitant les pseudo-systèmes de fichiers comme /proc et /sys.

sudo rsync -aAXHv --numeric-ids --info=progress2 \
 --exclude=/dev/* \
 --exclude=/proc/* \
 --exclude=/sys/* \
 --exclude=/tmp/* \
 --exclude=/run/* \
 --exclude=/mnt/* \
 --exclude=/media/* \
 --exclude=/lost+found \
 / /mnt/nvmeroot

Étape 4 : Lire les nouveaux PARTUUID

Maintenant, obtenez les ID de partition du SSD :

sudo blkid /dev/nvme0n1p1 /dev/nvme0n1p2

Vous avez besoin de deux valeurs :

• nvme0n1p1 → PARTUUID de la partition de démarrage
• nvme0n1p2 → PARTUUID de la partition racine

Ces valeurs exactes doivent être utilisées de manière cohérente à l'étape suivante.

Étape 5 : Mettre à jour cmdline.txt

C'est un fichier de paramètres de démarrage lu très tôt au lancement.

Ouvrez le fichier :

sudo nano /mnt/nvmeroot/boot/firmware/cmdline.txt

Trouvez la ligne existante :

root=PARTUUID=...

Remplacez-la par le PARTUUID de nvme0n1p2.

Important :

• cmdline.txt doit rester sur une seule ligne
• le root=PARTUUID doit pointer vers la partition 2 (nvme0n1p2), et non la partition de démarrage

Raspberry Pi OS utilise PARTUUID ici au lieu d'un nom de périphérique comme /dev/nvme0n1p2 ou /dev/sda2, car les noms de périphériques peuvent changer d'un démarrage à l'autre. Si cette valeur est incorrecte, le Pi pourrait trouver les fichiers de démarrage mais échouer à monter le système de fichiers racine.

Étape 6 : Mettre à jour /etc/fstab

Il indique à Linux quels systèmes de fichiers doivent être montés automatiquement après le démarrage, et où.

Ouvrez :

sudo nano /mnt/nvmeroot/etc/fstab

Nous devons le modifier pour nous assurer qu'il référence les partitions NVMe, et non les anciennes partitions USB.

Résultat typique :

proc            /proc           proc    defaults          0       0
PARTUUID=<boot-partuuid>  /boot/firmware  vfat    defaults          0       2
PARTUUID=<root-partuuid>  /               ext4    defaults,noatime  0       1

Remplacez :

• <boot-partuuid> par le PARTUUID de nvme0n1p1
• <root-partuuid> par le PARTUUID de nvme0n1p2

Vous devriez donc avoir quelque chose comme :

Un fichier /etc/fstab mal configuré peut empêcher le système de terminer son démarrage correctement, et les guides du forum Raspberry Pi avertissent explicitement qu'un mauvais PARTUUID peut faire passer la machine en mode d'urgence.

Étape 7 : Démonter et changer l'ordre de démarrage

Vous démontez le SSD pour que Linux termine et ferme correctement le système de fichiers avant d'essayer de démarrer dessus.

D'abord, forcez l'écriture des données en attente de la mémoire vers le disque avec la commande :

sync

Ensuite, on démonte :

sudo umount /mnt/nvmeroot/boot/firmware
sudo umount /mnt/nvmeroot

Enfin, nous nous assurons de démarrer depuis le SSD NVMe et nous redémarrons :

sudo raspi-config nonint do_boot_order B2
sudo reboot

La documentation du Raspberry Pi décrit B2 comme NVMe/USB Boot, ce qui signifie que le bootloader essaie d'abord le NVMe, puis l'USB, puis la carte SD.

Étape 8 : Vérifier que vous tournez bien sur le NVMe

Après le redémarrage, ne retirez pas encore la clé USB. Vérifiez d'abord ce qui a été réellement monté :

findmnt /
findmnt /boot/firmware
cat /proc/cmdline
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

Vous voulez voir :

• / monté depuis nvme0n1p2
• /boot/firmware monté depuis nvme0n1p1
• cat /proc/cmdline affichant le même PARTUUID racine que celui que vous avez mis dans le cmdline.txt du SSD

Ce n'est qu'après cette vérification que vous devriez éteindre et retirer la clé USB de démarrage.

Étape 9 : Étendre le système de fichiers racine si nécessaire

Une fois que vous savez que le Pi tourne vraiment sur le NVMe, exécutez :

df -h /

Si le système de fichiers racine affiche déjà la taille attendue du SSD, vous pouvez sauter cette étape.

Sinon, étendez la partition racine pour utiliser tout le SSD :

sudo raspi-config nonint do_expand_rootfs
sudo reboot

La documentation du Raspberry Pi décrit do_expand_rootfs comme la manière non interactive d'agrandir le système de fichiers racine après un clonage ou un redimensionnement.

Les pièges que j'ai rencontrés

Bien que tout ce que nous avons fait puisse être exécuté via SSH, si vous faites une erreur, vous pourriez avoir besoin d'une connexion directe. Je vous suggère donc de vous munir d'un câble HDMI avec un connecteur micro-HDMI mâle pour le débogage.

C'était mon cas et voici les quelques problèmes que j'ai rencontrés.

Piège 1 : Utiliser le mauvais PARTUUID

Vérifiez bien que le PARTUUID racine exact dans cmdline.txt correspond à nvme0n1p2, c'est-à-dire la partition racine.

Piège 2 : Modifier le mauvais fichier

Lorsque vous avez démarré depuis l'USB et que vous préparez le SSD, vous modifiez la future copie sur le SSD, et non le système en cours d'exécution.

Cela signifie que vous devez modifier /mnt/nvmeroot/boot/firmware/cmdline.txt et /mnt/nvmeroot/etc/fstab. Pas les fichiers /boot/firmware/cmdline.txt et /etc/fstab du système actif qui n'existent que sur la clé USB.

Piège 3 : cmdline.txt doit rester sur une seule ligne

cmdline.txt n'est pas un fichier de configuration normal avec une option par ligne. C'est une ligne de commande unique pour le noyau. Si vous insérez des sauts de ligne ou la divisez sans précaution, le démarrage peut échouer.

Piège 4 : Le Pi continuait de démarrer sur le NVMe défectueux au lieu de basculer sur l'USB

Si l'ordre de démarrage de l'EEPROM est réglé sur le NVMe en premier, et que le NVMe est "suffisamment amorçable" pour atteindre les premières étapes, le Pi peut continuer à essayer le SSD plutôt que de basculer proprement sur l'USB.

Un NVMe à moitié défectueux peut être pire qu'un NVMe totalement absent, car il peut toujours remporter la course au démarrage. Parfois, la récupération la plus rapide consiste à effacer la table de partition du SSD, ce qui n'est pas si grave puisque nous ne faisons que copier l'OS.

Si le Pi continue de préférer un NVMe défectueux et que vous ne pouvez pas facilement retirer le HAT ou le SSD physiquement, une méthode de récupération brutale mais efficace consiste à détruire la table de partition sur le NVMe pour qu'il ne soit plus amorçable. Une fois que le SSD n'apparaît plus comme amorçable, le bootloader peut passer à l'USB conformément à l'ordre de démarrage.

Un effacement typique ressemble à ceci :

dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=100

Cela écrit environ 100 Mo de zéros au début du SSD et détruit généralement la table de partition et les métadonnées de démarrage initial.

Piège 5 : La vérification après le redémarrage est plus importante que la copie elle-même

Vous pouvez faire une copie parfaite et tout de même rester démarré depuis la clé USB après le redémarrage si l'ordre de démarrage, les PARTUUID ou les fichiers de démarrage ne sont pas corrects.

Vérifiez toujours avant de retirer la clé USB :

findmnt /
findmnt /boot/firmware
cat /proc/cmdline

Dernières réflexions

Déplacer Raspberry Pi OS d'un disque de démarrage USB vers un SSD NVMe n'est pas difficile, mais cela peut être délicat.

La copie elle-même est la partie facile. La vraie difficulté est que le démarrage dépend de la concordance de plusieurs couches entre elles :

• l'ordre de démarrage de l'EEPROM
• le contenu de la partition de démarrage
• la ligne de commande du noyau
• les identifiants du système de fichiers racine dans /etc/fstab

La bonne nouvelle est qu'une fois que vous comprenez les modes d'échec possibles, il est facile de les corriger. Vérifiez les périphériques, vérifiez les PARTUUID, vérifiez après le redémarrage, et ne retirez pas la clé USB tant que vous n'avez pas prouvé que le système tourne réellement sur le NVMe.

C'est tout ! Le matériel et l'OS du Pi sont maintenant prêts pour tout ce que nous voulons. Dans le prochain chapitre, nous verrons comment installer Pi-hole comme serveur DNS local pour le blocage de publicités et plus encore.