Then you need to mount it manually:
sudo mount -U abd07649-4af0-49fa-906b-c8cc116b98e6 /mnt
Check if the subvolumes are correct;
sudo btrfs subvolumes list /mnt
Then unmount it:
sudo umount /mnt
Then mount the subvolumes:
sudo mount -o subvol=@ -U abd07649-4af0-49fa-906b-c8cc116b98e6 /mnt
sudo mount -o subvol=@home -U abd07649-4af0-49fa-906b-c8cc116b98e6 /mnt/home
Then
manjaro-chroot /mnt /bin/bashThen i learned:
Mounting with fstab does work this way, when you make your snapshot the default subvolume
PLEASE look into section with name:
Prepare the selected snapshot for booting:
btrfs subvolume set-default @
Because i think this may help others i wrote this tutorial 
[manjaro /]# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=901e9437-31d8-4a4f-ac41-d7e585b7cc79 /boot ext4 defaults,noatime 0 2
UUID=abd07649-4af0-49fa-906b-c8cc116b98e6 / btrfs subvol=@,defaults,noatime,space_cache 0 1
UUID=abd07649-4af0-49fa-906b-c8cc116b98e6 /home btrfs subvol=@home,defaults,noatime,space_cache 0 2
So here is nothing wrong and UUID matches with inxi output.
Since the problem is not BTRFS, but the ext4 boot partition, keep sure the partition is not corrupt. Check it with fsck.
[manjaro /]# sudo fsck -n /dev/sda7
fsck from util-linux 2.37
e2fsck 1.46.2 (28-Feb-2021)
/dev/sda7: clean, 390/51200 files, 115699/204800 blocks
I hope I did it right.
This is a partition layout that may lead to problems with manjaro. You can’t rollback securely this way !!!
Your /boot is on another partition then your / . When you update your system, the kernel will be updated at the same time.
on / you will have all revisions of all the different modules for all kernel-versions you need to rollback
on your /boot every kernel-version will replace each other. you really only have the newest kernel-version there !
When you roll back then there is a kernel in /boot with his new initramdisk.
later in the boot-process this new kernel will not find its own modules. because you rolled back / into an older snapshot.
I don´t know if this is the problem you face at this time. But i got burned. 
So i learned: With manjaro you have frequent changing kernels. To do a save rollback you can’t have /boot as extra partition. This used to be a good idea years ago. but nowadays it is best to not have /boot as partition
Thanks for your advice. I wanted to try to solve the problem according to your methods according to the link, but I thought to solve it with megavolt and not run from advice to advice of different people. But he doesn’t seem to want to deal with my problem)
I do not understand everything that you are saying because of the translation. I would like to know if it is possible to restore my system?
No thats not the case… If I have no idea at this moment, then I don’t answer. And it is bad if only one person answers. More heads produce better results… (something like that). So @andreas85 explained it in an excellent way.
So on /boot there are initramfs. These initramfs are not rolled back and therefore it crash. I guess an easy fix could be:
mkinitcpio -P
update-grub
You do all right, in only following one advice at a time! megavolt is very competent like a lot of members in this forum. I must be honest. you wrote the most of this in your first post. But i did not recognize some of it
So what do we know until now:
Lets assume that “Failed to start Load Kernel Modules” is because the Kernel-Modules on /lib/modules don’t match the kernel in /boot
There seem to be several ways to rescue your install:
After this i did remove the /boot and included it into /
This is indeed the first(best) way to go. It may be additionally necessary to replace the kernel with mkwd-kernel so that kernel and /lib/modules/* have the same version.
I don’t think so… Let’s assume he have installed an update. It updates the kernel, creates a new initramfs image and updates grub.
Now he rolled it back. But since /boot is not on the same partition (and therefore not included in the snapshot), it is not rolled back and stays the same. Now the new images after update stay and everything else is rolled back… So if he install a new kernel with mhwd, then the initramfs image will be recreated anyway, but the other stay.
Oh man… that is getting complicated…
On BTRFS /boot should be included and not a separated partition. Less headache, when using snapshots. Fully agree here with @andreas85 
I think in /lib/modules on the disk there may be an old version of the modules from the rollback. When mkinitcpio runs it will try to use these. but the kernel is an newer version. At the moment the kernel and the initramfs may be the same version.
But You may be right. And it does not harm to try this. There will be no damage
[manjaro /]# mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux419.preset: 'default'
-> -k /boot/vmlinuz-4.19-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.19-x86_64.img
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-4.19-x86_64'
==> Building image from preset: /etc/mkinitcpio.d/linux419.preset: 'fallback'
-> -k /boot/vmlinuz-4.19-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.19-x86_64-fallback.img -S autodetect
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-4.19-x86_64'
==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'default'
-> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64.img
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-5.10-x86_64'
==> Building image from preset: /etc/mkinitcpio.d/linux510.preset: 'fallback'
-> -k /boot/vmlinuz-5.10-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.10-x86_64-fallback.img -S autodetect
==> ERROR: specified kernel image does not exist: `/boot/vmlinuz-5.10-x86_64'
I made / boot a separate partition because grub doesn’t work with btrfs. So I had to do / boot ext4. This is how they explained it to me.
Since /boot is a seprated partition, you need to mount /boot also and then chroot
sudo mount -U 901e9437-31d8-4a4f-ac41-d7e585b7cc79 /mnt/boot
A few years ago this has been true
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_Btrfs.3F
)[manjaro /]# update-grub
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-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.
grub-probe: error: cannot find a GRUB drive for /dev/sdb4. Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb4. Check your device.map.
Found Windows 10 on /dev/sda1
Found Windows 10 on /dev/sda2
Found Manjaro Linux on /dev/sda8
Found Windows 10 on /dev/sdb1
Found memtest86+ image: /boot/memtest86+/memtest.bin
done
I don’t understand what the mistakes are
Ok I try to explain it more simple:
The mistake is that the files on /boot are not on your btrfs partition: /@/boot and therefore timeshift skip it when using the btrfs snapshot feature on timeshift. That results in updated boot files, but rolled back modules, when rolling back.
So i would suggest to:
Now you should see /boot with the kernel and initramfs!
then please:
install kernel 5.10 with mhwd-kernel
https://wiki.manjaro.org/index.php/Manjaro_Kernels
look wehter the kernel in /boot/… changed
look wehter the modules in /lib/modules/kernel-version are present
look wehter the generation of the initramfs did work (timestamp of /boot/
This is the first step. When this succeeded we will work from there on
I tried to install the kernel
# mhwd-kernel -i linux510
:: Synchronizing package databases ...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize all databases
And I couldn’t do it.
Then I tried to update the system, but the same thing came out
# pacman -Syyyu
:: Synchronizing package databases ...
error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize all databases
then i found a solution to this problem
rm -f /var/lib/pacman/db.lck
and now I can update.
But the update will make my system the freshest, and I would like to revert to my old snapshot. Is it possible?