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