Can't boot LUKS encrypted install after 2023-03-31 stable update

Support
, ,
1

Running Manjaro on a 2022 model LG Gram 17.
I get as far as the LUKS password screen. I type the password, get the “SLOT 0 Opened” message, and then it shuts down and bounces back to the BIOS setup screen ?!?

Any ideas?
This started happening right after the big update.
I’m running Manjaro KDE, and after running the update through pacman, I couldn’t start any applications, even non-KDE ones, nor could I log in from the fb terminal, so I just force powered it off and back on, and now it’s not starting.

2

You may have an unfinished update, hence it won’t start properly. Since there was most likely a kernel update involved, post transactions to actually update the initramfs images might not have been executed as that process only starts at the end of all package installations.

Plasma, when customized, may flake out with newer updates. Having the update done in a TTY or non graphical environment might bring better results. Having the hard drive encrypted might complicate things even further. Here is a longer article on how to deal with luks. You can partly read this wiki article on how to gain access with the install media if some went wrong. Newer install medias will ship manjaro-rescue which might help also on this.

3

The same problem, with the exception that at the end of booting. I’ve GNOME

4

Same here after update
“error: no such cryptodisk found , perhaps a needed disk or cryptodisk module is not loaded.
Press any key to continue …”

Then the system freeze.

5

I believe I have the same problem.

Here is a bit more detail :
The update went fine, and was successfully completed.
I have 4 kernels intalled, 4.19, 5.4, 5.15 and 6.1
The first password input show the slot 0 opened as expected.
Grub starts normally, and I can select my OS and kernel
All 4 kernels yield the same error message : “error: no such cryptodisk found”

For 4.19 and 5.4, pressing a key goes to a kernel panic screen :

initramfs unpacking failed: junk in compressed archive
kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)

initramfs unpacking failed: invalid magic at start of compressed
kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)

for 4.19 and 5.4, respectively.
For 5.15 and 6.1, the OS then successfully boots.

Running 5.15, I checked dmesg and journalctl for an error, but the initial cryptodisk error is nowhere to be found.
I found, however, this message :

[ 0.059108] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64 root=UUID=b0796842-2403-4e3a-b3b6-7cd0d7151b78 rw i915.enable_guc=2 quiet cryptdevice=UUID=814f0e15-209c-49d8-a680-a4ede7e8aded:luks-814f0e15-209c-49d8-a680-a4ede7e8aded root=/dev/mapper/luks-814f0e15-209c-49d8-a680-a4ede7e8aded
[ 0.059219] Unknown kernel command line parameters “BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64 cryptdevice=UUID=814f0e15-209c-49d8-a680-a4ede7e8aded:luks-814f0e15-209c-49d8-a680-a4ede7e8aded”, will be passed to user space.

This was not present in my previous boot before the update (however, these were on 5.4)

Remediation steps :
From the booted 5.15 :

mkinitcpio -P

No changes

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg

This has in fact removed the first cryptodisk error for all 4 kernels. 5.4 and 4.19 are still crashing with the same kernel panic.

mkinitcpio -P

No changes

uninstalling and reinstalling 5.4 from the manjaro-settings kernel application

No changes

EDIT : Solution for this particular problem (kernel panic with older kernels) :

2 Likes
6

Same problem for me, but at least I was able to boot after the error: no such cryptodisk found.
Reinstalling grub modules solved it, big thanks :+1:

see also:
https://bbs.archlinux.org/viewtopic.php?id=284011

1 Like
7

Well, there was also the grub update. pls check if it changed any settings on your end. At least you might need this in /etc/default/grub:

GRUB_PRELOAD_MODULES="cryptodisk part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
GRUB_ENABLE_CRYPTODISK=y
2 Likes
8

After today’s update and reboot I got the following message

error: no such cryptodisk found.
Press any key to continue...

but reboot continued and worked.

I found a solution that worked for me in the Unstable thread at [Unstable Update] 2023-02-17 - Plasma 5.27 LTS, GNOME, Python - #50 by Skunkie (THX @Skunkie)

1 Like
9

Just performed the following steps :

  • Uncommented GRUB_ENABLE_CRYPTODISK=y from /etc/default/grub
  • update-grub
  • mkinitpcio -P

No changes in the kernel panic for 5.4 and 4.19.

1 Like
10

Personally I don’t use luks and also don’t test it therefore. I only know we pushed the grub update on which I fixed some script to been able to load on older grub MBR installs. As I see it you have to check that all settings needed to load luks are given. Part of that might be the reinstall of grub into MBR. Check this post and see if you missed any step.

11

If you have

error: no such cryptodisk found , perhaps a needed disk or cryptodisk module is not loaded.

Don’t reinstall grub - it broke my system. I can’t boot anymore.

IMG_20230331_120618
IMG_20230331_1206181920×1440 69.9 KB

12

