Hoy he visto el mismo error en una computadora portátil con Ubuntu 15.10 que siempre mantuve actualizada pero que no había reiniciado durante un mes hasta que quería probar un núcleo actual (es decir, podría haber habido un cambio reciente).
De todos modos, descubrí que en mi caso la causa subyacente era en realidad una partición de intercambio "perdida" debido a un error de configuración al seguir el tutorial anterior. Si este es el caso y / o si realmente lo está utilizando lvm, es posible que pueda omitir el paso 2 a continuación. Por supuesto, también puede ver el mensaje de error anterior en caso de que la partición de su sistema (o de datos secundarios) se haya dañado o no se pueda encontrar (consulte el paso 3).
Paso 1: monte su sistema, inicie las particiones siguiendo el tutorial mencionado anteriormente
Digamos que su partición de arranque (ext2) es / dev / sdX1, su partición de intercambio (encriptada) es / dev / sdX2, su partición de datos (encriptada) es / dev / sdX3 y ha descifrado con éxito la última utilizando cryptsetup luksOpen /dev/sdX3 data, seguido de montaje que: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.
Preste atención a los montajes de enlace en el tutorial y asegúrese de montar / dev / sdX1 para que pueda acceder desde el directorio / boot de la partición de su sistema (esto es crucial ya que tenemos que ejecutarlo update-initramfs).
A continuación, asumimos que ha ejecutado con éxito chroot /tmp/data/@ubuntu1510(o como se llame la partición de su sistema montado)
Paso 2: deshazte del mensaje de error anterior
Estoy usando btrfs (como habrás adivinado por el nombre de subvolumen mencionado), por lo que lvmetad se puede deshabilitar fácilmente de la siguiente manera sin pérdida de funcionalidad:
- edite /etc/lvm/lvm.conf y cambie
use_lvmetad=1ause_lvmetad=0
- ejecutar
update-initramfs -k $(uname -r) -u ; sync
Ahora, puede reiniciar y el mensaje de error debería desaparecer. Sin embargo, en mi caso, el siguiente mensaje de error [1] me señaló el problema subyacente mencionado anteriormente, así que mientras estamos en eso, ...
Paso 3: asegúrese de que / etc / crypttab apunte a las particiones correctas y sin daños
Primero, ejecute sfdisk --list /dev/sdXy verifique que su partición de intercambio encriptada (en mi caso, / dev / sdX2) en realidad no se muestre como una partición de intercambio (normal). Si lo hizo (como en mi caso), esto significó que el arranque, por ejemplo, usando un disco de rescate probablemente usará esa partición de intercambio disponible, sobrescribiendo así sus metadatos relacionados con cryptsetup (frase clave y UUID).
A continuación, eche un vistazo a / dev / disk / by-uuid y compare los UUID respectivos de sus particiones cifradas con los contenidos en / etc / crypttab. Mi suposición en este punto: en su caso, hay una falta de coincidencia.
Si la partición de intercambio cifrada dedicada no se encuentra en ninguna parte debajo de / dev / disk / by-uuid, es porque su sistema de rescate la está utilizando actualmente. En ese caso, haga lo siguiente:
- asegúrese de dejar de usar la partición:
swapoff -a
- vuelva a formatearlo:
mkfs.ext2 /dev/sdX2(esto es crucial , especialmente cuando se usan particiones GPT [2], ya que deshace la falla que mencioné anteriormente. La causa probable de que la partición aparezca como tipo "swap" en la lista de sfdisk es que usted / yo usamos por error mkswap /dev/sdX2al configurar la partición al principio).
- siga el tutorial para cifrar la partición y establecer una frase de contraseña; luego, ábralo usando cryptsetup y vuelva a formatear correctamente la partición ahora descifrada (usando algo como
mkswap /dev/mapper/swap)
- asegúrese de que
sfdisk --list /dev/sdXno identificará la partición de intercambio como tal (en ese caso, repita los últimos pasos)
Ahora, vuelva a verificar que los UUID enumerados en / etc / crypttab estén en línea con lo que ve a continuación / dev / disk / by-uuid para sus respectivas particiones cifradas.
Nuevamente, para que los cambios sean permanentes, debe ejecutar update-initramfscomo se muestra arriba.
Si está satisfecho, asegúrese de que todo esté escrito en el disco y reinicie el sistema (no es necesario desmontar todo manualmente). Después, su problema debería desaparecer.
[1] tal vez no presté atención la primera vez o el primer mensaje de error "ocultó" el segundo; es decir, solo después de reiniciar (con use_lvmetad=0), se me presentó " Leer todos los volúmenes físicos. Esto puede llevar un tiempo ... " (repetido varias veces), seguido de " ¡ALERTA! / dev / disk / by-uuid / .. no existe ". (Cabe señalar que update-initramfstambién se quejó de una partición faltante).
[2] porque su tipo se deduce del análisis de su contenido y no se especifica en última instancia mediante un indicador / byte (es por eso que no hay una manera fácil de, por ejemplo, cambiar el tipo de sistema de archivos GPT usando [g]parted).