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.
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.
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 UUID=4c30397d-8190-4f94-8106-561d0e916e65
and the matching UUID is also there on sda2: btrfs 4c30397d-8190-4f94-8106-561d0e916e65
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 [...]"
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)
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:
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.