Des dangers de /dev/sdx

diesel · Le 29/01/2026, à 08:51

Avec l'arrivée de udev, et sauf paramétrage spécifique, la correspondance entre support de stockage physique et points d'accès /dev/sdx n'est plus garantie par défaut.

Et ça peut conduire à des catastrophes.

Hier, j'ai ajouté à mon système un disque dur externe que je voulais repartitionner. habituellement, lorsque j'ajoute des supports externes sur ma machine, je les retrouve en /dev/sdd (j'ai déjà 4 supports de données dans ma machine dont un nvme). Comme ça ne se passait pas très bien pour un certain nombre de raisons, j'ai décidé d'écrire une suite de zéros au début du disque externe. D'où un "sudo dd if=/dev/zero of=/dev/sdd count=100".

Sauf que..., contrairement à ce qui se passe d'habitude, udev avait attribué /dev/sdd à mon disque dur de sauvegarde, monté automatiquement en /mnt/Sauvegarde (c'est original ). D'où plus de table de partition sur ce disque. Très vite, je constate l'erreur et je me dis que je reconstruirai la structure de disque et referai une nouvelle sauvegarde plus tard. Erreur !

Peu de temps après, je reboote ma machine, et là ; CATASTROPHE !. Le PC ne veut plus démarrer. Il me propose juste de me connecter en root en mode secours. Sauf que..., sur cette machine, le login root est désactivé.

Il m'a fallu un bon moment pour comprendre ce qu'il se passait. Je suis un peu passé par tous les états ; Est-ce une panne matérielle (vu les messages affichés au boot) ?, Est-ce que j'ai planté complètement mon système, mais alors, où ?

J'ai créé une clé USB de boot (heureusement que j'ai un portable antédiluvien qui m'a permis de télécharger l'image et créer la clé) et j'ai rebooté la machine. Constat : Elle tourne correctement et les supports de données sont visibles. Ce n'est a priori pas une panne matérielle. J'ai pu monter la partition root sur un répertoire toto (sur le système de la clé) et j'ai rendu root logable (enlevé le point d'exclamation qui "tient lieu" de mot de passe chiffré dans etc/shadow). Et j'ai rebooté sur la configuration habituelle du PC.

J'ai enfin pu me logger en root tel que c'était suggéré et là : Que faire ?

Puis je me suis souvenu de ce dd malheureux.

Je suis allé dans /etc/fstab et j'ai commenté la ligne de montage de mon disque de sauvegarde, puis j'ai rebooté. Et là, "miracle" !, la machine est repartie comme si de rien n'était. Il n'y avait plus qu'à reconstruire le disque de sauvegarde, refaire le montage automatique avec le nouvel uuid et rendre à nouveau boot non loggable.

Voilà. Si cela peut rendre service à quelqu'un...

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 29/01/2026, à 08:53)

iznobe · Le 29/01/2026, à 09:02

Avec l'arrivée de udev, et sauf paramétrage spécifique, la correspondance entre support de stockage physique et points d'accès /dev/sdx n'est plus garantie par défaut.

ca fait un bail que c' est comme ça . cela dit , j ' aimerais bien voir ce que tu entends par : " paramétrage spécifique " .

Si je dois passer par la CLI , avant de faire un truc du genre de :

sudo dd if=/dev/zero of=/dev/sdd count=100

je m' assure via

lsblk -fe7 # /dev/sdd

, que je vais travailler sur le bon disque ...

diesel · Le 29/01/2026, à 13:31

Avec udev, on peut fixer la relation entre chaque périphérique et le /dev/sdx qu'on veut.

Oui, je n'ai pas assez vérifié avant de lancer le dd. En général, je fais un ls -l /dev/disk/by-id (mais pas ce coup-ci ).

Amicalement.

Jean-Marie

alh54 · Le 29/01/2026, à 14:11

