mortalglitch | just got back into my htc 10 via telnet after a reflash, still have no display. Checked the init log and the last line is ####### Beginning inject loop | 00:21 |
---|---|---|
mal | mortalglitch: do you connect to telnet port 2323? | 00:22 |
mortalglitch | 23 | 00:23 |
mortalglitch | i tried 2323 earlier and got connection refused | 00:23 |
mortalglitch | I tried the "echo "continue" >/init-ctl/stdin" and it seemed to trigger a reboot | 00:25 |
mal | check the init log to see if the mounting what successful | 00:28 |
mal | or if there are some messages about failing kernel config checks, better just pastebin the whole init.log | 00:29 |
mal | those are the two most likely causes of boot stopping at telnet 23 | 00:29 |
mortalglitch | pastebin.com/tRa5MytQ | 00:31 |
mal | mortalglitch: are you sure /dev/mmcblk0p63 is userdata partition? | 00:35 |
mal | what device is that? | 00:36 |
mortalglitch | HTC 10 | 00:36 |
mortalglitch | double checking mountpoints and making sure I didn't fat finger something | 00:37 |
mal | mortalglitch: init.log has "mounting /dev/mmcblk0p63 on /data failed: Invalid argument" which to me look like it could be the wrong partition | 00:37 |
mortalglitch | good call ty for taking a look. Will go back over the mounting and see what I can find. also I saw the "failed to boot init in real rootfs" | 00:38 |
mal | mortalglitch: yes the failure to boot message is because it cannot find the rootfs because mounting failed | 00:39 |
mortalglitch | the mmcblk0p63 is correct for the name of the block but the script looks like it's pointing at /dev/mmcblk0p63 when it should be /dev/block/mmcblk0p63, did I somehow trigger this through the fixup-mountpoints file? | 00:57 |
mal | no, the kernel init doesn't the /dev/block yet | 01:00 |
mal | mortalglitch: are you sure the userdata is not encrypted or something? | 01:00 |
mortalglitch | I had the device encrypted then wiped thing completely prior to starting this process. I'll see if I can find out if it still is somehow | 01:02 |
mal | mortalglitch: another possiblity, check what filesystem userdata has | 01:04 |
mal | some android devices have used something else than ext4 | 01:04 |
mortalglitch | using mount | grep "^/dev" - through adb everything there is reporting ext4 but block p63 isn't listed | 01:11 |
mal | so what is p63 then | 01:14 |
mortalglitch | haven't been able to figure out how to get it to list it's type | 01:17 |
mal | boot to android and check | 01:18 |
mal | or in recovery | 01:18 |
mortalglitch | trying most commands I can find and none seem to show the type of the block. | 01:34 |
T4 | <elros34> blkid, mount non of them? try mounting particular partition manually it should print error | 01:42 |
mortalglitch | ended up dumping twrp recovery log and it shows mcblk0p63 as ext4 | 01:50 |
mal | are you able to mount it manually in telnet 23 | 01:52 |
mortalglitch | the recovery log is saying that it's encrypted with a general default password if i'm reading this properly | 01:54 |
mal | so reformat the partition without encryption | 01:54 |
*** ChanServ sets mode: +v T4 | 02:33 | |
mortalglitch | seems to finally be able to mount ty all! now I can telnet into 2323 trying to find the hang here | 02:42 |
mortalglitch | /sbin/preinit is trigger Trying to run as user instance, but $XDG_RUNTIME_DIR not set, any clue on this one? I thought it was specific to selinux but I thought I disabled all that | 04:26 |
Umeaboy | Hi! Is it to much to ask to get a new build for jfltexx here: http://images.devaamo.fi/sfa/jfltexx/ ? | 04:32 |
Umeaboy | It's quite old. I'm thinking of purchasing the S4 again as I really like it. | 04:32 |
*** ChanServ sets mode: +v T4 | 08:26 | |
T4 | <adampigg> @eugenio_g7 i gave up and did the battery disconnect trick and it worked! | 09:57 |
piggz | mal: one thing to note when reviewing the Qtmm camerabin changes is that i tried to make it so that there was no change in bahavour if the properties dont exist | 10:12 |
eugenio | piggz, glad to read that the pad is booting again :) | 12:38 |
eugenio | ok | 13:16 |
eugenio | piggz, the pieces required to get UI working via mesa are now in my experimental repository: http://repo.merproject.org/obs/home:/eugenio:/latte-experiments/sailfishos_latest_i486/ | 13:16 |
piggz | eugenio: fab, i'll try them soon ... off out this afternoon | 13:18 |
piggz | what about other port status? | 13:19 |
piggz | BT, WIFI, sensors? | 13:19 |
eugenio | WiFi works, provided /system is mounted | 13:20 |
eugenio | BT and sensors don't | 13:20 |
eugenio | audio doesn't work too | 13:20 |
eugenio | WiFi advertises a random MAC address at every boot though | 13:23 |
eugenio | anyway, to get UI working these steps should be enough: | 13:23 |
eugenio | 1) remove libhybris | 13:24 |
piggz | cool ... im keen on BT so will work on that first | 13:24 |
eugenio | 2) install the following packages from my repository: "mesa-i915 mesa-i915-dri-i915-driver mesa-i915-libEGL mesa-i915-libGLESv2 mesa-i915-libgbm mesa-i915-libglapi mesa-i915-libwayland-egl" | 13:24 |
eugenio | 3) upgrade Qt with the recompiled version also available in the repository | 13:24 |
eugenio | 4) change the lipstick env variables as follows: https://github.com/g7/droid-config-latte/commit/ff5cacf868c06b810486666e2fd2d6e5606d2ad7 | 13:24 |
eugenio | 5) chmod -R 777 /dev, otherwise UI doesn't start (haven't actually see why, will take a look) | 13:24 |
eugenio | piggz, great | 13:24 |
piggz | eugenio: r0kk3rz i think posted a neat udev change that makes the touchscreen device predictable | 13:28 |
piggz | eugenio: also, did you have any issues mounting android partitions? i havnt looked into yet, but im sure /system wasnt mounted for me before I lost access to the tab | 13:31 |
mal | eugenio: could you grab output of evdev_trace -i (from mce-tools package) to see if the sensors are available as event devices | 13:37 |
r0kk3rz | not predictable, but it seems like theres some auto sensing in the evdevtouch plugin or something | 13:37 |
piggz | mal: my system.mount has the correct paths ... and when I mount manually it works fine... | 13:58 |
mal | piggz: could you show the mount file | 14:00 |
piggz | but when mounted with systemd, it times out waiting for | 14:00 |
piggz | Dec 01 13:53:17 Sailfish systemd[1]: dev-mmcblk0p11.device: Job dev-mmcblk0p11.device/start failed with result 'timeout'. | 14:00 |
mal | hmm | 14:00 |
piggz | https://bpaste.net/show/d6d0b3f3b5ec | 14:00 |
mal | piggz: increasing timeout doesn't help? | 14:01 |
piggz | mal: the device exists, and i can mount it | 14:02 |
piggz | i dont know where that depend job is from | 14:02 |
piggz | even me manually mounting now, it doesnt | 14:03 |
piggz | using systemctl start system.mount | 14:03 |
piggz | but using mount works fine | 14:03 |
piggz | no, increasing timeout didnt help | 14:07 |
piggz | have a think, im not in a rush out now for the afternnon, i'll check telegram for suggestions :D | 14:07 |
piggz | mal: a google sussgested config_fhandle, but i have that enabled | 14:14 |
piggz | mal: another suggestion is systemd waiting on udev to show the device exists... | 14:17 |
piggz | udevadm info --export-db | 14:17 |
piggz | but this doesnt print anything | 14:17 |
piggz | so maybe udev isnt working | 14:22 |
piggz | Dec 01 14:15:45 Sailfish systemd-udevd[2436]: unknown key 'DEVLINKS' in /lib/udev/rules.d/999-android-system.rules:268 | 14:23 |
piggz | Dec 01 14:15:45 Sailfish systemd-udevd[2436]: invalid rule '/lib/udev/rules.d/999-android-system.rules:268' | 14:23 |
mal | piggz: which rule is that line? | 14:27 |
piggz | SUBSYSTEM=="block", DEVLINKS=="* platform/pci0000:00/80860F14:00/by-name/android_persistent *|platform/pci0000:00/80860F14:00/by-name/android_persistent *|* platform/pci0000:00/80860F14:00/by-name/android_persistent|platform/pci0000:00/80860F14:00/by-name/android_persistent", MODE="0660", GROUP="system", OWNER="system" | 14:27 |
piggz | mal: https://bpaste.net/show/1dab9f8a0595 | 14:28 |
*** ChanServ sets mode: +v T4 | 14:41 | |
*** nic is now known as Guest74473 | 14:57 | |
eugenio | piggz, yup /system doesn't mount for me automatically but that is a moot point as I plan to get rid of it eventually :) | 14:58 |
eugenio | mal, this is the output of evdev_trace: https://pastebin.com/gQwZXMZZ | 14:58 |
eugenio | I don't think they're exposed as event devices :/ but that might be some firmware issue | 15:03 |
mortalglitch | /sbin/preinit is triggering "Trying to run as user instance, but $XDG_RUNTIME_DIR not set", any clue on this one? I thought it was specific to selinux but I thought I disabled all that | 15:10 |
mortalglitch | getting that through telnet 2323 trying to force it to finish initializing | 15:11 |
mal | mortalglitch: get output of dmesg and journalctl -a, also systemctl | 15:16 |
mal | eugenio: yep, no sensors in there | 15:17 |
eugenio | cherry trail uses this thing: https://www.kernel.org/doc/Documentation/hid/intel-ish-hid.txt | 15:18 |
T4 | <adampigg> We should be able to get sensors via hybris tho? But can we mix parts of hybris and native mesa? | 15:58 |
eugenio | I guess as long as we don't replace libegl/libgles/etc with the ones provided by libhybris it should work, but I think that they should be exposed as event devices | 16:12 |
eugenio | and there is something else wrong | 16:13 |
eugenio | the android init mixins load the modules manually (in fact, in /lib/modules there are a bunch of kernel modules for the various sensors) | 16:15 |
eugenio | after loading the hid-heci-ish.ko module I get this stack trace: https://pastebin.com/2xN73wsN | 16:17 |
eugenio | plus there seems that firmware loading is broken somehow | 16:18 |
eugenio | s/there seems/it seems/ | 16:18 |
eugenio | the kernel cmdline contains firmware_class.path=/system/etc/firmware but I've copied firmwares there so that they are available even though /system isn't mounted | 16:19 |
eugenio | the only device that correctly picks up the firmware is the wifi adapter, but I think that it doesn't search for it (the firmware is specified manually via the CONFIG_BCMDHD_FW_PATH kernel option) | 16:21 |
mal | eugenio: so it uses iio sensors? | 16:22 |
eugenio | yup | 16:22 |
mal | eugenio: sensorfwd has support for some iio sensors | 16:23 |
eugenio | great, so we could avoid hybris entirely | 16:24 |
mal | eugenio: I'll have a look how those should work | 16:25 |
mal | eugenio: pastebin output of ls -l /dev/ | 16:26 |
eugenio | great, thanks! | 16:27 |
eugenio | mal, https://pastebin.com/H3vKKbjn | 16:27 |
mal | wondering what sensors the device actually has? | 16:27 |
mal | eugenio: can you have a look at /sys/class and see if there is anything that looks like sensors or iio | 16:28 |
eugenio | nothing, but that could be because the kernel modules don't load properly (https://pastebin.com/2xN73wsN) | 16:30 |
eugenio | looking at /lib/modules I do have a bunch of sensor modules indeed: https://pastebin.com/F6s5p8E8 | 16:31 |
mal | can you find the firmware somewhere, maybe there is some symlink missing and it cannot find the firmware files? | 16:32 |
T4 | <adampigg> So much fun, kinda wish i wasnt out today!! | 16:34 |
eugenio | hm, no symlinks: https://pastebin.com/UjzZKVtf | 16:34 |
eugenio | dfw_sst.bin and fw_sst_22a8.bin should be related to the audio card | 16:35 |
eugenio | but the kernel doesn't manage to load them either | 16:35 |
eugenio | @adampigg: I won't steal all the fun, don't worry :) | 16:36 |
mal | there can be other places for firmware files like /firmware or something | 16:36 |
mal | eugenio: add symlink /etc/firmware pointing to /system/etc/firmware | 16:37 |
eugenio | yup done that, also /lib/firmware | 16:37 |
eugenio | hm there is /system/vendor/firmware though | 16:38 |
mal | what does it contain? | 16:39 |
mal | do you have /vendor? | 16:39 |
eugenio | https://pastebin.com/wqiYz1bU | 16:39 |
mal | can you point me to your kernel | 16:40 |
eugenio | yup /vendor exist too, /vendor/firmware has the same contents of /system/vendor/firmware (but actually /vendor is not a symlink, maybe I have copied it myself during my tests months ago and I don't remember) | 16:41 |
eugenio | kernel source: https://github.com/g7/android_kernel_xiaomi_latte | 16:41 |
mortalglitch | didn't find much in systemctl, dmesg ended up showing quite a bit https://pastebin.com/EjaqkNiq looks like at several points it's unable to read qcom,display-id or issue commands | 16:54 |
mal | olesalscheider: don't guess what is relevant, just show all | 16:55 |
mal | oops | 16:56 |
mal | wrong highligt | 16:56 |
mal | mortalglitch: have you masked droid-hal-init? | 16:56 |
mortalglitch | yeah, good call | 16:57 |
mortalglitch | did an unmask, rebooted : Systemctl https://pastebin.com/1awjmUpZ and jounralctl pastebin.com/zcUHLuti going back over them now | 17:09 |
mal | mortalglitch: which android base? | 17:11 |
mortalglitch | base off LineageOS 14.1 (android 7.1) | 17:13 |
mal | mortalglitch: so you are probably missing the 14.1 porting stuff mentioned in faq (linked in channel topic) | 17:14 |
mal | mortalglitch: search for "14.1 porting" in that | 17:15 |
mal | mortalglitch: so you need to run one script to create some needed symlinks | 17:15 |
mortalglitch | I had briefly saw that on r0kk3rz github earlier didn't see the exec it had mentioned and though the info may have been dated. Will check it out, thanks again mal | 17:16 |
mal | mortalglitch: there used to be more 14.1 specific things but now it's only running one script | 17:17 |
mal | in case you don't want to rebuild the image now then you can edit the script to create the links on the device but I recommend rebuilding the image so you won't be missing those next time | 17:20 |
eugenio | by loading the firmwares through userspace at least the audio card is now detected | 18:48 |
eugenio | too bad there aren't any ALSA UCM available for it (audio driver is rt5659) | 18:49 |
mortalglitch | keep making it a few steps forward at least, ran the script change rebuilt, reflashed los, flashed sailfish, was encrypted out of userdata again, had to fix that one more now i'm getting a ton of /dev/cpuset/xxxx : No space left on device | 20:07 |
mortalglitch | I tried some forums suggestions of push 0 to the .mem files in certain cpuset directories but I still can't start the services and if I reboot it seems to revert all the changes | 20:08 |
*** ChanServ sets mode: +v T4 | 20:10 | |
mal | mortalglitch: cpuset warnings or errors are irrelevant | 20:15 |
mal | mortalglitch: just get new versions of the logs I asked before | 20:16 |
mortalglitch | ah kk, will do | 20:17 |
mortalglitch | Systemctl : https://pastebin.com/HWFdAr2M Really Long DMESG: https://pastebin.com/iRCJE7YQ journalctl (fresh boot) : https://pastebin.com/nq7qTASV | 20:30 |
mal | mortalglitch: have you masked any systemd services? | 20:53 |
mortalglitch | didn't mask anything this go round | 20:54 |
mal | I didn't see any sign of it trying to start the UI in journalctl maybe it did reach that part yet, also output of /usr/libexec/droid-hybris/system/bin/logcat could be useful | 21:05 |
mortalglitch | logcat dump https://pastebin.com/9V2DGa6z | 21:12 |
mal | mortalglitch: could you get a new journalctl output but wait a bit longer after the boot before you get it so it will contain all | 21:28 |
mal | also check systemctl-user or systemctl --user whichever works | 21:30 |
mortalglitch | https://pastebin.com/JHzBg5fa long running journal dump | 21:32 |
mortalglitch | I did see systemd messages as I scrolled through that time | 21:32 |
mortalglitch | systemctl-user results in sysd "user session is not running" | 21:33 |
mortalglitch | since reboot autologin@100000 user@0 and user@100000 all failed | 21:34 |
mal | hmm, what could cause user session to fail | 22:02 |
mortalglitch | it's weird because after awhile I can systemctl start autologin@100000 and then start the other services | 22:17 |
mal | there shouldn't be need to run that manually, need to think more tomorrow | 22:46 |
mortalglitch | thank you for taking a look into it. I'm gonna to finish cleaning the house and then hack on it some more this afternoon. | 23:15 |
mortalglitch | 785hnrgn65 | 23:31 |
mortalglitch | pasted wrong address lol | 23:31 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!