Had a small issue, after post-update reboot I ended up in a completely black screen. But launching applications worked fine, so the system was working but no wallpaper and no control panels. After deleting the ~/.cache folder and another reboot everything seems to work fine. :slight_smile:

13

@Tobiwan: you may check this post for your luks issue. I also have updated the troubleshoot guide.

14

I had similar error wihout the “module is not loaded” part

  1. I have my grub bootloader encrypted but not my volumes so thats what I did to solve that error:
    commented out /etc/default/grub:

…
#GRUB_ENABLE_CRYPTODISK=y
…

and then sudo update-grub. but now the default manjaro grub theme is not loaded weirdly enough, though it is enabled in /etc/default/grub.

  1. I also tried to clear /etc/crypttab file, because I dont have encrypted volumes and I remember this file to be empty in my case. Then I reenabled GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub and sudo update-grub. That did not help and that error: no such cryptodisk found reappeared and so did the manjaro grub theme :grinning:.

OS boots as usual after pressing any key though. No major errors in logs.

15

It derailed so fast so quickly (like in xkcd: Success)

Current problem: I read on Reddit that maybe an erroneous entry in /boot/efi or /boot/grub is causing the “out of range pointer”.

So I deleted (I intended to rename them but moved them both the same location :frowning: ) these folders. (I’m using only one partition for /, home and boot + I’m also using LUKS)

And now grub-install fails: grub-install: error: /boot/efi doesn’t look like an EFI partition. After 20min of googling I found no way to fix this.

Sadly the older BTRFS snapshot does not contain an valid efi.

What can I do?

This were my previous actions:

  • boot into live usb OS
  • cryptsetup luksOpen /dev/nvme0n1p2 my_encypted_device
  • mount -o subvol=@ /dev/mapper/my_encypted_device /mnt
  • manjaro-chroot /mnt /bin/bash
  • …
16

see this

and this

17

You need to mount your efi partition to /mnt/boot/efi

Can you show us lsblk -f

18

I was able to boot Manjaro:

  • boot from live usb stick
  • instead of selecting “boot with open source / proprietary drivers” (How to install and run Manjaro Linux - YouTube) I selected “detect EFI bootloaders”
  • there was two .efi files on the same disk. One called system+something and the other Manjaro+something. The system one was broken but the Manjaro one did work
19

@ stephane I will try this again after I backup some important data :smiley:

@Zesko This is lsblk -f from my now working OS

NAME                                          FSTYPE      FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                                                          
|-sda1                                        ntfs                       6230467F304659E5                                    
|-sda2                                        vfat        FAT32          E61E-3D10                                           
|-sda3                                                                                                                       
`-sda4                                        BitLocker   2                                                                  
sdb                                                                                                                          
|-sdb1                                                                                                                       
`-sdb2                                        ntfs              Volume   CAC2B439C2B42B97                                    
sdc                                                                                                                          
|-sdc1                                                                                                                       
`-sdc2                                                                                                                       
  `-veracrypt1                                ntfs                       3ED4C14CD4C1075D                      838.5G    85% /mnt/veracrypt1
sdd                                                                                                                          
|-sdd1                                        exfat       1.0   Ventoy   991D-3E9E                                           
`-sdd2                                        vfat        FAT16 VTOYEFI  B228-8EFB                                           
sr0                                                                                                                          
sr1                                                                                                                          
nvme0n1                                                                                                                      
|-nvme0n1p1                                   vfat        FAT32 NO_LABEL B253-C727                             298.7M     0% /boot/efi
|-nvme0n1p2                                   crypto_LUKS 1              205e4e87-163d-4dae-bd7c-3cda9971fa7f                
| `-luks-205e4e87-163d-4dae-bd7c-3cda9971fa7f btrfs                      e7d503ab-58a1-4148-bbc9-9dccf89b6a20  427.7G    76% /var/log
|                                                                                                                            /home
|                                                                                                                            /var/cache
|                                                                                                                            /
`-nvme0n1p3                                   crypto_LUKS 1              8b452496-c619-4399-b0f5-0e387d52567b                
  `-luks-8b452496-c619-4399-b0f5-0e387d52567b swap        1     swap     a038d7b2-6bad-495b-812e-9e3c33303bf3                [SWAP]

And you are right Zesko - /boot/efi is not an folder, it is the first partition of nvme0n1. I should have figured that out myself.

20

For you using Grub and Btrfs with encryption

$ cryptsetup luksOpen /dev/nvme0n1p2 my_encypted_device
$ mount /dev/mapper/my_encypted_device -o subvol=@       /mnt
$ mount /dev/nvme0n1p1 /mnt/boot/efi
$ mount /dev/mapper/my_encypted_device -o subvol=@log    /mnt/var/log
$ mount /dev/mapper/my_encypted_device -o subvol=@cache  /mnt/var/cache
$ mount /dev/mapper/my_encypted_device -o subvol=@home   /mnt/home
$ manjaro-chroot /mnt

Then follow:

4 Likes