XZ-compressed data is corrupt, réparer une VM Debian au noyau tronqué

Une VM Debian redémarre après une mise à jour du noyau et s’arrête sur « XZ-compressed data is corrupt ». Le disque n’est pas en cause : ce sont le noyau ou l’initrd qui ont été écrits à moitié, et on peut s’en sortir sans réinstaller.

La cause

Observé sur des VM Debian 12 en BIOS legacy sous AHV. La racine / était saturée pendant la mise à jour du noyau, et /boot n’avait pas de partition dédiée : il vivait dans le LV racine. Résultat, vmlinuz et/ou initrd tronqués.

Les deux noyaux installés ne sont pas forcément touchés de la même façon. Cas rencontré : vmlinuz récent corrompu, et initrd de l’ancien noyau tronqué, ce qui donne sur ce dernier un autre message, « No working init found ».

Cas 1 : un couple sain existe, boot manuel depuis GRUB

Si l’un des noyaux a encore un vmlinuz et un initrd intacts, on démarre à la main depuis la console GRUB :

set root=(lvm/<vg>-<lv_root>)
linux /boot/vmlinuz-<ver> root=/dev/mapper/<vg>-<lv_root> ro
initrd /boot/initrd.img-<ver>
boot

Deux pièges :

• utiliser la complétion (Tab) pour les numéros de version, plutôt que de les taper ;
• si la commande initrd renvoie une erreur, ne pas taper boot.

Une fois la VM démarrée, la réparation est la même que dans le cas 2, sans le chroot.

Cas 2 : tout est corrompu, ISO de secours et chroot

Démarrer la VM sur une ISO de secours Debian 12, activer les volumes LVM puis monter le système. Debian 12 est en usrmerge : si /usr est sur un LV séparé, le monter est obligatoire. /var aussi.

vgchange -ay
mount /dev/mapper/<vg>-<lv_root> /mnt
mount /dev/mapper/<vg>-<lv_usr> /mnt/usr
mount /dev/mapper/<vg>-<lv_var> /mnt/var

Puis les montages bind et le chroot. La boucle vient du wiki Debian GrubEFIReinstall ; la page vise l’UEFI, on retire donc efivars de la liste en BIOS legacy :

for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt/$i; done
chroot /mnt

La réparation, dans le bon ordre

Premier geste, avant toute régénération :

df -h /

Si / est encore plein, libérer de la place d’abord. Sinon la régénération de l’initramfs tronque à nouveau le fichier, et on reproduit exactement la panne.

Ensuite, régénérer l’initrd du noyau voulu, puis contrôler sa taille :

update-initramfs -c -k <ver>
ls -lh /boot/initrd.img-<ver>

Enfin, régénérer la configuration GRUB et réinstaller le chargeur sur le disque (BIOS legacy) :

update-grub && grub-install <disque_de_boot>   # /dev/sda sur les VM observées

Ce qu’il faut retenir

• « XZ-compressed data is corrupt » après une mise à jour du noyau : chercher un / saturé avec /boot dans le LV racine.
• Les deux noyaux peuvent être abîmés différemment ; « No working init found » signale un initrd tronqué.
• Couple sain disponible : boot manuel depuis la console GRUB, complétion Tab, jamais boot après une erreur initrd.
• Sinon ISO de secours, vgchange -ay, montage de root, /usr (usrmerge) et /var, binds puis chroot.
• df -h / avant update-initramfs, puis contrôle de la taille de l’initrd et update-grub && grub-install.

In English

A full / during a kernel update, with /boot inside the root LV, leaves vmlinuz or initrd truncated. If a healthy vmlinuz and initrd pair exists, boot it manually from the GRUB console; otherwise use a rescue ISO and repair in chroot, mounting /usr too if it sits on a separate LV, and free space on / before regenerating the initramfs.

Sources & vérification

Testé sur : Debian 12 en BIOS legacy sur AHV

• Debian wiki GrubEFIReinstall wiki.debian.org
• Expérience directe de l’auteur, en production (versions ci-dessus)

Comment les billets sont vérifiés et corrigés