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

Support
, ,
79

Watch for grub-related info in announcements posts, check the date of files under /boot/grub/…, do not update if you see grub / systemd / mkinitcpio / cryptsetup / lvm / %younamewhatelseyoufearbreakingof% and you know you have no time to fix it. Always works for me.

And yes: if you’re ready to update these packages, you’d better make a backup right before that.

1 Like
80

This change to cryptsetup might also affect this. currently trying to push a working version to testing and stable branches: these libraries are installed by systemd hook now · archlinux/svntogit-packages@1f0acab · GitHub

1 Like
81

If you don’t mind, what’s the ELI5 version of what this does? I’m not familiar enough with code to figure out what it does. :flushed:

83

If you are not sure about the incoming changes, you should search in the forum for upgrade guidelines or wait till people post if they encountered any troubles during the upgrade.

In my understanding grub-install is only necessary when grub (the bootloader code itself) was updated and is now incompatible with old generated configurations
(update-grub/grub-mkconfig → /boot/grub/grub.cfg) and therefore needs to be re-installed and re-configured.

Please correct me if I’m wrong…

It would be nice if pacman itself could detect if a re-installation of grub is necessary.
Due to [1] it is not completely clear to me if this could be done in the preparation phase of the update, or is even considerable due to its risk of ending in an unbootable state:

lenhuppe 2022-12-11 00:23:31
There is no pacman hook to reinstall and reconfigure grub because it can be configured many different ways.
You have the option of creating your own pacman hook to reinstall and reconfigure grub automagically.

References:

  1. [SOLVED] Is there always need to reinstall grub after update? / Pacman & Package Upgrade Issues / Arch Linux Forums
84

This bit me hard right when I started using Linux full time. Just over 2 years ago I think, I installed Manjaro as my daily. Ran it about a month before I hit a grub issue. Took me 2 or 3 days and a few years off my life to repair. Gotta lot of help here. :+1:t2:

85

I applied the 2023-04-06 update in which philm made changes to cryptsetup and systemd to fix the issue discussed in this thread, but unfortunately it didn’t fix the error and the nag screen persists.

For others going through this thread who also have the no such cryptodisk issue but can still boot, the solution reported as working most often seems to be the one described here or here, but running sudo grub-install does have some risks (also reported in the thread), so I’m going to find some time next week to back everything up before trying it and reporting back.

1 Like
86

Cross-posting as this topic seems to have more people, though technically not exactly the same thing (since my problem was having the message, but my computer did still boot). Hopefully that’s OK:

2 Likes
87

Thank you, @brn! That was what I needed - I tried first with the default menu entry only (can’t hurt to be careful) and worked as hoped for…

1 Like
88

Having same issue after recent system update.
I have the problem on two different machines now.

error: sparse file not allowed.
error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded.
452: out of range pointer: 0x95d67020

Aborted. Press any key to exit.
89

