[RESOLU] Récupération d'un /home crypté après avoir altéré grub

Quenny · Le 29/05/2015, à 10:44

Bonjour!

J'ai manifestement fait une bêtise hier soir car mon PC ne veut plus redémarrer ce matin, et mes compétences ne me permettent pas de m'en sortir sans vous! Donc merci d'avance, car je suis vraiment coincé et dans l'urgence (je suis prof et j'ai des cours préparés sur ce PC que je dois donner cet après-midi).

Voici l'historique:
- Je suis sous Ubuntu 14.04 sur un PC portable LDLC, pas d'autre OS installé.
- Depuis quelques semaines, un message me signale que "Le disque /boot n'a presque plus d'espace disponible" - et en effet, j'étais arrivé à 0 octets. Je me renseigne, et je trouve sur ce forum des conseils, comme celui de supprimer manuellement les fichiers de noyau (est-ce le bon terme?) obsolètes. En regardant mon dossier boot, je constate que j'ai en effet une série de fichiers comprenant dans leur nom la référence "3.13.0-32" jusqu'à "3.13.0-52". Je vois que l'on conseille de garder la ou les deux dernières versions, par sécurité, et donc je suis très prudent et je supprime les versions "obsolètes" tout en gardant les trois dernières (49, 51 et 52, si ma mémoire est bonne).
- Ce matin, en voulant allumer mon ordinateur, on me propose de commencer avec Linux 3.13.0-46-generic, ou 39, 37, 36 ou 32 - soit toutes les versions que j'ai supprimées hier.

Alors, où est le problème? Pourquoi ne démarre-t-il pas avec les versions que j'ai conservées? Et comment puis-je réinstaller ce que j'ai supprimé, alors que je n'ai plus accès à rien, si ce n'est à ce message qui me dit que les fichiers manquent?

D'avance, merci pour vos réponses rapides - je suis dans la mouise!

Dernière modification par Quenny (Le 03/06/2015, à 01:01)

GhostSpirit · Le 29/05/2015, à 13:48

Salut,

tu as déplacer les ficher dans la corbeille ou supprimer ?
si tu les as simplement déplacer dans ta corbeille
lance ton ordinateur à partir d'un LiveCD
trouve le répertoire trash et recopie les fichiers là où il étais.
Autres solutions
réparer le boot avec bootrepair.

cqfd93 · Le 29/05/2015, à 14:29

Bonjour,

Pas certaine que récupérer des fichiers dans trash soit vraiment faisable et résolve le problème.

Quenny, pour tes cours de cet après-midi, tu peux y accéder par un liveUSB en espérant que tu en as un.

Comment as-tu supprimé ces anciens noyaux ? Avec une série de « rm... » ? Après ces suppressions, as-tu fait un « sudo apt-get upgrade » ?

J'imagine qu'avec tout ça, tu ne peux même pas lancer une session non graphique (avec ctrl-alt-F1) et je me demande même si ça serait possible de faire quelque chose en chroot. Espérons que des gens plus calés que moi vont passer ici !

Sciensous · Le 29/05/2015, à 15:01

rien n'est perdu, mais en effet il faut donner la procédure utilisée pour l'effacement.

As-tu fait un "sudo update-grub" après ?

Dernière modification par Sciensous (Le 29/05/2015, à 15:05)

Quenny · Le 29/05/2015, à 23:31

Merci déjà pour vos réponses! Quant à mes cours, j'ai improvisé; ce ne sera pas la première fois. :-)

Pour la procédure exacte, je ne peux que le faire de mémoire. J'ai lu le topic suivant : https://forum.ubuntu-fr.org/viewtopic.php?id=1299251 puis j'ai fait la manip proposée au post #8, soit :

sudo find / -name "*3.5.0-17*" -exec rm -i {} \;

en adaptant le "17" en 32, etc. jusque 46.

Et puis non, je n'ai pas fait de "sudo update-grub" après. (Que fait cette commande, exactement? Je suis parti de rien en arrivant sur Ubuntu et je découvre peu à peu: toute information m'intéresse.)

Est-ce assez précis?

Babdu89 · Le 30/05/2015, à 02:12

