`Système de fichiers en lecture seule` erreur en utilisant la complétion automatique des onglets, et la fermeture aléatoire de la fenêtre du terminal

J'ai redémarré en mode de récupération et suivi les instructions du système. J'ai exécuté fsck sur /dev/sda2, et cela a résolu le problème.

L'erreur du système de fichiers en lecture seule est l'indice majeur ici. Je suppose que votre répertoire personnel, où bash essaie de stocker votre historique de commandes et ainsi de suite, se trouve à l'intérieur d'une partition en lecture seule.

Je suppose qu'il essaie de mettre à jour votre historique de commandes récentes sur le disque une fois toutes les 32 commandes, c'est pourquoi il échoue à la 32ème commande que vous tapez dans une session.

Maintenant, une partition peut être montée en lecture seule si vous le faites délibérément, mais elle peut aussi être montée en lecture seule s'il y a eu une erreur - ce dernier comportement est généralement le défaut pour la partition racine.

Je serais surpris si vous ne rencontriez pas d'autres problèmes si votre partition racine est montée en lecture seule.

Vous pouvez essayer de redémarrer et de vérifier le disque à partir du menu de récupération. Appuyez sur Maj en maintenant la touche enfoncée lorsque l'ordinateur démarre, juste après la disparition de l'écran du BIOS et juste avant l'apparition du logo Ubuntu.

Cette situation exacte m'est aussi arrivée.

Cela se produit de manière intermittente.

J'en ai enfin eu assez et j'ai décidé de réinstaller le système d'exploitation - ubuntu-gnome 14.04 (propre).

Cela a réglé le problème! Du moins pendant quelques jours... Puis ce même problème exact est réapparu...

Alors je suis allé chez Fry's et j'ai acheté un nouveau disque dur (Seagate).

Jusqu'à présent tout va bien (6 mois et cela continue).

Note annexe : le disque dur d'origine était un Toshiba.

Comme d'autres l'ont souligné, un système de fichiers en lecture seule /tmp entraîne d'autres problèmes.

En ce qui concerne les 31 lignes, c'est lié aux internes de gnome-terminal.

Il garde un certain nombre de lignes en mémoire, dans un "ring" appelé ainsi. Le reste, les lignes qui sortent de ce ring, sont placées dans un "stream". Dans les anciennes versions de gnome-terminal, le stream était à peu près directement écrit dans un fichier sous /tmp, dans les nouvelles versions il y a un tampon, une compression et une encryption avant qu'il ne soit écrit. (Je ne me souviens pas spontanément si le fichier sous /tmp est ouvert lorsque le premier morceau de données est écrit dans le stream, ou lorsque le stream tente vraiment d'écrire dans /tmp; c'est un détail d'implémentation mineur.)

La taille de l'anneau est toujours une puissance de deux (chaque emplacement contenant 1 ligne du terminal; sauf qu'un emplacement n'est pas utilisé pour des raisons techniques), et est doublée chaque fois qu'elle est nécessaire en raison de la croissance de la hauteur du terminal (mais ne rétrécit jamais). Par exemple, avec la hauteur par défaut de 24 lignes, l'anneau contient les 31 dernières lignes de sortie, le reste va dans le stream (éventuellement vers /tmp). Si vous augmentez la hauteur de la fenêtre pour disons 40 lignes, l'anneau en mémoire va croître pour accueillir au maximum 63 entrées à la fois.

Ce que vous rencontrez, c'est que gnome-terminal essaie d'ouvrir un fichier dans /tmp pour stocker le stream, et se ferme en raison de l'échec inattendu ici. Essayez avec une fenêtre plus haute que la par défaut ; il plantera après avoir appuyé sur Entrée 63 (ou peut-être 127) fois.

Cela dit, /tmp devrait être réparé pour être inscriptible (avec des permissions 1777).

Mon problème était qu'un processus tournait avec 100% de CPU et prenait probablement toutes les ressources du disque (quelques processus de sauvegarde : Ur-Backup).

Une fois que je l'ai arrêté, tout est rentré dans l'ordre. Je pense donc qu'un goulot d'étranglement sur l'IO pourrait causer cette erreur même s'il y a assez d'espace et que vous avez les autorisations d'écriture.

(Raspberry Pi avec Jessy 18/03/16)