Cryptodisk access denied, entering grub rescue - any way to work around?

Support
1

Dear community,

My laptop running manjaro on an encrypted disk was freezing during some installation or software removal process related to android fastbooting. I suppose I was stupidly running a terminal and a software manager process at the same time, accidental. I waited for some time and, when still unchanged, forced shutdown.

Now, when booting and entering the passphrase, this shows up:

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

I use manjaro and encryption without greater knowledge of either, so I would like to get your suggestions on if there are any options I could try to access my encrypted disk, which I, spoiler, didn’t backup.

As far as I understood it could be a corrupted luks header, in which case I cannot do anything.

Or it could be that there is something wrong with GRUB.
Here I read that it’s possible to reinstall grub:

https://wiki.manjaro.org/index.php/GRUB/Restore_the_GRUB_Bootloader

I am unfamiliar with the process and do not have my original installation medium at hand.
Is there a way of reinstalling GRUB without one?

Any (other) steps which you recommend?

Two more info:

I unfortunately do not know my systems information by heart, saw this:

https://forum.manjaro.org/t/howto-reach-a-minimal-system/108687

but couldn’t get into grub.

And I am completely sure of the passphrase and triple checked the keyboard was on correct layout.

Appreciate your support!

2

Hi @ana_731 and welcome to the Manjaro forum.

If you cannot login to the system either directly or via TTY – Use the Terminal / TTY – then you will need an alternate method such as a bootable Manjaro installer, Live installer, or possibly the Super Grub2 Disk. The Restore the GRUB Bootloader link is the recommended guide to follow.

Regarding the major parts of your problem, I’m afraid I’m unable to assist (I never use encryption; deferring to a secure network environment, instead). I suggest you wait for better advice than the average forum user might give.

I’ll try to encourage some of that for you. @Yochanan .

Cheers.

1 Like
3

The workaround is to provide the correct decryption phrase.

Then you have a serious issue.

There is no workaround not being able to open your LUKS encrypted container.

But if the file system hosting the container is wrecked - ouch, that hurts.

if is is the file system hosting the container - you may be able to salvage the container.

Boot a live ISO and run fsck on the partition holding the container.

See comment #8

5

Thank you @soundofthunder and @linux-aarhus for your answers!

I followed @linux-aarhus suggestion and ran fsck from a live image. The output was just fsck from util-linux:

[manjaro@manjaro ~]$ sudo fsck /dev/sda1 5dfae470-60f9-8fec-7176483b2d9a
fsck from util-linux 2.39.3
[manjaro@manjaro ~]$

Do i need to specify the fsck command?

6

Hi @ana_731

The following links explain the usage of fsck. As you will find, the disk should first be unmounted before using fsck. Also, make sure you target your disk, and do not blindly copy/paste commands.

The /dev/sda that you might see in the examples may not be the same as your disk. Typical usage might be something like:

sudo umount /dev/sdXX
sudo fsck -a /dev/sdXX

Again, do not blindly copy/paste this.

7 
sudo fsck -f -y /dev/sda1

-f means forcecheck (so it scanns your drive and show you the result)
-y means instant yes prompt to all repair questions

I don’t think you need the additional UUID and best way to use fsck when you booted into a life environment from a Manjaro USB Bootstick to get sure no partition is mounted.

8

On a completely different note I realised that my suggestion on running fsck on the partition containing the encrypted volume is dangerously wrong.

Warning:

  • In any scenario, never use file system repair software such as fsck directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.
  • For the LUKS2 format:
    • GRUB’s support for LUKS2 is limited; see GRUB#Encrypted /boot for details. Use LUKS1 (cryptsetup luksFormat --type luks1) for partitions that GRUB will need to unlock.
    • The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the --pbkdf-memory option to control memory usage.[1]

– dm-crypt/Encrypting an entire system - ArchWiki

9

Can you try opening the encrypted device from a live USB?
Just open a file manager, then you should have the encrypted partition on the left side among others, click on it and you should get asked for a passphrase.
What happens when you enter the passphrase?

1 Like
10

Appreciate your support!

@eugen-b, when trying to open in the file manager of a live image, it says access denied because of incorrect passphrase. Same goes for
sudo cryptsetup open /dev/sda1 ....
As I said, I am sure of the passphrase and keyboard settings and trace this error back to the forced shutdown in the middle of running updates.

@Kobold , entered
sudo fsck -f -y /dev/sda1
it gives me again just:
fsck from until-linux 2.39.3

