I don’t know if this is because of the initrd (initial ramdisk, which is related to the update-initramfs command).
So as background (in case it is related), the simplest boot is if the bootloader sees the kernel on a partition which has a filesystem type the bootloader understands. Then the kernel loads, and as the kernel loads, so do the modules at “/lib/modules/$(uname -r)/kernel”.
Now consider that one filesystem type all bootloaders understand is an initial ramdisk. This is just a simple filesystem tree without permissions or special function. This is essentially a filesystem with no filesystem. One can put the kernel in “/boot” of ext4, and put the bare necessity modules in the initial ramdisk, and mount that initrd. The result is that the kernel still looks for modules at “/lib/modules/$(uname -r)/kernel/”, but this is not ext4…it is a generic tree of files in RAM. Almost the same thing.
Now let’s say that you are using a filesystem type which the bootloader does not understand, e.g., XFS. You could use a custom kernel with XFS built in to it (integrated, not a module format). Then your system will take considerable updates or modifications to find the new kernel in many cases. After an update it might break. Or you could just put the XFS in a module. Now if the kernel Image is in “/boot” on ext4, then this part is easy for the bootloader to deal with. But what about the modules? If the initrd creation tools worked right, then the XFS module is added to the initrd in the correct “/lib/modules/$(uname -r)/kernel/” tree, and that tree is mounted on “/” (the kernel itself with an ext4 partition is mounted on “/boot” after the initrd is mounted on “/”).
Suddenly, the generic kernel an understand XFS in that case. You don’t have the XFS module on XFS being used to read XFS; you have the XFS module on initrd. So it works. The initrd is a kind of “adapter” between things needed to boot on a system which cannot “self read” due to some paradox.
However, this is not the end because we cannot put an entire system in RAM. The only program the kernel runs is init (which is systemd on recent systems; used to be a bash script). The minimal init in the initrd loads modules, and performs a pivot_root (or something similar), and two things happen simultaneously: (A) The initrd goes away, and (B) the actual filesystem on disk assumes the initird’s place. So the actual filesystem could then be XFS even though the boot software does not understand XFS, and the kernel itself is unmodified. The modules have allowed the adaptation.
What I suspect if there is an issue as you have shown is that the most probably point of failure is in the creation of the initrd (via the update-initramfs not understanding what must go into the initrd). Now maybe if nothing had gone wrong it would have booted, but what I see is a failure of fsck. Perhaps the initrd needed something for fsck to work, and something is in need of filesystem repair, so it would make sense that it would fail to boot. If fsck cannot succeed on a system with a failure in the filesystem, then there is a refusal to continue to boot since that would likely result in complete loss of the filesystem.
I don’t know what is in the update-initramfs. I do wonder though about this name:
5.10.104-terga-another
That would imply CONFIG_LOCALVERSION is “-tegra-another” (I assume “-terga” is a typographic error). In reality it should just be “-another” if it was set up correctly. If the kernel wants files in “/lib/modules/5.10.104-tegra/kernel/”, or in “/lib/modules/5.10.104-another/kernel/”, but something has mistaken a location as “/lib/modules/5.10.104-tegra-another/kernel/”, the modules used in boot (and for fsck since the kernel is providing the system calls which fsck uses) will not be found.
I can’t answer what is missing. I just highly suspect it is an issue with what the update-initramfs creation parameters.