**** BEGIN LOGGING AT Tue Dec 31 02:59:57 2019 Dec 31 08:18:05 Morning Dec 31 09:50:25 Morning! Dec 31 09:53:41 Herrie: you also took this commit ? https://github.com/mer-hybris/android_system_core/commit/527baaa61fe3f5c5e18aaf7a9221cfa7da3b9ebc Dec 31 10:09:16 and this https://github.com/mer-hybris/android_system_core/commit/f24d040bf531b6887d69390585bd57df9ce4ec53 Dec 31 10:09:16 Tofe: We didn't disable ueventd in 7.1 **** BEGIN LOGGING AT Tue Dec 31 10:26:20 2019 Dec 31 10:30:46 ok, back to digging into this weird "height" issue with the power menu -- it seems it's not an issue with the js code Dec 31 11:18:14 Tofe: I'm trying another build with some changes to android_system_core, we'll see what it does. It seems I shouldn't be too far off to get it to work though Dec 31 13:12:11 morning :) Dec 31 13:13:50 what did I miss? My motherboard died just before Christmas and new one was supposed to be delivered yesterday, but wasn't, so waiting for 2020 to get my system back running :/ Dec 31 13:26:45 JaMa: That sucks :( Dec 31 13:26:50 Nothing too much Dec 31 13:27:04 Trying to get Halium 8.1 to run, but fighting with LXC a bit Dec 31 13:45:30 Tofe: Still getting the missing init binary. It does get build, just not deployed it seems... When I manually push it, it seems to behave a bit better, but still LXC is failing to run: https://paste.ubuntu.com/p/ThdSdG5ckm/ Dec 31 13:47:55 Herrie: you sure of your analysis? I do see "lxc_start - start.c:post_start:1447 - Started "/init" with pid "1824"." Dec 31 13:50:26 Tofe: Yeah it gets killed shortly afterwards Dec 31 13:50:47 I added the init manually now from the Halium-8.1/out/target etc directory Dec 31 13:50:52 but then, /init is found, isn't it? Dec 31 13:50:55 oh ok Dec 31 13:50:56 Simply ADB pushed it, so it can find it now Dec 31 13:51:09 Tofe: Yes, just now it seems that kernel is not very heappy Dec 31 13:51:16 init should be deployed when ramdisk is extracted Dec 31 13:51:21 Dec 27 10:26:07 hammerhead kernel[841]: [ 477.027403] type=1701 audit(1577442367.929:33): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1824 comm="init" reason="memory violation" sig=4 Dec 31 13:52:00 Tofe: Ah OK. Maybe I have the wrong init binary then Dec 31 13:57:21 that could be Dec 31 13:57:55 do you have a android-ramdisk.img somewhere in the halium image? Dec 31 13:58:10 that one should be a cpio.gz archive, iir Dec 31 13:58:11 iirc Dec 31 14:01:37 Yup I have that one Dec 31 14:01:47 At least it's in my out folder Dec 31 14:02:15 you should also have it in the halium image, otherwise halium's init won't find it Dec 31 14:02:29 Well I have a system.img let me check it's ocntent Dec 31 14:02:47 let me also check halium's init script Dec 31 14:03:11 Tofe: Well I have it, otherwise I wouldn't get this far even Dec 31 14:03:46 It was failing before because I didn't have it Dec 31 14:03:56 right Dec 31 14:04:23 in /boot of system.img Dec 31 14:05:45 Herrie: can you put the ramdisk on your server? I'll have a look too Dec 31 14:07:04 oh there's already the whole halium-8.1 image itself, I'll take that Dec 31 14:10:30 Tofe: yup Dec 31 14:11:19 ok, init is there Dec 31 14:12:15 so you shouldn't need to copy it Dec 31 14:13:18 you don't have it in /var/lib/lxc/android/rootfs ? Dec 31 14:13:32 Tofe: yes Dec 31 14:13:41 That's the issue Dec 31 14:14:02 then something is still wrong during halium boot Dec 31 14:14:35 halium extracts the ramdisk in a tmpfs, then moves that tmpfs to /var/lib/lxc/android/rootfs Dec 31 14:14:44 Logs look pretty OK Dec 31 14:14:58 I might have missed something somewhere though Dec 31 14:15:25 just after "device is xxxx" ? I guess you pasted all this already, but I lost track Dec 31 14:16:45 ah, found it. looks good. Dec 31 14:16:58 what's your "mount" output ? Dec 31 14:18:05 halium's boot even succeeds in parsing var/lib/lxc/android/rootfs/fstab Dec 31 14:18:06 Herrie:anything new? Dec 31 14:18:50 Hacker1245: we're investigating why fstab gets extracted alright, but not init binary Dec 31 14:19:17 Tofe: let me paste in a bit, away from device now Dec 31 14:19:20 Herrie: but but... according to https://paste.ubuntu.com/p/NzyDZzQ4pb/, android's init is started ?... Dec 31 14:19:40 Tofe: Alright, good luch Dec 31 14:19:43 *luck Dec 31 14:19:50 ping me if you want any help Dec 31 14:21:08 ok :) Dec 31 14:22:03 Herrie: if I read that log correctly, "init: processing action (wait_for_coldboot_done)" is what does fails (timeout), then a reboot is scheduled and also fails (but that's alright). The last failure might be a "file not found" error... Dec 31 15:42:02 Tofe: will be in train home shortly can look then Dec 31 15:42:31 Tofe: based on description coldboot_done is triggered by ueventd, so I enabled that again Dec 31 15:43:03 Seems there's some loop in LXC container and Android init where they're waiting for each other Dec 31 15:43:44 I.e. LXC wants Android init to finish but it doesn't Dec 31 15:45:07 android never waits for lxc, it doesn't know it exists Dec 31 15:45:50 Tofe: Mounts: https://paste.ubuntu.com/p/stx5z9VSwh/ Dec 31 15:45:57 I mean I should be pretty close already Dec 31 15:50:35 yup Dec 31 15:54:42 Tofe: I guess it doesn't hurt to disable this one as well: https://github.com/Herrie82/android_system_core-1/blob/halium-8.1/init/init.cpp#L1126 Dec 31 15:58:04 won't hurt, but it's unlikely to help either Dec 31 15:59:04 Yeah it seems issue is the coldboot done flag Dec 31 15:59:13 Seems Mer guys do it hacky via .sh: https://github.com/mer-hybris/droid-hal-configs/blob/859c277f2f534125b31d62d96790ea04627a0dde/sparse/usr/bin/droid/droid-hal-startup.sh Dec 31 15:59:48 Which gets called by droid-hal-init.service Dec 31 16:00:33 Which seems to be installed and run as systemd service as per as https://github.com/mer-hybris/droid-system-packager/blob/90d5008299b2d592cdb41c71ce021c8383ccfcd9/Makefile Dec 31 16:00:36 well we can't do that -- and we don't need in 7.1 Dec 31 16:00:51 Tofe: Yeah Dec 31 16:00:58 I mean, this supposes android lives outside of lxc Dec 31 16:01:08 So it must be something in vold or ueventd that doesn't get triggered Dec 31 16:01:14 ueventd isn't happy in general it seems Dec 31 16:01:17 likely yes Dec 31 16:06:14 Tofe: Ah ok maybe have a clue: https://github.com/Herrie82/android_system_core-1/blob/halium-8.1/init/ueventd.cpp#L260 Dec 31 16:06:32 I guess it wouldn't hurt to disable the selinux bits there as well Dec 31 16:06:36 And add some logging around Dec 31 16:08:47 Though we had it in 7.1 Dec 31 16:08:56 But I killed more SELInux stuff in 8.1 v.s. 7.1 it seems Dec 31 16:12:30 Tofe: Ah seems we actually pass that part and we end up somewhere here: https://github.com/Herrie82/android_system_core-1/blob/halium-8.1/init/ueventd.cpp#L265 Dec 31 16:13:01 Maybe the issue is some of the files it tries to open doesn't exists: Dec 27 10:19:25 hammerhead kernel[841]: [ 74.149208] ueventd: Unable to open '/vendor/ueventd.rc': No such file or directory Dec 31 16:13:13 Which then lead to: Dec 27 10:19:25 hammerhead kernel[841]: [ 74.176624] ueventd: Error reading from Uevent Fd Dec 31 16:30:37 it could be related to that yes Dec 31 16:31:18 given this: https://github.com/Herrie82/android_system_core-1/blob/halium-8.1/init/ueventd.cpp#L231 it's not fatal, the return code isn't tested Dec 31 17:01:05 I guess I could try to only load the ones I have for now Dec 31 17:01:20 So the missing ones don't get parsed