Troubleshooting : UUID + Initrd + publication de noyau = Timeout

Pour certains systèmes d'installation automatisée, comme SystemImager , il est possible de mettre à jour absolument tout et n'importe quoi, simplement par rsync ou en utilisant le mode de transport multicast . Et parfois, suite à cette mise à jour, et surtout quand elle touche le contenu du /boot, on peut être amené à constater, lors du reboot, l'apparition de messages concernant des timeout sur les disques supportant le système. Petites pistes pour traquer l'origine du problème -qui n'en est pas vraiment un, vu que le timeout passé, le boot se fait normalement-.

UUID

Avant toute chose, un petit précis s'impose. Un UUID, comme Universal Unique Identifier, sert à identifier de manière formelle et catégorique un device, que ce soit un disque dur, un device USB, bref, tout ce qui touche au matériel. Il est facile de les retrouver ou de les intégrer dans la fstab et dans le menu.lst de GRUB. Beaucoup de filesystems reconnaissent ces UUIDs, y compris le NTFS de Windows. Il existe également un autre moyen d'identifier ses partitions (en plus de celui de les appeler directement par leur petit nom), le Labelling, qui consiste à attribuer un LABEL à la partition. La grande différence avec l'UUID, mise à part sa compréhension plus intuitive, est que ce Label n'est unique que localement, tandis que l'UUID est censé (je dis bien censé, puisque ce sont les mêmes algorithmes de génération qui jouent, il y a forcément des intersections) être universellement unique.

Investigation !

Initrd.img

Pour savoir ce qu'il se cache dans votre initrd.img, rien ne vaut un lsinitrd ! Un peu d'exploration, et dans les dernières lignes, par exemple, on peut trouver :

# lsinitrd /boot/initrd.img

echo waiting for device sda1 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=0d4af533-85cf-4a81-a378-172ac9143140
echo waiting for device sda2 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=ce132640-34f0-43bd-b256-250ef6c369f6

Et là, vous avez cerné le problème !

Dans les faits...

Donc, d'après ce que l'on a pu tirer de notre lsinitrd, on peut facilement déduire que ce qui provoque le timeout vient justement des UUIDs qui sont appelé en dur. Voyons ce que l'on a à disposition... La méthode simple :

# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 100 2010-03-11 16:32 .
drwxr-xr-x 6 root root 120 2010-03-11 16:32 ..
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 1a3808ca-c81c-416f-9109-2ebc9c635722 -> ../../sda2
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 97a38b84-b2a2-4970-b593-8f561b827fda -> ../../sda1
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 c999ed94-737b-4a5a-8945-519e07c27610 -> ../../sda3

La méthode spécifique :

# /sbin/blkid
/dev/sda1: LABEL="ROOT" UUID="97a38b84-b2a2-4970-b593-8f561b827fda" TYPE="ext3"
/dev/sda2: LABEL="SWAP" UUID="1a3808ca-c81c-416f-9109-2ebc9c635722" TYPE="swap"
/dev/sda3: LABEL="HOMELOCAL" UUID="c999ed94-737b-4a5a-8945-519e07c27610" TYPE="ext3"

Divergence d'UUID

Le constat est simple. L'appel du initrd se base sur son UUID, et ici, les UUIDs entre l'appelé et le réel diffèrent. Pour fixer le souci, un simple mkinitrd remet à jour ces informations. Plus de timeout au boot, malheureusement, le problème reviendra avec d'autre mises à jour du initrd. Alors, aux vues de toutes les manips à faire, Reconsidérez bien l'affaire. Après tout, quelques minutes de timeout ne font pas de mal à vos utilisateurs !