grub отображает «ошибка: каталог зашифрован» при загрузке
Сегодня (15 августа 2019 года) на моем Lubuntu 18.04 я установил обновления, предлагаемые менеджером обновлений. Установка завершена без видимых проблем, а затем он сказал, что компьютер должен быть перезагружен. После того, как я перезапустил ноутбук, он сразу же перешел в режим grub rescue:
error: directory is encrypted.
Entering rescue mode ...
Я никогда ничего не шифровал на своем ноутбуке и тоже не хочу ничего шифровать, просто хочу, чтобы он нормально запускался. Как я могу устранить эту проблему?
1 ответ
Я пишу это как ответ, поскольку мне нужно пространство..
Заключая в кавычки из TJ-(IRC #lubuntu-devel, https://launchpad.net / ~ tj)
EXT4_ENCRYPT_FLAG, по-видимому, установлен... настолько преднамеренный или повреждение
Лучше всего, чтобы узнать, существует ли отдельная/boot/файловая система или если/boot/является частью корневой файловой системы - потому что GRUB, по-видимому, пытается считать свой/boot/grub /* файлы и сбой
Я предложил бы начальную загрузку от LiveISO и сделал бы fsck первоначально плюс использование 'dumpe2fs-h...' на том блочном устройстве для захвата метаданных FS
'LiveISO' означал бы любые медиа установки Lubuntu/Ubuntu и выбирающий 'человечность попытки', затем fsck Ваш диск.
Хотя считано полная деталь ниже:-
<TJ-> ./grub-core/fs/ext2.c::grub_ext2_iterate_dir() ...
<TJ-> if (diro->inode.flags & grub_cpu_to_le32_compile_time (EXT4_ENCRYPT_FLAG))
<TJ-> {
<TJ-> grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "directory is encrypted");
<TJ-> return 0;
<TJ-> }
<TJ-> So, EXT4_ENCRYPT_FLAG is apparently set... so deliberate or corruption
<TJ-> Best to find out if there is a separate /boot/ file-system or if /boot/ is part of the root file-system - because GRUB is presumably trying to read its /boot/grub/* files and failing
<TJ-> I'd suggest boot from LiveISO and do an fsck initially plus use 'dumpe2fs -h ...' on that block device to grab the FS metadata
<TJ-> From what I can see this is per-directory not per-filesystem. There's a tool in e2fsprogs "e4crypt" but its man-page is quite opaque on how to use, but looks like this has to be done deliberately. If this is not corruption and is not done by the user then I'd suspect Malware or some malicious person with access to the PC
<TJ-> Unfortunately GRUB isn't telling us which directory is encrypted
<TJ-> Invstigate from a LiveISO for sure
<TJ-> This page is useful https://loune.net/2018/12/ext4-encryption-multiple-filesystems-and-salt/
<TJ-> apparently if there are some directories/files encrypted the superblock will contain:
<TJ-> # sudo dumpe2fs /dev/sdb2 | grep Salt
<TJ-> Encryption PW Salt: d24c7f08-5092-4b3a-9180-6ed8244513e8
<TJ-> So I'd think that'd appear in the '-h' superblock summary output I mentioned earlier
<TJ-> more interesting, the Arch wiki contains this "Note: Ext4 forbids encrypting the root (/) directory and will produce an error on kernel 4.13 and later"
<TJ-> So that would infer the encrypted directory isn't / but possibly /boot/ or /boot/grub/
<TJ-> and apparently it is an FS feature since you can do "tune2fs -O encrypt /dev/device"
<TJ-> There's a tool in the archive for generic handling of this kernel-level file-system encryption, the package is "fscrypt" and it's a single GoLang binary. The package description suggests it handles PAM for user log-in to add the keys.
<guiverc> if the OP was correct in not having encryption; i doubt the fscrypt would help (it'll be corruption or user doesn't know their own system..)
<TJ-> Well, it would be an easy check to see if that package is installed
<TJ-> e2fsprogs will always be installed so we can't deduce usage of e4crypt from its presence, but if fscrypt is installed, we can
полное обсуждение может быть найдено, когда это появляется, - https://irclogs.ubuntu.com/2019/08/16/%23lubuntu-devel.txt; я только обеспечил части