**** BEGIN LOGGING AT Sun Jun 17 03:00:02 2018 Jun 17 06:13:52 Morning! Jun 17 06:44:59 Morning! Jun 17 06:57:52 mornin Jun 17 06:57:53 g Jun 17 08:32:30 Morning! Jun 17 08:33:30 So, just for your information, running luna-webappmanager with the user "wheel", and adding right for group "wheel" to access luna-session/ and wayland socket, then LunaWebAppManager works well without any additional flag Jun 17 08:34:03 If I find out how to change these default rights, it might be a good option for us I think Jun 17 11:55:58 Tofe: "wheel" ? Jun 17 11:56:04 Where does that come from? Jun 17 11:59:04 Herrie: oh that's just a usual fictive user that has more credentials than the usual user Jun 17 11:59:23 * elvispre discovers that his onyx lxc android rootfs does not have an init at the top level. That's not going to help. Jun 17 13:20:22 elvispre: Hmmz that's weird Jun 17 13:20:42 It could be something that Tofe did... He changed it for our targets, not sure he did for Onyx too Jun 17 13:22:53 mmmh not that I remember Jun 17 13:23:13 If there's no init, I don't see what the container starts, then Jun 17 13:23:45 Tofe: I mean I remmeber you changed a few things so we could use Halium's init? Jun 17 13:23:49 In meta-smartphone Jun 17 13:23:57 Or my memory is faulty could also be Jun 17 13:34:41 ah, but that would be Halium's initrd script I think Jun 17 13:35:14 Something I never quite had the time to do, is to use their lxc startup script Jun 17 13:35:41 https://gist.github.com/UniversalSuperBox/9421e4f1350e8959d2205cb3ad14a944 Jun 17 13:36:17 It might work as-is, but I never tried Jun 17 13:38:15 Tofe: Comparing lxc/android/rootfs on my mako and my onyx, the former has several init* files at the top level and the latter has only an init.rc file. Jun 17 13:39:27 My local halium build looks like it has the correct stuff at the top level. I shall try using that. Jun 17 13:42:33 mmmh is your Android's ramdisk alright ? Jun 17 13:42:56 Probably not. Jun 17 13:43:30 let me see how you could check that Jun 17 13:44:12 do you have a /var/lib/lxc/android/rootfs/system/boot/android-ramdisk.img file ? Jun 17 13:45:00 Just booting it... Jun 17 13:46:03 ...yes Jun 17 13:46:07 ok, good Jun 17 13:46:52 let's see now, how could we check if that file has been mounted correctly Jun 17 13:47:29 Hmmm! Now I'm in /var/lib/lxc/android/rootfs/ and there are all the init files I thought I was missing Jun 17 13:48:00 ah ! good :) Jun 17 13:48:26 I swear they weren't there earlier Jun 17 13:48:55 that's strange... maybe under some conditions the mount of the ramdisk doesn't go well Jun 17 13:50:56 There is some strange mount behaviour going on for sure. df looks OK then after a while there are lots of repeated entries. Jun 17 13:52:11 elvispre: with all the bind-mounts, df (and even mount) outputs are a bit weird; here's mine for N5: https://bpaste.net/show/078bf7daab5e Jun 17 13:53:56 Yes that's what my mako one looks like. My onyx one looks like that at first too. Jun 17 13:55:54 elvispre: it's corrupting the mounts across reboots, or is it during a single "session" ? Jun 17 13:56:14 Tofe: This is repeatable across multiple boots. Jun 17 13:56:22 that's bad... Jun 17 13:57:10 Do you have an output of df and of mount when it's corrupted ? Maybe I could find a hint Jun 17 13:58:25 Tofe: https://bpaste.net/show/921e07c8c00f is what it looks like at the moment. Jun 17 13:58:54 Let me try to provoke it... Jun 17 14:02:15 '/usr/bin/lxc-start -F -n android -l DEBUG -- /init' usually does the trick... Jun 17 14:03:47 https://bpaste.net/show/8f189d66d7e0 after one such attempt Jun 17 14:08:08 And this is what the foreground lxc-start output looks like: https://bpaste.net/show/6c741867cdfb Jun 17 14:10:58 but, do you start lxc-start when there's already an lxc running ? Jun 17 14:11:22 I don't believe so. Jun 17 14:12:09 Of course, it had tried to run. I think there are some mounts hanging around from the automatic attempt. Jun 17 14:12:32 ah, ok, possibly yes Jun 17 14:13:39 if you reboot, you'll still have several identical entries in df ? Jun 17 14:14:16 No, it goes back to the first case (https://bpaste.net/show/921e07c8c00f) Jun 17 14:15:55 I think our /var/lib/lxc/android/post-stop.sh isn't correct anymore Jun 17 14:16:14 I tried running it. It isn't :-) Jun 17 14:16:42 We don't really care when things behave I suppose Jun 17 14:17:04 exactly Jun 17 14:17:58 df after a reboot https://bpaste.net/show/594d0c1f5f13 Not identical to the original actually Jun 17 14:18:01 a better approach would be something like "for i in /android/*; do umount "$i" || true; done" Jun 17 14:18:09 no wait Jun 17 14:18:34 for i in /android/*; do umount "$LXC_ROOTFS_PATH/$i" || true; done Jun 17 14:19:09 oh there are sub-mounts... Jun 17 14:19:27 then Jun 17 14:19:27 for i in /android/*; do umount --recursive "$LXC_ROOTFS_PATH/$i" || true; done Jun 17 14:20:33 and even this command isn't really complete Jun 17 14:20:36 Tofe: Wow! How did you do that? All of my */lxc/android/* mounts have vanished. It's like you're running those commands in my onyx. Wevry weird. Jun 17 14:20:46 "Very" Jun 17 14:21:10 ... without executing that line ? Jun 17 14:21:40 Yes! I just typed df again, nothing else. Jun 17 14:21:46 spooky :) Jun 17 14:22:06 Too right. Jun 17 14:22:33 mmmh even android/rootfs has vanished ? Jun 17 14:22:48 Yes Jun 17 14:23:01 ah, that one's not very good actually Jun 17 14:23:22 it's mounted by the initrd, so it should stay there until poweroff Jun 17 14:26:24 try: for i in $LXC_ROOTFS_PATH/*; do umount --recursive "$i" || true; done Jun 17 14:26:32 in the post-stop.sh Jun 17 14:26:35 and reboot Jun 17 14:27:05 it should be much cleaner Jun 17 14:27:46 Do we have a usable text editor in our image? Jun 17 14:27:52 just vi Jun 17 14:28:04 I don't know if you consider it "usable" :) Jun 17 14:28:24 Not usable in Windows cmd prompt, I'll abd pull then push... Jun 17 14:28:36 yep Jun 17 14:28:46 vi is OK if I grit my teeth :-) Jun 17 14:30:22 hehe Jun 17 14:33:55 root 1305 1297 0 00:22 ? 00:00:00 lxc-wait -n android -s RUNNING Jun 17 14:34:01 That looks good, right? Jun 17 14:35:00 Nah! journalctl still shows container failed to start Jun 17 14:35:44 well the post-script.sh is just so that you won't end up with remaining mounts Jun 17 14:35:53 ...and now that process has gone. Jun 17 14:36:00 and the mounts? Jun 17 14:36:35 Now https://bpaste.net/show/fee72caa4854 Jun 17 14:37:10 can you execute lxc-stop by hand, Jun 17 14:37:11 ? Jun 17 14:37:40 lxc-stop -n android Jun 17 14:37:48 android is not running Jun 17 14:37:55 no really just the .sh Jun 17 14:38:20 I think lxc considers that the container hasn't even really started, so it didn't execute post-stop.sh somehow Jun 17 14:39:09 But to try again to start lxc by hand (and thus get some more logs), you need a clean starting point Jun 17 14:39:55 though you probably already have some logs: dmesg, /system/bin/logcat, journalctl Jun 17 14:40:20 They pretty much just say "container failed to start" Jun 17 14:41:20 post-stop.sh does not achieve much. All the devices are either busy or non-existent. Jun 17 14:42:18 I could maybe disable android-system.service, reboot and then try to start it by hand. Jun 17 14:42:37 yes, good idea, mask it Jun 17 14:42:55 mask rather than disable? Jun 17 14:44:21 well I'm not sure what's the difference anyway Jun 17 14:44:43 OK. I am systemding by google personally. Jun 17 14:50:49 android-service is still running. It does need to be mask actually. Jun 17 14:51:00 disable = do not start. Jun 17 14:51:09 mask = cannot start. Jun 17 14:51:53 s/service/system Jun 17 15:01:38 Much the same after a clean start unfortunately https://bpaste.net/show/7c4c008405df Jun 17 15:02:09 df is clean afterwards now though! Jun 17 15:28:01 I see that we run an android init inside the container but I don't see how the kernel from http://build.webos-ports.org/halium-luneos-7.1/ is involved though. Jun 17 15:54:55 elvispre: oh, that one is easy: it isn't involved Jun 17 15:55:07 we build the kernel in our OE toolchain Jun 17 15:55:51 the "kernel parts" is an old thing we should remove from our scripts, it's useless Jun 17 15:56:17 Tofe: So we just use the rootfs? Jun 17 15:56:46 (That *is* what it looks like.) Jun 17 15:57:00 not sure what you mean by that, but the android container uses the same kernel as the rest of the system Jun 17 15:58:07 My impression was that the http://build.webos-ports.org/halium-luneos-7.1/ image contains a kernel built with the halium toolchain. Jun 17 15:58:25 ah, yes it does; but we don't use it Jun 17 15:58:43 Ah! The mist clears :-) Jun 17 15:59:20 We use the rest of the ROM including the ramdisk Jun 17 16:01:09 elvispre: maybe you would know: I'm wondering what would be the easiest way of testing if my PalmServiceBridge is broken or not Jun 17 16:01:50 Some minimal app that would do a new PalmServiceBridge, use it a bit, show something if it works Jun 17 16:01:59 Tofe: Sorry. I am really not up to speed on that. Jun 17 16:02:23 no problem :) Jun 17 16:03:01 Actually, it could very well be that systemui uses it Jun 17 16:07:41 yep, that's exactly the case. Perfect. Jun 17 16:07:54 \o/ Jun 17 16:11:27 Herrie: working a bit on making QtWebEngine patches lighter: https://github.com/Tofee/meta-webos-ports/commits/pyro-5.11 Jun 17 17:47:51 Tofe: Looking good! Jun 17 17:48:00 I got a good deal on another 500GB SSD for my builder Jun 17 17:48:07 So can run some things side by side more easily Jun 17 17:48:29 Because with 4-5 Halium targets and some LuneOS for different archs my 500GB would get full quickly Jun 17 17:51:24 Herrie: isn't it :) Jun 17 17:51:38 Herrie: I'm also preparing the stage for my rosy device Jun 17 17:52:10 But I still don't have the unlock authorization .............. Jun 17 17:52:32 Anyway plenty of things to do Jun 17 17:53:10 I do hope my PalmServiceBridge replacement in QML will work; that'll be a relief for future updates Jun 17 18:44:57 Tofe: Can't you use Testr app for the PalmServiceBridge? Jun 17 18:45:07 It does some simple LS2 calls on public/private Jun 17 18:45:11 And some other LS2 bits Jun 17 18:46:30 DougReeder put up this one with new Enyo version to test via browseR: http://testr.surge.sh/ Jun 17 18:46:44 But pretty sure it does quite some LS2 calls for various bits Jun 17 18:49:56 Herrie: I'm confused. My halium repo setup has a pull from android_device_oneplus_onyx with two commits from you beyond the head of lineagos' cm-14.1 branch, but you don't seen to have such a repo on GitHub and their repo doesn't seem to have your commits. Where did I get them from then? Jun 17 18:56:45 elvispre|s: Good question Jun 17 18:56:49 Let me check Jun 17 18:58:05 elvispre|s: What are those commits? Jun 17 18:58:13 It could be my magic by the setup script Jun 17 18:58:41 Drop doze Jun 17 18:58:52 Hmmz that's weird :P Jun 17 18:59:10 Ah those come from our "old" stuff Jun 17 18:59:27 https://github.com/webOS-ports/android_luneos_hal/tree/halium-7.1/patches/device/oneplus/onyx Jun 17 18:59:38 This is what I'm trying to integrate into the setup script from halium-devices Jun 17 18:59:44 :-) Jun 17 18:59:47 BEcause this way of patching is nasty and prone to errors Jun 17 18:59:53 Just I'm not there 100% yet Jun 17 19:00:05 Idea is that android_luneos_hal will disappear completely Jun 17 19:00:26 And we'll use halium-devices instead. Jun 17 19:00:33 And also simplify our android repo Jun 17 19:00:43 Because now we basically duplicate android from halium Jun 17 19:00:46 Which is a bit silly Jun 17 19:00:50 So will rework that Jun 17 19:00:55 To remove duplication etc Jun 17 19:01:03 Good idea Jun 17 19:01:23 Doze, KeyHandler and CMActions/LineageActions are the next bits to be integrated into the setup script frm halium-devices Jun 17 19:01:28 Just they're a bit nasty Jun 17 19:01:38 And there seem to be different ways to "disable" them Jun 17 19:01:46 Just need to work out the "best" one ;) Jun 17 19:01:52 I.e. the one that has the least errors ;) Jun 17 19:03:12 The reason I'm looking at this is system.prop defines a bad device name that messes up our udev device rules mechanism during the LuneOS boot sequence. Jun 17 19:04:40 If I can get the udev rules applied, maybe that will allow the container to start on my onyx. Jun 17 23:58:23 My (indirect) patch to the android build.prop worked first time. udev rules for onyx now get applied. Jun 17 23:59:43 But Android System Container still fails to start. Oh well. **** ENDING LOGGING AT Mon Jun 18 03:00:06 2018