+1 pour la vérification comme l'a dit iznobe. Pour éviter les boot ratés, dans /etc/fstab il vaut mieux utiliser UUID = xxxx ou /dev/disk/by-uuid/xxxx, c'est sans équivoque.

geole · Le 29/01/2026, à 15:37

Bonjour.
Si tu es certain que ton script de sauvegarde vérifie bien la présence du disque avant de s’exécuter, tu n’es pas obligé de planter le boot s’il est absent ( nofail ).

Depuis pas mal de temps, si les supports externes sont branchés avant le boot et que le bios est réglé pour booter d’abord sur support externe, ce sont eux qui deviennent prioritaire donc sda sdb sdc.... les disques internes deviennent sdd sde .....

Dernière modification par geole (Le 29/01/2026, à 15:42)

ylag · Le 29/01/2026, à 18:36

Bonjour,

alh54 a écrit :

+1 pour la vérification comme l'a dit iznobe. Pour éviter les boot ratés, dans /etc/fstab il vaut mieux utiliser UUID = xxxx ou /dev/disk/by-uuid/xxxx, c'est sans équivoque.

+1 !

Sinon, on pourrait aussi utiliser une étiquette de partition, Label= ; voir cette section de la doc :

8. Les Étiquettes, c'est mieux non ?

A+

diesel · Le 30/01/2026, à 16:00

La solution trouvée est la suivante :

créer un fichier avec les identifiants des disques fixes de la machine (ata-CT1000BX500SSD1_2240E673BD2A par exemple)

Surcharger les commandes susceptibles de toucher à ces disques (dd en particulier mais pas que) afin de vérifier que le /dev/sdx passé en paramètre od= ne correspond pas à l'un des disques de la liste.

Je rappelle que les commandes "dangereuses" sont passées pour travailler sur des supports "temporaires" (y compris un ssd branché sur un port sata libre) et qui ne sont connus "facilement" que par un /dev/sdx

Amicalement.

Jean-Marie

Watael · Le 30/01/2026, à 18:20

que veux-tu dire par "surcharger" ?

krodelabestiole · Le 30/01/2026, à 18:50

ça fait un moment que fstab utilise les UUID (pour le système) et qu'il est recommandé à l'utilisateur d'utiliser des labels je crois... ça ne résoudrait pas le problème ?

krodelabestiole · Le 30/01/2026, à 18:51

dommage que la doc "label" n'explique pas l'utilisation des labels https://doc.ubuntu-fr.org/uuid_et_label

geole · Le 30/01/2026, à 19:00

https://doc.ubuntu-fr.org/uuid_et_label a écrit :

il est pleinement fonctionnel de remplacer dans /etc/fstab
UUID=12345678-abcd-1234-abcd-1234567890ab
par
LABEL=DONN-SAM500
Ainsi pourrez-vous brancher votre disque sur un autre pc sans risquer de confondre deux différentes "DATA"

Mais ll me semble que la bonne codification est maintenant /dev/disk/by-label/UB-26-04-DECEMBR

Dernière modification par geole (Le 30/01/2026, à 19:02)

xubu1957 · Le 30/01/2026, à 19:03

Bonjour,

Pour info > ixany.org/fr/articles/les-identificateurs-de-partition-sous-linux

krodelabestiole · Le 30/01/2026, à 20:15