@linux-aarhus thanks for your consideration.
As I understand, if I cannot open the encrypted system, I shouldnt be using fsck, and I cannot open the encrypted volume - hence the circle closes.
Any other ideas of what I could try?
I went thru the article @linux-aarhus shared, but it’s just too sophisticated, requires a too high knowledge of how things work for me to follow.

11

Perhaps you/we started approaching this with wrong assumptions.
First be sure about the actual layout of your disk which contains the encrypted partitions.
It is possible that you or the installer created a LVM (a logical volume) - which then in turn contains the encrypted partitions.
Or the other way around - an encrypted partition which contains logical partitions.

To be able to assess and see what you have, the following commands (from a live system) can shed light on the actual situation:

sudo parted -l

lsblk -f

blkid

HTH

1 Like
12

Okay @Nachlese, so:

The output to sudo parted -l is:

[manjaro@manjaro ~]$ sudo parted -lModel: ATA WDC WD5000LPCX-2 (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type     File system  Flags
 1      1049kB  491GB  491GB   primary               boot
 2      491GB   500GB  8884MB  primary


Model: SanDisk Cruzer Blade (scsi)
Disk /dev/sdb: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 2      3759MB  3763MB  4194kB  primary               esp

The output to lsblk -f is:

NAME FSTYPE FSVER LABEL             UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0
     squash 4.0                                                                0   100% /run/miso/sfs/livefs
loop1
     squash 4.0                                                                0   100% /run/miso/sfs/mhwdfs
loop2
     squash 4.0                                                                0   100% /run/miso/sfs/desktopfs
loop3
     squash 4.0                                                                0   100% /run/miso/sfs/rootfs
sda                                                                                     
├─sda1
│    crypto 1                       5dfae470-60f9-4143-8fec-7176483d2b9a                
└─sda2
     crypto 1                       47208842-3210-4dd1-8242-656265271565                
sdb  iso966 Jolie MANJARO_XFCE_2310 2023-12-15-02-06-48-00                     0   100% /run/miso/bootmnt
├─sdb1
│    iso966 Jolie MANJARO_XFCE_2310 2023-12-15-02-06-48-00                              
└─sdb2
     vfat   FAT12 MISO_EFI          0C12-C5B6

And for sudo blkid:

/dev/loop1: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="MISO_EFI" LABEL="MISO_EFI" UUID="0C12-C5B6" BLOCK_SIZE="512" TYPE="vfat"
/dev/sdb1: BLOCK_SIZE="2048" UUID="2023-12-15-02-06-48-00" LABEL="MANJARO_XFCE_2310" TYPE="iso9660"
/dev/loop2: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/loop0: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/sda2: UUID="47208842-3210-4dd1-8242-656265271565" TYPE="crypto_LUKS" PARTUUID="82063129-02"
/dev/sda1: UUID="5dfae470-60f9-4143-8fec-7176483d2b9a" TYPE="crypto_LUKS" PARTUUID="82063129-01"
/dev/loop3: BLOCK_SIZE="262144" TYPE="squashfs"

What does that indicate?
Thank you

13

It indicates that you where on the right track all along,
that you have two encrypted partitions, /dev/sda1 vey likely being your file system and /dev/sda2 being encrypted swap
Since you already tried opening it from the live system with:

and it didn’t work - I have no ideas beyond that and what was said already.
Without a valid password or key file there is no way to decrypt the device to even access it and have the file system checked.
Sorry!

14

So to sum up:

As my passphrase won’t match anymore since I forced shutdown during an update process, I cannot unlock my encrypted system anymore. Without unlocking the encryption I shouldn’t run a file system check, which means I cannot try to fix the issue.

So no solution :slight_smile:

15

I can’t give you a solution for your problem, but a solution to evade your problems in future.

Buy a external secondary drive and backup your files.

Stay away from encrypted bootdrives, you won’t archive anything from that, your files are fully decrypted while Manjaro is running… so you only have protection when your Device is shutdown and Physically stolen.

Instead use Veracrypt and use containers or a fully encrypted partition… its much more hassle free and you also has protection against a possible hacker attack, because your files don’t need to be always decrypted while your device is running.

Im also suggest using timeshift, it can help alot and its quick and easy to use.

1 Like
16

Not quite correct.
It’s not that you shouldn’t, it rather is: you can’t.
Without unlocking the encryption, you can’t even get to the file system to have it checked.
The file system is inside the encrypted “container”.