I’m not an expert and I did not follow this thread - but I sound that the cryptodisk module was not added to GRUB_PRELOAD_MODULES (see Can't boot LUKS encrypted install after 2023-03-31 stable update - #7 by philm)

Can you try to boot from a live usb stick + check if you can boot into your original OS? Can't boot LUKS encrypted install after 2023-03-31 stable update - #26 by Tobiwan

90

I followed the following steps:

The problem was not solved, the errors come, but after entering the passphrase for the second time, my system boots. I have to enter the passphrase two times for my system to boot. Very weird…

91

I had a similar problem (enter passphrase two times before booting). This was caused by bad RAM changing files on my filesystem (BTRFS). Can you verify that your system memory is working (for example with https://memtest.org/)?

92

Memory seems fine, Memtest shows no errors…

I am having the same issue on two machines and this started happening after the recent Manjaro System update, both machines are relatively new.

93

Maybe rebuilding the kernel could help? You can select an older kernel during boot and the remove + add the kernel in the graphical kernel overview.

94

I was using “6.1.22-1 LTS”, I installed “6.2.9-1” then rebooted using that, I then uninstalled “6.1.22-1 LTS”, rebooted, reinstalled “6.1.22-1 LTS”, rebooted then uninstalled “6.2.9-1”. Now I am running on “6.1.22-1 LTS” again :slight_smile:

After each reboot the errors were showing and I had to enter the passphrase two times for the system to boot :slight_smile:

95

I just did a fresh Virtualbox VM with 22.0.5 as base and updated to today’s stable update of 2023-04-11. The install used the automatic install mode with LUKS encryption using a normal password.

Boot process:

Now I’ve to see what changed and how to get that message away.

how I got rid of the nag screen

  • I had to reinstall grub via grub-install --force --target=i386-pc --recheck --boot-directory=/boot /dev/sda
  • then I ran update-grub to regenerate the menu

This got rid of the nag screen not finding the right partition.

Lets analyze the grub.cfg file of the old grub installed to MBR on this BIOS VM:

image

So it loads the needed modules. calls cryptomount -u and points to the right partitions.

After I also updated grub on MBR we got this menu entry for the same 6.1 kernel:

image

More or less it is the same entry as we had before. So the only change most likely made is on the binary files which got installed by the package update of grub package. Most similar on that issue, on which we reverted those modifications to call fwsetup: Arch Linux - News: Grub bootloader upgrade and configuration incompatibilities

Me and the dashes …

image
image1007×288 79.5 KB

Seems grub 2.06-r261 has the cryptomount -u cmd without the dashes and with 2.06-r456 those got added. So removing the dashes from the cmd “fixes” the issue. However, those changes are common and only get fixed when grub matches the binaries of the package and the version installed on MBR/EFI.

So what is the real issue now?

  • commit 3cf2e84 changes how UUIDs for cryptodisk got handled.
  • a user can now specify UUID strings with dashes, instead of having to remove
    dashes. This is backwards-compatibility preserving and also fixes a source
    of user confusion over the inconsistency with how UUIDs are specified
    between file system UUIDs and cryptomount UUIDs. Since cryptsetup, the
    reference implementation for LUKS, displays and generates UUIDs with dashes
    there has been additional confusion when using the UUID strings from
    cryptsetup as exact input into GRUB does not find the expected cryptodisk.
  • since we never update the corresponding MBR/EFI installation of grub, which needs to been called via grub-install and the parameters used to install grub the first time those changes in the binary files of the grub package won’t match the expectations the older grub may have from grub.cfg file. Hence it is a breaking change for older installations
  • Is Arch affected by this? Most likely yes when they updated their package to 2:2.06.r380.g151467888-1. But there people expect to know on how to fix issues with grub, especially when you use LUKS FDE.

What is the real fix?

Well Arch needs to fix on how it installs grub to begin with as upstream expects to have their binaries in sync with what the package installs on your hard drive and what is installed in your MBR/EFI.

Is there a workaround?

Sure, you can modify /usr/bin/update-grub by removing execand add the following line: sed -i -e '/cryptomount -u/ {s/-//g;s/ u/ -u/g}' /boot/grub/grub.cfg after the line which starts now with grub-mkconfig ...

How can I avoid all of that matter?

Simply put grub into the package ignore list as grub won’t get properly installed anyway.

What about security updates?

Well, you’re the admin of your machine. Update grub package and keep your MBR/EFI installation of grub in-sync

6 Likes
96

Confirm, reinstalling grub and then update-grub worked for me

97

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: https://gitlab.manjaro.org/packages/core/grub/-/commit/6eca32e6b0cf9cd948bf6718a19de704ebaae5f5

sudo pacman -U https://mirror.easyname.at/manjaro/pool/overlay/grub-2.06.r456.g65bc45963-6-x86_64.pkg.tar.zst

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.

2 Likes
98

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…

99

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

See Packages and Manjaro Features