web-dev-qa-db-fra.com

"Lvmetad n'est pas encore actif, il utilise l'activation directe pendant sysinit" au démarrage?

Il y a quelque temps, j'ai installé Ubuntu 16.04 sur mon PC. Tout s'est bien passé et aucun problème jusqu'à présent. Lorsque la première mise à jour du noyau est sortie, je ne pouvais pas la démarrer et j'ai le message d'erreur suivant:

Lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
Cannot process volume group ubuntu-vg

Lorsque je récupérais l'ancien noyau dans le menu GRUB, tout allait bien et aucun problème. Après cela, une autre mise à jour du noyau est sortie et celle-ci n’a pas fonctionné. En gros, après avoir cliqué sur la nouvelle version du noyau, j'ai eu l'erreur et cela a été répété à l'écran encore et encore (sans fin ni testée au moins).

J'ai essayé ce qui suit sans aucun succès:

Ni travaillé. J'ai mon disque crypté car c'était une option lors de l'installation et j'ai pensé pourquoi pas? Je pense que quelque chose se passe avec cela bien que cela ressemble plus à un instinct que des preuves tangibles. J'ai cherché s'il était possible de désactiver le cryptage et c'était un travail fastidieux, alors j'ai en quelque sorte arrêté de le rechercher, mais si cela semble être la solution, je peux toujours l'essayer.

Donc, la version du noyau installé était 4.4.0-21-generic (comme affiché dans GRUB). Fonctionne bien pas de problèmes. Après cela, les noyaux installés étaient4.4.0-22-generic, 4.4.0-24-generic et 4.4.0-28-generic (comme dans GRUB). Les trois ne fonctionnent pas et donnent exactement la même erreur.

Pourquoi est-ce que je reçois l'erreur et comment puis-je la résoudre?

bootgrub2kernelencryption
2
user3892683

J'avais les mêmes messages d'erreur après avoir effectué une mise à niveau de version d'Ubuntu 14.04 LTS vers 16.04 LTS dans un chroot (chroot comme décrit dans cet article en allemand ) à partir d'un système en direct.

L'erreur s'est produite avant l'invite du mot de passe. Comme le groupe de volumes LVM est généralement dans du volume chiffré, il doit s'agir d'un problème de configuration dm_crypt/LUKS.

J'ai trouvé une solution ici et l'expliquerai ci-dessous.

Dans mon cas, le nom du mappeur du volume chiffré était différent de celui indiqué dans/etc/crypttab.

J'ai choisi le nom du mappeur luks dans la sortie de ls -l /dev/mapper, après avoir ouvert le périphérique chiffré avec le gestionnaire de fichiers graphique . Dans mon cas, la sortie était:

control
luks-87fc4c8e-017b-8482-cd09-7332fe351628
vgubuntu-root
vgubuntu-swap

Ensuite, en tant que root, j'ai changé mon fichier/etc/crypttab (veuillez noter le début de la ligne) de:

sda5_crypt UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

à:

luks-87fc4c8e-017b-8482-cd09-7332fe351628 UUID=87fc4c8e-017b-8482-cd09-7332fe351628 none luks,discard

Enfin, j'ai mis à jour mes initramfs:

update-initramfs -u -k all

C'était un peu déroutant que ces deux noms soient différents. On pourrait supposer que lorsque le mappeur est créé, son nom provient du crypttab. Quoi qu'il en soit, cela a fonctionné.

J'ai tout fait dans un chroot, en exécutant un système live. Cela pourrait également fonctionner à partir du shell busybox dans lequel vous vous retrouvez après le démarrage de votre système, mais je n'ai pas essayé.

2
casi