Ubuntu с полным шифрованием диска - неверный пароль после обновления до 18.04

Несколько месяцев назад я установил полное шифрование диска во время установки Ubuntu 17.10. Теперь я решил обновить. Апгрейд прошел до конца без проблем. Однако после перезагрузки я не могу войти в мой зашифрованный диск.

Где может быть проблема? Я на 100% уверен, что нажимаю «правильные клавиши» на клавиатуре, но технически я не знаю, что пишу из-за символов «*» и, возможно, после обновления изменилась раскладка клавиатуры. Я использую некоторые символы, которые могут быть где-то еще на клавиатуре. Какой язык по умолчанию после обновления?

Кстати, я уже пробовал Caps-Lock, но все же не повезло.

Помощь будет по достоинству оценена. Я не фанат установки моей системы и всех резервных копий снова и снова.

— M_Ryan
источник

Вы пытались смонтировать диск с USB-ключа? Вы можете сделать это через графический интерфейс в приложении Drives.

— luisgonzalez

Спасибо за ответ. После нескольких неудачных попыток я попал в initramfs - так в командной строке. Здорово. Я проверил свою кодировку (все нормально), я проверил, есть ли какой-то набор ключей через $ cryptsetup luksDump. Поэтому я попытался добавить новую фразу-пароль в мой зашифрованный раздел: $ cryptsetup luksAddKey / dev / sdb1. Но я все еще получаю ошибку о неправильном пароле. Это безумие, я знаю на 100%, что этот пароль работал до обновления.

— M_Ryan

Итак ... Чтобы быть абсолютно уверенным, что это не опечатка, я загрузил live CD и потратил некоторое время, пробуя разные пароли с помощью: $ echo -n "blahblah" | cryptsetup luksAddKey / dev / sdaX Я знаю, что пишу правильный пароль, я даже тестировал те же клавиши клавиатуры, используя раскладку в Великобритании и США + в сочетании с caps-lock. Просто чтобы убедиться. Тем не менее "ключ не доступен с этой парольной фразой". cryptsetup luksDump / dev / sdaX показывает слот ключа 0 как включенный. Что ж, похоже, «что-то случилось» во время обновления Ubuntu 17.10 до 18.04, и мой раздел luks заблокирован. Что-нибудь подобное случилось с тобой?

— M_Ryan

Я обновился с 16.04 до 18.04, и у меня проблема, отличная от вашей. В моем случае это был раздел LUKS, который показывает другой тип ошибки.

— Луизгонзалес

Если ключей больше нет, чем раздел потерян, не так ли?

— Кристофер Перрен

Ответы:

Возникла та же проблема, когда я обновил Ubuntu с 17.10 до 18.04. После долгих испытаний я нашел решение своей проблемы. Я просто изменил раскладку клавиатуры в США и набрал свой пароль в моей нативной раскладке (azerty). Так что кажется, что приглашение cryptsetup теперь в моем нативном макете, а не в США. И мой пароль никогда не сохранялся в макете azerty, как я думал.

Надеюсь, что мое решение поможет вам, и извините за мой плохой английский.

— user825758
источник

Это было решением для меня. Пароль, введенный в cryptsetup (17.04), фактически находился в раскладке клавиатуры США, после обновления он переходит на родной язык; таким образом, теперь у вас есть различные клавиши для нажатия - например, если вы нажали «вы действительно ввели @ при вводе пароля, если вы нажали £, вы ввели #. Сопоставьте символы из нативного макета с соответствующими символами США».

— Vix

Тоже самое. Моя фраза, которую я ввел во время установки и всегда думал, что она была в макете sv_SE, кажется, что она всегда была в en_US. Следовательно, символы, которые находятся на разных ключах между en_US и sv_SE, должны были быть напечатаны там, где они были бы для sv_SE.

— Мгор

Я также потерял доступ к своему ноутбуку после обновления. Несмотря на то, что я использую американскую английскую раскладку, мой пароль не был принят при запуске, но я мог расшифровать диск из livecd. Я несколько раз менял пароль, используя только символы ASCII, и он никогда не работал, пока не попробовал пароль, состоящий исключительно из цифр! Это действительно раздражающая ошибка.

— Киселев

Похоже, что это вызвано ошибкой в 17.10, из-за которой макет всегда будет стандартным американским макетом при вводе пароля, даже если вы настроили макет на что-то другое.

Я использую Dvorak, поэтому при первоначальном вводе пароля для шифрования он был установлен на это. Только на самом деле это не Дворжак при наборе текста, а действительно стандартный американский макет.

Например, допустим, ваш пароль «привет». Вводя "привет" и предполагая, что Дворжак, когда макет действительно является стандартным американским макетом, выдает "jdpps". Вы предполагаете, что ваш пароль "привет", но он на самом деле хранится как "jdpps".

Вы никогда не замечаете этого, потому что, когда вам это подсказывают, это также стандартные США за кулисами, поэтому ввод вашего пароля "привет" в Dvorak выдает "jdpps" в реальности, и вы в.

Однако в 18.04 они, похоже, исправили ошибку. Так что теперь, когда вы набираете «привет» в Dvorak, это действительно «привет» и больше не соответствует вашему сохраненному паролю.

Чтобы вернуться обратно, вам просто нужно выяснить, что на самом деле было сохранено, посмотрев, что будет выводиться, если вы введете свой пароль в своем родном макете, в то время как фактический макет установлен на американский английский. Я сделал это и набрал этот пароль, и это сработало.

Надеюсь, это поможет кому-то еще, я боролся с этим в течение нескольких часов. Я бы сказал, что это действительно одна из самых совершенных ошибок, с которыми я когда-либо сталкивался.

— O.Powell
источник