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:
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.
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.
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.
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’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.