Partition Boot de Ubuntu 14.04 vide

tango-charly · Le 27/01/2016, à 21:25

Bonjour à tous et à toutes,

Il y a quelques jours, les mises à jour d'un nouveau kernel ne pouvait pas être fait car l'espace de la partition /boot était insuffisante.
J'ai donc supprimé les vieux kernels stockés. Cependant, comme un abruti, il semblerait que j'ai supprimé tout le contenu du dossier.
Lorsque Grub se lance au démarrage, il ne me propose plus mon disque dur sur lequel Ubuntu est installé, mais uniquement mes deux autres disques durs (Windows, et Mac OS).
Avec un Live CD d'Ubuntu, j'ai pu constater que le fichier /boot était vide. L'utilitaire Boot-repair n'a pas pu m'aider, car il semble chercher indéfiniment à réparer (chercher) des vieux kernels qui ne sont plus..

L'idée serait de récupérer un Kernel opérationnel avec ma version (Ubuntu 14.04) afin de pouvoir le copier dans le dossier, mais je ne vois pas vraiment où et comment je peux réaliser ces opérations.

Est-ce que vous avez des idées ?

Merci pour vos réactions, et votre lecture

Dernière modification par tango-charly (Le 27/01/2016, à 21:26)

malbo · Le 27/01/2016, à 21:41

Je te prie de faire un rapport Boot-Info et de donner l'URL de ce Boot-Info dans ta réponse à ce message.

tango-charly · Le 29/01/2016, à 04:02

Merci malbo,

Voici les prières exhaussées : Mon Boot-Info

nany · Le 29/01/2016, à 06:08

Bonjour,

tango-charly a écrit :

L'idée serait de récupérer un Kernel opérationnel avec ma version (Ubuntu 14.04) afin de pouvoir le copier dans le dossier, mais je ne vois pas vraiment où et comment je peux réaliser ces opérations.

C’est une idée qui me paraît séduisante. Mais, avant que j’indique la manière dont je procéderais, peux-tu me confirmer si j’ai bien compris que tu avais deux ordinateurs et qu’ils sont bien tout les deux avec la même version installée (14.04.X, ici le X a toute son importance). Si je me trompe, j’entrevois une autre voix qui peut s’avérer longue et fastidieuse. Donc, si tu as du temps à y consacrer, on peut tenter l’aventure, sinon il sera plus simple et plus rapide de réinstaller après récupération des données importantes. Si toutefois cette sauvegarde est possible car je vois que ton installation est en LVM. Elle ne me semble pas chiffrée car je vois dans le rapport Boot-Info que les données de mapper/ubuntu--vg-root/etc/grub.d/ et mapper/ubuntu--vg-root/etc/default/grub ont pu être analysées. En revanche cela me surprend de ne pas voir de détails de mapper/ubuntu--vg-root/etc/fstab. Sur ce point, peut-être que malbo (qui est l’ultra spécialiste de la lecture de rapports Boot-Info) pourra éclairer ma lanterne.
 
Sinon, au sujet du nettoyage des versions de noyau, tu as pu te rendre compte par doit même que trancher dans le vif à coup de rm dans /boot fut une très mauvaise idée. Et, outre le danger de vider /boot, ce n’est pas propre du tout car il reste des traces de ces anciennes versions sur le disque. Pour couronner le tout, tu as certainement exécuté un update-grub après ces suppressions dans /boot, ce qui explique l’absence d’entrée dans le menu de GRUB.
Donc, pour t’éviter à l’avenir tous ces désagréments, je te conseille vivement la lecture de la page de doc kernel. Le bug de l’autoremove y est signalé donc la méthode indiquée au chapitre 4.1 devrait suffire à condition de la pratiquer régulièrement (c’est à dire après chaque mise à jour du noyau). Seulement il existe entre autres un autre bug (rare mais qui existe tout de même) à propos de la conservation de deux versions. Donc, pour parfaire ta culture sur le sujet, je te conseille de lire aussi cet eXceLLent ( ) fil de discussion.

malbo · Le 29/01/2016, à 08:09

L'ultra-spécialiste malbo est effectivement surpris par cette ligne extraite du Boot-Info :

mapper/ubuntu--vg-root	: sda,	not-sepboot,	no-grubenv	grub2,	grub-pc ,	update-grub,	64,	no-boot,	is-os,	not--efi--part,	fstab-without-boot

La mention "fstab-without-boot" est anormale : on devrait trouver là "fstab-has-goodBOOT" (*). Moi, je pense qu'il faudrait tout réinstaller après récupération des données importantes comme le suggère nany.

(*) pour dire cela, je me suis référé à ce post qui me sert pour identifier les installations chiffrées et celles qui sont seulement LVM2