oui enfin en oubliant le fait que codification est un terme juridique et pas informatique ça n'explique pas d'où sort ce LABEL ni l'usage qu'on est censé en faire (en gros expliquer simplement qu'on peut - et qu'on devrait - nommer soi-même ses partitions comme ça nous chante pour nous y retrouver, avec un outil approprié au choix, et éventuellement que c'est la solution moderne et élégante à privilégier).

pas de lien vers le chapitre de la doc partition qui serait censé expliquer ça par ex. !

je ne pense pas qu'il soit recommandé d'utiliser /dev/by-label dans fstab non, vu que LABEL= est plus simple (ça c'est si on veut accéder à sa partition en système de fichiers, pour dd par ex.).

diesel · Le 30/01/2026, à 20:53

Vous suivez un peu ?

Qui a parlé de partitions (ou de fstab) ? Certainement pas moi.

Mon souci est l'accès à un périphérique a priori amovible (donc inconnu du système, et de moi dans la minute précédente) sans me casser la tête à aller voir dans /dev/disk/by-xxxx en étant certain de ne pas mettre le brin dans un disque permanent de la machine.

@ watael : surcharger = créer un script (par exemple dddisk) qui vérifie que le paramètre of= ne référence pas un disque permanent de la machine et en cas de réponse favorable appelle le vrai dd avec les arguments.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 01/02/2026, à 17:16)

krodelabestiole · Le 30/01/2026, à 21:25

double cliquer sur l'appareil dans nautilus ?
non parce que sinon, si tu veux paramétrer la manière d'accéder à un disque externe il va falloir parler de fstab à un moment !

sinon il n'y a pas grand chose à faire, à moins d'utiliser les label justement.

diesel · Le 30/01/2026, à 22:50

Bon, ça serait bien de lire un peu ce que j'écris (et peut-être de comprendre aussi).

Jamais je n'ai parlé d'une utilisation de tous les jours d'un disque externe (ou d'une clé USB ou d'une SDcard) pour y écrire (ou lire) des fichiers. Ça, ça ne pose jamais de problème.

J'ai parlé de tâches d'administration (écriture ou effacement d'une table de partition par exemple). Et c'est là que les soucis peuvent commencer.

Jean-Marie

krodelabestiole · Le 30/01/2026, à 23:01

tu parles d'une expérience personnelle sans détailler ton sujet, donc ça dépend ce que chacun fait de ses disques durs, on est juste dans la nomenclature générale.

sinon c'est sacrement niche de formater des supports externe à répétition !
et perso je ne ferais pas ça sans commencer par un lsblk...

diesel · Le 30/01/2026, à 23:11

oui, c'est de ma faute.

Alleï, amusez-vous bien.

Jean-Marie

krodelabestiole · Le 30/01/2026, à 23:43

je ne cherche pas à savoir qu'est ce qui est la faute de quoi, plutôt à rebondir sur le sujet (désolé si tu trouves que je suis hors sujet) :
tu crois qu'il y a besoin de mettre la doc à jour ? https://doc.ubuntu-fr.org/partitions#de … ans_ubuntu

je compte de toute façon déjà ajouter un chapitre pour l'utilisation des labels.

diesel · Le 31/01/2026, à 10:16

Mon intervention concerne un cas très spécifique (mais qui peut avoir des conséquences désastreuses) de l'utilisation des /dev/sdx. Rien à voir avec la doc que tu cites.

Jean-Marie

Dernière modification par diesel (Le 31/01/2026, à 10:40)

krodelabestiole · Le 31/01/2026, à 10:33

rien à voir avec les règles de dénomination type /dev/sdx ? ok si tu le dis...

diesel a écrit :

Je suis allé dans /etc/fstab et j'ai commenté la ligne de montage de mon disque de sauvegarde, puis j'ai rebooté. Et là, "miracle" !, la machine est repartie comme si de rien n'était.

et ton message public n'a rien à voir avec fstab non plus.

d'ailleurs :

diesel a écrit :

Vous suivez un peu ?
Qui a parlé de fstab (et de partitions) ? Certainement pas moi.

discussion close donc.

diesel · Le 31/01/2026, à 10:46

OK, j'ai cité le mot fstab.

Sauf que ce n'était pas le sujet. Si j'en ai parlé c'est juste pour évoquer le fait que supprimer le montage automatique du disque que je venais de planté m'avait permis de redémarrer la machine (j'aurais aussi bien pu l'exprimer comme ça sans citer fstab). Et de toutes manières, à ce moment là, le mal était déjà fait depuis longtemps. Et c'est ça le vrai sujet de mon intervention.

Et même si je ne l'ai pas précisé (une fois de plus parce que ce n'était pas le sujet), ça fait très longtemps que sur mes machines les lignes fstab commencent par UUID=... Rien à voir, donc, avec un /dev/sdx ou un quelconque label.

Jean-Marie

Dernière modification par diesel (Le 31/01/2026, à 10:47)

geole · Le 31/01/2026, à 15:58

diesel a écrit :

j'ai décidé d'écrire une suite de zéros au début du disque externe. D'où un "sudo dd if=/dev/zero of=/dev/sdd count=100".

Bonjour
Au cas où d'autres personnes liraient cette discussion, pour celles qui seraient alors inquiètes: Il est totalement possible de faire cela en mode graphique en utilisant l'application gnome-disks qui est préinstallée.
Visualisation des disques qui sont définis
Sélection du disque cible avec vision de son contenu
Décision de le formater
Avec les bonnes options

Dernière modification par geole (Le 31/01/2026, à 16:00)

iznobe · Le 31/01/2026, à 16:02

c' est avant tout une commande très dangereuse , qu ' il faut ne pas passer si on est pas absolument certain de savoir pourquoi !!
C ' est en général très peu utile en plus .
Bref , il faut éviter dans 99.99% des cas , surtout quand un mode graphique est disponible pour cette action , et , qui permet d' éviter toute confusion et accident malencontreux

j ' aurais plutôt mis ça dans une section du forum " trucs a ne pas faire "

Dernière modification par iznobe (Le 31/01/2026, à 16:05)

diesel · Le 31/01/2026, à 17:15

Vous faites bien ce que vous voulez.

Jean-Marie

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/01/2026, à 08:51

Des dangers de /dev/sdx

#2 Le 29/01/2026, à 09:02

Re : Des dangers de /dev/sdx

#3 Le 29/01/2026, à 13:31

Re : Des dangers de /dev/sdx

#4 Le 29/01/2026, à 14:11

Re : Des dangers de /dev/sdx

#5 Le 29/01/2026, à 15:37

Re : Des dangers de /dev/sdx

#6 Le 29/01/2026, à 18:36

Re : Des dangers de /dev/sdx

#7 Le 30/01/2026, à 16:00

Re : Des dangers de /dev/sdx

#8 Le 30/01/2026, à 18:20

Re : Des dangers de /dev/sdx

#9 Le 30/01/2026, à 18:50

Re : Des dangers de /dev/sdx

#10 Le 30/01/2026, à 18:51

Re : Des dangers de /dev/sdx

#11 Le 30/01/2026, à 19:00

Re : Des dangers de /dev/sdx

#12 Le 30/01/2026, à 19:03

Re : Des dangers de /dev/sdx

#13 Le 30/01/2026, à 20:15

Re : Des dangers de /dev/sdx

#14 Le 30/01/2026, à 20:53

Re : Des dangers de /dev/sdx

#15 Le 30/01/2026, à 21:25

Re : Des dangers de /dev/sdx

#16 Le 30/01/2026, à 22:50

Re : Des dangers de /dev/sdx

#17 Le 30/01/2026, à 23:01

Re : Des dangers de /dev/sdx

#18 Le 30/01/2026, à 23:11

Re : Des dangers de /dev/sdx

#19 Le 30/01/2026, à 23:43

Re : Des dangers de /dev/sdx

#20 Le 31/01/2026, à 10:16

Re : Des dangers de /dev/sdx

#21 Le 31/01/2026, à 10:33

Re : Des dangers de /dev/sdx

#22 Le 31/01/2026, à 10:46

Re : Des dangers de /dev/sdx

#23 Le 31/01/2026, à 15:58

Re : Des dangers de /dev/sdx

#24 Le 31/01/2026, à 16:02

Re : Des dangers de /dev/sdx

#25 Le 31/01/2026, à 17:15

Re : Des dangers de /dev/sdx

Pied de page des forums