Ubuntu ne démarre pas à cause de lvmetad

Question

J'ai suivi ce tutoriel pour installer Ubuntu 15.10:

https://thesimplecomputer.info/full-disk-encryption-with-ubunt

Après avoir redémarré mon ordinateur, je suis arrivé au menu de base et j'ai choisi Ubuntu. Peu de temps après, j'ai eu cette erreur:

/run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

Ces messages s'ajoutent constamment sur un écran noir toutes les secondes. Au bout d’un moment, j’ai accès à la console initramfs ash.

qu'est-ce que je fais mal?

Markus Ueberall · Answer

J'ai constaté la même erreur aujourd'hui sur un ordinateur portable fonctionnant sous Ubuntu 15.10, que je tenais toujours à jour mais que je n'avais pas redémarré depuis un mois avant de vouloir tester un noyau actuel (c'est-à-dire qu'il pourrait y avoir eu une modification récente).

Quoi qu'il en soit, j'ai constaté que dans mon cas, la cause sous-jacente était en fait une partition d'échange "manquante" en raison d'un problème d'installation suite au tutoriel ci-dessus. Si tel est le cas et/ou que vous utilisez réellement lvmname__, vous pourrez peut-être ignorer l'étape 2 ci-dessous. Bien entendu, vous pouvez également voir le message d'erreur ci-dessus au cas où votre partition système (ou une donnée secondaire) serait endommagée ou introuvable (reportez-vous à l'étape 3).

Étape 1: Montez votre système, démarrez les partitions en suivant le tutoriel mentionné ci-dessus

Supposons que votre partition de démarrage (ext2) est/dev/sdX1, votre partition de swap (chiffrée) est/dev/sdX2, votre partition de données (chiffrée) est/dev/sdX3 et que vous avez correctement déchiffré cette dernière à l'aide de cryptsetup luksOpen /dev/sdX3 data, suivi de le monter: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Faites attention aux montages de liaisons dans le tutoriel et assurez-vous de monter/dev/sdX1 pour pouvoir y accéder depuis le répertoire/boot de votre partition système (ceci est crucial car nous devons exécuter update-initramfs).

Dans ce qui suit, nous supposons que vous avez exécuté avec succès chroot /tmp/data/@ubuntu1510 (ou le nom de votre partition système montée).

Étape 2: Supprimez le message d'erreur ci-dessus

J'utilise btrfs (comme vous l'avez peut-être deviné grâce au nom de sous-volume mentionné), donc lvmetad peut facilement être désactivé comme suit sans perte de fonctionnalité:

éditez /etc/lvm/lvm.conf et remplacez use_lvmetad=1 par use_lvmetad=0
exécuter update-initramfs -k $(uname -r) -u ; sync

Maintenant, vous pourriez redémarrer et le message d'erreur devrait disparaître. Cependant, dans mon cas, le message d'erreur suivant [1] m'a indiqué le problème sous-jacent mentionné ci-dessus, alors pendant que nous y sommes, .. .

Étape 3: Assurez-vous que/etc/crypttab pointe sur les partitions correctes et non endommagées

Tout d’abord, lancez sfdisk --list /dev/sdX et vérifiez que votre partition de swap chiffrée (dans mon cas,/dev/sdX2) n’a pas pas comme un échange (normal) cloison. Si tel était le cas (comme dans mon cas), cela signifiait que l’amorçage, par exemple, l’utilisation d’un disque de secours utiliserait probablement la partition swap disponible, écrasant ainsi les métadonnées associées à cryptsetup (keyphrase et UUID).

Ensuite, jetez un coup d'œil à/dev/disk/by-uuid et comparez les UUID respectifs de vos partitions chiffrées avec ceux contenus dans/etc/crypttab. Mon hypothèse à ce stade: dans votre cas, il y a un décalage.

Si la partition de swap chiffrée dédiée n’est nulle part sous/dev/disk/by-uuid, c’est qu’elle est actuellement utilisée par votre système de secours. Dans ce cas, procédez comme suit:

