# Problème de changement de nom de périphériques

**URL:** <https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855>\
**Category:** Support Debian\
**Created:** [Décembre 13, 2025, 11:19 UTC](https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855 "2025-12-13T11:19:09Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Décembre 13, 2025, 11:19 UTC](https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855/1 "2025-12-13T11:19:09Z")

</div>

Bonjour,  
j’ai un phénomène que je n’arrive pas à régler:

1. j’installe un système sur un disque nvme0n1 avec partition EFI et LUKS (sur lequel ensuite il y a LVM et toutes les partitions, /, /boot, /home, /var, /var/tmp, /var/log, /var/log/audit, /tmp, swap). Jusqu’ici aucun problèmes. L’installation se passe bien, j’utilise systems-boot et je met en place l’UKI.
2. Sur un deuxième disque nvme1n1, je créé une partition chiffrée sur tout le disque, et je l’intègre au Volume Group LVM avec le disque précédent. Je met à jour /etc/crypttab, je met à jour l’initramfs avec update-initramfs -k all -u.
3. Quand je redémarre, il inverse les disque nvme0n1 et nvme1n1. Ce qui bien évidement empêche le système de démarrer.

L’installation est faite avec une iso conçu avec simple-cdd en preseed. Il n’est pas possible de faire une installation preseed avec plus d’un seul disque. partman-auto ne sait pas gérer. C’est pour cela que je fais l’ajout du deuxième disque après.

le fstab est le suivant (mais il n’intervient pas ici, car le système ne démarre pas):

```auto
 /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/vg050-root / ext4 relatime,errors=remount-ro 0 1
/dev/mapper/vg050-boot /boot ext4 nodev,nosuid,noexec 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=14E6-0FE4 /boot/efi vfat umask=0077 0 1
/dev/mapper/vg050-home /home ext4 relatime,nodev,nosuid 0 2
/dev/mapper/vg050-tmp /tmp ext4 relatime,nodev,nosuid,noexec 0 2
/dev/mapper/vg050-var /var ext4 relatime,nodev,nosuid 0 2
/dev/mapper/vg050-var_log /var/log ext4 relatime,nodev,nosuid,noexec 0 2
/dev/mapper/vg050-var_log_audit /var/log/audit ext4 relatime,nodev,nosuid,noexec 0 2
/dev/mapper/vg050-var_tmp /var/tmp ext4 relatime,nodev,nosuid,noexec 0 2
/dev/mapper/vg050-swap none swap sw 0 0
# CIS-1.1.2.2 Configuration remediation of /dev/shm
tmpfs	/dev/shm	tmpfs defaults,rw,nosuid,nodev,noexec,relatime,size=2G 0 0
# Lynis remediation FILE-6374 /dev
udev /dev devtmpfs rw,nosuid,relatime,size=15919300k,nr_inodes=3979825,mode=755,inode64,noexec 0 0

```

Comme j’utilise Secure-Boot, impossible d’avoir quoique ce soit de lisible dans les fichiers vmlinux et initrd.img, ni même dans les fichier .efi.  
Du moins, rien que je n’ai pu trouver pour le moment.

Cette inversion des deux disque fait que le bootloader, utilisant les uuid, ca ne marche pas au montage.  
En gros avant j’avais disque nvme0 → uuid 0 et nvme1 → uuid 1, quand le système se lance avec systemd-boot, je me retrouve avec disque 0 → uuid 1 et disque 1 → uuid 0.  
Le crypttab devient alors incompatible.

La question que je me pose c’est que:

- lors de l’update-initramfs après l’intégration du deuxième disque, aurais-je du faire un bootctl update?

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Décembre 13, 2025, 9:34 UTC](https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855/2 "2025-12-13T21:34:57Z")

</div>

Supplément:  
Je viens de découvrir que l’utilisation de UKI change le mode détection des périphériques du kernel. Ce qui peut conduire à des inversions de nom sur des systèmes avec plus d’un disque.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Décembre 13, 2025, 10:03 UTC](https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855/3 "2025-12-13T22:03:06Z")

</div>

Et j’ai trouvé la (une?) solution:

## Comprendre `devtmpfs.mount=1`

Le paramètre du noyau `devtmpfs.mount=1` est lié à la gestion des nœuds de périphérique dans Linux, en particulier concernant la manière dont le système d’exploitation gère le répertoire `/dev`.

* * *

### Qu’est-ce que `devtmpfs` ?

- **`devtmpfs`** est un système de fichiers responsable de la gestion dynamique des nœuds de périphérique (fichiers spéciaux représentant des périphériques matériels) dans le répertoire `/dev`. Il a été introduit pour améliorer l’efficacité et la simplicité de la gestion des périphériques dans Linux.

### Le rôle de `devtmpfs.mount=1`

- **Montage du Système de Fichiers** : En définissant `devtmpfs.mount=1`, vous indiquez au noyau de monter le système de fichiers `devtmpfs` au démarrage. Cela est crucial pour les situations où vous souhaitez que le système crée et remplisse automatiquement le répertoire `/dev` avec des nœuds de périphérique correspondant aux matériels présents dans le système.

- **Création Automatique des Nœuds de Périphérique** : Avec `devtmpfs` monté, tous les périphériques reconnus par le noyau sont automatiquement représentés dans `/dev`, permettant aux applications et démons en espace utilisateur d’accéder au matériel sans intervention manuelle.

### Avantages de l’utilisation de `devtmpfs.mount=1`

- **Création Rapide des Nœuds de Périphérique** : Cela réduit le temps nécessaire à la création des nœuds de périphérique au démarrage, car ils sont créés automatiquement à mesure que les périphériques sont détectés.
- **Interface Cohérente** : Les utilisateurs et applications interagissent avec les dispositifs via l’interface `/dev` sans se soucier des mécanismes sous-jacents de gestion des nœuds de périphérique.
- **Amélioration du Processus de Démarrage** : Cela peut conduire à un processus de démarrage plus fluide, car les fichiers de périphériques nécessaires sont disponibles plus tôt dans la séquence de démarrage du système.

### Quand utiliser `devtmpfs.mount=1`

- Il est généralement recommandé d’utiliser `devtmpfs` pour les systèmes Linux modernes, car cela simplifie la gestion des périphériques.
- Si vous rencontrez des problèmes de détection de périphériques ou de présence de nœuds de périphérique au démarrage, ajouter ce paramètre peut aider à résoudre ces problèmes.

* * *

### Conclusion

`devtmpfs.mount=1` est un paramètre du noyau important qui favorise une interaction plus efficace et sans heurts entre le noyau Linux et les périphériques matériels grâce à la gestion automatique des nœuds de périphérique dans le répertoire `/dev`. Tirer parti de cette fonctionnalité peut améliorer la stabilité et la performance du système, en particulier dans des environnements matériels complexes.

j’ai ajouté devtmpfs.mount=1 dans mon /etc/kernel/cmdline pour qu’il soit systématiquement utilisé lors d’une mise à jour des initramfs.

**A UTILISER IMPERATIVEMENT AVEC L’UKI**

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Décembre 14, 2025, 6:59 UTC](https://www.debian-fr.org/t/probleme-de-changement-de-nom-de-peripheriques/91855/4 "2025-12-14T06:59:51Z")

</div>

Finalement non, il semble que ce ne soit pas suffisant…
