LUKS device not recognized

[Nachordez]

After upgrade, the computer is unable to start for it doesn’t recognizes the luks device. Nor with the updated 6.5.5 kernel (same I was using) nor the 6.4-rt nor the 6.1 LTS.

Can’t give much more data right now, for I have to go to work, and for I can’t boot the system anymore… I had no time to try a failsafe boot, but I don’t really expect improvements…

And this is an extremely important failure, obviously. If I’m not the only one, the upgrade should be cancelled for safety reasons.

The only message (and hint) I get (same for every kernel installed) is:

ERROR: device ‘/dev/mapper/luks-95fc649b-53b3-blablabla’ not found. Skipping fsck.
mount: /new_root: no valid filesystem type specified
ERROR: failed to mount ‘/dev/mapper/luks-95blablabla’ on real root
You are now being dropped into an emergency shell.
sh: can’t access tty: job control turned off.
[rootfs ~]# _

I really need help…

Thx

Edit 2: There’s what I think can be a true hint for solution in post #12. Please, take a look there if you think you can help. Thanks in advance!

Edit 1: To make thing a bit more clear, so that is a very urgent problem…
I can go through the fist crypto question, just after boot. Says slot 0 open, so that works
Then Grub start and complains of not knowing about luks, and i arrive to an emergency shell.
Can’t do much from there, for there is no cryptsetup available in that shell . No way to mount the disk, so, nothing to do.
I can access from a live USB, and I can decrypt disk, that’s not the problem. But I rebuild both grub and initramfs, and everything stays the same. For each of the three kernels installed.
So, I would really help, for I read a lot of threads, but seems different.
If not, just reinstall from 0 system… that would be terrible, but at least I can access my disk from live usb…

[Zesko]

Did you have a backup before the update?

---

@Nachordez

I really need help…

Look at the similar issue:

Are concerns about GRUB breaking LUKS no longer an issue?

[Stable-Update-2023-03-31] Known issues and solutions 2023-03-31

GRUB: some backwards hardware compatibility has been restored

A modification has been reverted in order to restore support to old motherboards: <a href="https://forum.manjaro.org/t/unstable-update-2023-02-17-plasma-5-27-lts-gnome-python/134355/51" class="inline-onebox">[Unstable Update] 2023-02-17 - Plasma 5.27 LTS, GNOME, Python - #51 by philm</a>

GRUB, LUKS and full disk encryption: …

[Nachordez]

No backup (my fault, I know…)

But anyway, I cannot restore for I’m not able to boot system…
There was no pacnew nor pacsave files, so it should not be this kind of problem. But I’m confident that it’s something similar to the problem 31march, and that if I can boot system, will be easily fixable, perhaps downgrading grub or reconfiguring it. Or that I want to believe!

When at home again will try to boot from the rescue system is possible.

[Nachordez]

If I just try to mount from the emergency shell with

mount /dev/nvme0n1p2 or /dev/disk/by-uuid/95fcblablabla /new_root

It says

mount: /new_root: unknown filesystem type ‘crypto_LUKS’

And same if I try to especify -t ext4 or whatever, including crypto-LUKS

So, no way to advance.

I’ll try later to boot from a pendrive, to see what happens, for I can’t find way to boot with a y installed kernel. That’s the strangest part, for I could understand that the new kernel and init could be lacking luks support for any mistake, but why the other kernels?

Hope someone has any idea to continue, for I’m isolated now, no way to use computer (writing from phone, I’m sorry for possible mistakes)

[Teroh]

Are concerns about GRUB breaking LUKS no longer an issue?

Some time ago, when it was first proposed to move the updated grub package to Testing, then to Stable, there was concern about system breakage because grub needed to be re-installed manually. Is this no longer an issue?

Maybe something in here helps you. LUKS seems to have become an issue … yet again.

Esp. this might interessting :

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

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

I have not heard or read of the preload stuff before and am currently not using it. I just get the warning where you click any key and then boot normally.

[Zesko]

Do you have a bootable Manjaro ISO on a USB stick?

