Por lo demas tienes razón, las modificaciones del /etc/default/grub que te comento no tienen que ver con el problema (eran un comentario al margen).
En el menú de GRUB se supone que deberías poder iniciar cualquier kernel con una entrada estándard incluso mejor sin el
quiet splash para ver que sucede realmemte durante la carga del kernel y sistema (sin el plymouth). Podrías crear un entrada personalizada con el siguiente contenido Bastaría editar en el propio menú grub (con E o TAB) sobre esa entrada y cambiar los dígitos del kernel (en negrita) para iniciar con otro anterior (74 en vez de 77) o posterior recien instalado caso de que pruebes con el 5.8 o el 5.11.insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 2f207c07-10d2-4019-a271-d0e68e07c166
else
search --no-floppy --fs-uuid --set=root 2f207c07-10d2-4019-a271-d0e68e07c166
fi
linux /boot/vmlinuz-5.4.0-77-generic root=UUID=2f207c07-10d2-4019-a271-d0e68e07c166 ro
initrd /boot/initrd.img-5.4.0-77-generic
En esas condiciones podrías ver en pantalla la carga detallada del sistema , sus fallos y advertencias y sería extraño el resultado del Busybox con la shell initramfs sin que medie un kernel panic ni un taining kernel ni algún problema de acceso a la partición raiz , como el que mostraba una captura tras el
exit, u otro problemas con otras particiones,... Tambien editando la entrada del menú podrías añadir
debug a la línea del kernel (a continuación de ro) para que a costa de una ligerra lentitud en la carga observar mas detalles o incluso poder acceder al registro en /run/initramfs/initramfs.debug o drigirlo a la pantalla con debug=cv (mira aquí para empezar).Sobre los cambios en la configuración de la UEFI/BIOS como activación de TPM , la activación del Secure boot,..entre reinicios si podrían afectar en diferente forma a los kernel instalados por más fexible que traten de ser grub y kernels . De hecho el busybox suele ser el resultado normal de esos cambios y quizás también de los problemas que tuvistes con el cambio de disco y la instalación de grub-efi. Mientras el sistema no esté optimizado debes favorecer en lo posible la carga del kernel y controladores al probar otros kernels. Lo que puedes o no hacer con otros sistemas y pc no es la referencia, si lo sería si hicieras una instalación desde cero en ese pc.
Por otro lado son conocidos los efectos del cierre en falso de Windows sobre el acceso de Linux a sus particiones y otras compartidas tanto al reiniciar en vez de apagar e incluso apagando si se mantiene la hibernación y/o el fast-start-up activado en Windows o el simple el indexado de los discos que pueden llegar a impedir la carga del sistema de tener definido el automontaje de esas particiones como ocurre en tu caso con Backup y Win. Quizas mientras siga este problema deberías renunciar al automontaje de esas particiones al igual que la EFI.
Por lo demás es normal que un kernel instalado en otro equipo requiera de algún ajuste en cuanto la carga de módulos y controladores, empezando por los gráficos (por eso detetecté que el 5.4.0.73 del equipo anterior anterior, al no cargar el dkms de la nvidia). Tambien, aunque no recuerdo que aparecieran errrores relativos al TPM en el filtrado del los errores dmesg , aparecían problemas con la firma del controlador de la nvidia y otros con el firmware de dispositivos pci como la wifi.
La seleccion de la gráfica de inicio en el caso de gráficas hibridas puede ser determinante si el firmware no acompaña, en la UEFI/BIOS si es posible o si no con algún parámetro modificador (intel.modeset=1 nvidia.modeset=0,...) o el
sudo prime-select intel en una sessión activa una garantia de al menos iniciar si el problema es ese controlador y darle solución luego probando a resintalar el controlador, con otro controlador, con otro kernel....
pero 
