Ok, I went again through the process till chroot and thus running update-initramfs -u && update-grub but nothing happened, it looks like that commands didn’t interact with the bootloader or did not update grub at all.
To test this out I modified the fstab in order to boot from the SD Card and its partition /boot/efi and to use the partitions /boot and / from the emmc module, but simply the boot failed at an early stage and I had to remount in rw / and restore the original fstab; it didn’t matter that I updated the initramfs and grub from the SD Card, as a matter of fact, after restored the fstab, the system booted properly. It even asked me to unlock the partition that is encrypted so it means that crypttab was well configured, as you can see from this picture the LVM volume encrypted is active after the first login:
The standard boot chain is u-boot → GRUB → Linux initramfs → mount → fstab → systemd. Each component has its respective filesystem loaders. Your disk setup is misconfigured from whatever and where-ever initramfs is looking for and possibly what fstab is configured for if initramfs found the correct partition and mounted it.
You don’t have to modify u-boot. You’re trying to do something which you do not have the fundamental knowledge for. We recommend that you get a fundamental understanding before trying to do what you’re doing.
We provide standardized bootloaders that have the necessary hardware description to Linux. When Linux is started by GRUB via EFI, it can optionally use an initramfs which does all the low level mounting. If you want password security for an encrypted volume on top of LVM, that handling logic has to be in initramfs.
If you don’t know how to do that, you are in over your head as this is not trivial. Our boards support standard distro images so if they do that setup for you, you can run the installer to see how they setup the volume and initramfs as an example. Taking our images and modding them is only for expert Linux users.
Sure, I’d like to understand better the matter but I have my own limitations.
Anyway I “diff-ed” the working /boot/efi partition with the one I replicated and are identical but not the UUID where the loader should look to boot which is correct, but it looks like that grub or the loader can’t see or find it, but it is there.
Yes, it’s easier to create the partition table, the partitions, bootstrap, mount them, install GRUB, setup initramfs, etc than to hack an existing image to do stuff it was not designed to do. Some of the steps are available in libretech-slipstream.
