[OnePlus X Original Android Development] SebiderSushi:
running either one of the 2022-07-01 or 2022-07-24 builds and initiating storage encryption the ROM reboots to encrypt but keeps displaying the bootanimation. aborting the bootup with a hard reset leaves the phone with a working but unencrypted - seemingly untouched - /data partition.

when reformatting /data, wiping /system & flashing other YumeMichi LineageOS ROMs and then trying to encrypt again the operation fails as well until i zero-out reserve2, the partition that holds the encryption footer in YumeMichi's device tree.

when building from source with YumeMichi's device tree and kernel using this manifest (last repo sync & build tested September 15, tested both lineage-17.1 and lineage-18.1) storage encryption works as expected. however, it is not possible to use "Secure Startup" on the lineage-18.1 branch as the ROM never finishes the second round of booting after passcode entry for decryption. YumeMichi's TWRP build decrypts /data just fine after providing the passcode. when wiping /data without formatting it and flashing an older YumeMichi ROM it is able to boot properly after providing the passcode.

Secure Startup was fully functional on LineageOS versions prior to 18.1

the issue is not present up until los_v2.zip and first reproducible in los_v3.zip as uploaded by YumeMichi to the Telegram group. in this case the device doesn't even boot to the passcode entry.

in the system settings these builds report as 18.0-20201106-UNOFFICIAL-YumeMichi-onyx and 18.0-20201130-UNOFFICIAL-YumeMichi-onyx with kernel versions 3.4.113-Sultan-g39904a6f7cd and 3.4.113-Sultan-g5de6a8a8e18 respectively. los_v2.zip is SELinux permissive while los_v3.zip enforces it. the issue is reproducible when building from current lineage-18.1 source with permissive SELinux.

there were no commits to YumeMichi's device tree in that period. these are all commits between the reported kernel versions.

the only similar issue i could find affected legacy devices on lineage-17.1 but was reportedly eliminated by updating to LineageOS 18.1

i tried gathering useful logs using advice from said issue with no luck. adb didn't spin up during the unsuccesful encryption operations or infinite reboots. maybe /proc/last_kmesg could be another option.

i recognize that these are up to 3 distinct issues but i tried to collect every bit of related info that i know about.

----- Update 2022-10-20

i did some extra testing with current lineage-18.1 sources and vanilla yumemichi device tree at the latest commit.

when i apply the commit onyx: Start bootanim before mounting data partition from your device tree the ROM boots fine as long as /data is unencrypted

if i try to boot the rom on an already encrypted /data it fails to boot and jumps to recovery.

trying to encrypt /data with reproduces the behavior described at the beginning of this post. however, if i do a hard reset and restore the unpatched init.qcom.rc and reboot it successfully encrypts and boots up.

from a user perspective, i do not perceive any issue this commit might be intended to address and a web search for "aosp bug 30118894" does not return anything.

i am always compiling without the patch onyx: Enable encryption in all tests i've described so far.

applying it in isolation breaks encryption - trying to encrypt results in a bootloop. doing a hard reset leaves the /data partition seemingly encrypted with TWRP and ROM asking for a passcode. this is with secure startup disabled / no screen lock set before encrypting.

on your build lineage-18.1-20220724-UNOFFICIAL-onyx.zip when i write the original version of init.qcom.rc with cat init.qcom.rc > /system/vendor/etc/init/hw/init.qcom.rc trying to encrypt bootloops as well but after a hard reset /data is left unencrypted and booting works as well as data access in TWRP.

setting only TARGET_LEGACY_HW_DISK_ENCRYPTION to true appears to be fine / not change the behavior from yumemichis original device tree.