☰

grub 在启动时显示“错误：目录已加密”

tag-icon • tag-icon boot grub2 lubuntu
grub 在启动时显示“错误：目录已加密”

今天（2019 年 8 月 15 日），我在 Lubuntu 18.04 上安装了更新管理器提供的更新。安装完成，没有出现明显问题，然后提示必须重新启动计算机。我重新启动笔记本电脑后，它立即进入 grub 救援模式，提示：

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 安装媒体并选择'尝试 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；我只提供了部分

相关内容