Полное шифрование диска со сбоями lvm2 после обновления ядра

Я запускаю Ubuntu 12.04 с полным шифрованием диска.

Это было реализовано согласно руководству здесь:

http://57un.wordpress.com/2013/02/01/full-disk-encryption-using-ubuntu-in-most-secure-mode-with-aes-xts-plain64/

Это хорошо работало, пока ядро не было обновлено от 3.5.0-32-универсального до 3.5.0-34-универсального.

Теперь во время начальной загрузки, зашифрованный раздел не удается смонтироваться и заскакивает (initramfs) в подсказку со следующим.

Gave up waiting for root device.
...
ALERT! /dev/mapper/crypt does not exist. Dropping to a shell!

Система все еще загрузится хорошо, когда предыдущее ядро будет выбрано в GRUB.

Я понимаю, что процесс начальной загрузки требует, чтобы другой шаг или изображение позволили lvm2 смонтировать зашифрованный корень до начальной загрузки, но не уверен, где или как диагностировать и исправить проблему.

Я попытался создать новый initrd

    sudo update-initramfs -u
    update-initramfs: Generating /boot/initrd.img-3.5.0-34-generic

Извлечение из grub.cfg

Поврежденный:

menuentry 'Ubuntu, with Linux 3.5.0-34-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    gfxmode $linux_gfx_mode
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='(hd1,msdos1)'
    search --no-floppy --fs-uuid --set=root f4554fcf-eba8-4cb0-96ea-1427fff02328
    linux   /vmlinuz-3.5.0-34-generic root=/dev/mapper/crypt ro   quiet splash $vt_handoff
    initrd  /initrd.img-3.5.0-34-generic
}

Работы:

menuentry 'Ubuntu, with Linux 3.5.0-32-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    gfxmode $linux_gfx_mode
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='(hd1,msdos1)'
    search --no-floppy --fs-uuid --set=root f4554fcf-eba8-4cb0-96ea-1427fff02328
    linux   /vmlinuz-3.5.0-32-generic root=/dev/mapper/crypt ro   quiet splash $vt_handoff
    initrd  /initrd.img-3.5.0-32-generic
}

Какие-либо предложения?

Удачи

0
задан 18 June 2013 в 17:03

1 ответ

Я обнаружил, что пробелы в моем /etc/crypttab вызывали сбой вновь созданного initrd. Несмотря на то, что файл crypttab выглядел нормально.

Это было обнаружено после того, как я вернулся к работающему ядру, а также сломал его, когда создал новое initrd, используя:

sudo update-initramfs -u

Я удалил ненужные пробелы из / etc / crypttab и обновил И снова initramfs.

Все хорошо.

0
ответ дан 18 June 2013 в 17:03

Другие вопросы по тегам:

Похожие вопросы: