J'ai vu la même erreur aujourd'hui sur un ordinateur portable exécutant Ubuntu 15.10 que j'ai toujours gardé à jour mais que je n'avais pas redémarré depuis un mois jusqu'à ce que je veuille tester un noyau actuel (c'est-à-dire qu'il pourrait y avoir eu un changement récent).
Quoi qu'il en soit, j'ai trouvé que dans mon cas, la cause sous-jacente était en fait une partition de swap "manquante" en raison d'un problème d'installation lors de la suite du tutoriel ci-dessus. Si tel est le cas et / ou si vous utilisez réellement lvm, vous pourrez peut-être ignorer l'étape 2 ci-dessous. Bien sûr, vous pouvez également voir le message d'erreur ci-dessus au cas où votre partition système (ou une donnée secondaire) a été endommagée ou introuvable (voir l'étape 3).
Étape 1: Montez votre système, démarrez les partitions en suivant le tutoriel susmentionné
Disons que votre partition de démarrage (ext2) est / dev / sdX1, votre partition de swap (cryptée) est / dev / sdX2, votre partition de données (cryptée) est / dev / sdX3 et vous avez réussi à décrypter cette dernière en utilisant cryptsetup luksOpen /dev/sdX3 data, suivie du montage il: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.
Faites attention aux montages de liaison dans le tutoriel et assurez-vous de monter / dev / sdX1 afin que vous puissiez y accéder depuis le répertoire / boot de votre partition système (ceci est crucial car nous devons l'exécuter update-initramfs).
Dans ce qui suit, nous supposons que vous avez exécuté avec succès chroot /tmp/data/@ubuntu1510(ou quel que soit le nom de votre partition système montée)
Étape 2: se débarrasser du message d'erreur ci-dessus
J'utilise btrfs (comme vous l'avez peut-être deviné à partir du nom de sous-volume mentionné), donc lvmetad peut facilement être désactivé comme suit sans perte de fonctionnalité:
- éditez /etc/lvm/lvm.conf et changez
use_lvmetad=1pouruse_lvmetad=0
- exécuter
update-initramfs -k $(uname -r) -u ; sync
Maintenant, vous pouvez redémarrer et le message d'erreur devrait disparaître. Cependant, dans mon cas, le message d'erreur suivant [1] m'a signalé le problème sous-jacent mentionné ci-dessus, alors pendant que nous y sommes, ...
Étape 3: assurez-vous que / etc / crypttab pointe vers les partitions correctes et non endommagées
Tout d'abord, exécutez sfdisk --list /dev/sdXet vérifiez que votre partition de swap chiffrée (dans mon cas, / dev / sdX2) n'apparaît pas réellement comme une partition de swap (normale). Si c'était le cas (comme dans mon cas), cela signifiait que le démarrage, par exemple en utilisant un disque de secours, utiliserait probablement cette partition de swap disponible, écrasant ainsi vos métadonnées liées à cryptsetup (phrase clé et UUID).
Ensuite, jetez un œil à / dev / disk / by-uuid et comparez les UUID respectifs de vos partitions chiffrées avec ceux contenus dans / etc / crypttab. Ma conjecture à ce stade: dans votre cas, il y a un décalage.
Si la partition d'échange cryptée dédiée est introuvable sous / dev / disk / by-uuid, c'est parce qu'elle est actuellement utilisée par votre système de secours. Dans ce cas, procédez comme suit:
- assurez-vous d'arrêter d'utiliser la partition:
swapoff -a
- reformatez-le:
mkfs.ext2 /dev/sdX2(ceci est crucial , en particulier lorsque vous utilisez des partitions GPT [2], car cela annule le problème que j'ai mentionné plus tôt. mkswap /dev/sdX2lors de la configuration de la partition au début.)
- suivez le didacticiel pour crypter 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/sdXn'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 ci-dessous / dev / disk / by-uuid pour vos partitions chiffrées respectives.
Encore une fois, pour rendre les modifications permanentes, vous devez exécuter update-initramfscomme indiqué ci-dessus.
Si vous êtes satisfait, assurez-vous que tout est écrit sur le disque et redémarrez le système (pas besoin de tout démonter manuellement). Ensuite, votre problème devrait avoir disparu.
[1] peut-être que je n'ai pas fait attention la première fois ou que le premier message d'erreur a "masqué" la seconde; c'est-à-dire qu'après le redémarrage (avec use_lvmetad=0), on m'a présenté " Lire tous les volumes physiques. Cela peut prendre un certain temps ... " (répété plusieurs fois), suivi de " ALERTE! / dev / disk / by-uuid / .. . n'existe pas. ". (Il convient de noter que update-initramfsse plaignait également d'une partition manquante.)
[2] car leur type est déduit de l'analyse de leur contenu et n'est finalement pas spécifié par un indicateur / octet (c'est pourquoi il n'y a pas de moyen facile, par exemple, de changer le type de système de fichiers GPT à l'aide [g]parted.)