**** BEGIN LOGGING AT Tue Dec 29 02:59:57 2020 Dec 29 09:33:51 some progress (with baunilla's kernel) : https://paste2.org/ejDPHgZa Dec 29 09:37:53 I didn't use BOARD_BUILD_SYSTEM_ROOT_IMAGE though, I'm trying another way with putting the android ramdisk in our lxc folder, next to system.img and vendor.img, and take it into account by halium's script Dec 29 09:38:46 ( with this modification: https://github.com/Tofee/initramfs-tools-halium/commit/422e3d1caa6f1bd5aa79d7c7bf065a0140b1792e ) Dec 29 09:39:52 I think the fatal failure currently is "init: Failed to fchmodat socket '/dev/socket/property_service': No such file or directory"; not sure why this socket does exist though Dec 29 09:39:59 doesn't* Dec 29 09:45:13 now I'm comparing with recovery's dmesg https://paste2.org/Z0y58svz Dec 29 09:57:29 Morning Dec 29 09:58:17 Tofe: Could be we need some patch for property_service somehow Dec 29 09:58:25 It does ring a bell somewhere Dec 29 09:59:56 well, it does look like my ramdisk doesn't have /prop.default Dec 29 10:00:16 it's there in recovery, and holds a couple of basic values Dec 29 10:01:20 Ah ok that should be easy enough to add? Dec 29 10:02:11 probably, but then I'm not sure what else would be missing Dec 29 10:06:53 I have a system/etc/prop.default and a system/build.prop Dec 29 10:13:10 ah, I might have found the issue: my system/product/build.prop is incorrect Dec 29 10:13:57 https://paste2.org/z5PhHy2m Dec 29 10:19:16 That should be from Android build side normally? Dec 29 10:19:39 yes, I guess it doesn't handle well the fact that USE_LOGICAL_PARTITIONS isn't defined at all Dec 29 10:20:12 but I'm beginning to wonder if avoiding BOARD_BUILD_SYSTEM_ROOT_IMAGE is a good idea Dec 29 10:21:05 It'll be the default for all future Android versions, and is already mandatory in Android 9 for non-upgrade scenarios Dec 29 10:21:23 so maybe it would be just as well to begin really using it Dec 29 10:22:34 The only reason I'm hesitant is that our lxc start scripts do a lot of little patches in android's rootfs Dec 29 10:25:03 Tofe: Well it shouldn't be that many? Dec 29 10:25:08 ( ... and it's the same for halium's lxc start script. ) Dec 29 10:25:18 That are specific for us? Dec 29 10:25:39 no, it's not much, but we insert our startup-finished indicator there, for instance Dec 29 10:27:29 I think they might do that on Android side for Halium 9 Dec 29 10:27:34 I saw something like it somewhere Dec 29 10:28:00 ah, that would be nice Dec 29 10:28:07 I'll look in the patches Dec 29 10:30:47 there is 0013-hybris-reach-main-init-state.patch it seems Dec 29 10:31:17 ah, no, it's not that Dec 29 10:32:51 found it: https://github.com/Halium/hybris-patches/blob/halium-9.0/system/core/0008-hybris-Notify-Mer-s-systemd-that-we-re-done.patch Dec 29 10:33:12 yay, not at all Mer specific :p Dec 29 10:41:55 Tofe: I'm surprised they let it in there, but seeing UBTouch still uses Upstart probably it doesn't hurt them Dec 29 10:46:39 plenty of patches are actually Mer specific Dec 29 10:47:10 As they suppose that the Android runtime isn't run from within a LXC container Dec 29 10:47:33 (the former patch 0008 does so, for instance) Dec 29 10:55:04 Weird that UBPorts works then Dec 29 10:55:25 maybe they forked the patches ? Dec 29 10:56:23 ah, but they use their GSI Dec 29 10:57:00 so they probably integrated the patches, and then started from there to make GSI work on ubports Dec 29 10:57:30 You mean they forked hybris-patches again from Halium in UBPorts and patched further there? Dec 29 10:58:23 Seems 1 commit only, though 1 we might need: https://github.com/erfanoabdi/hybris-patches/commit/57ec8a6d4687cbb11c720aa812b4b3629710ece6 Dec 29 10:59:32 yes, that one would be needed Dec 29 10:59:54 it's a pity sailfishos guys didn't choose that solution Dec 29 11:04:55 I guess a good solution here would be to patch Mer's patch and add the property change Dec 29 11:07:03 Mer doesn't use Halium so we should be free to patch here Dec 29 11:07:59 let's test things a bit, first :) Dec 29 11:08:36 Herrie: I already proposed your vendor patch to Halium, but let's also wait until we have something working Dec 29 11:08:55 Which vendor patch? Dec 29 11:09:00 To build vendor.img? Dec 29 11:09:02 Or ... ? Dec 29 11:09:54 https://github.com/Halium/initramfs-tools-halium/pull/24 Dec 29 11:11:10 Ah ok Dec 29 11:11:13 Yeah I had that one Dec 29 11:12:45 Yes, I'm surprised Halium didn't add this already, it's quite essential with Halium 9+ Dec 29 11:19:02 What I understood is that they just use the Vendor from device itself Dec 29 11:19:06 That's what NotKit told me Dec 29 11:19:18 Since they mainly use GSI, it's not really their worry Dec 29 11:21:51 ok yes Dec 29 11:22:04 and we should do the same, in the end, of course Dec 29 11:31:41 Ideally yes, but GSI has it's own issues as well it seems Dec 29 11:45:50 damn, with a system-as-root, the android init goes to reboot almost right away Dec 29 11:50:08 still a faulty system/product/build.prop, even with system-as-root Dec 29 11:52:00 Probably issue in device tree? Dec 29 11:53:29 I've now defined USE_LOGICAL_PARTITIONS := false in Board file, it's better Dec 29 11:56:00 still the same, not much to read in the pstore Dec 29 12:04:27 :( Dec 29 12:09:48 Might be something small, it usually is :S Dec 29 17:44:28 from what I can see, it's a bit of a mess... no fstab in the root folder (but in system/etc), currently it's failing to find a /plat_property_contexts SELinux file... Dec 29 17:44:59 symlinks are going a bit everywhere (to system, odm, vendor...), it's quite hard to follow Dec 29 18:08:11 I thought SELinux was completely disabled somehow? Dec 29 18:08:17 Or should be at least Dec 29 18:20:10 well, it should, but it still seems to be fatal: https://paste2.org/Z2s76LZj Dec 29 18:20:48 I'll investigate a bit more thought, maybe it's something else that leads to "Failed to initialize property area" Dec 29 18:50:00 It could also be something that can be ignored Dec 29 18:51:08 Can also be you might need to check defconfig or kernel cmdline for selinux Dec 29 18:51:11 Not really sure Dec 29 18:54:14 Seems Mer guys just define some files in their setup? https://github.com/mer-hybris/droid-hal-sony-nile/blob/3976bff9f66f2fca85d868cacafed6259011757a/droid-hal-common.inc#L23 Dec 29 18:55:35 Ah seems they use that for packaging somehow: https://github.com/mer-hybris/droid-hal-device/blob/c9d2017d94f441e3bb1c00232876e8c99ca52ee4/droid-hal-device.inc#L84 Dec 29 21:16:17 Herrie: I mainly wonder why our standard halium build doesn't provide it; after all, I guess it's there for baunilla's build, and we're just inhibiting some parts Dec 29 21:29:44 Tofe: Well we strip down LOS build quite a lot Dec 29 21:30:27 I.e.: https://github.com/Herrie82/android_device_xiaomi_rosy-2/commit/3b3c0f30b528172ac459554dfa43af98f24aa0fb Dec 29 21:30:37 But they do that for GSI as well Dec 29 21:31:10 Though for GSI they might take it from LOS Android itself somehoqw Dec 29 21:32:16 yes... anyway, I'll continue tomorrow :) Dec 29 21:32:35 Does our fstab take care of f2fs fix? https://github.com/ubuntu-touch-lavender/android_device_xiaomi_lavender/commit/155d3912720908c3f4f4f8b3c8c5467ad8a7d5b6 Dec 29 21:34:00 https://github.com/ubuntu-touch-lavender/android_device_xiaomi_lavender/commit/a0253b06f6c023ea9015c48d10a3c83826c7e390 Dec 29 21:34:09 I don't know, I'll have to check; but our halium initrd doesn't even find fstab so far, so... :p Dec 29 21:38:03 Tofe: This one might have some clues: From 15 april onwards: https://github.com/fredldotme/android_device_google_bonito/commits/halium-9.0 Dec 29 21:49:24 Volla Phone Halium 9 might also give some clues: https://github.com/HelloVolla/android_device_volla_yggdrasil/commits/halium-9.0 **** ENDING LOGGING AT Wed Dec 30 02:59:57 2020