Dernière modification par malbo (Le 29/01/2016, à 08:16)

Bougron · Le 29/01/2016, à 12:18

Bonjour
La partition /boot n'ayant pas encore été réécrite, le logiciel EXTUNDELETE devrait faire le taff. A utiliser en live USB. https://doc.ubuntu-fr.org/extundelete

RECTIFICATION. Nany a rappelé avec raison que extundelete est basé sur l'existence d'un journal.

extundelete /dev/sda15 --restore-all
ERROR: The specified device does not have a journal file.	This program only undeletes files from file systems with journals.extundelete: Operation not permitted when trying to load filesystem parameters

Dernière modification par Bougron (Le 29/01/2016, à 17:40)

Rufus T. Firefly · Le 29/01/2016, à 13:34

Salut,

On ne peut pas tout simplement faire un petit chroot depuis un live, puis un dpkg -l | grep linux-image pour voir les noyaux "installés", en purger un parmi les récents, puis le réinstaller ?
Et une fois que ça fonctionne à nouveau, on termine tout ça proprement...
Parce qu'une ré-installation pour si peu... Un sudo rm à peine un peu brutal...

Je dis ça parce qu'un autoremove sur debian sid m'a proposé (il y a 2 ou 3 jours) de virer l'essentiel du serveur X et pratiquement que ça. Comme on entend beaucoup parler de wayland, et qu'on voit apparaître des choses à ce propos, je me suis dit, après tout... Et j'ai accepté. Un chroot depuis une jessie installée sur la même bécane a permis de ré-installer ça et c'était reparti...

Dernière modification par Rufus T. Firefly (Le 29/01/2016, à 13:48)

nany · Le 29/01/2016, à 14:50

Oui, j’ai moi aussi pensé au chroot mais, n’ayant jamais expérimenté LVM (je n’ai aucun ordi avec une batterie de disques), je ne sais pas faire. La piste d’extundelete est également intéressante. Et quelle que soit l’option choisie, il faudra songer à mettre une entrée de menu dans le GRUB et reconstruire le fstab (le plus grand mystère de cette histoire qui me fait penser qu’une réinstallation sera peut-être inévitable).

Bougron · Le 29/01/2016, à 15:12

malbo a écrit :

L'ultra-spécialiste malbo est effectivement surpris par cette ligne extraite du Boot-Info :
mapper/ubuntu--vg-root	: sda,	not-sepboot,	no-grubenv	grub2,	grub-pc ,	update-grub,	64,	no-boot,	is-os,	not--efi--part,	fstab-without-boot
La mention "fstab-without-boot" est anormale : on devrait trouver là "fstab-has-goodBOOT" (*). Moi, je pense qu'il faudrait tout réinstaller après récupération des données importantes comme le suggère nany.
(*) pour dire cela, je me suis référé à ce post qui me sert pour identifier les installations chiffrées et celles qui sont seulement LVM2

Il est possible que ce commentaire ne soit pas important au point de signaler que le boot ne peut pas fonctionner.
voir https://forum.ubuntu-fr.org/viewtopic.p … #p21433891

Restera alors à faire une épuration moins drastique

Dernière modification par Bougron (Le 29/01/2016, à 16:25)

Rufus T. Firefly · Le 29/01/2016, à 15:21

nany a écrit :

Oui, j’ai moi aussi pensé au chroot mais, n’ayant jamais expérimenté LVM (je n’ai aucun ordi avec une batterie de disques), je ne sais pas faire.

Moi non plus. Mais le problème se réduit, si j'ose dire, à monter / puis, certainement, /boot là-dessus. C'est forcément possible, puisque LVM fonctionne ! Et ça ne doit pas être très compliqué. Faudrait demander à tiramiseb qui doit bien savoir comment on fait ça...
Je vais chercher un peu...

