7. En cas de problème, ou L'agonie de la défaite

Lorsque l'on crée des disques d'amorce, les premiers essais n'amorcent souvent pas la machine. En général, la méthode utilisée consiste à construire le disque racine à partir de composants de votre système actuel pour essayer d'obtenir que le système de la disquette commence à afficher des messages sur la console. Une fois qu'il a commencé à vous parler, la bataille est presque gagnée puisque vous pouvez voir de quoi il se plaint et corriger les problèmes un à un jusqu'à ce que le système fonctionne normalement. Si le système s'arrête brutalement sans explication, il peut être difficile d'en trouver la cause. Pour que le système en arrive au point où il commence à afficher ses messages, un certain nombre de composants doivent être présents et bien configurés. La procédure à suivre pour déterminer les raisons du silence de votre système est la suivante :

• Si vous voyez un message du genre :

  Kernel panic: VFS: Unable to mount root fs on XX:YY
  

  C'est un problème courant qui ne peut avoir que quelques causes. Tout d'abord, cherchez le périphérique XX:YY dans la listes de codes des périphériques ; s'agit-il du bon périphérique racine ? Si ce n'est pas le bon, vous n'avez sans doute pas lancé rdev -R, ou alors sur la mauvaise image. Si le code du périphérique est correct, vérifiez attentivement quels gestionnaires de périphériques ont été compilés dans le noyau. Assurez-vous le support pour le lecteur de disquettes, les disques mémoires et le système de fichiers ext2 sont bien inclus ;
• Vérifiez que le disque racine contient bien les répertoires que vous croyez. Il est facile de se tromper de niveau d'arborescence et de se retrouver avec quelque chose du genre /racine/bin au lieu de /bin sur votre disquette racine ;
• Vérifiez qu'il y a un /lib/libc.so avec le même lien que celui présent dans le répertoire /lib de votre disque dur ;
• Vérifiez que tous les liens symboliques du répertoire /dev de votre système actuel existent également sur le système racine, quand ces liens sont vers des périphériques inclus sur la disquette racine. Notamment, les liens sur /dev/console sont souvent essentiels ;
• Vérifiez que vous avez inclus les fichiers /dev/tty1, /dev/null, /dev/zero, /dev/mem, /dev/ram et /dev/kmem ;
• Vérifiez la configuration de votre noyau : le support pour toutes les ressources nécessaires jusqu'à l'invite de login doit être directement inclus et non pas sous forme de modules. Le support des disques mémoires et de ext2 doivent donc être présents dans le noyau ;
• Vérifiez que le périphérique racine et le disque mémoire sont correctement configurés dans le noyau.

Une fois ces points généraux vérifiés, vous pouvez vous pencher sur ces points plus précis :

1. Vérifiez qu'init est présent en tant que /sbin/init ou /bin/init, et qu'il est exécutable ;
2. Lancez ldd init pour vérifier les bibliothèques d'init. Il n'y a normalement que libc.so, mais sait-on jamais... Vérifiez que vous avez bien inclus les bibliothèques et leurs chargeurs ;
3. Vérifiez que vous avez le bon chargeur pour vos bibliothèques : ld.so pour a.out et ld-linux.so pour ELF ;
4. Vérifiez le contenu de /etc/inittab sur la disquette d'amorce et ses éventuels appels à getty (ou tout autre programme du genre, tel que agetty, mgetty ou getty_ps). Comparez-le plusieurs fois avec l'inittab de votre disque dur. Vérifiez les pages de manuel du programme que vous utilisez pour être sûr de sa cohérence. inittab peut être le morceau le plus difficile en raison de sa syntaxe et du contenu qui dépendent de la version d'init utilisée et de la nature du système. La seule manière de s'en débarrasser, c'est de lire les pages de manuel d'init et inittab afin de comprendre exactement ce que fait le système lorsqu'il démarre. Vérifiez que /etc/inittab contient bien une entrée concernant l'initialisation du système. Elle doit contenir une commande lançant le script d'initialisation du système, qui doit lui aussi exister ;
5. Comme pour init, lancez ldd sur votre getty pour voir ses besoins, et vérifiez que les bibliothèques et chargeurs nécessaires sont présents sur le système racine ;
6. Assurez-vous d'avoir inclus un exécutable de shell (par exemple bash ou ash) capable de faire tourner tous vos scripts rc ;
7. Si vous avez un fichier /etc/ld.so.cache sur le disque de secours, refabriquez-le (le fichier, pas le disque).

Si init démarre mais vous obtenez un message du type :

        Id xxx respawning too fast: disabled for 5 minutes

il provient d'init et indique généralement que getty ou login meurt aussitôt après son lancement. Vérifiez les exécutables de getty et login, et les bibliothèques dont ils dépendent. Vérifiez que les appels depuis /etc/inittab sont corrects. Si vous obtenez d'étranges messages de getty, cela peut signifier que les arguments dans /etc/inittab sont faux. Les options des programmes getty sont variables ; on signale que les arguments sont parfois incompatibles entre deux versions d'agetty.

Si vous obtenez une invite de login et qu'après avoir entré un nom de login valide, le système vous en demande un autre aussitôt, le problème peut venir de PAM ou NSS. Lisez la section Utilisation de PAM et NSS. Le problème peut aussi venir du fait que vous utilisez les mots de passe cachés et que vous n'avez pas copié le fichier /etc/shadow sur votre disque d'amorce.

Si vous essayez de lancer un exécutable tel que df présent sur votre disque de secours, mais n'obtenez qu'un message du type : df: not found, vérifiez deux chose : (1) que le répertoire contenant le binaire est bien dans votre PATH, et (2) que vous avez les bibliothèques (et chargeurs) nécessaires au programme.