Trisquel ne se lance plus... Stopping read required files in advance
- Inicie sesión o regístrese para enviar comentarios
Bonjour à tous,
J'ai un gros problème, Trisquel ne lance plus.
Après un gel d'écran, j'ai forcé l’arrêt de la machine en maintenant le bouton de mise sous tension. Depuis, au démarrage, trisquel ne se lance plus et j'ai le message d'erreur suivant:
"Stopping read required files in advance"
Ensuite l'écran reste noir et tourne en boucle avec des "Call trace" et plein de ligne de charabia en dessous.
Pour info, ma machine est un thinkpad X200, je suis sous Trisquel 7 avec GnuGrub
N'étant pas ni un as en informatique ni en anglais, je n'ai aucune idée de ce qu'il faut que je fasse. Est-ce grave?
Quelqu'un aurait-il la gentillesse de m'aider?
D'avance merci!
il ressemble a ceci ton écran ?
https://trisquel.info/files/Trisquel_7_lxde_core_install_2.png
Essaye
après le $ écrit ceçi
startx
Cela devrait (éventuellement) t'ouvrir une session graphique
Et si tu n'as pas l'écran que Mangy Dog te montre, essaie Ctrl+Alt+F2 pour l'avoir.
Quelque chose de particulier que tu aurais installé récemment (comme un autre environnement de bureau) ? Une modification de /etc/fstab ?
J'ai peur que le problème soit un disque dur mourant...
Réalise donc déjà une sauvegarde depuis un système Live (comme le système qui t'a servi à installer Trisquel).
Bonjour Mangy Dog,
Merci beaucoup pour ta réponse. Malheureusement non, ce n'est pas le genre d'écran que j'ai.
En fait, habituellement quand je lance ma machine, j'ai d'abord une image de pingouin sur le bouc avec avec plusieurs choix. Si je ne touche à rien, quelque instants après un écran noir apparaît avec plein de ligne qui se succèdent très vite:
"* Starting machin chouette..." "* stopping bidule" etc. ensuite, d'habitude je tombe sur le choix d'utilisateur où j'introduis mon mot de passe mais depuis le problème, tout se passe de la même manière sauf que je n'arrive plus à l'écran de choix d'utilisateur. C'est comme si le chargement bloquait, comme si la séquence de "* starting... " "* stopping..." n'arrivait pas à aboutir.
J'ai quand même tenté ma commande que tu indiques mais rien ne s'affiche, pas même les lettres que je tapes sur le clavier, ça semble bloqué. Je vois juste une séquence d'une quinzaine de ligne qui se répète en boucle où chaque ligne apparaît très lentement. ça commence par "Call trace:" puis des lignes avec à chaque fois une intro entre crochet et entre "<" ">" puis du code.
Bonjour Magic Banana,
Merci pour ton aide! Ctrl+alt+F2 ne fait que faire apparaître un écran noir avec un tiret clignotant en haut à gauche de l'écran. Lorsque je tape sur le clavier, rien n’apparaît. "startx" ne semble rien donner. Après de longue minutes la séquence "Call Trace:" recommence.
Pour répondre à ta question, je n'ai pas l'impression d'avoir installé quelque chose de particulier ces derniers jours.
Je vais tenter une sauvegarde avec un système live... en espérant que ça marche.
Merci pour votre aide!
J'ai dit une bêtise en présentant ma machine. Je suis sur libreboot et non pas gnu grub.
A vrai dire je n'avais pas moi même installé Trisquel sur cette machine (achetée sur minifree). J'ai créé un live System usb à partir de l'ISO récupérée sur le site de trisquel via "startup disc creator".
Une fois la clé branchée, le PC allumé, dans le menu de libreboot j'ai la possibilité de choisir "* Parse ISOLINUX menu (USB)", je tape sur la touche "enter" et il apparaît à l'écran:
"error: syntax error.
error: Incorrect command.
error: syntax error.
Press any key to continue..."
quand je tape sur le clavier je reviens au menu de libreboot... impossible de démarrer sur le live system USB. Aurais-je mal fait quelque chose?
Je n'ai pas Libreboot. En revanche, j'ai écrit ce manuel qui pourrait, j'espère, t'aider à démarrer un système Live : https://trisquel.info/fr/wiki/d%C3%A9marrer-un-syst%C3%A8me-live-installable
Merci Magic Banana. En cherchant, j'étais déjà tombé ton super manuel!
Mais effectivement pour libreboot c'est un peu différent. Pour ceux qui se retrouveraient dans la même situation, en fait les disques créés avec start up disc creator ne fonctionnent pas avec libreboot... il faut faire une manip spéciale: https://libreboot.org/docs/gnulinux/grub_boot_installer.html
Ce qui explique pourquoi ça ne fonctionnait pas! Maintenant ça marche. J'arrive à lancer trisquel en mode "live".
Par contre, le problème c'est que le disque dur ne se monte pas. Il est reconnu mais lorsque je clique sur l’icône du disque, j'ai ce message "Unable to acces 213 GB Volume" An operation is already pending"
l'opération dont ils parlent doit être le fait que j'ai cliqué une première fois sur l’icône et que ça ne répond pas...
Voulant essayer de me débrouiller, j'ai tenté de faire l'opération présentée ici: http://coorprowave.info/2012/08/07/reparer-un-disque-dur-qui-ne-se-monte-plus-sous-gnulinux/
Sauf que j'ai pris soin de faire l'inverse, c'est à dire tenter de monter la partition de mon disque dur interne qui ne se monte pas sur mon disque dur externe. Ce qui n'a pas fonctionné malheureusement. Je ne sais pas si c'est très orthodoxe ce que j'ai fait. Peut être n'est-ce tout simplement pas possible de monter une partition d'un disque sur un autre disque... je ne maîtrise pas du tout le sujet.
Grâce à "Disk" et à la commande "lsblk" je vois que mon disque sda de 223,6G est divisé comme ceci:
sda1 18,6G part "filesystem"
sda2 1K part
sda5 6,3G part (swap)
sda6 198,7G part
En réalité c'est la partition sda2 qui est sous divisée en deux partitions (sda5 et sda6)
Connaissez-vous une solution qui me permettrait de récupérer le contenu de ce disque dur ? ... ou dois-je me résoudre à faire une croix définitive sur mes données? Aie... j'ai peur de la réponse.
Pas de crois définitive sur tes données, non.
Bon, déjà une chose : on ne monte pas un système de fichiers sur un disque mais sur une structure abstraite, la hiérarchie de fichiers (que l'on peut se représenter comme un arbre dont la racine est /, les embranchements sont les répertoires et les feuilles sont les fichiers), en un point qui est donc un des répertoires de la hiérarchie (la racine du système de fichiers monté se trouve au point de montage). Bref, tu n'as pas fait l'"inverse" mais la même chose que ce que http://coorprowave.info/2012/08/07/reparer-un-disque-dur-qui-ne-se-monte-plus-sous-gnulinux/ explique. Et le disque dur externe ne servait à rien.
Mais as-tu correctement informé le type du système de fichiers ? Si tes données (apparemment sur /dev/sda6) sont dans un système de fichiers de type XFS (choisi par défaut par l'installateur de Trisquel), c'est alors ce type qu'il faut informer (ici pour monter en /mnt) :
$ sudo mount -t xfs /dev/sda6 /mnt
Si cette commande ne renvoie rien, c'est que tout s'est bien passé et les dossiers personnels des utilisateurs sont dans /mnt : la sauvegarde peut commencer. Sinon, un message d'erreur est renvoyé. Quel est-il ? Aussi, juste après que l'erreur est renvoyée voyons les vingt dernières lignes du log système (il peut y avoir quelque chose d'intéressant) :
$ dmesg | tail -20
Toujours en supposant que tes données sont sur /dev/sda6 dans un système de fichiers XFS, il y a cette commande pour tenter de réparer le système de fichiers :
$ sudo xfs_repair /dev/sda6
Merci pour ton aide Magic Banana.
J'ai essayé "sudo mount -t xfs /dev/sda6 /mnt", la commande ne renvoie rien mais je pense que c'est parce qu'elle n’aboutit pas. J'ai un carré blanc en dessous et lorsque j'entre une autre commande rien ne se passe (et lorsque je tente de fermer le terminal, j'ai un message m'indiquant qu'un processus est en cours et que fermer le terminal le tuera).
Pareil avec "sudo xfs_repair /dev/sda6"
Je pense que ce qui pourrait aider à la compréhension du problème serait que je puisse copier coller les 20 dernières lignes d'erreur que j'ai au démarrage (sans le liveCD). Je peux essayer de le faire manuellement mais ça sera très fastidieux. Y a t il moyen que je puisse copier coller via le live system? Genre simuler un démarrage sur sda? puis effectuer la commande "dmesg | tail -20"?
Voici une idée de ce que je reçois comme message au démarrage ("charabia" correspond à des infos qui me semblent inutilles ou totalement obscures)
* starting Clean /tmp directory [ OK ]
[ charabia] XFS (sda6): Starting recovery (logdev:internal)
[ charabia] XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1602 of file /tmps/buildd/linux-3.13.0/fs/xfs/xfs_alloc.c. Caller 0xffffffffa0359ff5
[ charabia] CPU: O PID: 374 Comm: mount Tainted: G I 3.13.O-100-lowlatency #147+7.0trisquel12
[ charabia] Hardware name: LENOVO bidule
[ charabia] charabia
[ charabia] charabia
[ charabia] charabia
[ charabia] Call Trace:
[ charabia] [< charabia >] dump_stack+x64/0x82
[ charabia] [< charabia >] ....
.....
Pour écrire la sortie d'une commande (ici 'dmesg') dans un fichier (ici nommé "log") écrit le chemin vers le fichier (ici le répertoire courant, ton dossier personnel si tu n'utilises pas 'cd' pour changer de répertoire) après le caractère ">", lui même après la commande :
$ dmesg > log
Tu peux ensuite l'annexer à un message sur ce forum.
Mais XFS_WANT_CORRUPTED_GOTO ne laisse aucun doute : le système de fichiers est corrompu. Essaie donc de laisser tourner 'sudo xfs_repair -v /dev/sda6' pendant une nuit. J'ai ajouté l'option "-v" pour que la commande te raconte plus de choses et que tu n'ais pas l'impression qu'elle ne fait rien si, en fait, elle travaille.
Si ça ne donne rien, il y a l'option "-L" (avec un risque associé de perte de données). Si cela non plus ne fonctionne pas, ça risque de devenir compliqué. Mais il y a toujours GNU ddrescue pour du très bas niveau. Vois cette histoire : https://linuxfr.org/news/ddrescue-dd_rescue-myrescue-recuperer-ses-donnees-apres-un-crash-disque
Fait des photographies de l'écran et mets les en pièces jointes sur le forum.
merci
Bonne idee nmrk.n
merci a toi
Voici
Je n avais pas vu ta réponse Magic Banana. Merci aussi,
Voici le fichier log
par contre il s agit du fichier log via live system... je ne sais pas si c est bon ou pas.
| Adjunto | Tamaño |
|---|---|
| log.txt | 1.2 KB |
Et voici ce que répond la commande 'sudo xfs_repair -v /dev/sda6';
"Phase 1 - find and verify superblock...
- block cache size set to 753544 entries
Phase 2 - using internal log
- zero log...
zero_log: head block 194321 tail block 194071
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this."
Tiens tiens, ca ne semble plus bloquer comme avant?!
En fait Magic Banana j avais deja anticiper le fait que la commande prenne du temps, je l avais laisse tourner toute la nuit precedente
ps: mes excuses pour les accents manquants j ecris depuis un clavier qwerty
Pour info, je viens de relancer la commande 'sudo xfs_repair -v /dev/sda6'; et la, ca rebloque. Probablement parce qu entre temps j ai clique sur l icone du disque dur et qu il est "occupe"
Je laisse tourner je vous dis si ca retourne quelque chose...
Alléluia! Ça fonctionne. Je vous parle depuis ma machine qui refonctionne!!!
Merci Magic Banana! Merci à tous pour vos conseils!
Je suis tellement content d'avoir retrouvé mes données. Je m'empresse de ce pas de faire le backup que je repoussais depuis quelques mois.
Oserais-je une dernière question: est-ce que le problème est le symptôme de quelque chose? Un disque dur "en fin de vie" à remplacer? Ou bien une erreur de ma part dans un bidouillage un peu foireux que je n'ai pas identifié? Une config instable qu'il serait judicieux de netoyer? Puis-je encore attendre et voir si le problème revient avant de réinvestir dans un nouveau disque dur ou pensez-vous qu'il soit pertinent de le changer préventivement? (sachant que le SD à 2 ans).
Autre chose, en y réfléchissant mieux, j'ai oublié de vous dire que je m'étais habitué à des kernel panic au démarrage, depuis toujours (c-à-d depuis que j'ai réceptionné le x200 de chez Minifree), de temps et temps, la séquence de démarrage s'interrompait. Je mettais ça sur le dos de libreboot qui était un peu capricieux, puisqu'en forçant un redémarrage, ça démarrait normalement. Du coup, je n'y prêtais plus attention... peut-être à tort?
Autre info qui pourrait vous mettre la puce à l'oreille: ces derniers temps, j'ai reçu quelques alertes me disant que l'espace disque était faible "Le volume "Racine du système de fichiers" n'a plus que 809 Mio d'espace disponible."... j'avais fait un coup d'autoremove quelques jours avant le problème, je ne sais pas si ça peut avoir un lien... Je pensais avoir résolu le problème avec autoremove mais voilà que j'ai de nouveau reçu une alerte. A moins que la commande "repair" ait récupéré les Kernels et que cela ait un lien avec le probleme précédent??? je ne comprends pas bien.
Pour tester la santé de ton disque dur, utilise l'utilitaire "Disques" (dans les "Paramètres système"). Choisis le disque, à gauche de l'interface, puis "Données SMART et auto-tests..." dans le menu avec une icône d'engrenage, en haut à droite de l'interface. Depuis la fenêtre qui s'ouvre, tu peux "Démarrer l'auto-test" (que tu peux choisir "étendu") avec le bouton éponyme, en bas à gauche. L'"estimation globale", en haut, t'informera si ton disque dur est sain ou non.
La mémoire vive peut aussi être en cause. 'memtest86+' (à laisser tourner pendant une nuit) permet de tester la mémoire. Il se trouve dans le dépôt Trisquel. Tu peux par exemple l'installer depuis le "Gestionnaire de paquets Synaptic". 'memtest86+' se lance depuis les "Options avancées de Trisquel GNU/Linux" du chargeur de démarrage, GRUB, pas depuis Trisquel. L'ennui c'est que, par défaut, l'installateur Trisquel colle un mot de passe aléatoire à GRUB. GRUB demande ce mot de passe pour pouvoir lancer autre chose que Trisquel (par exemple 'memtest86+'). Ce mot de passe ne sert qu'à t'ennuyer. Même les développeurs de GRUB le disent : https://www.gnu.org/software/grub/manual/grub.html#Security
Bref, soit tu lances un 'memtest86+' qui se trouverait aux côtés d'un GNU/Linux live (pas Trisquel : les ISOs Trisquel n'ont pas 'memtest86+') soit tu commences par supprimer le mot de passe GRUB inutile (ou à l'apprendre, si tu ne veux pas le supprimer) : https://trisquel.info/fr/wiki/mot-de-passe-grub
Enfin, pour ce qui est de l'espace disponible sur la partition racine :
- Tu peux supprimer les paquets .deb (qui sont par défaut gardés pour éviter d'avoir à les télécharger de nouveau en cas de réinstallation) avec 'sudo apt-get clean' ou avec 'sudo apt-get autoclean', qui ne supprime pas les dernières versions des .deb.
- Tu peux supprimer les vieux Linux (par exemple depuis le "Gestionnaire de paquets Synaptic" dans les "Paramètres système"), c'est à dire les paquets installés dont les noms commencent par "linux-" mais qui n'incluent pas le numéro le plus haut, c'est à dire la version du noyau que tu dois utiliser actuellement ('uname -r' dans un terminal te dira de laquelle il s'agit).
Ceci dit, si les "kernel panics" sont apparus après une mise à jour du noyau, il vaudrait la peine d'essayer de démarrer une ancienne version (à ne pas supprimer, à choisir depuis les "Options avancées de Trisquel GNU/Linux" de GRUB après avoir supprimé ou appris son mot de passe) pour voir si cette version panique aussi ou non. Dans le premier cas, il s'agit probablement un problème matériel. Dans le second, essaie donc de mettre à jour ton noyau (tu peux aussi directement essayer cela plutôt que de d'abord tester une ancienne version) : https://trisquel.info/fr/wiki/actualiser-le-kernel-linux-libre
Mais bon, les crashs aléatoires sont, en général, signes d'un problème matériel...
Bonjour,
J'ai un T400 également préparé chez minifree (datant de ce début d'année). Mon PC a également tendance à se figer, et quelques rares fois à redémarrer, au démarrage. Il surchauffe aussi facilement si j'utilise la carte graphique ou qu'il n'est pas surélevé.
Concernant le manque de place sur la partition système, je t'invite à regarder mon commentaire, puis la taille de tes fichiers suivants :
https://trisquel.info/fr/forum/erreur-lightdm#comment-106200
ATTENTION, ouvrir les fichiers ci-dessous prends du temps et de la ressource CPU !
- /var/log/kern.log
- /var/log/kern.log.1
- /var/log/ufw.log
- /var/log/ufw.log.1
On utilise 'less' pour lire des fichiers immenses puisque, contrairement aux éditeurs de texte, il ne charge qu'une page du fichier en RAM (pas le fichier entier). Par exemple :
$ less /var/log/kern.log
Une fois dans 'less', on peut utiliser PgUp et PgDn pour avancer/reculer d'une page, / et ? pour chercher une expression régulière (qui peut être une simple chaîne de caractères) en avant ou en arrière et q pour quitter. Mais 'less' a des tonnes d'autres commandes : vois 'man less'.
Après, si une ligne est répétée ad nauseam, il est probablement suffisant de voir les 10 dernières lignes :
$ tail /var/log/kern.log
On peut aussi voir les dix dernières et continuer à voir les nouvelles lignes écrites dans le fichier (et ainsi prendre conscience de sa vitesse de remplissage) :
$ tail -f /var/log/kern.log
Ctrl+C permet de terminer la commande.
- Inicie sesión o regístrese para enviar comentarios