**** BEGIN LOGGING AT Fri Oct 06 03:00:01 2017 Oct 06 05:49:16 JaMa: Tried updated defconfig with all required kernel flags. Seems issue is likely caused by CONFIG_SECCOMP_FILTER which was introduced by kernel 3.5+ Oct 06 05:49:22 As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843537 Oct 06 05:49:47 So I guess we'd have to backport seccomp filter support to our 3.4 kernels when we want to use systemd 234 Oct 06 05:50:08 I still get the same error message with all the defconfig values being OK Oct 06 05:53:48 Morning! Oct 06 05:55:13 Herrie: you know chromium proposes a set of patches, iirc Oct 06 06:17:17 Tofe: Morning! Oct 06 06:17:25 For 3.4 kernels? Oct 06 06:17:38 I think so Oct 06 06:18:31 I put a link in my sandbox commit for qtwebengine iirc Oct 06 06:19:07 I'll check that shortly I'm still in the subway Oct 06 06:20:14 maybe it wasn't chromium but B2G Oct 06 06:20:36 I'll check :) Oct 06 07:23:27 Herrie: see attachments here https://bugzilla.mozilla.org/show_bug.cgi?id=790923 Oct 06 07:24:57 (I guess "Alternate list of kernel commits to cherry-pick for 3.4" would be the correct list) Oct 06 07:44:15 Morning! Oct 06 07:44:52 Tofe: Also read some launchpad from Ubuntu that they backported seccomp to 3.4 Oct 06 07:45:06 So should be in our Hammerhead as well I guess Oct 06 07:45:21 If they backported it to Mako Oct 06 07:45:26 I'll double check in a bit Oct 06 08:08:49 Seems that even though launchpad says it might have beeen backported I cannot find this code in the kernels we use :P Oct 06 08:09:24 ah, ok Oct 06 08:23:00 Seems b2g kernel does have them backported for Hammerhead Oct 06 08:24:27 As per https://github.com/mozilla-b2g/codeaurora_kernel_msm/commits/b2g-msm-hammerhead-3.4-lollipop-release Oct 06 08:33:44 We'll have to propose that to Halium Oct 06 08:35:00 Tofe: Let me first see if I can get them applied cleanly :P Oct 06 08:35:06 Tofe: But yes Oct 06 08:35:13 Anyway it shouldn't hurt them if they don't use it Oct 06 08:35:26 UBPorts merged our changes btw ;) Oct 06 08:35:45 https://github.com/ubports/android_kernel_google_msm/commit/281c522c951c8f319df229c8aa3fff1907705b35 Oct 06 08:35:47 For Mako Oct 06 08:38:58 ah, great! Oct 06 11:42:45 Hmmz B2G Hammerhead seems to use quite different kernel sources compared to ours :'( Oct 06 11:43:10 They use a codeaurora kernel.. Oct 06 11:43:32 So none of the patch files seem to apply or not cleanly at least :'( Oct 06 11:43:34 for hammerhead caf kernel exists :O Oct 06 11:44:17 bshah: Seems B2G uses it Oct 06 11:44:34 bshah: We're testing for Yocto Rocko release and get bootloops Oct 06 11:45:21 Probably due to systemd 232->234 upgrade and requirement for CONFIG_SECCOMP_FILTER Oct 06 11:45:41 do you have kmsg? Oct 06 11:45:56 I have klog :P Oct 06 11:46:10 can you show me? Oct 06 11:46:27 ... also this stuff oyu are using with halium stuff? Oct 06 11:46:56 bshah: Well we're using own kernel, now in process of switching to Halium one Oct 06 11:47:04 ah Oct 06 11:47:09 And at same time updating Yocto layers Oct 06 11:47:17 But I tried Halium kernel, same issue Oct 06 11:47:36 klog: https://bpaste.net/show/5b7c74e3132e Oct 06 11:48:11 This is from Tenderloin since I can more easily pull logs there Oct 06 11:48:20 systemd[1]: Failed to determine whether /sys is a mount point: Bad file descriptor Oct 06 11:48:21 I can just boot to webOS and run klog for previous boot ;) Oct 06 11:48:27 bshah: Yup Oct 06 11:48:41 That worked with patched systemd 232 but not with patched 234 it seems :( Oct 06 11:49:04 I *think* it's this one : https://github.com/Halium/android_kernel_lge_hammerhead/commit/25437b2a54dd619a96e268ecaf303b089aa785e4 Oct 06 11:51:01 Problem is that hammerhead is more difficult to debug for me Oct 06 11:51:02 hm, actually, not it was same error message for first part xD Oct 06 11:51:27 Herrie|Pre3: well, you can backport this commit on tenderloin? Oct 06 11:51:43 bshah: Let me see Oct 06 11:53:58 Seems like we have this already: https://github.com/shr-distribution/linux/blob/tenderloin/3.4/cm-12.1/fs/proc/base.c#L1857 Oct 06 11:54:29 Herrie|Laptop: right Oct 06 11:54:35 that was fix for this error : Failed to determine whether /sys/fs/cgroup is a mount point: Too many levels of symbolic links Oct 06 11:54:37 xD Oct 06 11:54:56 bshah: Yeah this seems to be a new one really Oct 06 11:55:10 There were some defconfig flags that needed updating but that didn't help much Oct 06 11:55:33 So I suspect we'll probably need a whole backport for CONFIG_SECCOMP_FILTER Oct 06 11:55:58 Which the B2G guys have already for Hammerhead & Mako but that's CAF it seems Oct 06 11:56:04 I guess I could try their kernel Oct 06 11:56:16 Shouldn't be too different from ours for Hammerhead & Mako Oct 06 11:56:26 Though will probably miss the 4.2 BT backports :S Oct 06 11:59:02 Let me see if I can get it to compile at least Oct 06 11:59:16 Will probably need to add all those GCC patches too :P Oct 06 11:59:54 At least would be good to see if backporting the CONFIG_SECCOMP_FILTER stuff would do any good :P Oct 06 12:00:06 If it won't fix it, won't bother with it :P Oct 06 12:03:47 In general there shouldn't be many specific requirements from either Ubuntu, Mer, LuneOS or B2G in terms of kernel ;) Oct 06 12:19:29 So I'll try B2G kernel with Yocto Pyro if works then with Rocko Oct 06 12:19:49 And see if the seccomp bits actually solve systemd issues or not Oct 06 12:35:54 Herrie|Pre3: can't you just cherry-pick the commits listed by B2G guys ? Oct 06 12:38:16 Tofe: nope it seems... None of them apply cleanly Oct 06 12:38:39 All source files differ a bit Oct 06 12:40:19 I guess android device kernels vs codeaurora kernel use a different sourcr Oct 06 12:41:08 Functions and code are quite different really Oct 06 12:41:30 Herrie|Pre3: ok; and in addition, I'm a bit pessimistic about the fact that it will solve the mount issue: I don't see how this would be related Oct 06 12:43:22 Tofe: Also not sure Oct 06 12:43:34 But shouldn't be too hard to test Oct 06 12:43:59 At some point, we'll have to stick to an older systemd version, I think Oct 06 12:47:03 Tofe: Might be true Oct 06 12:49:18 Or have targets with new kernels :P Oct 06 12:55:55 Herrie|Pre3: the current newest kernels are 3.10, if I didn't miss anything Oct 06 12:56:24 so it's not even matching our systemd's requirement :) Oct 06 12:57:30 Tofe: Some have 3.18 Oct 06 12:57:43 And seems Google is forcing 4.x on O devices? Oct 06 12:59:41 Ah 3.18 seems to be a hard requirement: https://www.linux.com/news/2017/9/android-oreo-adds-linux-kernel-requirements-and-new-hardening-features Oct 06 13:08:47 ok Oct 06 13:09:13 still, if we follow systemd's growing requirements, we'll soon have no device to test on Oct 06 13:12:18 Tofe: Agree Oct 06 13:12:37 Just also want to keep work for JaMa to minimum Oct 06 13:12:51 He's busy enough so already happy he keeps most layers up to date Oct 06 13:13:13 So don't want him to need to maintain 3 previous versions of Yocto like happened frequently in the past Oct 06 13:26:21 Tofe: Our gcc and other patches at least apply clean to the b2g kernel ;) Oct 06 13:26:27 So can quickly test a build :P Oct 06 13:30:12 If Pyro works OK with b2g kernel, can test Rocko to see what it does there Oct 06 13:30:26 It might be something completely different, seccomp seems likely Oct 06 13:39:04 https://github.com/Herrie82/codeaurora_kernel_msm/commits/b2g-msm-hammerhead-3.4-halium-5.1-gcc567 Oct 06 13:46:59 good :) Oct 06 13:53:52 1 minor patch needed but built: https://github.com/Herrie82/codeaurora_kernel_msm/commit/c2870e0fe01e7e4e775c532e9c5b157f25ff7fea Oct 06 13:54:05 Something to test when home :) Oct 06 14:06:55 Hey, some good advice against bare pings:http://edunham.net/2017/10/05/saying_ping.html Oct 06 14:08:38 (I'd expand it to explaining *why* people should follow a link in Twitter) Oct 06 14:28:56 Herrie|Pre3: we can also try to build Rocko with gcc-6* which is still in oe-core, but some qt* recipes might fail as someone reported on ML and I'm not too optimistic about it solving this boot issue Oct 06 14:29:18 I'll try to test qemu with rocko Oct 06 14:36:43 JaMa: I doubt gcc7 is the issue here Oct 06 14:37:52 JaMa: Getting a environment: TOPDIR not defined Oct 06 14:38:00 When trying to do a .setup-env Oct 06 14:38:03 Any suggestions? Oct 06 14:43:37 it should be defined when you create new build directory Oct 06 14:43:38 docker-shr @ ~/webos/owpb/webos-ports $ cat conf/topdir.conf Oct 06 14:43:38 TOPDIR='/OE/webos/owpb/webos-ports' Oct 06 15:09:17 JaMa: I get a value but it tells me it's not defined Oct 06 15:10:09 Rebooted machine, same issue :S Oct 06 15:10:23 This is after I built Rocko and now try to build Pyro again ;S Oct 06 15:17:55 Ah wait Oct 06 15:17:58 It points to wrong dir Oct 06 15:19:37 Working now Oct 06 15:20:02 OK should have 2 images when home to check Oct 06 15:20:18 1 with B2G kernel for Pyro and 1 with B2G kernel for Rocko Oct 06 15:22:58 Curious to see if the pyro one works Oct 06 15:25:46 But I expect dragons :P Oct 06 15:25:54 And bears Oct 06 15:33:28 Seeing we're based on CM12.1 and not direct Android, but who knows, we'll see Oct 06 17:42:04 I'm trying a new build for N5 with Halium's header -- just in case it fixes the sensor issue Oct 06 17:42:28 (but it means rebuilding a lot of things, so some patience is needed...) Oct 06 17:42:55 Tofe: it won't fix issue Oct 06 17:43:04 (test_sensors and things that is) Oct 06 17:43:12 does test_sensors report sensors for you? Oct 06 17:43:29 bshah: oh, nope, it doesn't Oct 06 17:43:38 and crashes, but that's always been the case Oct 06 17:43:42 Tofe: can you give me strace test_sensors? Oct 06 17:43:57 bshah: sure, let me boot my current N5 Oct 06 17:44:12 I didn't know that was a known issue Oct 06 17:44:37 https://github.com/libhybris/libhybris/issues/350 is issue Oct 06 17:44:46 bshah: btw, restarting sensorfwd + compositor does fix it Oct 06 17:45:21 do you have logs from first sensorfwd run? Oct 06 17:45:45 yup, it just booted, let me extract logs Oct 06 17:46:09 "void HybrisManager::startReader(HybrisAdaptor*) failed for Operation not permitted" Oct 06 17:46:39 But I wasn't able to determine much more so far, I should "gdb" it Oct 06 17:47:07 Tofe: I can help debuggng this tomorrow.. I've dealt with this error earlier I think.. but today need to crash in bed Oct 06 17:47:45 bshah: go get some sleep :) I can handle some libhybris debugging too Oct 06 18:00:15 Tofe: FYI both Pyro & Rocko with b2g hammerhead kernel bootloops Oct 06 18:00:27 Herrie: oh. ok :/ Oct 06 18:01:20 They use Android 5.0.1 Oct 06 18:01:26 We have cm Oct 06 18:01:34 So kinda expected Oct 06 18:01:37 yeah Oct 06 18:03:32 Tofe: Just from the patchset I found first 7 files wouldn't apply cleanly already Oct 06 18:03:39 So was kinda a no go Oct 06 18:03:45 And there were 20 or so Oct 06 18:04:02 I'll dig around a bit might find similar set that works for ours Oct 06 18:04:14 Herrie|Pre3: where do you take the cherry-pick from ? Oct 06 18:04:30 b2g Oct 06 18:04:48 Just they have caf and we non-caf Oct 06 18:05:00 Code structure in the .h files differs Oct 06 18:05:46 And in such a way I with limited C(++) knowledge don't know how to correctly patch it Oct 06 18:06:11 I can probably help with that :) Oct 06 18:06:54 I suspect there's a proper patchset around @ ubuntu somewhere Oct 06 18:07:10 perhaps Oct 06 18:07:36 Or other place that doesn't fail on every single file Oct 06 18:08:11 Will shout for help if needed Oct 06 18:08:50 ok :) Oct 06 18:21:04 For test_sensors, I think it's simply a matter of hardfp/softfp stack Oct 06 18:21:46 test_sensors is hardfp, but sensors.qcom is softfp; I'm pretty sure it doesn't help :) **** ENDING LOGGING AT Sat Oct 07 02:59:59 2017