Forcez fsck.ext4 au redémarrage, mais vraiment "avec force"
Un de mes serveurs Ubuntu 10.04 me pose problème. Lorsque je lance fsck.ext4 -n /dev/sda5, il me dit que le nombre d'inodes libres, le nombre de blocs libres, et plus sont erronés.
J'ai essayé:
touch /forcefsck
Aussi essayé:
shutdown -rF now
et encore, après le redémarrage, je vois des erreurs.
Je viens également de vérifier mon netbook eeePC, Ubuntu 10.10, et j'ai le même problème!
Comment puis-je forcer un "forcé" "forcer" "sérieusement à réparer mon système de fichiers" fsck du système de fichiers "/" au redémarrage?
Clarification: J'exécute fsck.ext4 -n car c'est un système de fichiers monté, pour vérifier s'il y a des erreurs. Cela me dit qu'il y en a. Je pensais que le fsck automatique tous les 30 montages pendant le processus de démarrage est justement pour prendre soin des erreurs dans le système de fichiers racine. Mais ça ne le fait pas dans mon cas. Je pourrais redémarrer avec un LiveCD et corriger les erreurs, puis redémarrer à nouveau, mais il s’agit là d’une grave panne de serveur. Un redémarrage, auto fsck, puis continuer à démarrer est beaucoup plus durable sur un serveur en direct, et je pense que cela devrait être le bon comportement.
Informations supplémentaires: Voici la sortie. Cela ressemble à quelque chose que l'autofsck corrigerait, n'est-ce pas?
root@server:~# fsck.ext4 -n /dev/sda5
e2fsck 1.41.11 (14-Mar-2010)
Warning! /dev/sda5 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1849368, counted=1948909).
Fix? no
Free inodes count wrong (545504, counted=552134).
Fix? no
/dev/sda5: ********** WARNING: Filesystem still has errors **********
/dev/sda5: 116752/662256 files (0.2% non-contiguous), 795324/2644692 blocks
De la page de manuel e2fsck:
"Notez qu'en général, il n'est pas sûr d'exécuter e2fsck sur des systèmes de fichiers montés. La seule exception est si l'option -n est spécifiée et si les options -c, -l ou -L ne sont pas spécifiées. Cependant, même si elle est sûre pour ce faire, les résultats imprimés par e2fsck ne sont pas valides si le système de fichiers est monté. Si e2fsck vous demande si vous devez ou non vérifier un système de fichiers monté, la seule réponse correcte est '' non ''. Seuls les experts qui savent vraiment quoi ils le font devraient envisager de répondre à cette question de toute autre manière. "
Donc, si vous vérifiez un FS monté avec fsck même en utilisant l'option -n, le résultat risque de ne pas être valide du tout. Ne vérifiez pas les systèmes de fichiers montés. Utilisez un Live-CD/Live-USB.
Si vous ne vérifiez pas le système de fichiers pendant qu'il est monté, je ne comprends pas pourquoi vous devez utiliser touch /forcefsck. Vous pouvez simplement le démonter et le réparer. Mais si c'est le cas et après un correctif, votre FS a encore des erreurs, vous pouvez envisager d'utiliser:
e2fsck -cy /dev/sda5
Cela corrigera un problème lié au disque dur appelé mauvais bloc que vous pourriez avoir (cela prendra beaucoup de temps).
Si vous voulez vérifier un système de fichiers monté, je ne sais pas comment procéder, mais je pense que vous devriez créer une autre question.
Je sais que c'est un très vieux sujet, mais j'ai récemment eu à résoudre ce problème. Je voulais donc publier comment forcer le système d'exploitation à résoudre les problèmes rencontrés avec fsck lors du démarrage (pour 12.04).
Vous devez exécuter la commande Sudo touch /forcefsck. Cela lui fera effectuer un fsck au prochain démarrage. Vous pouvez voir les résultats de la commande fsck dans /var/log/boot.log.
Cependant, rien ne garantit que fsck corrigera tout ce qu'il trouve. Pour ce faire, vous devez éditer le fichier/etc/default/rcS. Il y a une ligne à la fin de ce fichier:
FSCKFIX=no
Ceci doit être changé comme suit:
FSCKFIX=yes
Cela aura le même effet que d’exécuter fsck avec l’option -y, ce qui forcera l’implémentation de tous les correctifs possibles sans demander l’interaction de l’utilisateur.
Cela vous permettra d’exécuter fsck comme l’opérateur le demandait sans avoir à démarrer à partir d’un disque vivant, ce qui n’est pas toujours possible, surtout si vous êtes sur un système distant.
Sudo touch /forcefsck
Sudo reboot
Vous avez une typo- vous touchez/forcefcsk. Le "c" et le "s" sont échangés. fsck est l'abréviation de FileSystemChecK.
Vous ne pouvez pas forcer un fsck sur/qui va réparer car la partition est en cours d'utilisation. Essayez d'exécuter la vérification à partir d'une autre partition ou d'un cd en direct.
Les révisions peuvent être effectuées automatiquement de la manière suivante:
Tune2fs -c 5 -i 10 / dev / sda1
-c est le nombre maximal de montages avant d'exécuter fsck et -i est le nombre maximal de jours avant d'exécuter fsck.
Dans ce cas, cela se fera tous les 5 montages ou tous les 10 jours, selon la première éventualité.
J'ai deux ordinateurs, l'un avec Linux SuSE 13.2 et l'autre avec Linux Mint 18.0. Dans les deux cas, cela fonctionne parfaitement.
touch /forcefsck seul ne s'est pas assuré que mon système exécutait fsck au prochain démarrage. J'avais aussi besoin de courir:
Sudo tune2fs -c 1 /dev/<my partition>
par exemple.
Sudo tune2fs -c 1 /dev/sda1
Plus d'explications que j'ai trouvées sont ici: Comment forcer fsck à vérifier le système de fichiers après le redémarrage