If yes, then:

1. Connect your USB stick to your computer and boot into Manjaro Live.
2. Run the command cryptsetup ... to decrypt your system.
3. Use manjaro-chroot to chroot to the broken system.
4. Edit GRUB config from /etc/default/grub to add GRUB_ENABLE_CRYPTODISK=y
5. Run update-grub, then reboot.

[Nachordez]

Do you have a bootable Manjaro ISO on a USB stick?

If yes, then:

Connect your USB stick to your computer and boot into Manjaro Live.
Run the command cryptsetup … to decrypt your system.
Use manjaro-chroot to chroot to the broken system.
Edit GRUB config from /etc/default/grub to add GRUB_ENABLE_CRYPTODISK=y
Run update-grub, then reboot.

Unfortunately, that’s not (or not only) the problem.

I’ve been doing some research with the USB booting. I can access the partitions, encryption is working fine from the pendrive (at least, it’s not corrupted, and data is there)

I’ve checked the /etc/default/grub, that could seem as the most probable problem.
But the GRUB_ENABLE_CRYPTODISK=y was activated there as always, as was the GRUB_PRELOAD_MODULES=“cryptodisk part_gpt part_msdos”. The only thing missing (never saw that recommended before) was the cryptodisk module option, but as was suggested by @Teroh , I included also that module, for if perhaps that could be the problem (never has been before, but could have changed?).

And I did the chroot and update grub, but the fail is exactly there as before in next boot.

There is a couple of questions, for if they can be a hint:
Manjaro-chroot -a doesn’t find the folder, It says that
grub-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map
I have to specify manjaro-chroot /run/media/manjaro/4d2d0eblablabla
I don’t think that should be a problem, for afterwards it seems to function properly, but anyway, there is that. /dev/sda1 is, obviously, in the pendrive.
And update-grub shows some errors when invoked.

sh-5.1# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-6.5-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.5-x86_64.img
Found initrd fallback image: /boot/initramfs-6.5-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.4-rt-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.4-rt-x86_64.img
Found initrd fallback image: /boot/initramfs-6.4-rt-x86_64-fallback.img
Found linux image: /boot/vmlinuz-6.1-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Root filesystem isn't btrfs
If you think an error has occurred, please file a bug report at "https://github.com/Antynea/grub-btrfs"
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

So, I’m not sure if it’s working as it should…

Anyway: the options in /etc/default/grub were correct yet before the failure, and the logical solution proposed is not working (am I doing something wrong?).

So, there has to be something more (or something not properly done in the steps proposed)

Thanks, anyway, of course!

PD: I’ve also tried the
mkinitcpio -P
but there is no change. It still stops at booting, complaining there’s no valid silesystem type specified, etc.

[1efaf7d71a8637c6800a]

Unsure why it says btrfs above.
Do you use ext4 or btrfs for your system partition/drive?
Can you roll back via Timeshift or so?
When was your install?
I remember when the LUKS-no-boot error (or for most, only the error message that could be dealt with by hitting any key) occured earlier this year, one had to sudo update-grub (also mkinitcpio -P ??) before.

Please go through the update support threads, maybe this was March-June, and it is mentioned at the top under known issues.

My thought, but others confirm please: You need to sudo update-grub and then do the update.

[Nachordez]

Don’t know about the BTRFS, it seems something from the usb stick (or an error from the upgrade?), for I don’t use it (I’m in ext4) nor had nothing installed.

I’ve read threads, I’ve done update grub, grib install, mkinitcpio, and inspected system as much as I can, but I cannot find anything defective, nor have any improvement.

Don’t have timeshift, for I lost the drive I used for that some time ago, and I didn’t replace it…

I’m a bit in despair, to be honest. Nearly 23 years using linux, and never had important failures that I could not fix myself in any distro I used, and this is the second one in a year with Manjaro. Such a beautiful distro and community, but it’s being really unstable for me…

I don’t really understand what has changed in the upgrade last upgrade yesterday. But so that it seems unable to mount my encrypted partitions, I cannot also access any journal or error logs… I completely lost at this point.

