Non-boot VM image

Getting the following error when trying to boot VM EndeavourOS image after an update:

Starting systemd-edevd version 252.4-2-arch
mount: /openswap_keymount: no filesystem type specified.
Failed to open key file.
umount: can’t umount openswap_keymount: Invalid argument
ERROR: resume: no device specified for hibernation
mount: /new_root: can’t find UUID=4c30397d-8190-4f94-8106-561d0e916e65.
You are now being dropped into an emergency shell.

VM is an encrypted btrfs install with default partitions. I can chroot into the system from a live cd and have updated the system but continue to get same error.

As a newb to Linux and Arch based systems, have no clue where to troubleshoot from here. Any help is appreciated.

Are you sure you entered the password correctly?
Are you using SystemD to boot? Maybe post the content of /boot/loader/entries/arch.conf

It seems that the boot loader was unable to decrypt/unlock the root file system.

I am using the correct password as I have to use it to chroot into the image.

I honestly don’t know what SystemD is except what I see from a quick search, but I do see why you would ask from the output. I use grub, which then hands it over to systemd?

I don’t know where I would see the /arch.conf as when I chroot into the image that directory doesn’t exist. In /boot I have: efi grub initramfs-linux-fallback.img initramfs-linux.img intel-ucode.img and vmlinuz-linux.

Looking at the partition table:

vfat FAT32 NO_LABEL CCBE-8363

crypto 1 d38db100-afbc-4cd4-aac6-6f2c9f5fd3f1
btrfs 4c30397d-8190-4f94-8106-561d0e916e65

crypto 1 98451d76-8f43-4ac1-b8bd-1bae826d9d21

I only post this because I see the UUID for the system is the mount point that can’t be found but there is the crypto 1 on the same partition. Is this the /openswap_keymount ?

Sorry about the confusion. I was assuming you would not be using GRUB because the very terrible decision was made to abandon GRUB as a default. Despite GRUB being admittedly hard to configure right in certain scenarios – it is much worse now by introducing unmaintainable complexity that has a life of its own and will never give predictable results for anyone who is not a 100% Certified Red Hat Senior Professional Administrator.

From what you posted, the boot loader is expected to unlock

and the matching UUID is also there on sda2:
btrfs 4c30397d-8190-4f94-8106-561d0e916e65

  1. Maybe the Kernel option was not understood? Can you chroot into the image and post the output of
    grep GRUB_CMDLINE /etc/default/grub

For your system I would expect one of the lines to begin like this:
GRUB_CMDLINE_LINUX="cryptdevice=UUID=4c30397d-8190-4f94-8106-561d0e916e65:luks-sda2 root=/dev/mapper/luks-sda2 [...]"

  1. And also please check that the encrypt hook is still there:
    grep ^HOOKS /etc/mkinitcpio.conf

The output should include ‘encrypt’
HOOKS=(base udev autodetect modconf block keyboard keymap consolefont encrypt filesystems resume fsck)

Forgot to turn shared clipboard on so hand typing the responses but grub is wrong:

GRUB_CMDLINE_LINUX_Default=‘loglevel=3 quiet’

mkinitcpio.conf does include the encrypt hook.

I have tried reinstalling grub when the issue originally presented, using the guide from a few months ago when the grub update broke things. Is there a command that will rebuild the config by polling the system?

This line should not be empty. It is used to tell the Kernel and the initial RAM file system where to find the root partition and to unlock it. Edit /etc/default/grub (after chroot-ing) and change the line to this:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=4c30397d-8190-4f94-8106-561d0e916e65:luks-sda2 root=/dev/mapper/luks-sda2"

Important: While still being in the chroot shell, regenerate your GRUB config:
grub-mkconfig -o /boot/grub/grub.cfg

Reboot now. You might be asked for your password twice, but your VM should be able to boot again.

Got to learn vi…

It is giving same error now except now for /new_root: no filesystem type specified.

Everything else is the same.

Should the cryptdevice UUID be that of crypto 1 on sda2?

I am not sure what to do about GRUB and LUKS encrypted BTRFS partitions. It seems the initial RAM file system cannot mount the encrypted btrfs sda2 partition. I am out of ideas.

I am assuming sda2 is your root partition. Do you know what sda3 is used for? Maybe post the output of lsblk after you did chroot?

I believe its swap. I just took default partitions and its not labeled but I think:

loop0               7:0    0  1.6G  1 loop  
sda                 8:0    0   80G  0 disk  
├─sda1              8:1    0  300M  0 part  /boot/efi
├─sda2              8:2    0 71.7G  0 part  
│ └─mycryptdevice 254:0    0 71.7G  0 crypt /home
│                                           /var/cache
│                                           /var/log
│                                           /
└─sda3              8:3    0    8G  0 part

I found this:

And have tried this however still same issue. I did notice when removing swap from /etc/crypttab that only cryto 1 UUID is in there. Should the btrfs UUID be in /etc/crypttab as well?

Very good question. Usually SystemD would try to mount any unencrypted swap it can find (which is annoying). Have you seen this comment in the crypttab file:

# NOTE: You need not list your root (/) partition here, but it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.

Your system should be able to boot without any entries in /etc/crypttab.
Additionally, booting the system should not be impacted by non-existing swap in any way. Ignore swap for the moment and try to fix booting with your root partition first.