I am stuck in a strange situation:
I sucessfully built and installed LineageOS 16.0 for my Samsung S5 mini (kmini3g) from 2015.
So, after that, I tried to build e/OS 0.22 p, exactly the same way, using the very same local manifest (this strategy worked well before for two other devices).
But after flashing the rom, e/OS does not complete booting. After about 20 sec display of Samsung boot logo, the device turns off and reboots to bootloader, before the e bootanimation appears.
Unfortunately, also before ADB is active. I tried to analyse last_kmsg, but either I did not reach back to the “original” version, or there is nothing special in it, compared to the LOS bootlog…
Does anyone has a qualified opinion on this, or encountered a similar situation in the past and found a solution? I researched for hours on end, but to no avail…
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
Perform a Factory reset ?
Flash the lineage 's boot.img ?
Thanks for the suggestions, much appreciated! I did in fact all possible wipes and format data. And I indeed flashed boot.img from LOS, but that did not help. I even analysed both boot.img as far as I could, and diff-ed all rc files in initrc. I observed only slightest differences, and applying them to the e/OS build did not change anything…
My feeling was, that maybe the system partition is not identified or mounted properly, but fstab is identical in both versions. To reboot to bootloader probably means that the kernel thinks there is no valid system present… (disabling selinux did also not help).
I built using mka bacon in order to get flashable zip files to be used with twrp (to circumvent odin). In former builts I used m to generate img files for use with fastboot. Could this make a difference? I would think not, but who knows…?
fastboot commands are reputing not working with samsung devices.
i cannot try building /e/ ( knowledge, and hardware requirements) but have builded postmarketOS (linux on android devices) and you need to specify heimdall flashing method during build…
I see that there is no lineage+micoG so my first guess would be partition size. Do you know any way to check if that is the issue?
Thats true. Samsung’s bootloader does not implement fastboot. Therefore custom roms are usually flashed using twrp recovery and the OTA zip file.
I also read about cases where sucessfully flashing a rom also depended on the twrp version. However, beeing quite similar, LOS16 and e/OS pie should be able to be flashed by the same twrp version, I think…
3.3.1-0 works well for the old e-0.9-pie from june 2020 that i used on kminilte. on the same device, e-0.18 from august 2021 don’t boot (as your’s)
Interesting point. I can read partition data using adb shell. This would concern the system partiton? After installing the e/OS build, the system partition has several hundred (not remeber the actual figure, maybe around 400) MB left free.
Or do they use another partition for microG?
microG core (sorry I forget the correct name for it) does occupy /system – so you probably ruled that out.
Yes, probably. But however, somehow the actual system is not initiated… Could it happen that through the e/OS repos somehow some 64 bit binaries are introduced into the final build, that cause the immediate shutdown? Just a thought…
quote @Chimpthepimp (about kminilte) :
I can t remember the directory but somewehere in the sources are patches that have to be applied between sync and build…
Yes, I know postmarkedOS. With Android, i.e. e/OS, Lienage OS, AOSP, it is different. The ADB/Fastboot tools are in the toolchain (afaik), but not heimdall. However, the AOSP toolchain does not support Odin flashable files anyway (again afaik…). To initially flash twrp, or to flash boot.img, I use Odin nonetheless, and probably the whole system.img can be flashed when tar-ed using Odin. I did not yet try that, since I thought it should work the same way as with LOS16 - and if it does’nt, it probably is not a question of flashing method. But I may be wrong…
It would be surely interesting to know more about it…If this quote is from another thread, could you tell the link?
no, it was in a private message about the failling 0.18 test by @ itsclarence,
@ Chimpthepimp said he will have a look into the sources some days after, but forgot or don’t find, i don’t know as i have no news since that (september 2021)
Ok, if it can be found in the sources, I can probably figure it out somehow. I am still a Linux newbie (since 30 years…), but I really love find and grep now…(no problem with millions of files )
There actually is one 64-bit object file bpf_kern.o in /system/etc/bpf/… I assume Android will stop immediately as soon as this file is loaded by the kernel. Funny that this 64-bit file also exist in the LOS 16 build, where it seems to do no harm. But maybe the LOS build does not touch the file on startup, while the e/OS build does? That brings up the question, if or how startup procedure of e/OS could be different from LOS using the same local manifest and hence the same kernel configuration…?
Edit: No: Deleting the folder /system/netd/bpfloader from the source tree will prevent the 64-bit file bpf_kern.o from being included in the build, but, unfortunately, e/OS will still not boot properly…
Actually, using LOS boot.img on the e/OS Rom makes the device reboot to recovery instead of bootloader. So likely the fault lies within the e/OS boot.img, but that was expected anyway. I wonder if it is possible to somehow catch some kind of boot log to see what’s really happening…
BTW: The recovery.img is the same with e/OS as with LOS, both working fine…
Don’t know if this still works, but you can try this: here
I think I managed to fetch the respective last_kmsg:
[ 16.170502] sec_jack_probe - defer as codec_probe_done is false
[ 16.244221] selinux: SELinux: Could not stat /metadata: No such file or directory.
[ 16.253819] msm8226-asoc-tapan sound.44: Looking up qcom, cdc-lineout-spkr-gpios property in node /soc/sound failed -22
[ 16.255524] msm8226_asoc_machine_probe Ear adc LDO node not available
[ 16.256564] sec_jack_populate_dt_pdata : can not find the earjack-micbias-gpio in the dt
[ 16.256689] sec_jack_populate_dt_pdata: can not find earjack-micbias-ldo in the dt
[ 16.257123] sec_jack_gpio_init : gpio_request failed for 435
[ 16.257700] snd_soc_dapm_force_enable_pin is still needed, do not turn off
[ 16.258126] snd_soc_dapm_force_enable_pin is still needed, do not turn off
[ 16.312555] cyttsp5_i2c_adapter 79-0024: [TSP] iovdd_vreg error 0
[ 16.438732] Restarting system with command ‘bootloader’.
[ 16.440155] Calling SCM to disable SPMI PMIC arbiter
Funny enough, all those messages also appear in the last_kmsg of the LOS build, so it remains an absolute mystery to me why the kernel initiates the restart to bootloader…