Can't boot into my LUKS-encrypted Drive after deleting swapfile

Question

My drive uses LVM and is LUKS encrypted (EFI). I am trying to get into my drive, but after I put in my password for the LUKS encryption, it hangs.

I recently needed to add more memory to my root logical volume. So, at first I deleted my swapfile, reduced my journalfile, and deleted a lot of the cache that Pacman had been using (I'm using Arch Linux). After doing this, I realized, since I'm using LVM I could reduce the amount of memory in my home logical volume and use the leftover memory for my root partition, so I did the following commands (based on my recollection; for reference I only have two logical volumes in my physical volume):

lvresize -L-20G /dev/mapper/volgroup0-lv_home
lvresize -L+20G /dev/mapper/volgroup0-lv_root
resize2fs /dev/mapper/volgroup0-lv_root

One thing that might be an issue is I'm not sure what filesystem my root logical volume is, and I (unfortunately) did not know resize2fs was for ext3/ext4 filesystems exclusively. All I knew was that after resizing with the lv commands, I finally had more memory in my root logical volume after looking at the results of df -h.

Everything was hunkydory until I shut down my machine and tried to boot into it. After typing in the password to access the LUKS-encrypted drive I got the following error:

[FAILED] Failed to activate swap /swapfile.
[DEPEND] Dependency failed for Swaps.

And that error message would repeat. So, then I got a live disk, mounted the drive, and then tried to create the swapfile. These were the commands that I used:

cryptsetup luksOpen  /dev/sda3 home
mount /dev/mapper/volgroup0-lv_root /mnt
cd /mnt
dd if=/dev/zero of=/mnt/swapfile bs=1M count=2048 status=progress
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

After doing this, I was able to login with no error messages but it would hang on the login screen, and the computer did not show that it was processing anything (I waited on that screen for 10 minutes, nothing happened). Basically the same as what happened before when I tried to login, sans error messages.

[EDIT] After getting rid of the line in my fstab file, and removing the swap file from the directory. I think the issue doesn't have anything to do with the swap file. In any case, I can't log into my drive after putting my password in for LUKS encryption. Any help would still be appreciated. I'd be happy to provide more details.

[EDIT 2]

Do you have a backup of your /home filesystem stored safely elsewhere?

No, unfortunately

Please show your /etc/fstab (either by logging in as root, or by booting from a live disk, and accessing the root filesystem just like you did to recreate the swap file; you would find it as /mnt/etc/fstab then). That should identify the filesystem type used on your /dev/mapper/volgroup0-lv_home LV.

It looks like both volgroups are ext4.

You could also try mounting yout /home filesystem to see what, if any, error messages are displayed, and possibly to try and backup any important files if the mount attempt is successful.

When I try the following command `mount /dev/mapper/volgroup0-lv_home homey' (homey being a directory I made), I get the following error:

mount: /root/homey: wrong fs type, bad option, bad superblock on /dev/mapper/volgroup0-lv_home, missing codepage or helper program, or other error

Answer 1

Unfortunately, the problem is most likely the first command you listed:

lvresize -L-20G /dev/mapper/volgroup0-lv_home

Without the -r option, this command will just shrink the logical volume, and assume that the filesystem inside it is already shrunk appropriately. You don't mention which filesystem type you are using, but many filesystems allow shrinking only when the filesystem is unmounted, and some, like XFS, don't allow shrinking at all.

So unless your recollection misses some major steps, you have most likely damaged your /home filesystem by brutally chopping off 20G from its tail end. That is very likely also the reason why you apparently did not see any errors at boot, until trying to log in.

One thing that might be an issue is I'm not sure what filesystem my root logical volume is, and I (unfortunately) did not know resize2fs was for ext3/ext4 filesystems exclusively. All I knew was that after resizing with the lv commands, I finally had more memory in my root logical volume after looking at the results of df -h.

If you had tried to use resize2fs on something that was not a valid ext2/3/4 filesystem, it would have displayed an error message and done nothing else. So it looks like that part worked just fine, or at least did not do any damage.

It looks like you have also correctly regenerated the swap file you said you deleted earlier. (Side note: you should have used swapoff before deleting the swap file, but that's no longer important since the system has already been rebooted.)

For planning the next steps, you should edit your question to add the following information:

1. Do you have a backup of your /home filesystem stored safely elsewhere?

2. Please show your /etc/fstab (either by logging in as root, or by booting from a live disk, and accessing the root filesystem just like you did to recreate the swap file; you would find it as /mnt/etc/fstab then). That should identify the filesystem type used on your /dev/mapper/volgroup0-lv_home LV.

3. You could also try mounting yout /home filesystem to see what, if any, error messages are displayed, and possibly to try and backup any important files if the mount attempt is successful.

If the filesystem type of your lv_home is shrinkable, and the amputated part of the filesystem did not actually contain any data, then the situation might yet be fixable. You might have to temporarily fake the missing 20 G in lv_home to allow the filesystem shrinking tools to work correctly, by e.g. using a sparse file as a fake LVM PV, but let's check the basic facts first.