**** BEGIN LOGGING AT Sun Jan 03 02:59:56 2021 Jan 03 08:02:35 Morning! Jan 03 08:03:52 Tofe: Seems healthd is started by servicemanager, lots of other bits are disabled: https://github.com/Halium/hybris-patches/blob/halium-9.0/frameworks/native/0001-hybris-Use-mini-services-and-disable-starting-unneed.patch Jan 03 08:04:03 Seems healthd is used for battery level and some other things Jan 03 08:04:39 Healthd is built by build/make/target/product/embedded.mk: healthd \ Jan 03 08:05:34 Since LXC is not starting you cannot get to strace it yet right or logcat? Jan 03 08:05:49 Could be some binary is simply missing or in the wrong location Jan 03 08:07:37 If you tell me what you build exactly, I can reproduce at my side as well Jan 03 09:34:50 Morning! Jan 03 09:35:56 Herrie: I built halium_arm64, using the corresponding xml manifest in halium/devices Jan 03 09:36:40 so halium/devices/setup halium_arm64, then lunch lineage_halium_arm64-userdebug, then mka systemimage Jan 03 09:37:00 no need to remove the other rosy xml, I'd say Jan 03 09:37:30 and keep the patches, just sync devices_halium_halium_arm64 Jan 03 09:37:55 and don't forget vendersetup.sh (like in my PR for devices_halium_halium_arm64 repo) Jan 03 09:40:15 There are two things a bit annoying with healthd here: 1. I don't find any .rc that would start it, and 2. I don't know why it crashes Jan 03 13:07:59 Tofe: OK building here now as well Jan 03 13:08:11 Using our regular build script (Derrived from the Jenkins one) Jan 03 13:08:20 After adding the vendorsetup.sh Jan 03 13:13:15 GSI seems to build a lot more vs regular image Jan 03 13:13:31 I recall the number of things it was building to be around 32000, here it's 48000 Jan 03 13:24:32 out/build-lineage_halium_arm64.ninja: description = Copy: /media/herrie/HaliumDisk/9.0/out/target/product/halium_arm64/system/etc/init/healthd.rc Jan 03 13:24:32 out/build-lineage_halium_arm64.ninja: command = /bin/bash -c "(rm -f /media/herrie/HaliumDisk/9.0/out/target/product/halium_arm64/system/etc/init/healthd.rc ) && (cp \"system/core/healthd/healthd.rc\" \"/media/herrie/HaliumDisk/9.0/out/target/product/halium_arm64/system/etc/init/healthd.rc\" )" Jan 03 13:24:32 out/build-lineage_halium_arm64.ninja:build /media/herrie/HaliumDisk/9.0/out/target/product/halium_arm64/system/etc/init/healthd.rc: rule4990 system/core/healthd/healthd.rc Jan 03 13:28:54 Seems /media/herrie/HaliumDisk/9.0/out/target/product/halium_arm64/system/etc/init/healthd.rc has the "critical" value in there.. Jan 03 15:49:18 but I don't have healthd.rc in my image Jan 03 15:49:50 let me double-check it was correctly pushed on device Jan 03 15:51:05 yes, it's the gsi one Jan 03 15:53:06 damn, I have it in out/ folder, but not in system.img Jan 03 15:53:18 Hmmz OK Jan 03 15:53:36 I didn't check system.img though Jan 03 15:53:44 Can do in a bit, guests now Jan 03 15:54:20 double-damn, I have it in my system.img ! what did I do wrong.... Jan 03 16:05:20 ah, I got it. It's our initialization of /var, in the halium script, which confuses everything. At first boot after flash, we copy all of /userdata/luneos/var to /userdata/luneos-data/var... and that includes /var/lib/lxc/android/rootfs (already mounted). That's what creates this mess. Jan 03 16:13:03 I'll just disable copy of /var for now Jan 03 18:10:15 after struggling a bit with our first-start halium script, which was doing weird stuff, I now have the gsi+vendor booted Jan 03 18:10:17 and it seems to hold Jan 03 18:11:07 now I have a "library "libsdm-disp-vndapis.so" not found" which shouldn't be a big problem I guess Jan 03 18:12:43 Well this library could be important Jan 03 18:13:01 Since it's display with vendor api's Jan 03 18:13:03 I see in sailfishos-porters logs that they had a similar issue Jan 03 18:13:17 At least going by name Jan 03 18:13:22 I probably have it something in my rosy repos Jan 03 18:13:34 Should be easy enough to fix in general Jan 03 18:13:40 yep Jan 03 18:13:49 Symlink or copy to right place Jan 03 18:14:42 found it in my vendor repo, I guess it's simply missing in the .mk file Jan 03 18:14:54 Could be yes Jan 03 18:15:19 Bit of a hassle these vendor files at times Jan 03 18:15:51 Or halium_arm64 is expecting them at another location Jan 03 18:18:59 it was missing in the vendor mk file Jan 03 18:19:08 rebuilding vendor image... Jan 03 18:19:11 OK Jan 03 18:58:43 mmh I think that doing mka systemimage also populates the /vendor folder, so it's also needed to get a correct vendor.img output (TBC, I'm still building systemimage) Jan 03 18:59:23 System.img on GSI takes sygnificantly longer for me Jan 03 18:59:35 for me it was also longer Jan 03 18:59:44 but at least it's just once Jan 03 18:59:48 About 12 mins while normal one about 5 probably Jan 03 18:59:53 meh :D Jan 03 19:02:08 let's see, but the future procedure will probably be: 1. for GSI: checkout halium_arm64 + some kernel (or maybe not even needed ?), build systemimage. 2. for vendor.img: checkout as usual both device, kernel and vendor, mka systemimage vendorimage, only keep vendor.img Jan 03 19:04:05 though if the vendor part is done well, we shouldn't need to built systemimage. But we've all seen the quality of these repos :p Jan 03 19:04:49 and of course, we should be able to handpick a vendor.img from another ROM Treble build Jan 03 19:05:01 theoretically. Jan 03 19:07:49 I think I was correct: I see plenty of new binaries in /vendor now (like /vendor/bin/hw/android.hardware.graphics.allocator@2.0-service , so really important stuff) Jan 03 19:34:06 Ok good you have plenty more now :) Jan 03 19:50:27 better, now luna-next is still crashing, but at least it looks like no .so is missing Jan 03 19:51:46 Well luna-next crashing can have other causes Jan 03 19:52:11 You did put the correct android-headers this time :P? Jan 03 19:53:50 yes, but I only rebuilt libhybris, because I like crashes :p Jan 03 19:54:26 Hehe well rebuilding the rest might solve some crashes :P **** ENDING LOGGING AT Mon Jan 04 02:59:57 2021