Vous n'êtes pas identifié.
Bonjour,
Un client a effectué une mise à niveau de son why! W650SZ vers Ubuntu 18.04 sans brancher le chargeur. Et ce qui devait arriver arriva: une fois la batterie vide, l'ordinateur s'est arrêté net avant que la mise à jour ne soit terminée. A partir de là, impossible d'ouvrir une session ou de se connecter en mode non-graphique pour tenter des réparations.
Comme le client n'avait pas fait de sauvegarde récemment, j'ai cherché à savoir comment tenter une réparation en démarrant la machine sur une clé llive-USB et en montant la partition sur laquelle se trouve le système...
Hors ligne
Je suis assez rapidement tombé sur ce tutoriel Réparer Ubuntu après un plantage lors d'une mise à niveau.
Pour démarrer sur la clé live-USB, il faut la sélectionner après avoir tapé [F7] Boot select et, dès l'apparition du logo "clavier"en bas de l'écran, taper sur la barre d'espace, puis choisir le Français et le clavier Swiss french (menu [F3]).
Une fois que le bureau Ubuntu apparaît, on peut ouvrir une fenêtre terminal (clic droit sur le bureau).
On peut lancer gparted pour savoir sur quelle partition se trouve le système. Dans le cas d'une why! W650SZ, il se trouve sur le SSD de 120 GB, sur la partition sda2. (NB: la commande sudo fdisk -l donne la liste des partitions)
Passer en root pour avoir tous les droits avec la commande:
sudo -s
Monter la partition système contenant Linux sur votre disque dur:
mount /dev/sda2 /mnt
Monter /dev, /proc et copier les points de montages dans ce point de montage:
mount -o bind /dev /mnt/dev mount -o bind /proc /mnt/proc cp /proc/mounts /mnt/etc/mtab
Se donner les droits dans ce système avec la commande:
chroot /mnt
On peut alors lancer en une fois une série de commandes pour remettre le système d'aplomb:
sudo dpkg --configure -a && sudo apt-get clean && sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get -f install
L'opération a pris un certain temps. Après redémarrage, il a été possible d'ouvrir une session et de sauvegarder les données (à faire avant toute autre chose!). Malheureusement, les mises à jour, la réparation des paquets cassés, le ré-enclenchement de certains ppa (désactivés pour la migration) et d'autres choses ne fonctionnaient pas du tout. J'ai donc réinstallé un système propre et le client va devoir réinstaller les logiciels qu'il avait précédemment installés sous Ubuntu 16.04 et récupérer les fichiers, dossiers (y compris cachés) sauvegardés sur le gros disque dur de 500 GB. C'est probablement plus rapide que de chercher à régler les problèmes les uns après les autres...
Hors ligne
Bonjour,
Bravo pour ce post. Ca c'est du grand art et une bonne information.
Avec mes remerciements.
JBGruring
Hors ligne
Complément d'information...
En testant la procédure ci-dessus sur une W670SZQ1 qui ne parvenait plus à démarrer et se bloquait sur un message:
ubuntu 18.04 starting hold until boot process finishes up
j'ai pu identifier l'origine du problème: un SSD de 120 GB complètement plein (empêchant même de démarrer en recovery mode depuis le menu GRUB!). J'ai pu, en mode graphique sauvegarder 2-3 gros dossiers sur un HDD externe, les mettre à la corbeille sur le SSD du système défectueux, mais pas vider la corbeille (qui d'ailleurs ne s'affichait pas dans la fenêtre du navigateur de fichiers!). Probablement pour des questions de droits, la suppression doit se faire avec la commande rm (remove) une fois qu'on est allé avec le terminal sur le SSD monté comme indiqué ci-dessus. Bon à savoir.
Hors ligne
Bonjour,
Je suis em train de refaire l'opération de réparation du système Ubuntu (22.04?) sur un W670SZQ1, après avoir fait un
chroot /mnt
j'ai voulu lancer la commande groupée décrite à la fin, mais j'avais un message d'erreur
sudo: impossible d'allouer le pty: Aucun périphérique de ce type
Le même message apparaissait en faisant un simple:
sudo apt update
J'ai essayé sans mettre le sudo:
apt update
et tout a fonctionné normalement.
J'ai alors pu enchaîner les autres commandes usuelles sans sudo:
dpkg --configure -a apt update apt upgrade apt autoclean apt autoremove
Au final, j'avais toujours des messages d'erreur au démarrage. Heureusement, BootRepair a pu réparer le système et j'ai finalement pu sauvegarder les données sur un HDD avec DéjàDup, installer notre build Ubuntu 22.04 (UEFI, cette fois-ci), restaurer les données dans un fichier Sauvegarde du 23.09.2022 et, de là, déplacer les fichiers aux bons endroits pour éviter de réimporter des scories des versions Ubuntu 16.04, 18.04 et 20.04 (la machine a été achetée en 2015). Ce fut un peu plus compliqué pour Firefox et Thunderbird, mais tout est rentré dans l'ordre.
Hors ligne
Attention! Un disque NVMe ne se monte pas de la même manière qu'une disque SATA (voir https://swisslinux.org/forum/viewtopic.php?id=6383).
SOLUTION AU POST #8
Hors ligne
Bonjour,
Un client nous a confié son why! N240JU-PRO qui ne démarrait plus. L'option libérer de l'espace dans le Recovery mode ne réglait pas le problème. Le démarrage de Ubuntu 22.04 sur une clé live-USB a permis d'identifier le problème, à savoir un disque mSATA (et pas NVMe) de 120 GB plein, dont 70 GB dans le dossier Téléchargements (principalement des films). Il a été possible de copier ces données sur un disque externe, pour les restaurer par la suite.
Pour effacer ces 70 GB sur un SSD non-NVMe, la procédure décrite au post #2 a parfaitement fonctionné:
ubuntu@ubuntu:~$ sudo -s root@ubuntu:/home/ubuntu# mount /dev/sdb5 /mnt root@ubuntu:/home/ubuntu# mount -o bind /dev /mnt/dev root@ubuntu:/home/ubuntu# mount -o bind /proc /mnt/proc root@ubuntu:/home/ubuntu# cp /proc/mounts /mnt/etc/mtab cp: '/proc/mounts' and '/mnt/etc/mtab' are the same file root@ubuntu:/home/ubuntu# chroot /mnt root@ubuntu:/# ls bin dev lib libx32 mnt root snap sys var boot etc lib32 lost+found opt run srv tmp cdrom home lib64 media proc sbin swapfile usr root@ubuntu:/# cd /home root@ubuntu:/home# ls william root@ubuntu:/home# cd william root@ubuntu:/home/william# ls Public Bureau Documents Images snap Téléchargements Modèles Vidéos Musique root@ubuntu:/home/william# cd Téléchargements/ root@ubuntu:/home/william/Téléchargements# rm *
Pour un SSD M.2 NVMe voir SOLUTION AU POST #8
Cordialement.
Hors ligne
Bonjour,
Pour obtenir le même résultat sur un NVMe, il suffit de remplacer sdb5 par le nom du NVMe correspondant et le tour est joué.
Exemple:
ubuntu@ubuntu:~$ sudo -s root@ubuntu:/home/ubuntu# mount /dev/nvme0n1p2 /mnt root@ubuntu:/home/ubuntu# mount -o bind /dev /mnt/dev root@ubuntu:/home/ubuntu# mount -o bind /proc /mnt/proc root@ubuntu:/home/ubuntu# cp /proc/mounts /mnt/etc/mtab cp: '/proc/mounts' and '/mnt/etc/mtab' are the same file root@ubuntu:/home/ubuntu# chroot /mnt
Donc sdb5 devient nvme01p2.
Cordiales salutations.
Dernière modification par Doruk (18 Jun 2024 11:32:43)
Hors ligne
Voilà que je tombe à nouveau sur un os...
Le N240WU d'une cliente affiche le message d'erreur suivant:
Failed to start Network Manager
et ne va pas plus loin.
Après avoir lancé BootRepair pour tenter de réparer le système, j'ai encore fait toutes sortes de choses en recovery mode, en passant notamment des commandes trouvées sur le web en lien avec "Failed to start Network Manager". A chaque fois, sans succès.
Je me suis décidé à suivre le tuto ci-dessus à l'aide d'une clé bootable Ubuntu 24.04.1, sachant que le SSD qui contient le système est un nvme...
Malheureusement, impossible de lancer une mise à jour ou toute autre opération sur la partition de notre cliente. L'utilitaire de disque voit le SSD Samsung et indique qu'il est monté. Dans un terminal je vois tous les fichiers en allant dans son home avec la commande
cd /home(son_user_name
Mais je ne parviens pas à lancer une sauvegard sur un disque externe avec DéjàDup, car il est impossible de sélectionner cette partition. Je ne sais plus comment faire...
Alors je vais tenter encore une fois de réparer le système en recovery mode...
Hors ligne
Oh la la!
A tout hasard, j'ai tenté la même opération avec une live-USB Ubuntu 22.04.4 et cela a fonctionné comme décrit au post #8!
Malheureusement, les commandes de réparation n'aboutissent pas, exactement comme en recovery mode dans un terminal root!...
Je vais chercher encore un petit peu...
Hors ligne
Pour lancer avec DéjàDup une sauvegarde de la partition que l'on a montée sur /mnt, il faut aller avec le navigateur de fichier dans le répertoire /mnt et sélectionner le dossier home!
Hors ligne
Attention! Pour restaurer les données sauvegardées avec le DéjàDup de Ubuntu 22.04, il faut le faire avec la même version, autrement dit sur une machine avec Ubuntu 22.04.
Comme j'avais installer Ubuntu 24.04.1 sur la machine de notre cliente, je n'ai pas pu restaurer ses données et il m'a fallu réinstaller Ubuntu 22.04.4 pour y parvenir.
J'imagine que si on migre maintenant cette machines vers la 24.04 et que l'on fait une première sauvegarde avec DéjàDup, il sera possible d'y restaurer des données...
Cordialement.
Hors ligne