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

I’ve added a workaround for the main issue we are facing here. This way grub doesn’t need to been updated on MBR/EFI. Simply a package update of the grub package is enough. update-grub script will handle the issue with the dashes: [pkg-upd] 2.06.r456.g65bc45963-6 (6eca32e6) · Commits · Packages / Core / grub · GitLab

sudo pacman -U

It would be good if people who already have updated via grub-install ... to 2.06-r456 on MBR/EFI to check if still all works.


Thank you, when will this package be available through the public repositories?
Currently I can only see version “2.06.r456.g65bc45963-4” through the package manager…

It’s been available in the unstable branch since Phil posted.

See Packages and Manjaro Features

I mean available in the stable branch :slight_smile:

When we’re sure that version actually fixes the problem and doesn’t break everyone’s system. :wink:

1 Like

Until the grub-update reaches the official repo, I managed to boot my fully encrypted Manjaro system using “Super Grub2 Disk Beta”

Steps I did:

Visit: Super Grub2 Disk Beta

Download supergrub2-classic-2.06s2-beta1-multiarch-CD.iso

Write the *.ISO file to a USB Stick using this command:
(edit [PathToSuperGrub2ISO] & [SDXXX])

sudo dd if=/home/...[PathToSuperGrub2ISO].../supergrub2-classic-2.06s2-beta1-multiarch-CD.iso of=/dev/[SDXXX] bs=4M status=progress && sync

From your BIOS boot menu select booting from the USB Stick.

From the “Super Grub2 Disk Beta” menu choose "Detect…"

After that choose your Manjaro partion…

That Super Grub2 Disk Beta might also not work as it is an older version which doesn’t has the dashes support. That got added in December 2022 to a more modern grub version which is not released. Those changes will be included in 2.08 version of grub. So people simply call the pacman cmd as I compiled grub against stable branch anyway. I simply didn’t upload it there yet …

1 Like

Please also have a look at:

I’m not affected, so I just skimmed over this long thread and am sorry, if this has been mentioned before:
If you get dropped into grub recovery console because cryptomount failed, you can execute it manually. For example, /boot is on the second partition of the first disk:
cryptomount (hd0,gpt2) or alternatively cryptomount -u <uuid>
it should ask for the pass again. Once that succeeds to unlock, execute:

insmod normal

should be all you need to get started. source

I installed the update, but I still need to enter the password twice and still getting the following error:

Installed Manjaro like 6 weeks ago.

Got hit by this issue after the 7gb update but only with the “click button to continue” thing. Since i rarely reboot i did not do anything in this thread but keeped a very close eye on it.

As of the update 15min ago the issue is fixed.

Instead of the warning i will now see the boot menu for 3 seconds and then Manjaro loads with no issues. I also updated to the 6.2 kernel in the process.

Dont get the crypt error msg anymore.

@boustanihani well. You may want to post the content of your /etc/fstab file and compare it with the cryptomount llines of your /boot/grub/grub.cfg file. If you have dashes in the grub.cfg file for the UUID remove them in all the lines you find the word cryptomount and save the file. That is what the updated /usr/bin/update-grub does. You can re-read my more lengthy posts, as I explained the issue in rich details. Only updating the grub packages won’t update the grub install on you MBR/EFI. So you have to call grub-install ... at some point to fix it properly.

Thank you Philip, I was able to solve two of the errors.

Removing the dashes in /boot/grub/grub.cfg and calling grub-install fixed the “no such cryptodisk found…” error.

In “/etc/default/grub” I changed:




This is how I fixed the “sparse file not allowed…” error.
Check: GRUB error: sparse file not allowed

Caution: Calling grub-mkconfig -o /boot/grub/grub.cfg regenerates the dashes in /boot/grub/grub.cfg

Now, I am only getting the “out of range pointer…” error , but after entering the password twice, the system boots correctly =>

452: out of range pointer: 0x95d6a020

Aborted. Press any key to exit.

nearly same thing ; since the “crypto bug” last day of march
I did several things but my computer was able to mount finaly (Sorry for my english language. Media items -screenshots- can’t be uploaded) :

Now at boot my PC prompts 2 times hd1, gpt2 UUID without dashes…

result :
sparse file not allowed…” error.
452: out of range pointer: 0x95d67020
Aborted. Press any key to exit

the third time, it prompts hd1,gpt2, UUID with dashes
and it’s OK

NB : no such a crypto disk message disappear with Philm command (sudo pacman etc Great Thanks to Philm !)

For information :

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=0118-AEE6                            /boot/efi      vfat    umask=0077 0 2
/dev/mapper/luks-bab359ae-44e6-42f6-89ec-7d25913c7c37 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

NB :

  • I dare not to delete dashes from cfg (because I get impression system is mounting when it prompts UUID with dashes)
  • I dare not make this change (I had seen before boustanihani post) because He still has to put 2 times the PW (me 3)




A post was split to a new topic: Error no such cryptodisk found

Yes, that is why you should use /usr/bin/update-grub script which removes the dashes again. Anyhow, if you installed it to your MBR/EFI your new grub install supports also the value with dashes.

Thanks Philip, I did this, just wondering why all those errors happened at once…

Do you have an idea what could be causing the “452 out of range pointer…” error?

You forgot the option where you use and test FDE+sboot because it’s not the 1990s any more :stuck_out_tongue:

But seeing that I can use a initramfs hook to accomplish FDE instead of grub there may be too many ways to skin that cat for testing…

I don’t know if this might help.
I have an older PC with an Intel i7-3770 CPU with the latest Manjaro using the LTS Kernel 6.1.49-1 an no bott problems.

I bought a modern Mini-PC with a Ryzen 7 4800U CPU and used Clonezilla to do (automatic) full disk cloning of my old SSD to a the new SSD.

When I try to boot the new PC, I get the "452: out of range pointer" error and I also need to enter my password twice…

I noticed I have two Boot Priorities in my Bios on my Manjaro SSD.
I switched to the other boot option, simply named “manjaro” (not UEFI).
This magically solved all issues, the “452: out of range pointer” error is gone, and I no longer need to enter the password twice.

Is it the non UEFI mode that solved the problem?

Below are some screenshots for my BIOS and my partition on the SSD.