rinigus | @b100dian: Great test! Ok, so it's working in terms of config on pc. Maybe we just miss something in kernel config. | 05:25 |
---|---|---|
T42 | <elros34> similar dmseup issue: https://irclogs.sailfishos.org/logs/%23sailfishos-porters/%23sailfishos-porters.2023-03-29.log.html | 07:02 |
rinigus | @elros34: unfortunately, no solution in that log | 08:00 |
rinigus | but they refer to ubuntu touch where it works. | 08:00 |
rinigus | @TheVancedGamer: ping. did you managed to resolve your issue with dmsetup of system (see link to the log above) | 11:41 |
T42 | <TheVancedGamer> I gave up because of time constraints back then | 12:04 |
T42 | <TheVancedGamer> I'll try again some day | 12:04 |
rinigus | @TheVancedGamer: thanks! we will probably try to update lvm2 and see if it helps | 12:15 |
mal | rinigus: I have lvm update branch somewhere | 12:46 |
mal | I should sync it with upstream, I also have that libaio in my github https://github.com/mlehtima/libaio | 12:47 |
mal | I forgot to push that to github.com/sailfishos | 12:47 |
rinigus | mal: great! I started to look into packaging of libaio - would be happy to use yours :) | 12:49 |
mal | I will sync that to latest version also | 12:49 |
rinigus | thank you very much! | 12:50 |
mal | rinigus: libaio is now ready in my github, lvm2 to latest version is still wip | 12:58 |
rinigus | mal: nice! I am hacking some dirty lvm2 update meanwhile - we will switch over to your version as soon as it is ready | 13:02 |
mal | the reason why lvm2 was not merged was that I didn't have enough time to test it, maybe it's finally time to update it | 13:03 |
rinigus | I hope that new lvm2 will be able to run our dmsetup and, as a result, we could become your first testers | 13:05 |
rinigus | not that we can test much yet with non-booting fully to sfos device | 13:06 |
rinigus | let me know when some newer lvm2 will land and we can use that branch | 13:06 |
mal | what is the problem with dmsetup? | 13:09 |
T42 | <adampigg> getting a new device to port soon also | 13:11 |
rinigus | mal: we cannot create system_a on nagara devices. it was discussed last night, will find pastes that describe it | 13:12 |
rinigus | on device, it fails with "device-mapper: table: 253:2: linear: Invalid argument count" | 13:12 |
rinigus | on PC, @b100dian managed to mount super partition. corresponding config at https://paste.mozilla.org/RafuTi9i/raw | 13:13 |
T42 | <b100dian> So mal was two steps ahead, with aio prepared and all,can't wait to test tonight | 13:42 |
T42 | <b100dian> @adampigg which device are you eyeing? | 13:43 |
rinigus | mal: seems like issue is not new, @elros34 found a similar description from 2023 as well. see https://irclogs.sailfishos.org/logs/%23sailfishos-porters/%23sailfishos-porters.2023-03-29.log.html | 13:45 |
rinigus | @b100dian: lvm2/aio waiting at our obs repo already | 13:45 |
T42 | <b100dian> Great! | 13:47 |
T42 | <adampigg> getting sent the new volla (re @b100dian: @adampigg which devi...) | 13:53 |
T42 | <b100dian> The amoled one? | 13:57 |
T42 | <b100dian> I wonder who's manufacturing this time | 13:59 |
T42 | <leandrofriedrich> me | 14:02 |
T42 | <adampigg> didnt realise how pricey it was! https://www.kickstarter.com/projects/volla/volla-phone-quintus | 14:03 |
T42 | <b100dian> looks like a couple of oppo phones. good luck with the under-display fingerprint! 🙂 | 14:25 |
T42 | <b100dian> phones with this chipset https://www.gsmarena.com/results.php3?sChipset=137 | 14:25 |
*** deathmist1 is now known as deathmist | 14:44 | |
mal | rinigus: latest lvm2 is now here https://github.com/sailfishos/lvm2/tree/jb60487 only build tested so far | 15:05 |
rinigus | mal: thank you very much! we will test it tonight | 15:16 |
rinigus | I am sure @b100dian is also looking forward. will build on obs in a sec | 15:17 |
rinigus | @b100dian and mal : new lvm helped! we have partitions mounted | 18:21 |
rinigus | mal: now it reboots into bootloader | 18:21 |
rinigus | I remember you having a fix for that | 18:21 |
T42 | <b100dian> great, lvm update helped | 18:21 |
T42 | <adampigg> good to watch your progress :) | 18:21 |
T42 | <b100dian> you mean if you leave it running it reboots? Need to see some logs. I am curl-ing the lvm/asio packages now | 18:22 |
rinigus | @b100dian: I will upload hal packages to OBS with updated init script - the one with sleep instead of usleep | 18:25 |
rinigus | will take few minutes | 18:25 |
T42 | <b100dian> thanks | 18:25 |
rinigus | I actually reflashed it, to check if obs is up to date. wasn't in terms of init :) | 18:26 |
rinigus | if you let it boot into sfos, it does proceed after, but at some moment just reboots into bootloader. I remember mal asked about it, will have to see the logs | 18:27 |
rinigus | @adampigg: progress is relatively slow, but it is there :) | 18:27 |
rinigus | from grepping logs: seems its related to https://android.googlesource.com/platform/build/+/refs/heads/main/target/product/gsi/init.vndk-nodef.rc | 18:33 |
mal | yes, either set the property or patch that file to not reboot | 18:34 |
mal | I haven't yet found what the root cause of the issue is | 18:35 |
rinigus | sounds like patching the file is easier. now just will have to find where it is ... | 18:38 |
rinigus | I wonder whether this property is somewhere defined in aosp sources. will look around a bit | 18:39 |
T42 | <b100dian> rinigus: I don't have a bootloader reboot, but I do have a reboot https://paste.mozilla.org/erKpNKQ8/raw - do you have logcat for that early-init thingie? I didn't manage to launch logcat timely | 19:03 |
rinigus | no logcat. but if we look here then we can see where it is called from: https://android.googlesource.com/platform/build/+/refs/heads/main/target/product/gsi/init.gsi.rc | 19:05 |
rinigus | so, we need to have ro.vndk.version defined | 19:05 |
rinigus | I wonder if we have one in our getprop | 19:06 |
*** deathmist1 is now known as deathmist | 19:06 | |
rinigus | weird, but there are no files other than nodef in /system/system_ext/etc/gsi/ | 19:14 |
rinigus | mal and @b100dian: I had older logs from AOSP. in those logs, this service is parsed but fails. see https://paste.mozilla.org/H3xmUTkm/raw | 19:19 |
rinigus | so, we should probably just disable it. | 19:19 |
T42 | <b100dian> lol, so it doest reboot because 🤦 | 19:27 |
T42 | <b100dian> I'm still unsure if mine rebooted to bootloader - what does that mean, normal reboot? | 19:30 |
T42 | <b100dian> cant really disable an on early-init hook though, you mean editing the partition? | 19:32 |
rinigus | looking exactly for the same solution - how do I disable it... | 19:33 |
rinigus | as for reboot. for me, with usb connected, I reboot into "blue light" | 19:33 |
mal | rinigus: some other file is loading that based on build prop | 19:33 |
mal | forgot which, need to check | 19:33 |
mal | you can grep for gsi.*rc in /*/etc/init/* | 19:34 |
rinigus | the one in /system_ext/etc/init/init.gsi.rc | 19:34 |
rinigus | mal: is there a way to disable that file specifically from hybris side? as we do with disabled_services | 19:35 |
T42 | <b100dian> that's just | 19:35 |
T42 | <b100dian> import /system/system_ext/etc/gsi/init.vndk-${ro.vndk.version:-nodef}.rc | 19:35 |
rinigus | @b100dian exactly | 19:36 |
T42 | <elros34> mount /dev/null to this file | 19:37 |
T42 | <b100dian> ah, voice of reason! | 19:37 |
T42 | <b100dian> that could work ;) | 19:37 |
rinigus | but sounds like this is aosp bug. | 19:40 |
T42 | <b100dian> # mount -o bind /dev/null /system/system_ext/etc/gsi/init.vndk-nodef.rc | 19:40 |
rinigus | @elros34: how would I do that? using systemd service | 19:40 |
rinigus | will have to look it up | 19:41 |
T42 | <elros34> I guess probably n oraml mount unit will do the job | 19:41 |
T42 | <elros34> I think simple droid-hal-early-init .sh is not bad idea too | 19:43 |
rinigus | thanks, that would probably work indeed | 19:44 |
T42 | <b100dian> yeah, i added that to /usr/bin/droid/droid-hal-early-init.sh | 19:45 |
T42 | <b100dian> SELinux: Loaded vndservice context from: /vendor/etc/selinux/vndservice_contexts | 19:50 |
T42 | <b100dian> time to grap those selinux files from actual device/image | 19:50 |
rinigus | @b100dian I'll be afk. Will try to catch up tomorrow | 19:56 |
ecrn | things get super weird | 20:29 |
ecrn | the very first problem with hwcomposer was that it was segfaulting at exynos_open, due to messed memory leading to getExynosHWCService returning junk address | 20:30 |
ecrn | when I patched out the hwcomposer module to ignore return value of getExynosHWCService and assume simply that it failed, the hwcomposer worked to the extent which allowed me to run lomiri composer displaying loading screen | 20:31 |
ecrn | BUT the thing is | 20:32 |
ecrn | test_hwcomposer didn't segfault | 20:32 |
ecrn | and I made an isolated case from its code, that loads the hwcomposer module and calls hwc_open_1 | 20:33 |
ecrn | which in turn calls exynos_open | 20:33 |
ecrn | that also doesn't segfault | 20:33 |
ecrn | all these things don't segfault even on the "unpatched" hwcomposer module | 20:33 |
ecrn | only if it is the android.hardware.graphics.composer@2.4-service that loads the module, there is segfault | 20:35 |
ecrn | so I checked what else is done in the android sources for the composer 2.4 | 20:36 |
ecrn | the answer is: not much | 20:36 |
ecrn | after some boilerplate, the function below is reached iimmediately | 20:37 |
ecrn | https://android.googlesource.com/platform/hardware/interfaces/+/refs/tags/android-14.0.0_r75/graphics/composer/2.1/utils/passthrough/include/composer-passthrough/2.1/HwcLoader.h?autodive=0%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F#100 | 20:37 |
ecrn | so then, the fault mystery is getting interesting | 20:38 |
ecrn | is it possible that somehow the module loading is the problem? does libhybris use other rtld implementation for example for android "native" versus globc programs? | 20:39 |
ecrn | glibc | 20:39 |
ecrn | because the hw_get_module on android is a rtld action | 20:39 |
mal | does it load correct lib? | 20:40 |
ecrn | probably, how do I check? right now there is only one hwcomposer.*.so in my linking paths | 20:42 |
ecrn | or you mean some other lib? | 20:43 |
ecrn | or, maybe there is some stack size issue? | 21:03 |
ecrn | quite unlikely | 21:03 |
ecrn | copying bionic from original image crashes something so that it stops initializing usb | 21:20 |
mal | is that android 14 base? | 21:27 |
ecrn | android 12 hopefully | 21:27 |
ecrn | I mean, I have both 12 and 14 downloaded and I flashed 12 | 21:28 |
mal | I think nobody has used android 12 base before | 21:28 |
mal | at least not on sailfish device | 21:28 |
ecrn | xperia III can also work with android 12 base if the instructions are correct | 21:30 |
ecrn | so are things that much different? | 21:30 |
mal | not sure what you mean | 21:33 |
mal | if you mean the flashing instructions about which android to have before flashing sailfish then it's a different thing, sfos flashing on x10iii replaces everything except firmware partitions etc | 21:35 |
ecrn | ok | 21:35 |
T42 | <b100dian> rinigus: I pushed selinux and droid-hal-early-init.sh (edited on device, build not tested) | 21:40 |
T42 | <b100dian> I had to change odm.mount to sda76 instead of sda76_a (why?) and added CMDLINE+=audit=0 in my BoardConfig.mk for clarity in logs | 21:40 |
T42 | <b100dian> not sure why is there /odm and /odm_root as the latter was supposed to be linked to|from /odm/etc ? or is it only for Lineage | 21:40 |
T42 | <b100dian> With droid-hal-init masked and started after checking /odm mount I got a first logcat https://paste.mozilla.org/DB2HDAqy/raw | 21:40 |
T42 | <b100dian> We have tombstones in /data/tombstones ;) | 21:40 |
ecrn | replacing the com.android.runtime files with original ones yielded: | 21:44 |
ecrn | Nov 14 14:32:58 ubuntu-phablet lxc-android-ready[3501]: TLS relocations not yet implemented in libhybris | 21:44 |
mal | which libhybris version do you have? | 21:49 |
ecrn | probably some old one | 22:01 |
ecrn | it has only up to q.so | 22:01 |
ecrn | in the linker directory | 22:01 |
ecrn | Version: 0.1.0+git20240229+9dea23c-0ubports1+0~20240912111840.3+ubports20.04~1.gbp1dda99 | 22:02 |
mal | q is latest linker in lihybris but we add TLS relocation support on August 13th | 22:06 |
mal | *added | 22:06 |
ecrn | ok | 22:07 |
ecrn | I could update if you recommend to, but that only prevents systemd from continuing boot beyond the container (and possibly will prevent using glibc programs after that) with the original rom's libc | 22:08 |
ecrn | the container still booted, and has the same exact issue with hwcomposer | 22:09 |
ecrn | so I probably don't need to replace the bionic libs | 22:09 |
ecrn | trying to run /vendor/bin/hw/android.hardware.graphics.composer\@2.4-service directly makes it fork and then segfault | 22:19 |
mal | does strace or gdb reveal anything? | 22:23 |
mal | for gdb HYBRIS_ENABLE_LINKER_DEBUG_MAP=1 env var is helpful | 22:23 |
ecrn | hm, it didn't segfault after forking, just exited immediately | 22:26 |
ecrn | I mistaken logcat entry for the restarted service | 22:26 |
mal | what does logcat say? | 22:26 |
ecrn | nothing about the manually started file | 22:27 |
ecrn | but about the init service there are repeating segfaults as it tries to restart it | 22:27 |
ecrn | https://pastebin.k4be.pl/view/raw/b3e65721 | 22:29 |
mal | strace with manual start? | 22:29 |
ecrn | the gdb does in fact show something interesting | 22:30 |
mal | ok | 22:30 |
ecrn | BFD: /android/system/lib64/libnetd_client.so: unknown type [0x13] section `.relr.dyn' | 22:30 |
ecrn | warning: `/android/system/lib64/libnetd_client.so': Shared library architecture unknown is not compatible with target architecture aarch64. | 22:30 |
ecrn | and others like | 22:30 |
mal | maybe try updating libhybris | 22:31 |
ecrn | but does it even come into play in the container itself? | 22:32 |
mal | I have no idea how that container works | 22:32 |
ecrn | running /vendor/bin/hw/android.hardware.graphics.composer\@2.4-service through lxc-attach worked and gave segfault | 22:36 |
ecrn | running without the lxc-attach with the immediate exit seems to origin from it trying to open framebuffer devices and then failing, probably some environment issues, which is understandable | 22:37 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!