Encrypted install alongside Windows 10 fails to boot

Hardware / Version:

  • Lenovo T460s WQHD i7 (Quad-Core version)
  • 512GB SSD NVMe
  • Windows 10
  • endeavours-2021.04.17-x86_64.iso

Steps to reproduce:

  • Disable Secure Boot in BIOS
  • Install a fresh copy of Windows 10 (use whole drive, 512GB NVMe)
  • Install EndeavourOS (Online, with KDE) alongside Windows, Encryption checkbox active
  • Reboot, Enter grub password, wait… (about 30 seconds)

What should happen?

  • Decrypt and show boot menu (for Win or Lin)

What happens instead?
Error Message:

error: access denied.
error: no such cryptodisk found.
error: disk cryptouuid/e5....6a not found.
Entering rescue mode...
grub rescue>

So, what can I do?

  • Is your Windows encrypted?
  • Why did you install Windows on the entire drive if you also are installing Linux?

Check /etc/crypttab if everything checks out (UUID, specifically).

No, currently not, but I tried the encrypted variant (bitlocker), too. Same issue. Since I’m not a total beginner on Linux, I tried A LOT of things to be honest (5 or 6 complete reinstalls with different options). I did not find a way to get an encrypted EndeavourOS installation working alongside windows.

I tried to use only 200GB of 500GB for windows first to use the rest for Linux. Using “alongside” options then took half of the 200GB and left the rest unused without a possibility to change that easily.

Ok, I’ll try - I have to read some manuals first, how to do that in grub rescue mode.

I’m still wondering why the default process of installing fails on this. I did not try to perform an EndeavourOS Encrypted install without using windows, though. I’ll try that first and check if the problem persists without using it alongside windows (this would mean that there is some kind of problem with my hardware config).

Boot off the iso.

Then use cryptsetup to unlock your device. Something like this:

sudo cryptsetup open /dev/sda2 myluks

Replace /dev/sda2 with the correct device.

Then you should be able to mount the partition and explore it or chroot into it.

1 Like

Thx :slight_smile: I’ll try it today or tomorrow.

1 Like

Ok, after experimenting a bit I now know, what the problem is. The used password is specific to the keyboard layout (I’m from Germany). While the installer lets me chose “German” for the keyboard layout, the grub boot password prompt won’t. I don’t know, if this is a bug (I think so), if not, at least it is a Major UX issue.

  • The grub password prompt does not allow language specific input by default (and does not let me choose)
  • Entering a wrong password does not show a valid error message but directly leads to grub rescue
  • The password verification process takes forever on my system (regardless valid or invalid password)
  • Grub does not allow switching between windows and linux, but only shows Linux options (Windows can only be booted by the BIOS boot menu)
  • This might be a problem with Remote unlocking, which I usually use (https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/)

What would be the next steps? Is this a “feature request” or a “bug” and where can I add an issue?

It does sound like an issue that the team should be aware if they are not already. Maybe @joekamprad can weigh in?

It looks pretty valid to me.

error: access denied.
error: no such cryptodisk found.

It is telling you “access denied” immediately after your password entry. Next it is telling you it can’t access your encrypted disk.

If you were to put a stopwatch on “forever” what would it show? :wink:

It does take grub a few seconds to unlock and access a luks partition but without knowing how long you are actually talking about and what your hardware is like it is hard to say if what you are seeing is normal or not.

This is a separate issue and likely one of two things:

  • If you windows is installed legacy/bios and your linux is installed efi(or the reverse) grub won’t be able to detect them.
  • A recent grub update disabled the detection of other OSes by default so you may need to enable it. The solution for that can be found here.

Interesting. Does that work with the standard EndeavourOS encryption setup? Since EOS uses an encrypted /boot by default grub needs to unlock your encrypted disk before it can even load the initramfs. Does that require an unencrypted /boot or does it work as-is with the default setup?

Thank you for your detailed repsonse and quick help. I really appreciate it. I’m sorry for being imprecise, with this post I’m trying to fix that…

To be more precise: The message could be more user friendly and a RETRY option would definitely improve my personal user experience instead of opening grub rescue mode after one attempt.

26,48 seconds… precisely.

I’ll try to find more about this in the next days, thank you.

I’m not sure about this - I’m just trying to get away from Ubuntu and EndeavourOS looks very promising. I’ll find out.

Yes, I think so. Maybe this would not work then. You should think of providing this options, it works flawlessly and is awesome for server setups.

That is not normal unless your hardware is quite slow. For me it takes 3-5 seconds.

To be fair, I haven’t tested it, it is supposition based on my reading of the article you linked.

BTW: Here is a description of how to achieve this on an Arch-based distro:

The installer creates an encrypted /boot by default but it isn’t a requirement. If you use manual partitioning you can configure an unencrypted /boot if that turns out to be needed.

You can also change it after the fact but if it is a fresh install it is probably easier to re-install.

Yeah I know :slight_smile: That’s why I told you. It’s probably not a hardware issue (Lenovo T460s with NVME and 20GB RAM), other distros work like a charm - but I have not tested other Arch distros yet.

Would it help, if I provide you a Virtual Box image to reproduce the issues? Then I could try that.

The downside of using an encrypted /boot is that your partition gets unlocked more than once. grub unlocks so it can read and load the initramfs. Then your initramfs unlocks it again using a key.

If you switched to an unencrypted /boot, the unlocking process is different. Since that is your plan anyway, I would probably try that and see what changes.

In case you are wondering, “why is /boot encrypted if it slows the process down and adds complexity?”, the answer is that many people want their initrams encrypted to further obscure information about their system.

Just F.Y.I. I have an encrypted install with Windows 10 and have no issues. I have EOS installed on it’s own drive. If i was going to install Windows 10 on the same drive i would create the partition for windows sizing it for what i needed leaving the rest of the space i need for EOS as unallocated until Windows is installed. Then i would install EOS on the unallocated space. Just my 2 cents.

Possible. If you happened to let Windows take the whole space you can resize the partition in Windows itself afterwards as well.

I did hear that you should not let Linux do that, but I’m not certian if that’s still actual.

I have installed EOS more times than you want to know with Windows 10 and no issues. So there has to be an issue with the install configuration.

Not what I meant, should’ve been clearer. I meant that as far as I remember it it was usual advice to not let Linux resize the Win10-NTFS-partition, but do it in Windows before you install Linux.

I think the reason why is because Windows has those other partitions and if you move them sometimes it won’t boot. If you resize it in Windows it only resizes the partition that windows is actually installed on.

I do find that all too confusing. That’s why for my Win10-installation, I use a seperate, older SSD, with an own EFI that can be detected by os-prober. Works like a charm, and a small SSD is not that expensive.

I have EOS installed on a separate SSD also and Windows is on my m.2 drive.

I would love to have a Checkbox for that in the installer :slight_smile:

I would have been surprised, if there was a major issue with that in the stable release for everyone… but I would also love to help EndeavourOS to get better :slight_smile:

The problem was, that the default installer of EndeavourOS would not let me choose the “alongside” option without having to resize the main windows partition. Unfortunately 2 drives are not an option for me, since I have none :slight_smile:

Sure it is possible to do everything manually. But as I already stated, having a wizard is quicker and prevents non experienced users to make mistakes. I would like to suggest the following improvements to the installer:

  • An option to choose whether the bootloader should be encrypted (e.g. a Checkbox with short explanation)
  • A RETRY option for the password prompt of the encrypted drive (with and without bootloader)
  • An option to choose keyboard layout, or at least a warning, that it might cause trouble to use non US layouts with encrypted drives

If that is also to your liking, I would add a feature request. Where can I do that?