Correction de l’inconsistance d’usr sur FreeBSD

Samedi, j’ai continué mon aventure FreeBSD sur mon ordinateur de gaming et mon objectif était de résoudre le problème dont j’ai parlé dans l’article précédent, avec le slice consacré à /usr. J’écris cet article qu’aujourd’hui parce qu’hier, c’était Pâques x)

Voici un petit rappel du problème que j’ai rencontré une fois l’installation de FreeBSD terminé, et le boot réussi.

THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
        ufs: /dev/nvd0p3 (/usr)

C’est le message que j’avais et qui m’interdisait l’accès à ma session puisque tout ce qui permet cette dernière dépend de /usr 🙂 J’ai donc cherché comment corriger ce problème. Mais, je n’ai pas réussi par la méthode à utiliser dans ce type de cas. Je vous direz à la fin comment j’ai réglé le problème, mais d’abord voici ce que j’ai appris en m’y confrontant.

Tout d’abord, ce genre de problème se produit lorsque le système d’exploitation n’a pas été éteint convenablement. Je ne me souviens plus comment je m’y suis prise pour éteindre mon ordinateur ou le redémarrer une fois l’installation terminée. Je ne suis pas sûr que le problème ait réellement été provoqué par ce type d’évènement, mais quoi qu’il en soit, c’est ce qui arrive en cas d’arrêt brutal de l’ordinateur. Lorsque ça se produit, il y a un risque pour que les mesures à mettre en place entraine la perte des données. Il est bon de faire une sauvegarde des données avant tout opération de maintenance pour corriger le problème. Par contre, pour l’instant n’ayant pas pu aller plus loin dans les mesures à prendre, je n’ai pas encore appris à faire cette sauvegarde. Je n’en parlerais donc pas ici.

La première chose qui peut aider dans ce cas, et dans d’autres, c’est de pouvoir lister et regarder les systèmes de fichiers présents dans mon très cher FreeBSD. Ainsi je pouvais voir entre autres /usr au cas où j’aurais fait une boulette lors du partitionnement et du montage du slice pendant l’installation. Pour avoir la liste des systèmes de fichiers, il faut aller dans /etc/fstab.

cat /etc/fstab

Apparemment, de ce côté là, ça avait l’air d’aller. Ensuite, il faut appeler un commande qui a pour fonction de vérifier la consistance des systèmes de fichiers et de réparer si nécessaire. La fonction en question est normalement appelé lors du boot du système d’exploitation. C’est de cette manière que le système a pu m’avertir de l’erreur. Mais, on peut l’appeler soi-même pour dépanner.

fsck -t ufs /dev/nvd0p3

Malheureusement, il était impossible pour le système de faire quoi que ce soit, en raison d’un problème de superblock. Le seul moyen de corriger le problème, d’après le système, était de proposer un superblock alternatif à celui qu’il voulait utiliser pour le système de fichier de /usr. Ce serait bien si j’expliquais ça, mais je ne suis pour l’instant moi-même pas encore assez calée pour en parler x) Il s’agit en fait de bloques de mémoire. Il y a des plages libres et d’autres occupées et pour bien faire, les plages ont une certaine taille. Le système utilise ces tailles comme unités de mesure en quelque sorte pour stocker proprement et retrouver les différents systèmes de fichiers. Voilà pour très grossièrement imager et avoir un minimum une idée de ce que c’est pour avancer sur ce problème 🙂

Pour tenter de donner au système un superblock, il fallait que je sache lesquelles sont disponibles. Pour savoir ça, j’ai entrée la commande suivante :

newfs -N /dev/nvd0p3

Il est très important de ne pas oublier l’option -N sinon la fonction peut créer un nouveau système de fichier sur l’actuel et donc détruire ce qui s’y trouve. Cette option permet uniquement d’afficher les superblocks disponibles et ensuite il est possible de les tester pour réparer le système corrompu. Pour faire cette opération j’ai essayé la commande suivante :

fsck_ffs -b <le numéro du superblock> /dev/nvd0p3

Et malheureusement, ni cette commande, ni d’autres ont pu fonctionner pour moi. J’ai du me résoudre à corriger tout ça en faisant une chose radicale. Réinstaller FreeBSD. Il est possible que quelque chose s’est mal passé lors de l’installation, ou après, mais comme je n’arrivais à rien et que je n’avais pas encore eu l’occasion d’utiliser mon nouvelle OS, je n’avais rien à perdre.

J’ai donc tout réinstallé en ajoutant un service que je n’avais pas pris, et en testant au passage si je pouvais ajouter un /home comme Linux. Ce qui n’a pas été possible 🙂 Finalement après avoir refais cette étape, mis à jour le boot loader pour prendre en compte mon SSD et testé un petit cat /etc/fstab au cas où avant le reboot, tout était rentré dans l’ordre 🙂 J’ai pu accéder à ma session pour la première fois 😀

Aujourd’hui j’ai déjà commencé à télécharger le code-source du driver réseau approprié pour mon matériel et à le transférer via clé USB dans un répertoire temporaire. J’en parlerais au prochain article :p

Les liens utiles qui m’ont aidés :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *