Habituellement cette erreur est due à une mauvaise configuration du chargeur de démarrage (Boot Loader). Votre priorité étant que votre système démarre, vous devez donc adapter la configuration du chargeur de démarrage.
Si vous avez une disquette de démarrage pour votre système, vous avez de la chance ;-) Sinon, je vous conseille d'en créer une tout de suite. Vous pouvvez le faire facilement en utilisant le Centre de Contrôle Mandrake (menu Démarrage, puis Création d'une disquette d'amorçage).
Si vous préférez la ligne de commande :
mkbootdisk $(uname -r)
fera la même chose.
Testez-la en essayant de démarrer avec.
Si vous n'avez pas de disquette de démarrage sous la main, vous devez essayer avec le système de secours Mandrakelinux
Si vous démarrez via le système de secours ('rescue') de Mandrakelinux et que vous modifiez la configuration du Boot Loader ~LiLo en éditant le fichier '/etc/lilo.conf', vous devez lancer la commande lilo ensuite. Mais il doit s'agir du 'lilo' du disque dur, parce que vous voulez mettre à jour le secteur de démarrage du disque 1.1
Comment faire ça en mode 'rescue' ?
C'est simple. Allez sous le répertoire '/mnt'
cd /mnt
où se trouve en fait la racine de votre disque. Maintenant changez le répertoire racine avec la commande
chroot .
.
Qu'est-ce que ça fait ?
Lorsque vous utilisez le système de secours ('rescue'), le répertoire racine est celui du CD et le système du disque dur est monté sous '/mnt'. Avec la commande 'chroot', vous basculez le répertoire racine sur celui du disque. Si vous lancez une commande maintenant, la version de la commande qui se trouve sur le disque sera exécutée, et non plus celle qui se trouve sur le CD. Lancez la commande
/sbin/lilo
et un nouveau secteur de démarrage avec la configuration courante sera écrite sur le secteur de démarrage principal (master boot record). Pour GRUB, vous aurez quelque chose comme grub-install /dev/hda à exécuter, le nom du device pouvant être différent suivant votre configuration matérielle.
Pour revenir au répertoire racine du CD, tapez la commande
exit
.
NdT: Je résume la suite des commandes pour mettre à jour le secteur de démarrage en utilisant le système de secours qui se trouve sur le premier CD de votre distribution Mandrakelinux :
* d'abord monter les partitions
* puis choisir le mode console
* et enfin, utilisez les commandes suivantes :
1. cd /mnt
2. chroot .
3. vi /etc/lilo.conf
modifiez le fichier de configuration de lilo comme bon vous semble
1. /sbin/lilo
2. exit
Table des partitions détruite ou corrompue:
Si vous ne pouvez pas corriger vos problèmes de démarrage, et que les commandes 'cfdisk' et 'fdisk' vous disent qu'il n'y a pas de table de partitions à lire sur votre disque dur, il est possible que cette table ait été corrompue.
Si cette maudite table n'est pas sur le disque dur qui contient votre installation Linux, installez l'utilitaire de recupération de la table des partitions gpart et lancez-le sur le disque qui contient l'enregistrement de démarrage défectueux :
gpart /dev/device
où device est le nom global du disque (e.g. hda ou sda). Il s'agit simplement de savoir si 'gpart' peut trouver des partitions (habituellement il trouve). Ce test peut prendre du temps et prendre beaucoup de ressources système. Si ce que 'gpart' a trouvé vous semble possible, demandez lui de l'écrire sur le secteur de démarrage (boot record) :
gpart -W /dev/device
N'éteignez pas votre ordinateur et n'arrêtez pas le programme tant qu'il n'a pas fini d'écrire la table. 'gpart' peut certaines fois paraître bloqué, mais il ne n'est pas. Attendez, simplement. Lorsqu'il a fini, redémarrez la machine.
Si la table des partitions du disque ne peut pas être lue, démarrez à partir du CD 1 de Mandrakelinux en mode 'rescue'. Il contient un utilitaire non documenté qui s'appelle 'rescuept' qui … et bien, je suppose que vous l'aurez compris par son nom ;-). La première étape est comme 'gpart' :
rescuept /dev/device
Ce que 'rescuept' trouve sera affiché sur la console. Si cela vous paraît raisonnable, redirigez son affichage vers un autre utilitaire, 'sfdisk', qui écrira les données sur le secteur de démarrage du disque dur :
rescuept /dev/device | sfdisk /dev/device
Assurez-vous d'utiliser le même nom de _device_ des deux côtés du _pipe_ (le caractère |). Lorsque c'est fini, redémarrez.
Super Bloc endommagé:
Il s'agit d'un problème vraiment rare. Parmi tous les scénarios listés dans cet article, c'est probablement le seul qui ne me soit pas arrivé en 6 ans d'utilisation de Linux ;-)
Le super bloc est le premier bloc de chaque partition ext2. Il contient des données importantes concernant le système de fichiers comme la taille, l'espace libre, … (c'est similaire à la table d'allocation des fichiers dans les partitions FAT). Une partition avec un super bloc endommagé ne peut pas être montée. Heureusement extfs2 conserve des copies de sauvegarde du super bloc.
* Démarrez avec votre système de secours préféré.
* Les copies sont en général au début de chaque bloc de 8 KO (8192 octets). Donc la copie suivante se trouve à l'octet numéro 8193.
* Pour reconstituer le super bloc à partir de sa copie, utilisez la commande :
e2fsck -b 8193 /dev/device
Si ce bloc est aussi endommagé, essayez avec le suivant au numéro 16385.
* Redémarrez.
Le noyau ne se charge pas correctement
Si cela arrive après la mise à jour du noyau, le problème est dû soit à une mauvaise configuration du chargeur de démarrage (Lilo, Grub), soit à de mauvais liens symboliques dans le répertoire '/boot'. Démarrez à partir d'un autre noyau ou à partir d'un système de secours.
Blocage au démarrage dans la phase Rebuilding RPM database ou Finding Module Dependencies
Si le système se bloque pendant le 'Rebuilding RPM database' ou le 'Finding module dependencies', utilez simplement le code touche simultanément. Cela va sauter cette étape et continue la phase de démarrage.
Une des solutions est d'utiliser dans le shell la commande rpm ––rebuilddb en tant que 'root' si le blocage était à 'Rebuilding RPM database'.
Si votre système se bloque à 'Finding module dependencies', vous venez problabement de faire une mise à jour du kernel à partir des sources, mais pas de manière correcte. Vérifiez si les fichiers dans les répertoires '/boot' et '/lib/modules' correspondent à la version du kernel utilisé (i.e. contiennent le numéro du noyau).
Blocage au démarrage dans la phase RAMDISK: Compressed image found at block 0
Le système essaie de charger un RAM-Disque pour un noyau (kernel) différent. Vos fichiers de configuration du chargeur de démarrage pointent sur un mauvais RAM-disque ou un RAM-Disque n'existant pas (option
initrd=
). Démarrez avec les autres entrées de votre chargeur de démarrage puis créez un RAM-disque pour votre nouveau noyau (kernel) avec 'mkinitrd' ou utilisez le module de "configuration du démarrage (gestionnaire de démarrage)" du centre de contrôle de Mandrakelinux , qui générera automatiquement les images 'initrd' et les entrées correspondante dans le fichier de configuration de votre chargeur de démarrage.
Si vous n'avez pas d'autres entrées qui fonctionnent pour démarrer, utilisez un disque externe de démarrage.
Blocage au démarrage dans la phase Kernel panic: VFS: Unable to mount root fs on xx:yy
Le noyau (kernel) essaie de monter la partition 'root'('/') mais ne trouve pas les pilotes nécessaires ou/et la partition 'root'.
Si les pilotes nécessaires pour accéder au système de fichiers du root sont construits en tant que modules du noyau (kernel), ces modules doivent étre chargés via un 'RAM-Disque init' ('initrd'), référencés dans les fichiers de configuration du chargeur de démarrage. Notez que l'accès aux systèmes de fichiers non-ext2 tel que son sucesseur ext3 ainsi que Reiserfs, XFS ou JFS demande aussi ces manipulations.
Si le noyau (kernel) ne peut pas trouver la partition 'root', vérifiez la configuration du chargeur de démarrage (boot loader), spécialement les options 'root'.
Vérification de défaillance du système de fichiers
Si le système rencontre un support qui n'avait pas été démonté proprement, il utilisera son journal pour récupérer une partie des données qui n'ont pas été correctement enregistrées, dans le cas de l'utilisation de système de fichiers journalisé (Par défaut depuis Mandrakelinux 8) tel que ext3. De plus il vous proposera après, de lancer une routine de vérification du système de fichiers (fsck). Dans le cas de systèmes non journalisés il lancera juste la routine de vérification (fsck).
Si 'fsck' est lancé, il vérifirera le système de fichiers pour récupérer et éffacer, ou déplacer, les morceaux de données vides ou inconsistant du système. Vous trouverez ensuite ces données dans le répertoire _'lost+found'_ de la partition où ils ont été trouvés.
'fsck' réparera la plupart des erreurs de lui-même. Si il lui arrive d'effacer des données, 'fsck' s'arrêtera et vous serez envoyé à un shell 'root'. Appelez encore 'fsck' par la ligne de commande, le système de fichiers où l'utilisation automatique de 'fsck' à échoué.
e2fsck /dev/device
Cela va démarrer 'fsck' dans un mode intéractif où vous serez solicité à chaque action que 'fsck' veut faire. Si vous n'êtes pas un spécialiste des systèmes de fichiers, il sera préférable de laisser 'fsck' faire ce qui lui semble le meilleur.
e2fsck _option_ /dev/device
L'option '-p' commande à 'e2fsck' de faire toutes les réparations nécessaires sans rien demander, '-y' permet de répondre 'yes' à toutes les questions.
Lorsque la vérification et la réparation est finie, utilisez le code touche + pour quitter la console d'urgence. Le système redémarrera.
La première chose que vous devriez faire lorsque le système aura rebouté, est de sauvegarder immédiatement toutes les données importantes dans un support (CDrom, DVD, etc...) externe. Jetez un coup d'oeil au répertoire 'lost+found' du système. Celui-ci peut contenir des fichiers '#'. Ces fichiers ont été déplacés de leurs répertoires pour accroitre l'intégrité du système de fichiers. Cela signifie que ces fichiers peuvent être d'importants fichiers de configuration système.
Échec de Login
Notez que ce scénario se base sur le mode console traditionnel. Pour des problèmes en relation avec X, regardez le scénario suivant .
Avant de paniquer, assurez-vous que vous n'avez pas été victime d'une faute de frappe : vérifiez si la touche 'MAJUSCULE' est active, essayez avec une combinaison différente de majuscules/minuscules, utilisez un autre compte ou un autre terminal (_vous pouvez passer à un autre terminal en appuyant simultanément sur les touches _), etc.
Un échec de connexion peut être dû à une mauvaise entrée (ou une entrée corrompue) dans les fichiers _'/etc/passwd', '/etc/shadow'_ ou _'/etc/securetty'_, de mauvaises permissions ou un mot de passe _'root'_ oublié.
* Afin de rentrer dans le système, redémarrez-le et tapez :
linux init 1
lorsque le prompt LiLo (en anglais) s'affiche. Si vous êtes en mode graphique, appuyez sur la touche Echap pour obtenir le prompt. Si vous utilisez GNU GRUB (en Anglais) appuyez deux fois sur la touche 'e' et ajoutez init 1 à la commande de démarrage puis appuyez sur la touche ENTREE et enfin sur 'b' pour démarrer.
Cela démarrera le système dans le mode 'single user'.
* Par défaut, Linux conserve des copies de sauvegarde des fichiers _'/etc/shadow'_ et _'/etc/passwd'_, appelées _'/etc/passwd-'_ et _'/etc/shadow-'_. La première chose à faire est d'utiliser ces copies.
* Conservez les fichiers 'shadow' et 'passwd' actuels ainsi :
* Puis écrasez les fichiers avec les copies de sauvegarde ainsi :
cp /etc/passwd- /etc/passwd
cp /etc/shadow- /etc/shadow
* Essayez de passer au runlevel 3 pour voir si vous pouvez vous connecter au système maintenant :
init 3
* Si cette démarche échoue, redémarrez à nouveau au runlevel 1 (appuyez simultanément sur les touches ).
* Lorsque le système est à nouveau opérationnel, tapez :
vi /etc/passwd
Regardez ce fichier. Il ne doit pas contenir de lignes blanches, de commentaires ou de caractères non ASCII. Si vous en voyez, supprimez-les. L'entrée pour 'root' doit être exactement ceci :
root:x:0:0:root:/root:/bin/bash
Si ce n'est pas le cas, changez-la et sauvegardez le fichier.
Lancez la commande chmod 644 /etc/passwd pour rétablir des droits d'accès corrects.
* Puis, faites vi /etc/shadow.
Le format des entrées dans '/etc/shadow' est nomDuCompte:password:autresChoses
Par exemple :
Le mot de passe est chiffré, bien sûr.
Supprimez le mot de passe pour 'root'. Pour cela, déplacez le curseur sur le premier caractère du mot de passe (habituellement le premier caractère '$') et tapez x autant de fois que nécessaire pour atteindre le séparateur (':') de champ suivant.
Avec l'exemple précédent, cela donne :
root::12437:0:99999:7:::
Maintenant tapez :wq pour sauvegarder le fichier.
* Regardez aussi le fichier '/etc/securetty' (commande cat /etc/securetty), qui devrait contenir ces entrées (NdT : avec Mandrakelinux 9.1 => 10.1. Cela peut être différent avec d'autres versions) :
* Consultez le fichier '/var/log/messages' (commande tail -30 /var/log/messages). Cela pourrait révéler la nature de vos problèmes. Vous devez aussi vérifier les droits et permissions (par la commande ls -al) des fichiers '/root/.bash_profile', '/root/.bashrc' et '/etc/gettydefs' si ils existent.
Tous ces fichiers doivent appartenir à 'root' et doivent être en lecture/écriture (rw) pour lui uniquement.
* Redémarrez avec la commande init 6
* Au prochain login, tapez root pour le nom du compte puis appuyez simplement sur la touche ENTREE lorsque le mot de passe est demandé.
* Une fois connecté, lancez la commande passwd pour donner un nouveau mot de passe au compte 'root'.
Si vous ne pouvez toujours pas vous connecter à votre système, c'est qu'il y a quelque chose de vraiment mystérieux. Cela pourrait être l'un des rares cas où la réinstallation du système pourrait résoudre votre problème.
Le système se bloque lors du chargement de X
Si vous avez configuré votre machine pour démarrer directement en mode graphique, des problèmes de configuration de votre serveur X peuvent vous empêcher de vous connecter.
Appuyez simultanément sur pour vous connecter à partir d'une autre console, tuez le processus? qui essaie de lancer le serveur X et suivez les recommandations de l'article X Setup Troubles.
Sinon, vous pouvez aussi redémarrer sans le serveur X.
Au prompt de ~LiLo, tapez linux init 3 pour démarrer sans le serveur X.
Le système se bloque
Les interruptions silencieuses, appelées 'hang' ou 'freeze', sont habituellement provoquées par des problèmes entre le système d'exploitation et le matériel (mauvaises barrettes mémoire, bogues dans les pilotes, conflits d'IRQ, etc.). Ces interruptions ne laissent en général aucune trace dans le fichier de log '/var/log' et cela nécessite une mise à jour logicielle ou matérielle.
Votre tâche principale dans une telle situation est d'empêcher d'autres problèmes, par exemple une corruption du système de fichiers en éteignant brusquement l'ordinateur. La touche magique ~SysRq? est alors bien commode ici.
Par le réseau
Si votre machine fait tourner un serveur SSH ou Telnet, vous devriez essayer de vous y connecter via une autre machine. Il se peut qu'il n'y ait que l'interface graphique qui soit gelée, et que le reste du système et les services réseau fonctionnent toujours.
Récupérer des fichiers perdus
NdT : Cet outil n'agit que sur des partitions ext2. De plus, il n'est manifestement plus livré avec Mandrakelinux.
Faites-vous plaisir et installez l'utilitaire de récupération de fichiers Recover. Il s'agit d'un front-end à l'outil 'debugfs'. La seule chose à faire est de lancer la commande 'recover' avec pour paramètre le nom de la partition où se trouvait le fichier qui a été perdu (commande à lancer sous 'root') :
recover /dev/device
'recover' vous posera des questions afin de minimiser le nombre de fichiers selectionnés. Notez que 'recover' ne récupère que le contenu du fichier, pas son nom. Il est donc dans votre intérêt de lui donner le plus d'info possible.
Le système ne démarre pas
Le système ne démarre pas:
