roar

Nevermind, everything is working as expected with the latest 20.08 release

Right, sorry for not doing this earlier: http://ix.io/2u26 The logs from the encrypted root system are at the end, there are multiple reboots in between. - I screwed up the armbianEnv.txt file at one point, and restored it from a fresh armbian image. I will try another fresh install and encrypted root setup to be sure there aren't any other problems - The CPU temperature seems quite high to me? I remember using the same board a year or more ago and the temps were around 45C instead of 65C. I have a cubietruck that hovers around 45C, seems odd the lime2 emmc would be so much hotter

Hi everyone, I am trying to setup a new armbian buster system on a lime2 eMMC board. Not currently using the eMMC. Wanted to have a regular armbian install on the sd card, and then an encrypted root partition on an SSD attached with SATA. I've done this before by loosely following this post If I setup a system without using dropbear to unlock the root partition and boot, and use a keyboard to enter the password to unlock it instead, that works fine. However, if I install the `dropbear-initramfs` package, copy my ssh keys to /etc/dropbear-initramfs/authorized_keys and then do `update-initramfs -u` the bootloader doesn't seem to get past the initial stages. Here is some of the output from the bootup leading me to believe something went wrong in updating the kernel image and the bootloader on the SD card: Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3789 bytes read in 2 ms (1.0 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 250 bytes read in 2 ms (122.1 KiB/s) 142269496 bytes read in 704 ms (17.3 MiB/s) 7163856 bytes read in 396 ms (17.3 MiB/s) Found mainline kernel configuration 42254 bytes read in 7 ms (5.0 MiB/s) 5532 bytes read in 5 ms (1.1 MiB/s) Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) ## Executing script at 44000000 ## Loading init Ramdisk from Legacy Image at 43300000 Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14226432 Bytes = 13.6 MiB Load Address: 0000000 Entry Point: 0000000 Verifying Checksum ... Bad Data CRC Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... A bunch of messages flash by which I couldn't get on camera, and then it hangs with something along the lines of `autload with TFTPGET...` From what I understand, the ramdisk image is corrupted and u-boot falls back to trying to download it from the network somehow. Is this ramdisk the `boot.scr` file? The interesting thing is if I downgrade the kernel, by downgrading the packages `linux-image-current-sunxi` and `linux-dtb-current-sunxi` to version 20.05.0-trunk instead of 20.05.3 then I can successfully install `dropbear-initramfs` and unlock the system via ssh. Does anyone have any ideas of how this can be fixed? I can provide more info if need be. Like how I setup the encrypted system. Or I can find my serial to usb cable to try and get more output Thanks

So i've gotten round to testing this on the cubox i4 and lime2. Both seem to work fine with the 5.4.22 kernel with apparmor enabled as per the gentoo wiki I used an ubuntu 18.04 VM with the armbian build system, and used KERNEL_CONFIGURE to change the relevant settings So far, i've only tried this with an lvm + luks setup on both the cubox i4 and lime2. I took an existing armbian install and just installed the `linux-image` and `linux-dtb` packages on top of it. I also enabled some kernel options for lvm on the lime2, again as per the gentoo wiki Some next steps to try out: - install to eMMC on the lime2 - try booting from USB/SATA. is this even possible on both boards? i guess armbian-config is good for this - build a full debian image, flash it and test

Thanks for the positive reply! I had thought as much, that it was maybe breaking something else and had been disabled for that reason. However, I'm not sure it even gets loaded if you don't specify the boot parameter for it. I can test this on the boards I have: cubox i, cubietruck and olimex lime 2 with and without eMMC If it goes well i'll submit a PR with a changed kernel config for these boards

I've noticed that the AppArmor kernel config was switched off from kernels 4.19.x onwards. I've searched the forum and the github issues but haven't found any problems related AppArmor. I'm using the current kernel for cubox (5.4.x) that I've compiled by adding AppArmor config back, everything works as it should for a headless system. Would it be possible to add the AppArmor kernel config back? I can help with testing on the following boards: cubox, olimex lime2, cubietruck