**** BEGIN LOGGING AT Thu Mar 21 02:59:57 2019 Mar 21 07:19:41 JaMa: swrast can be dropped, I only use freedreno Mar 21 07:19:49 Morning! Mar 21 07:22:36 JaMa: also my own thud build took a while to boot, maybe I should analyze it Mar 21 08:01:39 Morning! Mar 21 10:37:18 Tofe: morning Mar 21 10:37:52 Tofe: my warrior build actually wasn't using gcc-7, so hammerhead failed to build http://jenkins.nas-admin.org/job/LuneOS/view/unstable/job/luneos-unstable_hammerhead/57/consoleFull and could be the reason why tissot didn't boot for me, will fix my backport and trigger again Mar 21 10:41:20 JaMa: These "warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]" are due to gcc8 right? They should all be patched in a similar way to https://patchwork.ozlabs.org/patch/909905/ for example? Mar 21 11:10:23 IIRC yes, but these aren't the fatal issue Mar 21 11:10:35 the asm in uacess is Mar 21 11:11:22 and my gcc-7 backport doesn't work, damn need to double check gcc-cross-initial removal with 7, maybe it won't be as easy as in 8 Mar 21 11:15:06 and using gcc7 with warrior might be a bit difficult as well Mar 21 11:15:07 | aarch64-webos-linux-gcc: error: unrecognized command line option '-fmacro-prefix-map=/home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/tissot-webos-linux/linux-xiaomi-tissot/3.18.31+gitrAUTOINC+a8412322dc-r0=/usr/src/debug/linux-xiaomi-tissot/3.18.31+gitrAUTOINC+a8412322dc-r0' Mar 21 11:15:30 so we would need to revert some of the changes which assume that gcc-8 is the oldest one being used Mar 21 11:16:07 fetching http://build.webos-ports.org/luneos-unstable-warrior/images/tissot/ for another test with gcc8 Mar 21 11:40:08 good news libgcc-initial probably doesn't build from the same reason config.log shows: Mar 21 11:40:11 i586-webos-linux-gcc: error: unrecognized command line option '-fmacro-prefix-map=/home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/i586-webos-linux/libgcc-initial/7.3.0-r0=/usr/src/debug/libgcc-initial/7.3.0-r0' Mar 21 11:52:51 JaMa: let me look at that consolelog, maybe with my rudiments in asm ... (or maybe not... ) Mar 21 11:55:12 Isn't the solution simply to disable CONFIG_KCOV_INSTRUMENT_ALL ? Mar 21 12:02:20 Tofe: see our older discussion in https://webos-ports.org/wiki/Repository_Layout#kernel_and_gcc8 Mar 21 12:02:52 I haven't tried with CONFIG_KCOV_INSTRUMENT_ALL Mar 21 12:04:03 the image from http://build.webos-ports.org/luneos-unstable-warrior/images/tissot/ didn't boot as well (haven't tried to get logs yet), but gcc-7 should be fixed in warrior now, running new builds with it Mar 21 12:05:03 JaMa: Warrior should be out soon right? Mar 21 12:05:07 April is the schedule Mar 21 12:05:19 Let me download as well and see if I can pull some logs Mar 21 12:05:27 It's usually systemd or glibc or a combination Mar 21 12:05:55 warrior = OE master branch right? Mar 21 12:15:01 webos-ports-setup warrior Mar 21 12:15:14 warrior branches where available + master branches Mar 21 12:16:35 mmh the real kind of fix we'd need is things like this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/h8300/kernel/sim-console.c?id=811d1b0e65bed442050d62a48c39263f4c5b2d68 Mar 21 12:17:05 assigning a const register variable for use in the asm code doesn't work well with gcc 8.x Mar 21 12:21:28 hold your horses for a bit longer, lets verify that warrior is usable with gcc-7 Mar 21 12:21:44 then we can test with gcc-8 in separate step on top Mar 21 12:22:36 ok :) Mar 21 12:24:00 I'm updating that git svn mirror of vbox with latest code Mar 21 12:25:13 so, my best shot for my next rebuild would be qemux86 on thud, right? Mar 21 12:25:43 that way I can investigate a bit this vbox API Mar 21 12:26:09 which will be quite annoying for our sumo users too, if I understand correctly Mar 21 12:26:57 qemux86 in thud isn't worse than it was in sumo or pyro, maybe check the long boot on tissot you mentioned before Mar 21 12:27:29 that's probably new regression and would be nice to resolve before upgrade to thud Mar 21 12:28:16 so vbox issue appears... when ? Mar 21 12:28:26 have anyone tried thud on hammerhead? http://build.webos-ports.org/luneos-unstable-thud/images/hammerhead/ Mar 21 12:28:30 (but yes, I'll look at the long tissot boot first) Mar 21 12:28:52 Tofe: since I've upgraded mesa/vbox modules/linux-yocto some time ago in pyro Mar 21 12:29:17 ah ok, it was already in pyro, I though it was only rocko+ Mar 21 12:30:16 * JaMa flashing thud on hammerhead Mar 21 12:31:04 I'm optimistic. Mar 21 12:34:32 there is PR for qt 5.12.2 (from 5.12.1), we can do that on top of warrior as well :) Mar 21 12:35:11 I feel like warrior will be a challenge... Mar 21 12:35:23 good naming, then. Mar 21 12:36:26 * Tofe had forgotten that qtwebengine's synchronous message patch needs a rebase... Mar 21 12:39:23 thud on hammerhead seems to be stuck booting on Google logo, will give it a bit more time Mar 21 12:40:20 so much for my optimism... Mar 21 12:40:32 hehe Mar 21 12:41:14 if it has the same boot time issue as tissot, it might take a while though Mar 21 12:41:37 it could also be that the initrd script is slightly unstable and sometimes doesn't boot Mar 21 12:58:49 still nothing Mar 21 13:01:17 you've tried a reboot too? Mar 21 13:02:02 yes Mar 21 13:02:19 well this build doesn't have the fix for wayland-egl yet, should have added it there as well Mar 21 13:04:06 that shouldn't prevent luna-next starting Mar 21 13:06:12 true, but will cause another long build after warrior is finished Mar 21 13:07:29 btw is it expected that TWRP warns that no OS was installed after sideload finished OK? Mar 21 13:08:10 there were also 3 xfer errors written after the "kernel flashed" message, so maybe something in the updater failed already, but wasn't catched by the script Mar 21 13:08:34 with failing usb3 hub I've seen it few times before Mar 21 13:32:03 updater log https://paste.ubuntu.com/p/pCBQ32Vd73/ Mar 21 13:42:43 I don't see anything wrong in hammerhead/thud last_kmsg: http://dpaste.com/22AR20C and this time I've checked /data/luneos and /data/hallium-rootfs after updater and all looked reasonable as well Mar 21 13:42:49 trying the same on tissot Mar 21 13:48:43 JaMa: Yeah nothing too suspicious in the log actually Mar 21 13:50:10 updater log on tissot shows that it was killed and ERROR: Failed to extract LuneOS on the internal memory. Propably not enough free space left to install LuneOS? Mar 21 13:50:23 JaMa: I have hte same on mine Mar 21 13:50:26 but it's shown only in recovery.log, not on the display when running the sideload :/ Mar 21 13:50:30 I guess I should factory reset it Mar 21 13:50:34 recoverly.log: https://paste.ubuntu.com/p/5SyVPMwsq3/ Mar 21 13:50:51 Mine stops adb sideloading at 3% and TWRP shows like it's successful but it isn't Mar 21 13:51:09 Also "out of space' so I guess I messed up partitions somehow at some point Mar 21 13:51:13 and indeed there is only /data/luneos_tmp_extract/ Mar 21 13:51:35 for me it was around 47% for both hammerhead and tissot Mar 21 13:53:57 yes, it's the tar being killed: Mar 21 13:53:58 ~ # tar --numeric-owner -xzf /data/webos-rootfs.tar.gz -C /data/luneos_tmp_extract2 Mar 21 13:54:01 Killed Mar 21 13:54:16 by OOMK Mar 21 13:54:16 if in doubt, rm -rf /data/luneos* before flashing Mar 21 13:54:16 <3>[ 610.599067] Out of memory: Kill process 1713 (tar) score 1626 or sacrifice child Mar 21 13:54:20 <3>[ 610.599072] Killed process 1713 (tar) total-vm:6152944kB, anon-rss:3452680kB, file-rss:2670608kB Mar 21 13:56:59 interesting it fails on the same place Mar 21 13:57:00 88.8M /data/luneos_tmp_extract Mar 21 13:57:00 88.8M /data/luneos_tmp_extract2 Mar 21 13:57:00 216.0K /data/media Mar 21 13:57:00 606.6M /data/webos-rootfs.tar.gz Mar 21 13:58:38 md5sum of /data/webos-rootfs.tar.gz is the same on the device and in the zip unpacked on host, so it's not somehow broken gz Mar 21 14:02:06 doing gzip -cd separately doesn't get killed Mar 21 14:03:24 and then tar still gets killed :/ Mar 21 14:10:45 that's new Mar 21 14:11:48 busybox tar on my host unpacks the same archive without any noticeble memory-usage spikes Mar 21 14:12:02 might be a bug in busybox included in twrp :/ Mar 21 14:12:15 what twrp are you using on tissot? cosmicdan? Mar 21 14:12:43 I'm on twrp-3.2.1-2.5-cosmicdan.img Mar 21 14:13:02 looks similar, but not sure mine was from cosmicdan Mar 21 14:13:11 BusyBox v1.22.1 bionic (2018-08-18 14:48 +1000) multi-call binary. Mar 21 14:13:33 https://dl.twrp.me/tissot/ 3.2.1 image there Mar 21 14:13:50 cosmicdan's was the only one working for me when tissot was half dead with touchscreen and then pie Mar 21 14:14:16 ok, let me try that one Mar 21 14:14:53 the error shown in twrp ui after sideload finished is: "E:recv error on uevent" Mar 21 14:15:36 looks like a cable issue? but if md5sum is correct, it's unlikely Mar 21 14:16:22 593d607eb8780efe16b60787dc85d39b twrp/twrp-3.2.1-0-tissot.img Mar 21 14:16:31 this one doesn't seem to work for me Mar 21 14:17:11 booting it from fastboot, stays on fastboot logo (fastboot protocol stops responding) and after a while the phone reboots Mar 21 14:17:41 trying again Mar 21 14:18:53 3 times the same Mar 21 14:20:14 I've factory reset mine now to see if I can get it to work Mar 21 14:20:38 twrp-3.2.3-1-tissot.img starts, lets see if it can unpack :) Mar 21 14:21:04 BusyBox v1.22.1 bionic (2018-10-04 22:46 +0000) multi-call binary. Mar 21 14:22:05 killed as well Mar 21 14:22:22 damn, how does it use 6+ GB to unpack 1.8G rootfs Mar 21 14:22:50 from 1.7G tar file Mar 21 14:23:56 I guess we can include out own tar binary with updater script, let me try that Mar 21 14:24:07 or own busybox Mar 21 14:27:54 heh everything is plot against me, now I cannot even fetch 2 .ipk files from our build server Mar 21 14:28:56 there is a minute delay between "HTTP request sent, awaiting response..." and the response.. that might be the same cause why rsync to milla is quite slow recently for jenkins jobs a well Mar 21 14:29:29 not that milla would be busy: top - 14:29:09 up 75 days, 8:27, 3 users, load average: 1.01, 0.65, 0.31 Mar 21 14:32:15 ka6sox: novaldex: can you give me access to nginx logs on milla? I don't have my own account on milla only going there as jenkins user Mar 21 14:33:05 ka6sox: novaldex: even better if you have some logs analyzer handy which would show which files are being downloaded and how often Mar 21 14:34:37 lol, your day is doomed Mar 21 14:37:07 neither tar.tar nor busybox can be easily used OOTB, because /lib/ld-linux-aarch64.so.1 isn't in TWRP Mar 21 14:37:25 whole 2019 is doomed it seems Mar 21 14:38:27 not giving up yet though Mar 21 14:38:28 /data/luneos_tmp_extract7-tar.tar # /data/luneos_tmp_extract/lib/ld-linux-aarch64.so.1 ../tar.tar Mar 21 14:38:32 ../tar.tar: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Mar 21 14:39:37 with LD_LIBRARY_PATH added as well it was unpacked fine (with just warnings about timestamps in future) Mar 21 14:40:57 our busybox unpacked it fine as well Mar 21 14:41:50 JaMa: We've seen issues with TWRP before Mar 21 14:41:59 Certain versions would work, others not Mar 21 14:43:57 heh, best news of today is that tar.tar gets unpacked from our rootfs before tar gets killed Mar 21 14:44:10 so if it fails updater can use: LD_LIBRARY_PATH=/data/luneos_tmp_extract/lib/ /data/luneos_tmp_extract/lib/ld-linux-aarch64.so.1 /data/luneos_tmp_extract/bin/tar.tar to unpack the rest Mar 21 14:44:16 but it's a bit ugly :) Mar 21 14:44:28 a *bit* Mar 21 14:44:59 well lets see if it boots after I deploy it manually first Mar 21 14:45:11 Don't forget to flash the kernel ;) Mar 21 14:45:21 maybe this whole ugliness is the smallest of the issues we have Mar 21 14:45:22 (in boot_a) Mar 21 14:45:32 probably already have kernel from the updater, but will recheck Mar 21 15:00:25 behold lord ugly https://github.com/shr-project/android-update-package/commit/a15dbbe778c6691d8f91767557dc685134e1ed33 Mar 21 15:05:18 JaMa: we can prefix an executable with a library name ? That's new to me Mar 21 15:06:44 looking at https://github.com/james34602/update-binary/blob/master/jni/update-binary/install.c#L970 the script for update-binary cannot easily check the return code from run_program to check if webos_deploy.sh was executed fine :/ Mar 21 15:07:35 Tofe: the ld-linux-aarch64.so.1 ? that's the loader for the binary (interpreter) Mar 21 15:08:03 Tofe: so you can use it to execute the binary (like you can execute the interpreter for some script instead of depending on the shebang inside the script) Mar 21 15:08:10 JaMa: i'm sure I can sort some access for you. No analyzer to hand at the moment unfortunately! Mar 21 15:09:12 JaMa: oh, ok ! Mar 21 15:09:14 Tofe: without that you get a bit misleading "not found" error when you try to execute binary which has interpreter which doesn't exist, e.g. in this case: Mar 21 15:09:17 tar.tar Mar 21 15:09:19 /data # ./tar.tar Mar 21 15:09:22 /sbin/sh: ./tar.tar: not found Mar 21 15:09:53 the file tar.tar _does_ exist Mar 21 15:09:54 -rwxrwxrwx 1 root root 462.8K Mar 20 2019 tar.tar Mar 21 15:15:26 novaldex: ok, can you install https://goaccess.io/ ? Mar 21 15:15:40 jenkins@milla:~$ apt-cache search goaccess Mar 21 15:15:40 goaccess - log analyzer and interactive viewer for the Apache Webserver Mar 21 15:15:53 the package is available and looks like it should support nginx as well Mar 21 15:16:34 or just give me cow powers Mar 21 15:17:33 tissot booted now with the thud image, touchscreen seems to be busted again :/ Mar 21 15:19:22 ot it might be the qt crash due to wayland-egl, but I couldn't unlock the screen in TWRP already so I guess it's touchscreen FW again Mar 21 15:20:01 * JaMa looking for OTG Mar 21 15:27:55 damn this 2019, first mouse battery, then it didn't work with 2nd mouse as well, so guess the UI is really broken, adb didn't work as well, now rebooted to TWRP and busted TS is confirmed Mar 21 15:28:42 * JaMa reading logs to find out which kernel was the one to correctly update the TS firmware, hopefully it will work again Mar 21 15:32:36 log/memory refresher: Mar 21 15:32:36 dmesg.tissot_images_7.12.19_7.1:[ 1.740509] ft5435_ts 3-0038: Firmware version = 10.0.0 Mar 21 15:32:40 dmesg.tissot_images_7.12.19_7.1:[ 1.740676] ft5435_ts 3-0038: Current firmware: 0x0a.0.0 Mar 21 15:32:43 dmesg.tissot_images_7.12.19_7.1:[ 1.740681] ft5435_ts 3-0038: New firmware: 0x10.0.0 Mar 21 15:32:46 dmesg.tissot_images_7.12.19_7.1:[ 12.450463] ft5435_ts 3-0038: Firmware version = 16.0.0 Mar 21 15:33:08 future JaMa: bad TS fw is 0x0a, good one is 0x10 and 7.12.19_7.1 is what you need to flash Mar 21 15:40:16 one more build issiue with gcc-7 in thud, but getting closer! Mar 21 15:45:43 JaMa: done, both of, please try Mar 21 15:47:20 novaldex: ty Mar 21 15:48:32 novaldex: cannot ssh even as jenkins which worked ~ hour ago Mar 21 15:48:35 novaldex: jenkins@bonaire:~$ ssh milla.nao Mar 21 15:48:54 novaldex: sorry, it's just _really_ slow Mar 21 15:48:57 I noticed milla was being very sluggish for me, but no evidence why yet! Mar 21 15:49:05 certainly no rogue process running away Mar 21 15:59:00 I do hope I'll never experience that nasty fw issue... Mar 21 16:00:24 novaldex: even rsync jobs from the build servers took almost double time for last 1-2 days Mar 21 16:01:03 looks like webosose has more hits than out images :/ Mar 21 16:01:16 will publish report for longer period soon Mar 21 16:06:17 JaMa: Well OSE does a lot more publicity ;) Mar 21 16:06:24 We should work on that too I guess Mar 21 16:09:05 http://build.webos-ports.org/build.webos-ports.org.access.html Mar 21 16:19:03 Tofe: it's not that nasty once the fix is known, reflashing 7.12.19_7.1 fixed it again Mar 21 16:21:54 http://build.webos-ports.org/downloads.webos-ports.org.access.html doesn't look used much Mar 21 16:22:11 http://build.webos-ports.org/feeds.webos-ports.org.access.html Mar 21 16:23:17 http://build.webos-ports.org/sources.openembedded.org.access.html this is interesting, looks like the sources.oe.org domain was moved few months ago (which matches with info from halstead) Mar 21 16:24:02 http://build.webos-ports.org/sources.webos-ports.org.access.html Mar 21 17:01:42 Tofe: Herrie|Laptop: we should try to integrate this into our webos-deploy.sh https://forum.xda-developers.com/showthread.php?t=1023150 Mar 21 17:01:59 or use some other update-binary Mar 21 17:13:12 testing it now Mar 21 17:13:28 JaMa: i can show my solution (for webos OSE) in a minute Mar 21 17:14:45 * nizovn is uploading his OSE work before long break Mar 21 17:14:56 JaMa: https://gitlab.com/nizovn/meta-smartphone/commit/36a75340ba1a65c8d3f533a9faa608fa73c24d07 Mar 21 17:15:32 basically use not broken static busybox for reliable installation Mar 21 17:18:15 Tofe: Yeah would be useful I guess to integrate. Will give a bit better feedback about things Mar 21 17:19:31 nizovn: looks good, pity that it uses binary blob in meta-android Mar 21 17:19:55 the ui_print didn't work on first try, but probably some small issue Mar 21 17:21:04 JaMa: true, i'm a bit ashamed of published wip code, but i really don't have time to beautify it... Mar 21 17:21:49 just throwing what i have now Mar 21 17:44:03 understood Mar 21 17:44:52 Herrie|Laptop: Tofe: the ui_print seems to work partially, but the output still ends only in recovery.log, not on the screen, any idea why? Mar 21 17:48:17 JaMa: I don't have any knowledge about recovery scripting, unfortunately... Mar 21 17:51:28 nvm it works now Mar 21 17:52:17 the update binary, isn't called update_binary, nor update-binary as in our .zip file, but just /tmp/updater, that's why the ps call never catched the right line and correct FD Mar 21 17:55:38 oh, ok ! Mar 21 18:04:21 https://github.com/shr-project/android-update-package/commit/cd361b3beeb79caf91f48e34888b9b3b9e918ec0 Mar 21 18:04:26 https://github.com/shr-project/android-update-package/commit/51bb0acedf1640827f51d20fb88cd215b83a567e Mar 21 18:05:01 will send PR, I guess we can merge this (the ui-print will need small tweak in the recipe), it's ugly but it doesn't make things worse and it helps in some cases Mar 21 18:05:21 at least it will show when it fails and we'll know if the tar gets killed for you as well or not Mar 21 18:17:19 yep Mar 21 18:18:06 for the long boot, the logs show it, though it's not very useful: https://bpaste.net/show/0068b7158f37 (regular boot) vs https://bpaste.net/show/95edac70a739 (looong boot) Mar 21 18:19:35 there now seems to be a 1min delay between each "subsys-pil-tz 1de0000.qcom,venus: venus: Failed to locate venus.mdt" Mar 21 18:25:11 maybe linux-firmware changes, but strange when it fails in both cases anyway Mar 21 18:38:55 Tofe: To me that indicates missing firmware Mar 21 18:39:07 This is Tissot or Hammerhead mainline? Mar 21 18:39:19 Herrie|Phone: yes, but it was also there before... Mar 21 18:39:22 Tissot Mar 21 18:39:39 Well yes but it should be fixed anyway Mar 21 18:40:22 Then we'll need either to set some driver as module, or provide the firmware in the initrd Mar 21 18:40:24 It's used for hw video decoding Mar 21 18:40:35 By the looks of it Mar 21 18:40:41 probably yes Mar 21 18:41:08 Could be it's just missing in our proprietary Tissot blobs or at wrong location Mar 21 18:41:16 We hacked these Tissot repos together Mar 21 18:41:28 So I wouldn't be surpised if something is missing Mar 21 18:42:16 Herrie|Phone: we're still in the initrd script, at the veeery beginning --> no rootfs yet, no halium, nothing Mar 21 18:43:50 Ah ok Mar 21 18:44:33 mainly I wonder what the difference might be, because nothing changed for defconfig... Mar 21 18:56:14 Yes well maybe something changed that early in Yocto parts? Mar 21 18:57:44 in initrd ? or maybe gcc ? I don't know... Mar 21 19:00:28 gcc should be almost the same in thud Mar 21 19:01:13 there are those android_kernel.bbclass changes I made, but not sure how they would cause this Mar 21 19:02:43 Tofe: how does tissot behave with the delay? is it stuck still on white Mi screen, or does it go black then for those 2 mins? Mar 21 19:07:01 JaMa: stuck on Mi screen yes Mar 21 19:07:49 * Tofe was about to ask "you don't have the same?", but then remembered about the doomed day Mar 21 19:17:38 hehe, I might have the same at first (the Mi screen is there for quite long), but then it goes all black and nothing is shown, without adb.. so yes doom Mar 21 19:18:00 but I was sideloading .zip with slightly busted webos_deploy.sh, so it might be my fault for a change Mar 21 19:18:35 the last comment https://github.com/webOS-ports/android-update-package/pull/4 is because of modified webos_deploy.sh from previous ui-print tests.. Mar 21 19:25:21 JaMa: ok, so the issue is identified? Mar 21 19:26:59 yes, doing the final test now, then will ad one more commit with just small cleanup Mar 21 19:27:33 the luneos-package change will need just SRCREV bump (the chown +x like webos_deploy.sh has, won't be needed as the perms are set by updater-script on target Mar 21 19:29:58 ok great Mar 21 19:36:51 looks like web.skype.com doesn't work in chromium anymore. bye bye skype. Mar 21 19:43:14 even chromium ?! Mar 21 19:43:43 From what I understood, it *should* support it Mar 21 19:44:05 (I'm a Firefox user anyway.......) Mar 21 19:49:02 not sure, their message states only edge and chrome. but maybe my chromium build is considered too old somehow, as it's 70 and latest is 72. Mar 21 19:49:46 firefox is blocked for sure, yes. seems now qt based browsers too Mar 21 19:50:16 At this point, why not block chrome too... Mar 21 19:50:35 and disable web.skype.com along the way Mar 21 19:51:09 :) Mar 21 19:57:55 Tofe: can you please try to sideload http://build.webos-ports.org/luneos-unstable-thud/images/tissot/luneos-dev-package-tissot--unstable-0-37.zip Mar 21 19:58:07 just to verify that tar does or doesn't get killed for you? Mar 21 19:59:38 heh, I'm actually flashing warrior, not thud, so : http://build.webos-ports.org/luneos-unstable-warrior/images/tissot/luneos-dev-package-tissot--unstable-0-38.zip Mar 21 19:59:54 this is the one with boots to black screen Mar 21 20:00:50 but no /proc/last_kmsg Mar 21 20:02:18 one moment, I'll slooowly download it :p Mar 21 20:02:23 (compared to Herrie|Phone !) Mar 21 20:06:26 encryption should be removed before flashing LuneOS? Mar 21 20:06:46 Yes, iirc Mar 21 20:07:02 ok, that might explain the black screen Mar 21 20:07:22 when flashing the stock 7.1 to fix touchscreen I got /data encrypted again Mar 21 20:08:07 at least twrp says so: I:Device is encrypted with the default password, attempting to decrypt. Mar 21 20:09:03 ok, yes, it will not help luneos Mar 21 20:21:38 Tofe: thud started for me, just no wizzard Mar 21 20:22:19 btw: how do you authorize adb connect from desktop from LuneOS? or is it possible only from installed android? Mar 21 20:23:15 mmh only from installed android Mar 21 20:23:34 ok, let me reflash again :) Mar 21 20:23:54 warrior sideloading in progress... Mar 21 20:23:54 but I'm getting optimistic for warrior Mar 21 20:24:23 well, I know about that feeling :p Mar 21 20:25:35 I got the wizzard in some previous image, and now I believe that it was that 0-38 built with warrior after flashing it manually Mar 21 20:25:36 no OOM here Mar 21 20:25:47 Tofe: did you check recovery.log? Mar 21 20:25:52 nope :) Mar 21 20:25:52 it's not shown on the screen Mar 21 20:26:03 oops, too late, already rebooting Mar 21 20:26:06 on screen it just says successfully installed :) Mar 21 20:26:49 ok, then from running system check /etc/luneos-version to confirm that you have 0-38 version Mar 21 20:28:39 "1.0-unstable-unstable-0-38" Mar 21 20:28:49 firstuse shows up Mar 21 20:28:50 looks very unstable Mar 21 20:29:15 isn't it Mar 21 20:29:19 firstuse was broken by wayland-egl? Mar 21 20:29:26 yes, also Mar 21 20:29:42 all wayland clients Mar 21 20:29:53 ok, that might explain it warrior has the fix already, thud doesn't Mar 21 20:30:18 mmh after firstuse is closed it doesn't switch to main mode, it stays in firstuse mode (no gesturearea) Mar 21 20:30:34 and the boot was delayed for you like in thud? Mar 21 20:30:39 yes Mar 21 20:30:58 ok, finishing setting the stock image, will re-sideload both after Mar 21 20:34:09 of course doom needs to hit me again to break my optimism Mar 21 20:35:03 twrp didn't start after first reboot from stock where I've enabled adb.. Mar 21 20:36:11 if you reflashed everything, that includes recovery, of course Mar 21 20:39:01 it didn't start after "fastboot boot twrp/twrp-3.2.1-2.5-cosmicdan.img" Mar 21 20:41:16 that's more annoying, yes... Mar 21 20:41:58 maybe you should just name it day lost to fate, and try tomorrow ;) Mar 21 20:42:11 and again there might be something still wrong with ui-print, damn Mar 21 20:42:39 s/name it/call it a/ Mar 21 20:42:50 yes I plan call it a day soon once I get those 2 dmesgs with delayed boot Mar 21 20:43:15 ok :) Mar 21 20:43:46 anyone seen WARNING: linker: error reading config file "/system/etc/ld.config.txt" for "/sbin/busybox" (will use default configuration): error reading file "/system/etc/ld.config.txt": Too many symbolic links encountered Mar 21 20:43:50 before? Mar 21 20:44:23 it might be caused by my changes to webos_deploy.sh for ui-print or it might always be there just not shown/seen without ui-print Mar 21 20:44:35 and it seems to happen only when there is some OS in /system Mar 21 20:45:41 it's shown even before webos_deploy.sh is executed, so I guess I'm not to blame here :) https://paste.ubuntu.com/p/H9V3tFm4Mk/ Mar 21 20:50:29 never saw that before, no Mar 21 20:51:29 JaMa: I don't think you're to blame either Mar 21 20:53:13 adb permissions are stored somewhere on /data? Mar 21 20:53:36 I have no idea ! Mar 21 20:53:41 ok Mar 21 20:53:53 it's always been a mystery to me Mar 21 20:54:10 after wiping /data to remove encryption, I again get adb: error: failed to get feature set: insufficient permissions for device: user in plugdev group; are your udev rules wrong? Mar 21 20:54:16 when trying to use adb with luneos installed Mar 21 21:00:46 heh? Mar 21 21:50:57 Tofe: data/misc/adb/adb_keys stores the keys Mar 21 21:51:23 it looks like authorized_keys from ssh inside Mar 21 21:52:28 so wiping /data to remove encryption wiped also the access Mar 21 21:57:24 heh and of course, I need better busybox to restore the backup after formating the /data :) Mar 21 21:57:27 Killed Mar 21 21:57:37 /data # tar xf data-developer-adb.tar.gz Mar 21 21:59:58 and when I gave up and go to kitchen for a beer instead I find out that we run out of beer as well, FML Mar 21 22:27:20 Tofe: I'm seeing the same 1+1 minute delay when booting thud Mar 21 22:27:28 I'm also seeing couple [ 148.723205] init: couldn't write 1224 to /dev/cpuset/system-background/tasks: No space left on device Mar 21 22:27:53 whole dmesg with thud: http://dpaste.com/2MJJ5FQ Mar 21 22:39:03 whole dmesg with warrior: http://dpaste.com/0KTH9CJ Mar 21 22:48:29 the diff between these 2 (without timestamps) doesn't show anything surprising on first glance http://dpaste.com/2SQCM2H Mar 21 22:48:49 will compare with sumo Mar 21 22:49:33 hurry before my temporary luck (or just lower doom radiation) lasts :) Mar 21 22:55:18 hmm unpacking sumo also gets tar killed Mar 21 23:06:27 latest testing image from jenkins http://build.webos-ports.org/luneos-testing/images/tissot/luneos-dev-package-tissot-20190318183124-testing-0-34.zip still suffers from tar: skipping unsafe symlink to '/system/vendor' in archive, set EXTRACT_UNSAFE_SYMLINKS=1 to extract Mar 21 23:10:00 ah previous fix was in initramfs-boot-android: https://github.com/webOS-ports/meta-webos-ports/pull/311/commits/70b9092d579c9456f6769b33e31e3bea7ea8891a Mar 21 23:11:09 but I'm seeing it from tar in TWRP when extracting luneos, because I'm using busybox's tar after the TWRP's was killed, damnII Mar 21 23:43:06 dmesg with luneos-testing-0-25-pyro: http://dpaste.com/3CE6J58 Mar 21 23:46:25 the firmware fails to load with pyro as well, but doesn't cause 60s delay: Mar 21 23:46:26 luneos-testing-0-25-pyro/dmesg.txt:[ 5.969702] msm_vidc: info: Opening video instance: ffffffc0db130000, 1 Mar 21 23:46:29 luneos-testing-0-25-pyro/dmesg.txt:[ 6.203154] msm_vidc: err: Failed to download firmware Mar 21 23:46:40 luneos-unstable-0-37-thud/dmesg.txt:[ 6.061009] msm_vidc: info: Opening video instance: ffffffc0db812000, 1 Mar 21 23:46:43 luneos-unstable-0-37-thud/dmesg.txt:[ 66.080239] msm_vidc: err: Failed to download firmware Mar 21 23:47:23 the diff again doesn't show anything strange (to me) http://dpaste.com/03QV6FC Mar 21 23:49:29 last try on luneos-testing-0-34-sumo and that's it for today Mar 21 23:54:11 luneos-testing-0-34-sumo dmesg: http://dpaste.com/34NPBTQ Mar 21 23:54:28 and the diff between pyro and sumo: http://dpaste.com/04AFN22 **** ENDING LOGGING AT Fri Mar 22 02:59:57 2019