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.

Comme le souci semble émaner du fsck, dirigez vous dessus et faites Enter à nouveau.

ça ne fonctionne pas non plus en appuyant sur Shift + esc.

Que puis-je faire?

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.

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?

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...

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...

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...

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).