assurez-vous de ne plus utiliser la partition: swapoff -a
reformatez-le: mkfs.ext2 /dev/sdX2 (c’est crucial , en particulier lors de l’utilisation de partitions GPT [2], car cela annule le problème que j’ai déjà mentionné. La cause probable de la La partition apparaissant comme type "swap" dans la liste de sfdisk est que vous/j’ai utilisé par erreur mkswap /dev/sdX2 lors de la configuration de la partition au début.)
suivez le tutoriel pour chiffrer la partition et définir une phrase secrète; ensuite, ouvrez-le en utilisant cryptsetup et reformatez correctement la partition maintenant déchiffrée (en utilisant quelque chose comme mkswap /dev/mapper/swap)
assurez-vous que sfdisk --list /dev/sdX n'identifiera pas la partition de swap en tant que telle (dans ce cas, répétez les dernières étapes)

Maintenant, vérifiez à nouveau que les UUID répertoriés dans/etc/crypttab correspondent à ce que vous voyez sous/dev/disk/by-uuid pour vos partitions chiffrées respectives.

De nouveau, pour rendre les modifications permanentes, vous devez exécuter update-initramfs comme indiqué ci-dessus.

Si vous êtes satisfait, assurez-vous que tout est écrit sur le disque et redémarrez le système (inutile de tout démonter manuellement). Ensuite, votre problème devrait disparaître.

[1] Peut-être que je n'ai pas fait attention la première fois ou que le premier message d'erreur "masquait" le second; c'est-à-dire qu'après le redémarrage (avec use_lvmetad=0), on m'a présenté " Lecture de tous les volumes physiques. Cela peut prendre un certain temps ... " (répétition multiple fois), suivi de " ALERT!/dev/disk/by-uuid/... n'existe pas. ". (Il convient de noter que update-initramfs s'est également plaint d'une partition manquante.)

[2] parce que leur type est déduit de l’analyse de leur contenu et non pas spécifié par un indicateur/octet (c’est pourquoi il n’existe pas de moyen simple, par exemple, de modifier le type de système de fichiers GPT à l’aide de [g]parted.)

quagmire · Answer

Ubuntu 18.04.1 LTS ici. Il avait fonctionné sans surveillance pendant quelques mois, mais à mon retour, le clavier n’a pas été reconnu. Lorsque j'ai redémarré, j'ai reçu le message "Impossible de se connecter à lvmetad" et davantage d'informations sur le fait de ne pas pouvoir obtenir la "liste UEFI db".

J'avais installé sans chiffrement de disque.

Le message de l'UEFI était inquiétant car il s'agissait de ma première installation sur un ordinateur UEFI; je n'avais donc aucune expérience et je ne suis franchement pas informé quant à son utilité. Mon problème était aggravé par le fait que j'avais utilisé "lvm" sur ce qui allait devenir mon "/", racine, volume. (En fait, j'ai déjà oublié comment j'ai accompli CELA en premier lieu! Hé. Je suis vieux.)

Cependant, lorsque la machine ne redémarrait pas, j'ai cherché une solution et je n'ai rien trouvé de définitif, mais j'ai remarqué que a) ma partition EFI était plus petite que les 500 Mo recommandés sur un site et b) la partition/boot/séparée que j'avais arrangée. car était probablement hors de propos et inutilisé. Je pensais qu'il était possible qu'une mise à niveau sans surveillance ait peut-être causé quelque chose qui ait pu remplir son espace alloué.

J'ai décidé de réinstaller - ce qui a fonctionné et j'ai laissé la structure de mon/home/directory intacte. Je n'ai pas vérifié/etc /, mais j'ai déjà fait une copie des deux [1] pour que je puisse vérifier plus tard./etc/est vraiment petit.

J'ai également supprimé supprimé et combiné les partitions pour EFI et/boot/en une seule partition EFI plus grande (> 750 Mo).

Il redémarre maintenant, mais un seul message d'erreur clignote trop rapidement pour pouvoir être lu, et un "menu" de démarrage d'images Linux ne démarre pas, il démarre directement dans Ubuntu. Pour résoudre ce problème, il reste encore beaucoup à faire, avec grub. Mais au moins mes fichiers sont de retour.

[1] J'ai démarré l'installation Ubuntu à partir d'une clé USB et choisi "d'essayer" Ubuntu, ce qui m'a permis de faire des copies de etc et de la maison, avant de choisir "Installer" à partir du bureau.