**** BEGIN LOGGING AT Tue May 04 02:59:57 2021 May 04 07:20:10 morning May 04 08:20:04 luneos-hardknott/webos-ports$ grep CONFIG_AUDIT= tmp-glibc/work/tissot-webos-linux/linux-xiaomi-tissot/4.9.188+gitrAUTOINC+be9bf75629-r0/build/.config May 04 08:20:07 CONFIG_AUDIT=y May 04 08:20:22 at least my local build has it May 04 08:37:48 JaMa: yes, I had it too on hammerhead, at least I think so May 04 08:38:11 but another test is needed to determine which piece is the cause of the trouble May 04 08:38:38 one halium build can be KO, but 3 of them, it's strange May 04 09:35:16 pinephone is building now, then rpi and then will finally trigger testing builds to confirm android-system-image May 04 09:35:36 which MACHINE would be preferred first for test? May 04 09:39:44 I've found hammerhead and tissot, charging them now May 04 14:45:14 hammerhead, yes, that's a good start May 04 14:48:42 pinephone is built as well, if you want something without android-system-image May 04 14:59:09 JaMa: New systemd in hardknot it seems? May 04 14:59:17 Might be the cause somehow May 04 15:06:48 it's different 246.9 in gatesgarth 247.6 in hardknott May 04 15:25:40 That might be it or another defconfig value that flipped May 04 15:26:35 I'm loading luneos-dev-package-hammerhead-testing-0-268.zip now (with older android-system-image) to compare May 04 15:26:48 new testing build in queue, but it will be an hour or so May 04 15:27:11 CONFIG_SECURITY_SELINUX=y, CONFIG_SECURITY_SELINUX_BOOTPARAM=y, CONFIG_SECURITY_SELINUX_DEVELOP=y, CONFIG_SECURITY_SELINUX_AVC_STATS=y, CONFIG_DEFAULT_SECURITY="selinux" and CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 is what we have in defconfig for Tissot May 04 15:27:18 Question is what ends up in .config of course May 04 15:28:04 https://paste.ubuntu.com/p/FvggRXQXD2/ grep CONFIG.*SECURITY tmp-glibc/work/tissot-webos-linux/linux-xiaomi-tissot/4.9.188+gitrAUTOINC+be9bf75629-r0/build/.config in my local build May 04 15:31:13 268 booted ok on hammerhead, first-use was working, but now it seems to be stuck a bit (only power button to switch screen on/off seems to work) May 04 15:33:05 first-use started after reboot again, so I guess it wasn't completely finished when it closed May 04 15:33:35 and doing first-use 2nd time rebooted the phone in the middle May 04 15:34:48 3rd time charm, it triggered 4th first-time immediately after finishing the 3rd, but now it seems working May 04 15:36:03 sh-5.0# uptime 12:28:21 up 3 min, 0 users, load average: 7.92, 4.37, 1.78 May 04 15:41:47 [ 103.458988] init: Couldn't open /sys/fs/selinux/null: No such file or directory May 04 15:41:50 [ 103.459062] init: Reboot start, reason: reboot, rebootTarget: bootloader May 04 15:41:53 [ 103.459189] init: Reboot ending, jumping to kernel May 04 15:42:15 so I guess it's the android-system-imge (this was local gatesgarth build with the new android-system-image) May 04 15:42:54 JaMa: that's on the working image ? May 04 15:43:17 oh, sorry, didn't read the whole sentence :p May 04 15:43:26 Tofe: no, that's after sideloading my local build instead of 268 build from jenkins May 04 15:43:56 JaMa: and /proc/config.gz does contain AUDIT=y, right May 04 15:44:42 https://paste.ubuntu.com/p/Fm3x8pPJFZ/ yes May 04 15:45:21 CONFIG_SECURITY_SELINUX_DISABLE=y May 04 15:45:26 should it contain this? ^ May 04 15:46:19 but why would this change by halium image upgrade? May 04 15:48:55 JaMa: good remark May 04 15:49:02 kernel is done on yocto side May 04 15:49:25 so this is something else May 04 15:49:47 whole boot log https://paste.ubuntu.com/p/yBwgzQyDf7/ May 04 15:49:59 [ 2.544973] /halium-boot.sh: line 252: dumpe2fs: command not found May 04 15:50:09 There could well be a missing piece in the halium build script on jenkins for halium 9.0 May 04 15:50:20 JaMa: yes, this is "normal" May 04 15:50:25 ok May 04 15:51:06 [ 5.151899] mkdir: can't create directory '/rfs/android//boot': Read-only file system May 04 15:51:10 and similar as well? May 04 15:51:20 I should have saved the log with previous image to compare :/ May 04 15:51:48 JaMa: that mount isn't used by android, so it's fine (though not very good looking) May 04 15:51:49 anything else you want me to try before rebooting to 268 image? May 04 15:52:04 not that I can think of May 04 15:58:36 maybe we don't handle well building several halium targets in chain May 04 15:58:52 like for the patches, or I don't know exactly May 04 15:59:23 Tofe: Locally I usually do a "rm -rf bionic | rm -rf device | rm -rf kernel | rm -rf vendor" in between targets May 04 15:59:27 That seems to work for me May 04 15:59:46 I sometimes get something funny in .repo but that's usually because I aborted a build May 04 16:00:08 As you know I switch between targets frequently for building May 04 16:00:39 And that works well for me. Better then your switch script it seems May 04 16:02:26 But if there are issues with chained builds we should be able to see in Halium builld log May 04 16:03:48 Tofe: Also we might need to fix this: hybris-patches/apply-patches.sh: line 23: cd: /home/jenkins/workspace/halium-luneos-9.0-build/halium-luneos-9.0/./hybris/hybris-boot: No such file or directory May 04 16:03:58 I found that apply-patches.sh doesn't like it when things go wrong May 04 16:08:11 Nasty solution could be to just do "rm -rf hybris-boot" after applying the patches, but I'm sure there could be something more elegant May 04 16:13:55 It seems apply-patches.sh stops when 1 patch fails to apply, at least that's what my assumption was based on my issue last week May 04 16:14:01 Where I had a wrongly formatted patch May 04 16:14:29 Another more proper solution would be to have apply-patches.sh to behave better and apply everything and not stop when 1 fails May 04 16:14:50 the new image doesn't have '[ 21.370909] init: init first stage started!' at all May 04 16:15:39 JaMa: See above... Halium build runs https://github.com/Halium/hybris-patches/blob/halium-9.0/apply-patches.sh May 04 16:15:59 When there's something wrong with a patch it seems it doesn't continue with other patches, but doesn't stop the Halium build May 04 16:16:11 I had some funny results with my mido because of that last week locally! May 04 16:17:11 So when https://github.com/Halium/hybris-patches/blob/halium-9.0/apply-patches.sh#L24 fails for whatever reason (already patched, cannot patch, incorrectly formatted patch), it will stop applying other patches (at least that's my understanding). May 04 16:17:18 And that causes random issues May 04 16:21:06 android-system-image-hammerhead# diff -rq *rfs/ 2>/dev/null | grep Only May 04 16:21:06 Only in 20210405-1-r0-old-rfs/: init.extraenv.armeabi-v7a.rc May 04 16:21:06 Only in 20210429-18-r0-new-rfs/: res May 04 16:21:06 Only in 20210405-1-r0-old-rfs/system/etc: recovery-resource.dat May 04 16:21:06 Only in 20210405-1-r0-old-rfs/system/lib: lib May 04 16:21:08 Only in 20210405-1-r0-old-rfs/system/lib64: lib May 04 16:23:50 should I revert the image upgrade from meta-smartphone or do we want to fix halium build first? May 04 16:44:42 JaMa: Let me propose something to jenkins-jobs for now May 04 16:58:02 JaMa/Tofe: Happy for other suggestions, this is untested and quite nasty, but should do the trick: https://github.com/webOS-ports/android/pull/9 and https://github.com/webOS-ports/jenkins-jobs/pull/20 May 04 17:02:37 I don't have enough experience with halium builds to have an opinion on this May 04 17:03:16 JaMa: Well it's nasty in general... But this might work, at least I think it might... I haven't tested it yet May 04 17:03:34 I know I do the rm -rf bionic|device|kernel|vendor here and that helps me May 04 17:03:42 I had issues with apply-patches.sh before May 04 17:03:58 Not sure how to adjust the script so it wouldn't stop when 1 git am command fails... May 04 17:04:14 where is this apply-patches.sh script? May 04 17:04:58 https://github.com/Halium/hybris-patches/blob/halium-9.0/apply-patches.sh May 04 17:05:14 L24 specifically seems to cause havoc May 04 17:05:49 it still strange to me that instead of fixing missing hybris-boot directory we need to just ignore that issue (don't we need to patch whatever it was trying to patch in hybris-boot?) May 04 17:06:23 Well we don't use hybris-boot at our end May 04 17:06:37 we can just drop "set -e" if we really don't care about any errors here May 04 17:06:42 So we remove it from our android manifest (because it causes build issues at our end) May 04 17:06:58 But then the apply-patches.sh stops in the middle it seems May 04 17:07:18 So now I propose to nastily remove the folder after apply-patches.sh and before actual build starts May 04 17:08:27 why not remove https://github.com/Halium/hybris-patches/tree/halium-9.0/hybris/hybris-boot ? May 04 17:10:00 if that's the only patch which doesn't apply in our builds May 04 17:11:21 and then keep "set -e" for apply-patches.sh to fail if something unexpectedly fails to apply again (and fix jenkins-job.sh to fail when apply-patches.sh fails instead of ignoring it and producing wrong image) May 04 17:29:11 JaMa: Well we don't use hybris-boot but others do it seems May 04 17:29:15 So it cannot be removed from upstream May 04 17:32:51 Just got home, let me catch up a bit May 04 17:33:17 I do have a slightly modified apply-patches at home, a bit more permissive May 04 17:34:15 I use "patch --forward -r /dev/null -p1 < $OLD_WD/hybris-patches/$patch || /bin/true" May 04 17:34:28 mostly works, but not perfect either May 04 17:34:43 Well I think in general UBTouch also doesn't use hybris-boot May 04 17:34:56 We migth want to check in #halium and just drop it altogether? May 04 17:35:02 I think it's mer/sfos specific May 04 17:35:11 And just there as legacy leftover from their manifest May 04 17:38:29 some use hybris-boot, other use halium-boot, I never remember who uses what May 04 17:38:36 and we use neither :) May 04 17:40:09 Herrie: here's my complete apply-patches.sh modification at home: https://paste2.org/nVG7YtC7 May 04 17:40:41 so, if a directory doesn't exist, it's skipped, and if a patch is found to be already applied, it's skipped. May 04 17:40:48 Quite permissive, has its downsides... May 04 17:40:51 Herrie: I was assuming we can use luneos specific fork of hybris-patches repo May 04 17:41:08 Tofe: but here it's cd which is failing, why not drop "set -e" then? May 04 17:41:56 JaMa: what does "set -e" do ? exit on failure ? May 04 17:42:02 yes May 04 17:42:11 that's why it stops in the middle May 04 17:42:49 but IMHO forking hybris-ports and making sure that halium jenkins job fails whenever something doesn't apply is much safer in long-term May 04 17:42:56 well if "cd" fails we don't really want to do the "patch" at next line, though it will probably fail too harmlessly May 04 17:44:01 JaMa: I agree, in the context of a jenkins job, we have to detect failure more precisely May 04 17:44:46 forking hybris-boot you mean? May 04 17:45:10 sorry hybris-patches May 04 17:45:21 to remove https://github.com/Halium/hybris-patches/tree/halium-9.0/hybris/hybris-boot May 04 17:45:29 ah, well, yes why not May 04 17:45:40 the 9.0 is quite stable now May 04 17:45:55 I'm fine with doing that. Herrie ? May 04 17:46:03 I assume that all other patches should apply for all MACHINEs we build May 04 17:46:23 yes, they do May 04 17:46:23 Tofe: Yeah we can fork patches for now May 04 17:46:28 hybris-patches May 04 17:46:35 But I suggest we send a PR upstream to remove it as well May 04 17:46:40 Let's see the feedback May 04 17:47:04 ok,I'll do the fork May 04 17:47:42 nope, I can't put a fork in webos-ports :p May 04 17:48:01 Tofe: Let me sort thgat May 04 17:49:29 Tofe: Done, it's there May 04 17:52:29 Here it comes: https://github.com/Halium/hybris-patches/pull/20 May 04 17:53:09 hehe... hum... https://github.com/webOS-ports/hybris-patches/pull/1 here, now, better May 04 17:55:19 Tofe: https://github.com/Halium/android/pull/58 May 04 17:55:45 Let's see the feedback May 04 17:56:05 My understanding is that hybris-boot is Mer/SFOS specific and they don't support Halium anyway May 04 18:00:22 Herrie: ah, but let me reopen my PR then, your PR is linked to it May 04 18:00:57 Yes May 04 18:01:03 Mayme mention mine May 04 18:03:38 Or my understanding is wrong, but I think I'm right here May 04 18:05:07 They Mer uses Halium, but quite differently, without lxc May 04 18:05:46 For the boot part, I have no idea what they do May 04 18:06:28 Tofe: No they don't.... May 04 18:06:33 They have their own way May 04 18:06:43 Therefore Halium patches it differently May 04 18:06:50 They just piggy-backed off Mer/SFOS work May 04 18:07:19 Oh. My mistake ! May 04 18:08:41 Unless halium uses hybris-boot somewhere somehow, we shouldn't really need it... May 04 18:08:43 IMHO May 04 18:09:04 They use halium-boot for UBPorts or at least used to May 04 18:09:42 and plasma mobile is off the boat now (if they used hybris-boot) May 04 18:10:19 I'm not really sure about pmOS and Mobian May 04 18:11:24 pmOS does their own stuff, pretty sure May 04 18:11:29 Mobian, no clue May 04 18:12:37 Let's see what feedback we get May 04 18:12:56 That should answer our questions :P May 04 18:14:52 yep May 04 18:19:25 https://github.com/ubports/porting-notes/wiki/Halium-9 says they use halium-boot for UBPorts **** ENDING LOGGING AT Wed May 05 02:59:56 2021