Edit : j'ai trouvé ceci : https://memo-linux.com/comment-monter-u … ous-linux/
Ça me semble une bonne piste (2 commandes de plus qu'un chroot classique)... Chez Debian, c'est dans le paquet lvm2, qui est peut-être déjà installé sur la live ubuntu (puisqu'il propose du lvm par la suite)

Dernière modification par Rufus T. Firefly (Le 29/01/2016, à 16:17)

tango-charly · Le 29/01/2016, à 16:39

Merci à tous pour vos réponses.

Visiblement un problème, plusieurs solutions. C'est ce que j'aime en informatique.

Nany, effectivement, mes volumes sont en LVM et non cryptées car je pensais à l'époque faire un dual boot, et le redimensionnement de partition cryptées m'a posé des soucis dans le passé. Je pensais utiliser TrueCrypt, mais il n'est plus maintenu.
Effectivement, je n'aurai pas du procéder ainsi ^ ^. Il était tard, je ne savais plus ce que je faisais
https://forum.ubuntu-fr.org/img/fluxtoo … t_bold.png

Malbo, je pense que fstab without boot est dû, effectivement, à l'absence totale de fichier dans la partition /boot

Bourgon, très bonne solution, cependant, le paquet extundelete est indisponible avec ma version Live (Unable to locate package extundelete, j'ai également essayé avec la logitech), par contre elle est bien dispo sur mes autres machines Linux.
Je ne sais pas comment l'importer sur ma version Live (En fait j'ai trouvé, http://extundelete.sourceforge.net/ je cherchais à modifier mon source.list.d mais bon je peux le dl directement)

Rufus T.Firely effectivement, ceci semble être une bonne solution, je vais me renseigner sur les procédures pour chrooter depuis un live. Seul la partition /boot est défaillante LVM est encore opérationnel, j'ai accès à tous mes fichiers.

La piste de extundelete peut être une solution rapide et simple. Je vous tiens bien évidemment au courant de mes opérations.

Merci beaucoup pour votre participation à mon soucis ^ ^

Dernière modification par tango-charly (Le 29/01/2016, à 16:48)

nany · Le 29/01/2016, à 16:43

Rufus T. Firefly a écrit :

Ça me semble une bonne piste (2 commandes de plus qu'un chroot classique)...

La solution chroot m’apparaît alors la plus propre. Personnellement, puisque la dernière màj de noyau a échoué, je commencerais par tenter un upgrade ou un -f install qui devrait du coup mettre la dernière version (maintenant qu’il y a de la place dans /boot).
Resterait ensuite à voir ce problème de fstab.

Chez Debian, c'est dans le paquet lvm2, qui est peut-être déjà installé sur la live ubuntu (puisqu'il propose du lvm par la suite)

Oui, il me semble que c’est installé dans le Live. Au pire il faut juste l’installer pour pouvoir ensuite faire le chroot.

Rufus T. Firefly · Le 29/01/2016, à 17:08

Pour le chroot, une fois que tu as activé lvm et localisé tes volumes (/ et /boot) :

sudo -i
mount /dev/vol_racine /mnt
mount /dev/vol_boot /mnt/boot
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

A partir de là, tout ce que tu fais comme commande s'exécute dans ton linux à réparer...
Comme dit nany, on peut tenter :

apt-get upgrade

Selon ce qui se passe,

apt-get -f install

Si tout ça ne donne rien ou pas grand-chose, on peut faire la liste des noyaux en principe installés, purger le plus récent (donc compléter ta "désinstallation" à la hussarde) puis le ré-installer.

Edit :
1) en chroot, pas besoin de sudo...
2) tous les montages indiqués ne sont peut-être pas nécessaires pour ces opérations, mais ça ne mange pas de pain.

Dernière modification par Rufus T. Firefly (Le 29/01/2016, à 17:14)

nany · Le 29/01/2016, à 17:10

man extundelete a écrit :

extundelete is a utility that can recover deleted files from an ext3 or ext4 partition

Comme sda1 est en ext2, je pense que la piste d’extundelete peut être abandonnée.

Rufus T. Firefly · Le 29/01/2016, à 17:37

@nany

Cette histoire de fstab me surprend beaucoup. Hormis une action manuelle de notre ami, qui aurait bien pu effacer cette ligne ? Qui devait y être avant les ennuis !
A moins que... Et s'il n'y avait pas, en réalité de partition /boot séparée ?
Parce que si grub ne gère pas le chiffrement, il gère en revanche les volumes lvm. Il n'y a donc aucune raison de faire une partition /boot séparée. On en voit d'ailleurs une trace ici :

insmod part_msdos
insmod lvm
insmod ext2
set root='lvmid/0aqRjT-mHHE-HyAx-e2S4-N2LD-p4Bc-r6x7co/q86Pg4-gr74-a6Kh-708t-IqqC-2aob-WjGrKJ'

Et si c'était l'installeur ubuntu qui avait crée une partition /boot, inutilisée par la suite, puisque pas de cryptage ? Du coup ce serait normal qu'il n'y ait rien dans fstab !

Mais ça voudrait dire alors que la seconde ligne des montages du chroot serait peut-être désastreuse en tous cas inutile, à moins de vouloir à tous prix une partition /boot (avec tous les emm... que ça comporte, sans compter la modification à faire dans fstab).

Donc à tango-charly
Avant de faire le chroot, pourrais-tu monter /dev/sda1 et regarder ce qu'il y a dedans ? Est-ce compatible avec ton effacement de noyaux ou pas ?

Dernière modification par Rufus T. Firefly (Le 29/01/2016, à 17:46)

tango-charly · Le 30/01/2016, à 21:11

Merci,

Il y a plusieurs choses que je ne saisi pas, entre partition réelle et virtuelle...

J'ai débranché tous mes disques durs, car j'ai eu un soucis avec mon alimentation cet après midi.

Quand je n'avais plus que mon disque dur (Ubuntu 1To) et mon Live CD.
Voici ce que j'ai eu :

Après avoir rebranché tous mes disques durs, voici ce que j'obtiens :

Je ne comprends pas, j'ai un disque de 255Go et un autre de 999Go alors qu'il n'y qu'un disque dur de 1To... Est-ce que les 255g est un espace virtuel contenu dans le 1To réel ?

Rufus T. Firefly · Le 30/01/2016, à 21:16

255 Mo pas Go !
C'est ta partition sda1.
Si tu pouvais faire un

ls -l

pour qu'on voit ce qu'elle contient.

tango-charly · Le 30/01/2016, à 22:19

Voici le résultat de ls -l

ubuntu@ubuntu:/media/ubuntu/f8565c91-cde6-4b48-9d29-e517b5e28f71$ ls -l
total 539
drwxr-xr-x 6 root root   1024 Jan 26 16:48 boot-sav
drwxr-xr-x 5 root root   1024 Jan 24 23:49 grub
drwx------ 2 root root  12288 Feb  7  2015 lost+found
-rw-r--r-- 1 root root 176500 Mar 12  2014 memtest86+.bin
-rw-r--r-- 1 root root 178176 Mar 12  2014 memtest86+.elf
-rw-r--r-- 1 root root 178680 Mar 12  2014 memtest86+_multiboot.bin

Dernière modification par tango-charly (Le 30/01/2016, à 22:20)

nany · Le 30/01/2016, à 22:30

Le contenu de ta deuxième image, en somme. Peux-tu monter le volume de 991Go et y faire aussi un ls ainsi qu’un ls du répertoire boot s’il existe.

Sincèrement, je pense que tu peux faire ce que Rufus T. Firefly propose en #13.
Ensuite, dis-nous si tu as un message de problème de montage ou pas au démarrage.
Je pense qu’il faudra peut-être regarder ton fstab dans ton Ubuntu partiellement réparé.
Mais avant tout, pense à faire des sauvegardes car ça pourrait, malgré nos tentatives pour t’aider, se terminer par une réinstallation comme l’a suggéré malbo.

Dernière modification par nany (Le 30/01/2016, à 22:32)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 27/01/2016, à 21:25

Partition Boot de Ubuntu 14.04 vide

#2 Le 27/01/2016, à 21:41

Re : Partition Boot de Ubuntu 14.04 vide

#3 Le 29/01/2016, à 04:02

Re : Partition Boot de Ubuntu 14.04 vide

#4 Le 29/01/2016, à 06:08

Re : Partition Boot de Ubuntu 14.04 vide

#5 Le 29/01/2016, à 08:09

Re : Partition Boot de Ubuntu 14.04 vide

#6 Le 29/01/2016, à 12:18

Re : Partition Boot de Ubuntu 14.04 vide

#7 Le 29/01/2016, à 13:34

Re : Partition Boot de Ubuntu 14.04 vide

#8 Le 29/01/2016, à 14:50

Re : Partition Boot de Ubuntu 14.04 vide

#9 Le 29/01/2016, à 15:12

Re : Partition Boot de Ubuntu 14.04 vide

#10 Le 29/01/2016, à 15:21

Re : Partition Boot de Ubuntu 14.04 vide

#11 Le 29/01/2016, à 16:39

Re : Partition Boot de Ubuntu 14.04 vide

#12 Le 29/01/2016, à 16:43

Re : Partition Boot de Ubuntu 14.04 vide

#13 Le 29/01/2016, à 17:08

Re : Partition Boot de Ubuntu 14.04 vide

#14 Le 29/01/2016, à 17:10

Re : Partition Boot de Ubuntu 14.04 vide

#15 Le 29/01/2016, à 17:37

Re : Partition Boot de Ubuntu 14.04 vide

#16 Le 30/01/2016, à 21:11

Re : Partition Boot de Ubuntu 14.04 vide

#17 Le 30/01/2016, à 21:16

Re : Partition Boot de Ubuntu 14.04 vide

#18 Le 30/01/2016, à 22:19

Re : Partition Boot de Ubuntu 14.04 vide

#19 Le 30/01/2016, à 22:30

Re : Partition Boot de Ubuntu 14.04 vide

Pied de page des forums