Как предотвратить катастрофическую потерю ключа шифрования диска ubuntu lvm?
В предыдущей установке ubuntu мой pv шифрования lvm больше не распознавался, и я потерял все это! Это произошло при установке с двойной загрузкой на MacBook Pro 2010, с тех пор, как я выполнил ремонт диска из Mac OS X и впоследствии сбросил коляску. Некоторое время я включал двойную загрузку в Ubuntu.
Однако недавно я решил попробовать еще раз и установил Ubuntu 15.04 на раздел MacBook Pro 2010 со следующей конфигурацией: точка монтирования шифрования раздела lvm в /, незашифрованная точка монтирования 1gig /boot.
Теперь он нормально загружается, хотя я работаю над настройкой зашифрованного раздела подкачки (я разместил его здесь: Добавление раздела подкачки после установки 15.04 ). Единственным заметным сбоем, по-видимому, является искаженный экран при загрузке, когда он должен запросить проход шифрования lvm, однако он отображается в виде скремблированной белой сетки. Однако здесь я могу ввести свой проход шифрования lvm, который перенаправляет меня на вход в Ubuntu, как обычно.
Моя главная проблема заключается в том, что, если я выполню восстановление диска из моего раздела osx или если мой ram будет сброшен, я потеряю ключ шифрования lvm и больше не смогу получить доступ к своему разделу ubuntu, как это было ранее при предыдущей установке. !
Есть предложения или идеи от сообщества?
1 ответ
AFAIK, сброс PRAM/NVRAM не должен влиять на ключ шифрования. Вы сказали, что сделали "восстановление диска из Mac OS X", и то действие могло бы вызвать проблемы, но это идет вне шифрования диска - при принуждении утилиты, которая не понимает LVM или файловые системы Linux для "восстанавливания" файловой системы Linux или Linux раздел LVM, результатом, вероятно, будет повреждение данных, используется ли шифрование. Шифрование сделает восстановление данных из такого события намного тяжелее, чтобы сделать, все же.
Обычно, я ожидал бы, что утилиты OS X не попытаются "восстановить" файловую систему Linux или раздел LVM, который они не понимают. Они могли бы сделать так, если Ваш раздел вводит код, является неправильным, все же. Разделы Linux должны иметь тип 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (никакой набор флага в последних версиях GParted или parted, введите код 8300 в gdisk). Существует связанный вопрос гибридного MBRs. IMO, лучше устанавливать Linux без гибридного MBR на Mac. Можно проверить эту деталь с gdisk:
$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.0
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Этот пример показывает негибридный MBR, как определено MBR: protective строка; гибридный MBR покажет MBR: hybrid вместо этого. Можно преобразовать от гибрида до защитного путем сохранения таблицы разделов в parted или GParted или при помощи n опция на gdiskэксперты' меню и затем сохранение изменения через w (то есть, x -> n -> w).
Знайте, тем не менее, что при использовании гибридного MBR можно загружать Ubuntu в режиме BIOS/CSM/legacy и удалять гибридный MBR, представит Mac, не могущий загружаться в том режиме. Это требует устанавливать загрузчик режима EFI. (Можно проверить режим начальной загрузки Ubuntu путем поиска названного каталога /sys/firmware/efi - если это присутствует, Вы загрузились в режиме EFI; если это отсутствует, Вы загрузились в режиме BIOS/CSM/legacy.) Кроме того, если Вы - тройная начальная загрузка с Windows, у Вас должен обычно быть гибридный MBR. Таким образом Вы не должны вслепую удалять гибридный MBR, если Вы присутствуете; вместо этого, необходимо сначала оценить, нуждаетесь ли Вы в нем и затем удаляете его, только если Вы не делаете или если у Вас есть план обновить Ваш загрузчик (загрузчики) соответственно.
Вне этого я соглашаюсь с user68186: необходимо создать резервную копию данных к внешнему диску или другим внешним медиа. Риски для потери данных идут далеко вне проблем шифрования и включают вещи как физическая потеря Вашего ноутбука, катастрофический отказ Вашего жесткого диска или SSD, случайного катастрофического неправильного употребления dd или другие дисковые утилиты, и так далее.