I believe there is something that is not quite right: in Debian in order to have and encrypted LVM partition with inside /, /home , swap you need two partitions: /boot (ext2/3/4) and /boot/efi (vfat) now your image has only /boot/efi and / over btrfs…
In order to achieve what I want I have to create a new partition on the SD card shrinking the btrfs partition or redo the partition scheme on the eMMC creating two partitons one for /boot and the other for the crypt/lvm. If I am going to modify the SD I believe that I am going to change the various UUID position…
If the default image would have /boot & /boot/efi in two separate partitions I could, perhaps, booting from the SD and dd the / into the encrypted partition formatted in btrfs instead of ext4. Maybe I missed some important steps and therefore I can’t boot from the eMMC…
However when after I flashed again the image from the SD to the eMMC, Debian started fine.
Based on your reccomendation I am going to wipe off the eMMC and flash the bootloader, and see if at least u-boot runs… And if it works, perhaps I am going to use dd to clone the partition rather than rsync to copy files.
Then something is wrong in the process. Using lft to flash the bootloader to eMMC should start u-boot just like with full image writes to eMMC This board looks for the bootloader at sector 1 and is not finding it.
It did not boot, and this time I cloned the partitions and copied just /boot. Now since you stated that when you flash the bootloader it should start not matter what… Perhaps it won’t boot if you have /boot split in /boot (ext2) and /boot/efi (fat16) and it expects the same partition you made /boot/efi (fat16) and / (btrfs). I can’t find any other explanations…
I bought the eMMC from your store on Amazon eMMC Module 5.x 128GB.
I tried but I didn’t want to de-assemble the board from the case, from what I can remember it is white and contrasted.
Anyway I want to reiterate that I was able tobright chroot the OS in both the methods: using rsync to copy files as well as cloning the partitions with dd; although I’d definitely preferred get rid off btrfs, which is fine to use when you have to handle multiples storage but becomes annoying when you have to mess with the partitions because it is aware of every btrfs volume and subvolume and therefore you can’t can clone and mount a partition, you need the extra-step to update the UUID to avoid potential data losses.
My knowledge doesn’t go more far than this. If you are able to encrypt system partition please let us know, with btrfs is feasible to create a snapshot of /home and mount it as subvolume for the ones that want the /home separate from /.
I personally stopped this practice on Linux, now I use exclusively ext4 and only /boot, /boot/efi and / as partitions; and if I want to use an advanced filesystem I go directly on FreeBSD and ZFS; and it is a shame that you don’t support FreeBSD since it can run on the Rock64 board which has the same RK3328 SoC of your Renegade board.
All these words to explain that I am basically giving up…
If DDing a full image works, ./lft.sh should work too. Have you tried wiping the eMMC and just doing lft.sh against the eMMC module and trying to boot into u-boot? You need to copy and paste the actual output of ./lft.sh instead of giving meta summaries that provide no real information.
Don’t understand why you bother modifying an existing image when you are trying to achieve a very odd configuration. Just boot on SD card and bootstrap your own using losetup, fdisk, mkfs, and debootstrap? It’s easier than what you are doing. Or even just do NFS mount.
Pine64 doesn’t do much if any software. FreeBSD is a completely different beast with completely different toolchains. We do one thing and we do it well.
I’ll wipe out the board again and run lht.sh, I should record the session to grab the output or otherwise taking a picture, I don’t know any other method.
I am just trying to encrypt “root” as I would do with any other Debian installation, and as I did a couple of times with BTRFS since the Debian installer doesn’t support subvolumes; and have this partition layout as in my laptop:
# /boot was on /dev/mmcblk0p2 during installation
UUID=643befdd-7011-4e54-afe4-0f5ef7e426a8 /boot ext2 defaults 0 2
# /boot/efi was on /dev/mmcblk0p1 during installation
UUID=F447-1A01 /boot/efi vfat umask=0077 0 1
/dev/mapper/a11bk--vg-swap_1 none swap sw 0 0
This is anything special just a regular Debian installation.
You only need to provide your best selling boards to the various BSD foundations, they will do the job for you and let your boards able to run a BSD system.
Anyway if you know a better method to encrypt the operative system and boot anywhere please instruct me. I am trying to do what I would do on a x86 system, I don’t know any other means to achieve my goal, thanks.
I created the partitions one-to-one, and testing if the bootloader would work, and it worked; then I tested the partitions with the filesystem enabled, always one-to-one, and it worked; then I copied /boot and /efi/boot, always one-to-one, the not only the bootloader worked fine but it also landed in both steps into grub.
At this point the issue is likely to come out when I update the initramfs and grub…
For the next troubleshooting part I am going to copy (not cloning cause I want preserve ext4) /, into the encrypted partition, simply updating crypttab and fstab and:
reboot and see if grub still works;
chroot into the emmc and update grub and see if grub still works and if it is able to boot Debian from the encrypted partition.
p.s. I didn’t post any screenshot cause everything worked as it was supposed to be.