Bonjour.

Et puis non, je n'ai pas fait de "sudo update-grub" après. (Que fait cette commande, exactement? Je suis parti de rien en arrivant sur Ubuntu et je découvre peu à peu: toute information m'intéresse.)

Cette commande fait la mise à jour de Grub..
Il aurait fallu la faire après les suppressions des noyaux. Pour qu'il ne reste au menu grub, que ceux que tu avais décidé de garder.

- Ce matin, en voulant allumer mon ordinateur, on me propose de commencer avec Linux 3.13.0-46-generic, ou 39, 37, 36 ou 32 - soit toutes les versions que j'ai supprimées hier.

Si tu peux démarrer en mode recovery, tu vas arriver à une fenêtre avec des options, dans laquelle sera proposée la mise à jour de grub.

Essaye çà, si çà ne marche pas il faudra passer par un chroot en session live, ou utiliser Boot-Repair pour réinstaller grub.

@+. Babdu89 .

Quenny · Le 30/05/2015, à 02:52

Babdu89 a écrit :

Cette commande fait la mise à jour de Grub..
Il aurait fallu la faire après les suppressions des noyaux. Pour qu'il ne reste au menu grub, que ceux que tu avais décidé de garder.

Merci! En effet, c'était nécessaire. Il faudra que je pense à l'ajouter au post que j'avais consulté.

Quant au reste, je n'arrive pas redémarrer en recovery, donc je tente le LiveUSB. Là, je suis devant mon disque /boot (que j'ai monté sur /media/system, créé pour l'occasion) et voici son contenu:

ubuntu@ubuntu:~$ ls /media/system/boot
grub
ubuntu@ubuntu:~$ 
ubuntu@ubuntu:~$ ls /media/system
abi-3.13.0-51-generic     memtest86+.elf
abi-3.13.0-52-generic     memtest86+_multiboot.bin
boot                      proc
config-3.13.0-51-generic  run
config-3.13.0-52-generic  sys
dev                       System.map-3.13.0-51-generic
grub                      System.map-3.13.0-52-generic
lost+found                vmlinuz-3.13.0-51-generic
memtest86+.bin            vmlinuz-3.13.0-52-generic

Comment faire pour réinstaller les paquets manquants - ou mettre mon grub à jour?

A propos du grub, si je fais un update-grub, j'obtiens

sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of `/cow'.

Qu'est-ce qu'une vache vient faire ici?

Dernière modification par Quenny (Le 30/05/2015, à 02:57)

Quenny · Le 30/05/2015, à 03:04

Pour info complémentaire, voici mon boot-info: http://paste.ubuntu.com/11442622/

Dans cette situation, dois-je lancer le Boot-Repair?

Dernière modification par Quenny (Le 30/05/2015, à 03:07)

Quenny · Le 30/05/2015, à 03:19

Question complémentaire: Boot-Repair me recommande de faire un backup de mes données avant toute utilisation du logiciel. Or, comme mon disque dur est crypté et que je ne possède pas, en live, les permissions pour y accéder (décrypter oui, accéder au dossier home, non), je n'arrive pas à faire de backup des données sensibles puisque je n'y ai pas accès. Sont-elles à l'abri? (Mon dernier backup d'avant le plantage remonte un peu et je ne peux pas m'y fier entièrement) Et si non, comment faire pour changer les permissions?

Merci d'avance de répondre à mes questions de néophyte!

Babdu89 · Le 30/05/2015, à 09:26

Bonjour.

Aïe, aïe!!!.

Boot-repair ne peut pas prendre en charge les installations chiffrées.

Pour obtenir de l'aide de contributeurs qui connaissent ce type d'installation, je te conseille de mentionner dans ton titre, "....disque de Boot chiffré". Si çà peut faire avancer l'aide.

Désolé de ne pouvoir t'aider plus.

@+. Babdu989 .

Quenny · Le 30/05/2015, à 20:08

Non, pardon, je précise: mon disque dur n'est pas entièrement chiffré. Mon disque boot se trouve sur une partition non chiffrée (sda1) de mon disque dur. Mais c'est sur la partie chiffrée (sda5) que se trouvent les données que je ne veux pas perdre, d'où mon dernier post à propos du backup. A priori, boot-repair devrait donc pouvoir gérer la réparation de mon grub.
A moins que mon boot-info ne dise autre chose?
En tout cas, merci pour tes réponses, Babdu89!

Dernière modification par Quenny (Le 30/05/2015, à 20:09)

Rufus T. Firefly · Le 30/05/2015, à 20:28

Salut,

Je n'ai pas bien compris ce qui était chiffré et ce qui ne l'était pas.
As-tu accès par exemple à /usr/sbin de ton système installé ?

Dernière modification par Rufus T. Firefly (Le 30/05/2015, à 20:32)

Quenny · Le 30/05/2015, à 20:52

Oui, oui, j'y ai accès. Il est sur la partition cryptée, mais j'arrive à la décrypter, donc j'y ai accès.

En fait, j'ai
- une partition de 225Mb, non cryptée, sur laquelle se trouve mon disque boot: sda1
- une partition de 124Gb, cryptée mais que j'arrive à décrypter, sur laquelle se trouve l'essentiel de mon disque dur habituel: sda5.
----> sur cette partition, j'ai mon /home, qui m'appartient en temps normal, mais qui appartient à un "user #1000" quand j'essaie d'y accéder en live.
cf le boot-info, quelques posts plus haut.

Est-ce plus clair? Dois-je encore ajouter des infos?

Dernière modification par Quenny (Le 30/05/2015, à 20:53)

Rufus T. Firefly · Le 30/05/2015, à 20:57

1000 ce n'est pas un problème, c'est l'id du premier utilisateur crée, le suivant étant 1001, etc.
Si tu arrives à décrypter et à accéder à la partition sda5, qu'est-ce qui t'empêche de copier tes documents ailleurs ?
J'ai oublié de préciser, mais c'est peut-être utile pour un néophyte, en démarrant le gestionnaire de fichier en root (mode administrateur).
Genre :

sudo nautilus

Dernière modification par Rufus T. Firefly (Le 30/05/2015, à 21:13)

Quenny · Le 30/05/2015, à 22:34

Merci pour l'info! Je me demandais justement comment lancer Nautilus en root - et je n'avais pas pensé à ça (c'est pourtant logique).

Bon. Je devrais pouvoir sauver mes données, puisque j'ai changé le propriétaire de mon fichier /home. Cependant, je m'aperçois qu'il n'y a plus, dans mon répertoire /home, que deux fichiers: un "access-your-private-data.desktop" et un readme qui m'informe que cette partie du disque n'a pas été montée pour protéger mes données. Tant mieux! (C'est que c'est bien pensé, ces trucs-là... ;-) ) Mais alors, j'en reviens à ma question de base:

Puis-je, dans ces conditions, lancer un Boot-repair sur mon disque de 225Mb (celui est non crypté et qui contient mon répertoire /boot) sans craindre pour mes données situées sur l'autre disque (dont la partie sensible est démontée), ou le backup est-il tout de même plus prudent?

Je pose la question parce que faire un backup n'est pas si facile puisque le disque est démonté par sécurité et que lorsque je veux le remonter avec la commande "ecryptfs-mount-private" suggérée dans le readme, on me répond:

ERROR: Encrypted private directory is not setup properly

(Désolé pour les complications en chaine! :-s )

Bref: je lance boot-repair sans crainte, ou pas?

Dernière modification par Quenny (Le 30/05/2015, à 22:35)

Babdu89 · Le 30/05/2015, à 23:47

Bonsoir.

Bref: je lance boot-repair sans crainte, ou pas?

Si c'est pour ne rien faire d'autre que ce qui est dans le boot info que tu as posté, je pense que non. Çà ne sert a rien.

=================== Suggested repair
The default repair of the Boot-Repair utility would not act on the MBR.
Additional repair would be performed:  repair-filesystems

@+. Babdu89 .

Dernière modification par Babdu89 (Le 30/05/2015, à 23:55)

Rufus T. Firefly · Le 30/05/2015, à 23:57

Boot-repair ne sert strictement à rien : tu n'as plus de noyau installé !
Preuve ?
On voit ici qu'il manque les initrd.img-xxxx qui correspondent au vmlinuz (et autres abi, etc.)
On sait aussi qu'ils n'apparaissent pas dans le menu de grub.

La raison la plus probable de ce fait, c'est que lors des dernières mises à jour, il n'y avait pas assez de place sur /boot. A ça il y a 2 raisons, aussi, d'une part le cryptage qui oblige à créer une partition séparée et non cryptée pour /boot, et d'autre part la gestion calamiteuse des noyaux par ubuntu.

La seule solution, c'est de ré-installer un noyau correctement !

Sans cryptage, ça se fait très facilement. La tête et les jambes. On greffe un linux qui tourne en live par exemple (la tête), sur le linux du disque installé, qui ne tourne pas (les jambes). A partir de là, ce sont les jambes qui courent pour exécuter les commandes que l'on passe, par exemple apt-get install un noyau...

Si tu arrives à monter ta partition cryptée avec ecryptfs-mount-private, dont j'ignore complètement les propriétés, il se peut que l'opération précédente soit possible aussi.
Je te donne la recette classique, il faudra remplacer le premier mount par ta commande ecryptfs-mount-private avec les paramètres qu'il faut, éventuellement... Si ça veut bien...
Evidemment tu peux monter ailleurs que sur /mnt, il suffit d'adapter les commandes qui suivent...

sudo -i
mount /dev/sda5 /mnt <= le résultat est de retrouver le contenu de sda5 dans /mnt. A toi de voir pour y arriver...
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount -t proc /proc /mnt/proc
mount --bind /run /mnt/run
mount -t sysfs /sys /mnt/sys
chroot /mnt

Si ça n'a pas râlé, toutes les commandes vont s'exécuter, si elles s'exécutent, sur le disque dur.
Donc :

apt-get install linux-image... <= tu tapes tab pour compléter nom du paquet

Si tab ne fonctionne pas, je te laisse chercher le nom exact du paquet

Ensuite il faut mettre le menu de grub à jour

update-grub

Et sortir de chroot, puis redémarrer :

exit
sudo reboot

Dernière modification par Rufus T. Firefly (Le 31/05/2015, à 00:21)

Quenny · Le 31/05/2015, à 00:18

Déjà: Babdu et Rufus, merci pour votre patient suivi de mes problèmes.

Je vais décortiquer tout ça demain et essayer au calme; ce soir, il est un peu tard. J'essaierai aussi de comprendre ce que je fais, parce que toutes ces commandes me paraissent un peu obscures, je l'avoue! D'ailleurs, si quelqu'un a le temps de me détailler ce que fait exactement la procédure que Rufus me suggère, cela m'intéresserait au plus haut point! Sinon, je chercherai.

A demain pour la suite!

Babdu89 · Le 31/05/2015, à 00:38

Bonsoir.
Ton système de marche plus pour le moment.
Donc tu ne peux pas passer des commandes qui devraient agirent sur ton système en marche.

Pour le moment, tu ne peux que utiliser qu'une session live.
Les commandes que l'on passe depuis la session live, n'agissent que sur la session live, pas sur le système en pane.
Lorsque l'on fait un chroot.
En gros. Çà consiste à se positionner dans le système qui ne marche pas, comme si il fonctionnait. Les commandes auront le même effet sur le système en pane, que si elle étaient exécutées depuis ce système en fonctionnement.

Donc on prépare le chroot, on passe les commandes pour réparer, on démonte le chroot. Et on regarde si çà redémarre.

C'est aussi ce que font les scripts de Boot-Repair en session live, lorsqu'il veux bien faire le travail.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 31/05/2015, à 00:40)

Quenny · Le 31/05/2015, à 09:44

Bonjour!

Voici des nouvelles fraiches: j'ai réussi à faire les opérations décrites par Rufus jusqu'au "chroot /mnt", qui devient chez moi:

chroot /media/system

Réponse:

root@ubuntu:~# chroot /media/system
chroot: failed to run command ‘/bin/bash’: No such file or directory

J'ai lu (ici) que ce message pouvait arriver lorsque l'architecture du LiveCD (ou LiveUSB dans mon cas) était différente du système que l'on cherche à réparer. J'ai créé mon LiveUSB (sans réfléchir à cette donnée) à partir de l'image 64bits disponible par défaut sur la page de téléchargement - mais je ne sais plus si mon architecture initiale est en 32 ou 64bits (je crois 64, mais je n'en suis pas sûr à 100%). Comment puis-je le vérifier? Ou voyez-vous une autre cause à ce message d'erreur?

Quenny · Le 31/05/2015, à 09:50

Pour info :

ubuntu@ubuntu:~$ uname -m
x86_64

Donc... 64 bits à tous les coups, ou pas nécessairement?

Et dans ce cas, le message d'erreur ne viendrait pas de la différence d'architecture?

Dernière modification par Quenny (Le 31/05/2015, à 09:51)

Babdu89 · Le 31/05/2015, à 11:59

Bonjour.

Avec une session live en 64 bit tu peux réparer les 32 et 64 bit installés, normalement.
Avec une session 32 bit tu ne peux réparer que une installation en 32 bit.

Ton Ubuntu est installé en 64 bit, donc il faut une session live 64 bit pour réparer.

Remarque, si tu avais eu à utiliser Boot-Repair, tu te retrouves dans les mêmes conditions.
Une session live 32 bit ne répare pas une installation 64 bit, tu as un message d'erreur de Boot-Repair.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 31/05/2015, à 13:26)

Quenny · Le 31/05/2015, à 12:13

Ma session live est en 64 bits! (cf. #20) et mon installation Ubuntu aussi (c'est ce que tu sembles dire, et cela confirme ce que je pense) Donc je ne comprends toujours pas la raison du message d'erreur.

Une autre idée? :-)

Babdu89 · Le 31/05/2015, à 13:46

Stp. Pour aider à comprendre. Il semble que ce ne soit pas un souci d'architecture, mais de fichier et répertoire non trouvé.
Tu veux bien poster le retour des commandes de ;

sudo -i
à
chroot /mnt

Que l'on puisse voir ce qui se passe.

/media/system , c'est le contenu de ta partition /dev/sda1
Rufus a demandé de monter le partition /sda5 si j'ai bien suivi ...

@+. Babdu89 .

Dernière modification par Babdu89 (Le 31/05/2015, à 13:56)

Rufus T. Firefly · Le 31/05/2015, à 13:56

Merdre ! Cornegidouille !
J'ai oublié le montage de /boot ! C'est une partition à part !

sudo -i
mount /dev/sda5 /mnt <= le résultat est de retrouver le contenu de sda5 dans /mnt. A toi de voir pour y arriver...
mount /dev/sda1 /mnt/boot
... <= la suite comme avant

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 29/05/2015, à 10:44

[RESOLU] Récupération d'un /home crypté après avoir altéré grub

#2 Le 29/05/2015, à 13:48

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#3 Le 29/05/2015, à 14:29

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#4 Le 29/05/2015, à 15:01

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#5 Le 29/05/2015, à 23:31

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#6 Le 30/05/2015, à 02:12

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#7 Le 30/05/2015, à 02:52

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#8 Le 30/05/2015, à 03:04

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#9 Le 30/05/2015, à 03:19

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#10 Le 30/05/2015, à 09:26

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#11 Le 30/05/2015, à 20:08

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#12 Le 30/05/2015, à 20:28

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#13 Le 30/05/2015, à 20:52

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#14 Le 30/05/2015, à 20:57

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#15 Le 30/05/2015, à 22:34

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#16 Le 30/05/2015, à 23:47

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#17 Le 30/05/2015, à 23:57

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#18 Le 31/05/2015, à 00:18

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#19 Le 31/05/2015, à 00:38

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#20 Le 31/05/2015, à 09:44

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#21 Le 31/05/2015, à 09:50

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#22 Le 31/05/2015, à 11:59

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#23 Le 31/05/2015, à 12:13

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#24 Le 31/05/2015, à 13:46

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

#25 Le 31/05/2015, à 13:56

Re : [RESOLU] Récupération d'un /home crypté après avoir altéré grub

Pied de page des forums