Updated GRUB, can't boot into encrypted installation

So I wanted to change my GRUB theme and I updated it via this command:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Something tells me this is something I shouldn’t have done, because now upon boot, when I type in the passphrase to decrypt my LUKS installation, GRUB wouldn’t accept it and it would go to the rescue prompt:

20220210_232126

Right now, I don’t have access to another PC or an EndeavourOS live image, is there anything I can do?

sorry to see you can not boot… but the update of the grub.cfg itself should not have done that…
Could be you change something inside /etc/default/grub that was causing this?

The only change inside the cfg file I made was editing the GRUB_THEME to the directory of the theme I wanted. I did not touch anything else, at least I hope not.

I would undo whatever you did. I know very little about encryption as I’ve never really needed/cared to use it. . . As far as I know without password there’s not really much for options.

If you can get to the login screen you could tty and redo it and update grub again?

This is before the login screen though isn’t it? hmmm… . .

I’m def subscribing as I have no idea what to do in this scenario.

you can boot into a LiveISO and mount your encrypted partitions to arch-chroot into it still.

Filemanager can call decryption on mounting them or use cryptsetup open from commandline …

Just to be sure, you don’t have caps lock on?

It would help to list the contents of the files you altered, with the changes you made, but you’ll have to chroot into your system from a live environment to do that.

As @joekamprad suggested probably something to with your changes to /etc/default/grub.

From live environment …

sudo cryptsetup open [root-partition] root
sudo mount /dev/mapper/root /mnt
sudo arch-chroot /mnt

Once inside chroot shell …

sudo mount [efi-partition] /boot/efi

Diagnose issue, make necessary fix to /etc/default/grub (I assume), update grub.

Unmount efi partition and exit chroot.

Unmount root partition and close luks partition in live environment.

sudo cryptsetup close root

Reboot.

the output say that or not ? i would bet it is simply wrong password…

DE account logins can inform users caps lock is on, grub luks decrypt doesn’t.

Grub just spits out the same error messages if the password entered doesn’t match any luks slots, and falls through to the grub rescue shell.

2022-02-10-grub

1 Like

My passphrase consists entirely of numbers, so I don’t believe caps lock would’ve made a difference.

I’ve tried to to open cryptsetup from a live USB, but once again it does not accept the passphrase, just like in GRUB.

Here’s what I’m seeing:
20220211_130822

Are you using the numpad with numlock on?

Are you using a different keyboard layout than American English?

sudo cryptsetup luksDump [root-partition]

I used the numpad with numlock on when setting the passphrase. I entered it the same way, but no dice.

Language was default American English.

Also, the luksDump shows me this:
20220211_160233

Better to provide formatted text than screen capture images.

```
[text]
```

You have two luks slots, one for your password and one for a luks keyfile Calamares generates during install.

Don’t suppose you backed up the luks keyfile /crypto_kefile.bin ? This could be used to open the luks container, but without it your password is your only way in.

Usually this sort of issue is either keymap or keyboard related, a different keyboard layout using in installation and login, or a new usb keyboard.

What did you do exactly? A grub change would not stop you from opening a luks volume.

The thing is, is that I don’t know what i did that could’ve caused this issue. I was busy re-theming my system and I wanted to change the GRUB theme as well, which in the process I updated it. Upon reboot, it just wouldn’t recognize my passphrase when prompted to enter it, so naturally I assumed messing with GRUB caused it.

I did not make a backup of the keyfile directly, but is there a way to find out? There’s also system snapshots I made before this happened, could they be accessed somehow?

I assume you tried different combintations of numlock on & off and the top number row (ie not numpad).

Have you tried a different keyboard?

If using a USB keyboard on a laptop have you tried the laptop keyboard instead?

Lastly you are sure you haven’t mis-remembered your password?

Is your system a recent install, or have you been using it for a while?

I assume your snapshots are within the luks volume, so they are of no use if you cannot access them.

A pretty harsh reminder that the point of at rest encryption is to prevent access without the password; and that snapshots are not backups.

I suppose the luks headers could have corrupted.

Luks2 containers automatically have redundant “backup” headers in case of corruption, luks1 containers do not, so it is good practice to manually back them up using cryptsetup luksHeaderBackup.

Grub is not fully compatible with luks2 containers, which is why Calarmares still uses luks1 for encrypting root partitions.

This is why I backup the luks keyfile, luks header and file system within the root luks1 container on all my systems. Luks has been super reliable for me, but when it goes there is nothing you can do to get your system & data back. Its gawn.

With backups at least you can try to open with keyfile, or cryptsetup luksHeaderRestore corrupt luks headers, or if it dies completely just cryptsetup luksFormat --type luks1 the partition again and restore the backed up file system into it.

Sorry for my off-topic, uninformed interjection.

Was just curios to ask if LUKS partitions normally show as full, like in the picture from Gparted?

3ac4b4d9b98fa4d6344d6684a4ace77890a31125_2_690x388

And the biggest dunce of the month award goes to…me!

I have indeed misremembered the passphrase and can now boot just fine.

How the hell it went over my head just now is beyond me, maybe typing the standard root password when installing and updating stuff so often just made me think, that for some reason, it was also the decryption passphrase, that’s why it didn’t work.

I SINCERELY apologize for wasting your time.

1 Like

@BlueBogus

Is your system partition really that full as shown in the picture you had posted before?
Or encrypted partitions show like that in Gparted?

No, not even half full. This is probably because of encryption.

1 Like

Alright, thanks!
I just wondered. It made me think that if it was the case you would have other problems on your hand to solve.

LOL. Good news.

I’d still look into doing keyfile and luksHeader backups though at a minimum though, just in case, and develop a proper backup strategy.

As they are encrypted the contents cannot be determined, so gparted just shows it as full. If you decrypted it gparted could read the file system and determine usage.

1 Like