Le service système qui sabote silencieusement votre install

Pour préparer une clé USB Debian bootable, j’utilise QEMU pour faire une vraie installation Debian dans une VM dont le disque cible est la clé USB physique branchée sur mon laptop.

Procédure standard :

qemu-system-x86_64 -enable-kvm -m 2048 \
  -drive file=/dev/sda,format=raw,if=virtio \
  -cdrom debian-netinst.iso \
  -boot d

L’install se déroule, je clique « Continue » à la fin, je ferme QEMU. Je vérifie la clé. Surprise :

$ fdisk -l /dev/sda
/dev/sda1  *  2048  ...  Linux  
$ file -s /dev/sda1
/dev/sda1: data

La table de partition est OK, mais le filesystem ext4 n’a pas été écrit correctement. Une partition vide marquée Linux mais sans superblock valide. Bizarre, l’install Debian a pourtant bien tourné.

Plusieurs essais, même résultat. Quelque chose corrompait l’écriture pendant l’install.

Le coupable : udisks2, le service d’auto-mount du desktop Linux. Au moment où Debian formatait la partition pendant l’install, udisks2 du système hôte détectait l’apparition de partitions sur /dev/sda et tentait de les automonter, créant un conflit avec QEMU qui écrivait au même endroit. Résultat : superblock cassé.

Solution :

sudo systemctl stop udisks2
qemu-system-x86_64 ... # install propre

Et au passage, modifier le cache pour être plus tolérant aux interruptions :

-drive file=/dev/sda,format=raw,if=virtio,cache=writeback,aio=threads

Au lieu de cache=none qui était trop strict avec ces conditions de course.

Lessons learned

• Quand tu donnes un device USB brut à QEMU, désactiver udisks2 sur l’hôte. Sinon le desktop sabote silencieusement ton I/O.
• cache=writeback,aio=threads est plus robuste que cache=none pour des installs sur device USB. Légèrement moins safe mais beaucoup moins fragile aux conflits.
• Un filesystem qui semble formaté mais qui montre data au file -s = superblock corrompu. Souvent le signe d’une race condition pendant l’install.
• Ne pas oublier de relancer udisks2 après : sudo systemctl start udisks2.