Luks encrypted BTRFS boot giving wrong fs type, bad option, bad superblock error on boot

Hi, I’ve been runnings EndeavourOS plasma without issue for about a year. Possibly after an update I didnt notice, my system now cannot boot. After entering my luks password, the screen progresses to:

: : running hook [encrypt]
: : mounting 'dev/mapper/luks-whatever
mount: /new_root: wrong fs type, bad option, bad superblock on /dev/mapper/lukswhatever missing codepage or helper program, or other error.
Error failed to mount /dev/mapper/lukswhatever
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off.

I’ve previously had an issue with grub where I chrooted in to my system from a liveUSB and rebuilt my grub or some such. (Grub 2:2.06.r322.gd9b4638c5-1 won't boot and goes straight to the BIOS after update - #805 by LeEmu)
I’ve tried following those steps, but at the instruction on mounting my btrfs system for chroot

sudo mount -o subvol=@ /dev/mapper/mycryptdevice /mnt

I receive the same error

mount: /new_root: wrong fs type, bad option, bad superblock on /dev/mapper/lukswhatever missing codepage or helper program, or other error.

Would apprecient any and all advice on getting back into my system cheers.

You also have to mount the subvolume that has the efi partition. Did you do that? I usually mount all the subvolumes even though you probably don’t have to but I’m not sure.

Edit Because you are using luks I’m not familiar with what other subvolumes it has for that.

Edit2: Please follow the wiki for arch-chroot on btrfs

I have followed the instructions as per that page, which are also what was posted in the help thread I linked.
I have the Luks partition decrypted, then mounted to /dev/mapper/encrypted . I then run

sudo mount -o subvol=@ /dev/mapper/encrypted /mnt

Which gives the wrong fs type, bad option, bad superblock on /dev/mapper/encrypted error as previously described. I have mounted all the other partitions including EFI, but it seems I cant progress while getting that error. This is the error I get when trying to boot the system as well.

Are you mounting them all before attempting to arch-chroot?

The wrong fs_type error is preventing the main volume “@” from being mounted, so can’t chroot in at all.

I guess you’ll have to get some help from someone more knowledgeable on this. I use btrfs with grub but i don’t use luks and I’ve never ever had an issue like this with updating or booting on btrfs.

No worries. Pretty sure it’s no the Luks bit as I’m able to decrypt and read the files. I can also chroot directly into @ from the mounted drive, but that’s not a proper mount point like that.

When i have seen this issue before it seems that the updates didn’t complete and requires to run the update and reinstall the kernels. Not sure how you can do that if you can’t arch-chroot to the /mnt point.