Any Idea is welcome…

[1efaf7d71a8637c6800a]

@superthug

There seems to be an issue with grub/btrfs in the latest update.
I just tried fresh install and after the first update without installing anything else
@ boot i get this error:
error: file “/@/boot/grub/x86_64-efi/bli.mod” was not found.
System boots fine after a few seconds.
I tried install on both encrypted drive and nonencrypted using btrfs. Same issue on both.
After boot running grub-install as root solves the issue

Ok but you said you reinstalled grub already.
I assume you can decrypt and mount your system disk from the live system?
Then you’d be able also to use
manjaro-chroot

and then you’ll be able to do any re-configuration. If so, you got all that is needed to configure your system to make it work.
Someone knowledgeable please step in here to help please…

[Nachordez]

Yes, I can access system from a live usb, decryption works fine so.
And I did the chroot, and reconfigured grub and even mkinicpio

No improvement. When booting from the system, it arrives the same point. There’s something more.

I’m just trying to analyze the dmesg from the emergency terminal that I arrive to. Searching for errors or warnings gives nothing unusual.

Filtering for luks just gove a couple of messages (sorry, just abbreviated version, I’m writing fron phone…)

Command line: BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64 root=UUID=4d2d0blablabla rw quiet cryptodevice=UUID=95fc6blablabla:luks-95fc6blablabla root=/dev/mapper/luks-95fc6blablabla apparmor=1 security=apparmor resume=/dev/mapper/luks-e4419blablabla udev.log_priority=3 ibt=off mem_sleep_default=deep

Kernel command line: (same as before)

Unknown kernel command line parameters "BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64 cryptdevice=UUID=95fc6blablabla:luks-95fc6blablabla" , will be passed to user space

I suspect this Last line is the question, kernel is not able to manage the luks system. But I cannot guess nothing from here, nor I’m sure about if any info is really there, more than a failure is happening.

I’m taking photos of the dmesg screens (16) to keep them just in case something from them can be needed

[Nachordez]

Important cue :
I’ve found what seems identical problem in an Arch user
https://bbs.archlinux.org/viewtopic.php?id=284931
Everything seems identical, and make sense.
It seems to be a hook that has changed in mkinicpio and makes unable to get encryption working, and even not getting cryptsetup in emergency shell (which would make a difference).
In this case is changing Plymouth-crypt hook to just crypt, or something like that. This kind of stupid undocumented changes that cam destroy your life till someone discover them
But I don’t use Plymouth, but something similar has to be happening, for it’s the most obvious reason, and makes sense.
I’m out of home right now, but will be there in some hours, probably, and will post my config file for mkinitcpio, for most probably there is it, some undocumented change in hooks (or similar).
If someone, in the meantime, has any idea for that, this would be helpful (and I’ll be grateful for life…)

Hope, at last!

That was it: just to add encrypt hook to the section in /etc/mkinitcpio.conf
Don’t know if something changed that during update, or was not needed with a previous version of mkniticpio, but it was absent, and was completely necessary to open luks on boot.

Solved!!!

Thanks anyone trying to help

[Nachlese]

Command line: BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64 root=UUID=4d2d0blablabla rw quiet cryptodevice=UUID=95fc6blablabla:luks-95fc6blablabla root=/dev/mapper/luks-95fc6blablabla apparmor=1 security=apparmor resume=/dev/mapper/luks-e4419blablabla udev.log_priority=3 ibt=off mem_sleep_default=deep

Kernel command line: (same as before)

Unknown kernel command line parameters "BOOT_IMAGE=/boot/vmlinuz-6.1-x86_64 cryptdevice=UUID=95fc6blablabla:luks-95fc6blablabla" , will be passed to user space

In the first line, it says "cryptodevice - which is definitely wrong
In the third line it says (correctly): “cryptdevice”

[Nachordez]

Don’t worry about that, I was writing from my phone, I just mistook.

But I found it (sooo stupid, as always), see previous post in a couple of minutes, I’m editing it (and writing from my laptop!!)