Vous n'êtes pas identifié.
Bonjour,
Le propriétaire d'un portable why! W253EU nous indique que sa machine ne démarre plus et affiche les messages d'erreur suivants:
Les messages concernant ACPI sont sans gravité, mais il faut visiblement remettre de l'ordre dans le système de fichiers. pour cela, il faut démarrer la machine en recovery mode comme expliqué ci-dessous.
Hors ligne
Au démarrage, il faut garder la touche [Esc] enfoncée dès l'apparition du logo why! jusqu'à l'affichage du menu GRUB.
Une fois là, dirigez-vous sur Options avancées pour Ubuntu et faites Enter.
Hors ligne
Ensuite dirigez vous sur un des noyau suivi de la parenthèse recovery mode (de préférence le plus récent) et refaites Enter.
Hors ligne
Une fois que la vérification des systèmes de fichiers est faite, résumer le démarrage normal.
Cordiales salutations.
Hors ligne
ça ne fonctionne pas non plus en appuyant sur Shift + esc.
Que puis-je faire?
Hors ligne
Mon épouse pourrait vous apporter l'ordinateur demain matin à Lausanne.
Elle passe la journée en ville et pourrait peut-être le récupérer en partant.
Est-ce que ça pourrait fonctionner pour vous?
Hors ligne
Bonjour,
Demain va être un peu compliqué, elle pourrait l'amener mais je ne sais pas si elle pourra le récupérer dans l'après midi.
Cordiales salutations.
Hors ligne
Bonjour,
J'ai eu deux cas ce matin avec deux machines différentes (N240JU et W650SZ) présentant le même message d'erreur UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Dans les deux cas, j'ai tenté de démarrer en recovery mode comme expliqué ci-dessus, mais le système plante avec le même message d'erreur. Avant cela, j'ai utilisé BootRepair sans succès. J'ai encore tenté de démarrer sur une clé live-USB Ubuntu 20.04 pour monter la partition sur laquelle se trouve le système défectueux en suivant mon propre tuto (voir https://swisslinux.org/forum/viewtopic.php?id=5003), mais sans aucun résultat.
Finalement, je n'ai pas eu d'autre choix que de réinstaller un build Ubuntu 20.04, avec quelques pertes de données pour le client qui n'avait pas effectué de sauvegarde avec DéjàDup (y compris dossiers et fichiers cachés).
En revanche, j'ai découvert que DéjàDup monte le disque système et qu'il est donc possible de copier les données sur un disque externe, mais je n'ai pas trouvé comment faire pour sauvegarder aussi les dossiers et fichiers cachés (signets, historique de navigation Firefox, courriels stockés en local, carnet d'adresses, etc.).
Hors ligne
Bonjour,
Confrontée au même problème, une cliente française nous écrit:
J'ai essayé de suivre le guide en ligne que vous aviez partagé, mais j'ai un problème lors de l'étape 3 : lorsque je choisi le menu Recovery mode, je ne tombe pas sur un nouveau menu dans lequel je peux choisir fsck...
J'ai au contraire une série d'écritures qui s'enchaîne, sans que j'arrive à en sortir. Il semble pourtant que le pb se pose avec fsck , puisque je lis notamment cette phrase : "RUN fsck MANUALLY".
Ma question est donc : comment puis-je accéder à ce dernier menu de récupération par un autre moyen ?
Quelqu'un aurait-il une solution si le recovery mode ne fonctionne pas?
Hors ligne
En cherchant un peu, j'ai trouvé cette solution sur unix.stackexchange.com qui permet avec la touche E (même position sur les claviers QWERTZ, QWERTY, AZERTY) d'éditer la manière de démarrer en forçant la commande fsck.
A tester...
Hors ligne
Bonjour,
Je viens de tester sur une machine réclamant RUN fsck MANUALLY...
Afficher le menu GRUB (en tapant une fois [Esc] pendant l'affichage du logo why! pour une N240BU), choisir Options avancées, sélectionner Recovery mode, puis taper [E] pour afficher les consignes de démarrage. Descendre avec les flèches jusqu'à la fin de la ligne commençant par Linux et ajouter l'instruction fsck.repair=yes (fsck.mode=force n'a rien donné). NB: par défaut, on a un clavier US QWERTY. Sur un clavier QWERTZ-CH, pour afficher un Y il faut taper Z, pour = on tape ^ à gauche de backspace.
On valide le tout avec [F10] et le système démarre sans problème jusqu'au menu Recovery mode. On peut alors se brancher à Internet en filaire, activer le réseau, entrer dans une console Root et faire toutes les opérations utiles, dont apt update, apt upgrade, etc. et sortir en tapant exit pour reprendre le démarrage normal.
Malheureusement, dans mon cas, la machine reste bloquée avec un souligné blanc clignotant et, en redémarrant normalement après avoir forcé l'extinction, le logo Ubuntu s'affiche sans que les petites puces en-dessous ne s'allument les unes après les autres et il ne sert à rien d'attendre...
Je vais devoir réinstaller un système propre...
Hors ligne
Notre cliente française (voir post #10 ci-dessus) nous écrit ceci:
La proposition avec fsck.mode=force OU fsck.repair=yes marche au bout de la 3ème tentative sur 1er recovery mode (le plus en bas)
je peux donc accéder au menu Mode récup puis choisir fsck vérifier tous les fichiers
mais il me dit ensuite :
fsck de util-linux 2.31.1
/dev/nvm0n1p2 est monté
e2fsck: Ne peut continuer, arrêt immédiat.
Terminé
J'éteins, je rallume,
Je recommence, mais au lieu de choisir fsck, je choisis Reprendre le démarrage normal...et là, miracle, il aboutit entièrement et je retrouve mon bureau.
Ma question est donc : puisque vraisemblablement je n'ai pas réussi à faire le nettoyage, comment puis-je éviter un nouveau crash en m'assurant que j'ai la nouvelle version Ubuntu (si tant est que le problème vienne de là)?
La version qui s'affiche dans mes paramètres, pour le moment, est toujours 18.04.5. Pourriez-vous m'indiquer la méthode pour passer au 20 ? Ou même m'expliquer que faire pour s'assurer de la bonne santé générale du système?
Je pense qu'elle devrait effectuer les mises à jour dans un terminal ([Ctrl]+[Alt]+[T]):
sudo apt update sudo apt upgrade sudo apt autoclean sudo apt autoremove sudo update-grub
Je pense qu'elle est toujours sous Ubuntu 18.04. Pour connaître la version du noyau, il suffit de taper la commande uname -r. Chez moi, sous Ubuntu 20.04, j'ai:
francois@francois-N240JU:~$ uname -r 5.8.0-63-generic
J'espère que ça va jouer...
Hors ligne
Encore une modulation sur ce même problème RUN fsck MANUALLY...
Un client vient de passer avec un portable why! N650DU sous Ubuntu 18.04. Il m'a tout d'abord été impossible d'accéder au menu du GRUB (j'ai tout tenté: ESC une fois, gardé enfoncée, idem Shift...) et il m'a fallu réparer le GRUB2 avec une clé live-USB et BootRepair.
Comme le recovery mode ne démarrait pas non plus, j'ai appliqué la procédure décrite au post #12 en recovery mode, puis, une fois la session ouverte, effectué les mise à jour (y compris sudo update-grub), avant de lancer la commande reboot.
Lors de l'extinction, le système semblait planté sur un message a stop job is running for Network Name Resolution. Le temps de rechercher une explication sur Internet et de trouver, par exemple, cette discussion sur reddit.com, le système avait fini d'exécuter le job (environ 6 minutes!!). Après cela, la machine fonctionnait à nouveau parfaitement.
Mais je reste perplexe...
PS: Suite à l'utilisation de BootRepair, le menu du GRUB s'affiche à chaque démarrage. Comme le client préférait valider Ubuntu à chaque démarrage et que je n'avais pas le temps de retrouver comment paramétrer le fichier /etc/default/grub avec gedit (probablement GRUB_TIMEOUT_STYLE=hidden), j'ai laissé cela comme ça...
Hors ligne
On a vraiment tout essayé avec la machine récalcitrante qui ne démarrait plus, pas même en nomodeset...
Restait juste à trouver le moyen de sauvegarder les dossiers et fichiers cachés (autrement dit tout le home), afin de pouvoir réinstaller un système propre.
Voici la procédure que je viens de tester:
1. Démarrer la machine sur une clé Ubuntu 20.04 live-USB.
2. Raccorder la machine à Internet en mode filaire (plus rapide).
3. Dans mon cas, il a fallu aller dans Paramètres système / Pays et langues virer les langues pour ne conserver que le français et choisir le format Français (Suisse) pour avoir un clavier QWERTZ-CH
4. Ouvrir un terminal ([Ctrl]+[Alt]+[T]) et taper sudo -s pour avoir les droits root.
5. Brancher un disque dur externe et y créer un dossier destiné à recevoir le backup. Dans mon cas, j'ai utilisé le HDD de la machine qui fonctionne comme un disque dur externe.
6. Ouvrir le navigateur de fichier avec les droits root en tapant nautilus, ce qui aura pour effet de monter tous les disques qui ne le sont pas encore.
7. Dans le navigateur de fichiers, aller sur le SSD et trouver le home de la machine en panne et cocher l'option Afficher les fichiers cachés.
8. Ouvrir un nouvel onglet dans la fenêtre du navigateur de fichiers en tapant [Ctrl]+[T] et se rendre sur le HDD dans le dossier de backup (cf. point 5).
9. Copier le home du SSD avec [Ctrl]+[C] et le coller dans le 2e onglet avec [Ctrl]+[V].
10. Vérifier que tout est bien dans le dossier de backup avant de réinstaller le système propre.
Et voilà! Un immense merci à Florent Cayré de la coopérative Commown qui propose des ordinateurs why! en France et qui m'a rappelé cette possibilité d'effectuer une sauvegarde en mode graphique!
Je marque le problème comme [Résolu], même si c'est avec la manière forte!...
Hors ligne
Bonjour,
Les ennuis continuent avec une why! N131ZU qui ne démarre plus.
J'ai tenté d'ouvrir Nautilus avec les droits root (sudo -s), mais le SSD de 500 GB sur lequel se trouve le système n'est pas vu. L'explication se lit dans le terminal:
root@ubuntu:/home/ubuntu# nautilus ** (org.gnome.Nautilus:13289): WARNING **: 08:14:57.384: Unable to get contents of the bookmarks file: Erreur lors de l’ouverture du fichier /root/.gtk-bookmarks : No such file or directory ** (org.gnome.Nautilus:13289): WARNING **: 08:14:57.384: Unable to get contents of the bookmarks file: Erreur lors de l’ouverture du fichier /root/.gtk-bookmarks : No such file or directory Nautilus-Share-Message: 08:14:57.467: Called "net usershare info" but it failed: L’exécution du processus fils « net » a échoué (No such file or directory)
Encore faut-il savoir ce que cela signifie et comment réparer...
Hors ligne
Bonjour,
Même problème avec une N240JU sous Ubuntu 18.04 qui ne démarre plus. J'ai tout essayé, sans succès...
Après avoir démarré sur une clé live-USB Ubuntu 20.04 et monté la partition où se trouve le système (voir https://swisslinux.org/forum/viewtopic.php?id=5003), je n'ai pas réussi à lancer nautilus pour pouvoir sauvegarder les données et les fichiers cachés:
root@ubuntu:/# nautilus No protocol specified Unable to init server: Impossible de se connecter : Connexion refusée (nautilus:6564): Gtk-WARNING **: 13:23:23.245: cannot open display: :0
En réfléchissant un peu, je me suis dit qu'il fallait démonter cette partition en fermant la fenêtre terminal, en rouvrir une nouvelle et taper:
sudo -s nautilus
Cela me permet de faire une sauvegarde et de réinstaller un OS proprement... Malheureusement, Nautilus permet d'aller sur le HDD externe branché pour la sauvegarde, mais pas le disque système!?!?!
Hors ligne
En fait, il semble possible de suivre la procédure de sauvegarde décrite au post #15 ci-dessus, mais avec une clé live-USB avec BootRepair. On peut ouvrir le navigateur de fichiers, monter le disque système en cliquant dessus, repérer le home, ouvrir un second onglet avec [Ctrl]+[T] et se rendre dans le dossier créé pour recevoir la sauvegarde, puis, [Ctrl]+[C] sur le home et [Ctrl]+[V] sur le dossier de sauvegarde.
Ça a l'air de fonctionner, les fichiers copiés défilent, mais j'observe tout de même un grand nombre d'erreurs (probablement liées aux droits requis):
.xsession-errors : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/.xsession-errors: Permission denied .xsession-errors.old : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/.xsession-errors.old: Permission denied untitled_1.odt : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/untitled_1.odt: Permission denied .Xauthority : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/.Xauthority: Permission denied Zert-Antrag-2019-zur-Erneuerung-SFV_ausfüllbar(1).pdf : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/Téléchargements/Zert-Antrag-2019-zur-Erneuerung-SFV_ausfüllbar(1).pdf: Permission denied $PLUGINSDIR : Error opening directory '/media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/Téléchargements/$PLUGINSDIR': Permission denied Zert-Antrag-2019-zur-Erneuerung-SFV_ausfüllbar.pdf : Error opening file /media/lubuntu/01870d89-9a77-40a2-9f2a-5707af45db55/home/pascaline/Téléchargements/Zert-Antrag-2019-zur-Erneuerung-SFV_ausfüllbar.pdf: Permission denied
... (impossible de tout copier ici, car le mini-navigateur de BootRepair ne reconnaît pas le bouton Code et interdit de copier plus de X milliers de caractères)
En fait, aucun fichier caché n'a été sauvegardé, même si j'avais trouvé comment les afficher dans BootRepair. Contrairement à ce que j'ai pu expérimenter avec une live-USB Ubuntu avec les droits root.
Le problème était exclusivement logiciel, car, après réinstallation propre de Ubuntu 20.04, la machine a démarré comme une fleur et j'ai pu y restaurer tous les fichiers qui avaient été sauvegardés avec DéjàDup, sauf, évidemment:
- le carnet d'adresses et les courriels sauvegardés en local dans le dossier caché .thunderbird
- l'historique de navigation, les signets et lesmots de passe sauvegardés dans .mozilla/firefox
- les pilotes pour l'imprimante multifonctions
- Zoom
- etc.
Pas si dramatique dans la mesure où la machine se trouve dans un état comparable à celui de la commande d'il y a 6 ans, avec la dernière version LTS de Ubuntu.
Mais j'enrage de ne pas parvenir à réparer un système d'exploitation, malgré des heures d'essais et de nombreuses expériences réussies...
Cordialement.
PS: Pour l'anecdote, le home de la cliente comprenait un dossier Duplicity contenant une sauvegarde du home sur lui-même et qui occupait une grande partie de l'espace disque. Si DéjàDup est paramétré pour réaliser une sauvegarde régulière (par exemple, une fois par semaine), les sauvegardes de sauvegardes de sauvegardes de sauvegardes vont rapidement saturer le disque. Ce n'est pas la première fois que je vois cela et il est important que les gens comprennent qu'une sauvegarde des données avec DéjàDup doit se faire sur un disque dur externe (ou sur le cloud).
Hors ligne
J'aurais dû préciser qu'il aurait peut-être été possible de sauver ce système en créant une partition boot comme indiqué sur https://doc.ubuntu-fr.org/tutoriel/partition_boot.
En effet, après utilisation de BootRepair, j'avais le message suivant:
Si je ne l'ai pas fait, c'est que la première recommandation est d'effectuer une sauvegarde des données. Cela fait, après avoir perdu plus de 4 heures, je n'ai pas testé cette option et me suis empressé de réinstaller un système propre.
Ce sera pour la prochaine fois...
Hors ligne
PS: La procédure décrite au post #12 a très bien fonctionné pour un NUC7i5BNH: voir https://swisslinux.org/forum/viewtopic.php?id=7913.
Hors ligne