# Ubuntu – Grub displays “error:directory is encrypted” on boot

bootgrub2lubuntu

Today (15 Aug 2019), on my Lubuntu 18.04 I installed the updates offered by the update manager. The installation completed without apparent issues and then it said that the computer has to be restarted. After I restarted the laptop, it immediately entered grub rescue mode saying:

error: directory is encrypted.
Entering rescue mode ...


I never encrypted anything on my laptop and I also don't want to encrypt anything, just want it to start normally. How can I troubleshoot this problem?

• I'm writing this as an answer as I need the space..

Quoting from TJ- (IRC #lubuntu-devel, https://launchpad.net/~tj)

EXT4_ENCRYPT_FLAG is apparently set... so deliberate or corruption

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

I'd suggest boot from LiveISO and do an fsck initially plus use 'dumpe2fs -h ...' on that block device to grab the FS metadata

The 'LiveISO' would mean any Lubuntu/Ubuntu install media and selecting 'try ubuntu', then fsck your drive.

<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-> 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


the full discussion can be found when it appears, - https://irclogs.ubuntu.com/2019/08/16/%23lubuntu-devel.txt ; I've only provided parts