I just have restarted the computer and in the BIOS, the nvme is not listed as a bootable device.
I am very sorry that I have given you misleading infos concerning the nvme. Today I am working already about 10 hours on this problem and I should go to bed.
Do you think, it makes sense to go on with this or should I reinstall everything from ground new?
And how can I install it from ground, when this nvme is not visible in the BIOS anymore?
That’s because the EFI variables have been wiped. But as I told you in my previous post, there are only two things that I know of which could have done that, i.e.:
I think there’s still a chance we may salvage this. 
By chroot’ing from the live USB and reinstalling grub to the EFI partition, as I showed you a few posts up. Reinstalling grub with the --recheck option will also recreate the EFI variables.
OK, I followed your advice from above (Post 11).
I had to use chroot /mnt instead, because manjaro-chroot does not work on btrfs.
Now it is mounted and I tried the next step, doing:
install-grub
EFI variables are not supported on this system.
lsblk: failed to access sysfs directory: sys/dev/block: No such file or directory
WARNING: EFI directory not found! Grub couldn't be installed.
I suppose, that is, because I should mount the esp /boot/EFI additionally to chroot. From this source https://forum.manjaro.org/t/root-tip-recovery-basic-manjaro-linux-recovery/175302 I found the code:
mount -t vfat $esp /mnt/boot/efi
And the reaction was:
mount: /mnt/boot/efi: can't find in /etc/fstab.
OK in the Live-System there is no such a mount point and I will try to mount it as the other subvolumes at /mnt
But this leads to the same reaction. OK, may be, because efi is vfat and therefor cannot be mounted within a ext4 System, which is default when using Live-Stick? But the instructions from the source (URL above) told so.
Just for fun, I tried to change the directory by cd boot and then cd efi and I could get in these directories. I suppose, the Live-Disk does not have boot or efi directories? If so, these directories must be those from the not booting system on nvme1n1.
Also “just for fun” I had a look at the nvme1n1 by using Gparted. And now the black info sign is there again at the fat32 partition. When I click “info” of this partition, I get:
Unable to read the contents of this file system! Because of this some operations may be unavailable. The cause might be a missing software package. The following list of software packages is required for fat32 file system support: dosfstools, mtools.
In the columns of the fat32 partition, there is a simple line which shows, that this partition is neither used nor has unused space. On my laptop, I get this info for fat32 partition, but perhaps this is due to the fact, that this partition is not mounted yet.
Sorry but now I am stuck again at this point.
Hmm… I submitted a patch in June to remedy that problem, but apparently it hasn’t been merged yet. 
This means that you’ve booted up in legacy BIOS mode instead of in UEFI mode. You will have to enter the UEFI settings first and disable all CSM (legacy BIOS compatibility mode) options again.
Which makes me think of something… There is a third reason as to why your UEFI variables might have gone missing, which is that the CMOS battery has died. This is a small cell-type battery which powers the non-volatile memory and the real-time clock on the motherboard.
The live USB uses a regular kernel, with support for all of the usual filesystems, so yes, it most certainly can mount, read from and write to vfat.
Yes, the live USB uses a different filesystem layout, with an overlayfs on top of a static ramfs.
So those directories will have been the one from the installed system.
Those packages are normally installed already. They are part of the stock installation.
It may be a damaged filesystem, or even a damaged partition table. It is really difficult to tell from the information you’re providing, and we seem to be jumping all over the place.
First and foremost, there is the problem that you’ve booted up in legacy BIOS mode and that your EFI variables are gone, which tells me that your CMOS battery may be dead, or at the very least, that it’s only working intermittently anymore.
Once we got that sorted — which is best handled by replacing the CMOS battery and then restoring all of your UEFI settings to how they should be — then we can start looking at whether your EFI partition is damaged or not, and only then can we start thinking about reinstalling grub to the EFI partition and restoring the EFI variables in the non-volatile memory.
Hi again! I have bought the mainboard 3 weeks ago. I don’t think, that the CMOS battery could be the cause. But additionally I have measured it and it is absolutely fresh.
I am sure I did not boot into legacy BIOS. I had checked all relevant BIOS settings before I started this discussion. And I have simply booted from USB stick without any other settings.
When I can get into the dirctories boot and efi, then this could be an indicator, that the file system of the vfat partition is not broken.
A friend recommended me to follow a tutorial, which you have written here: https://forum.manjaro.org/t/howto-recovering-from-an-interrupted-update-upgrade/132762
I cannot proof whether following this tutorial would solve my problems here. It is strange, that I could mount the "@" at mnt but could not mount /boot/efi to mnt also. As I just wrote: In Gparted there is a black circle with an “i” in it, showing, that there is something odd. When I rightclick on the /boot/efi partition and choose information, I get the info, I had posted already. And if the tools were already installed within the life-system to access and read vfat partitions, then it would confirm, that something is wrong with this partition. I don’t know, how this could be fixed!
When I regard, that I have invested more than 18 hours to restaurate a damaged system, then it seems, it could be more efficient, to do a complete new installation and setup. Further it seems to me, that in case of success here, there may be a risk, that something keeps unrepaired and later I have a ticking bomb in my system.
What do you think? Should I try to follow your tutorial, I have linked above? Or is it useless, especially with regard to the possibility of a damaged vfat partition?
I just have found a notice from 11th of August, which I wrote after updating the actual damaged system by using pacman. When pacman was finished I have got:
found 8 snapshot(s)
Unmount /tmp/grub-btrfs.FGHGij7uqc .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: Warning: Unknown device type nvme0n1.
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
/usr/bin/grub-probe: Warning: Unknown device type nvme0n1.
finished
Warning: GRUB bootloader at '/boot/efi/EFI/Manjaro' was updated.
Your booted entry 'UEFI OS' is not the same as 'Manjaro'.
This may be a rescue ISO, but if not check your EFI boot priority.
(19/33) Updating Grub-Bootmenu
GRUB-Configuration file will be created …
Because the system was running without problems after that, I did not check it further. But it might be, that this was the beginning of all this trouble. I simply wanted you to know this.
After another phone call / discussion about these problems I have now decided, to do a complete new installation of all.
I thank you very much for your engagement and your patience with me!!!
That is not how you do it.
First you have to mount the root filesystem — in this case, the @ subvolume of the btrfs partition — to /mnt. Then, you must mount the EFI system partition to /mnt/boot/efi.
You’ve said this before, but I have no idea what that means. Is this — see the yellow arrow — what you mean? 
If so, that’s simply an indication of whether it’s mounted or not. In the above picture, it’s mounted.
Well, it’s a tutorial on how to recover from an interrupted update/upgrade. It’s not meant to deal with other scenarios.
Well, in that case… 
