**** BEGIN LOGGING AT Fri Mar 02 03:00:03 2018 Mar 02 04:11:09 Same issue even with the fstab change Mar 02 04:11:28 vold just decides to crash Mar 02 04:16:46 and the modem doesn't have a reason for restarting, just "-19" Mar 02 06:31:05 morning Mar 02 06:31:09 mariogrip: You around? Mar 02 06:36:38 I doubt he will be at moment Mar 02 06:36:54 bshah: OK you might know this one as well ;) Mar 02 06:37:16 * bshah hides Mar 02 06:37:57 https://github.com/Halium/android_device_htc_pme/commit/4de59918ba8361111cac2c26ee593a6f80e1d346 Mar 02 06:38:12 This context in fstab is ubports specific or also for the other OS-es? Mar 02 06:38:29 it's for all OS-es Mar 02 06:38:46 basically coreutils in some distribution is not built with selinux enabled Mar 02 06:38:53 so it fails to mount in that case Mar 02 06:38:56 so we remove it just Mar 02 06:39:10 exaple of such distro debian, arch Mar 02 06:39:12 bshah: OK. Could this be the case of my sensors not working or would other stuff like wlan also not work then? Mar 02 06:39:31 no.. not really Mar 02 06:39:33 Because seems most my things work except for sensors... Mar 02 06:39:47 this is fix for when the partition fails to mount Mar 02 06:40:09 Well seems we don't have this issue in LuneOS, we just missed the bind-mount :P Mar 02 06:40:12 That didn't help Mar 02 06:40:57 For persist ;) Once that was added my wifi started to work without me needing to copy files around ;) Mar 02 06:41:26 right Mar 02 06:45:08 bshah: Got any clue what causes "02-13 18:24:30.371 64 491 E NetlinkListener: recvmsg failed (I/O error)" in logcat? Mar 02 06:45:16 It floods my logcat quite a bit Mar 02 06:45:23 When that one is gone, it's pretty clean Mar 02 06:45:25 If you find out let me know :P Mar 02 06:45:47 For sensors I see this in logcat: https://bpaste.net/show/87b4a4f77785 Mar 02 06:45:54 Does that ring a bell somehow? Mar 02 06:55:51 02-13 18:05:18.035 5736 5739 E Sensors : sns_reg_la.c(305):Error opening registry file ... it seems to be trying to open some file but fails.. Mar 02 06:56:20 it is either case of missing mount points? or simply file not existing? or dunno Mar 02 08:14:17 morning Mar 02 08:15:34 is there some initrd of halium-boot lying around ? For any kind of device really, it's just to see the content without having to build one myself Mar 02 08:16:17 hammerhead would be perfect though :p Mar 02 08:16:29 initrd is device independant Mar 02 08:16:56 ah yes right, it doesn't have the kernel yet in there Mar 02 08:17:53 hum wait, you don't have the same initrd for armv7 and aarch64 Mar 02 08:18:08 Tofe: https://github.com/Halium/initramfs-tools-halium/releases Mar 02 08:18:22 perfect, thanks Mar 02 08:19:38 bshah: Well it points to some file called sns.reg however there's little evidence of it existing on many targets ;) Mar 02 08:20:21 I do see this in strace, not sure that's normal: "newfstatat(AT_FDCWD, "/dev/__properties__", 0x7fed582418, 0) = -1 ENOENT (No such file or directory)" Mar 02 08:20:31 To me __properties__ looks like a weird name? Mar 02 08:25:51 Another one might be openat(AT_FDCWD, "/etc/qmi_fw.conf", O_RDONLY) = -1 ENOENT (No such file or directory) Mar 02 10:23:39 krnlyng: ping Mar 02 10:45:55 Herrie|Laptop, o/ Mar 02 10:47:26 krnlyng: I think I found it already... Just wasn't sure when I will need the QT_OPENGL_NO_BGRA for qtscenegraph and --enable-adreno-quirks for libhybris Mar 02 10:47:59 Documentation seems to suggest 64 bits and SFOS browser, but I'm on LuneOS :P Mar 02 10:48:48 Herrie|Laptop, QT_OPENGL_NO_BGRA fixes hybris textures i.e. disables the usage of BGRA textures created with eglHybris calls. since those will result in black pictures. Mar 02 10:49:07 krnlyng: Ah that's what I might be having Mar 02 10:49:08 Herrie|Laptop, it is also used to avoid BGRA in other cases where it causes insane perfomance degradation Mar 02 10:49:18 I'm missing my background in LuneOS Mar 02 10:49:32 Well I actually have LunaSysService crashing but that might be due to that Mar 02 10:49:35 It randomly works Mar 02 10:49:54 I.e. sometimes I see it, sometimes not... So that's not very helpful Mar 02 10:50:10 Herrie|Laptop, QT_OPENGL_NO_BGRA doesn't avoid crashes Mar 02 10:51:18 I guess I'll try the quirks & QT_OPENGL_NO_BGRA to see if it fixes anything Mar 02 10:51:32 Herrie|Laptop, --enable-adreno-quirks is used to avoid crashes in certain adreno implementations which are most likely caused by driver bugs (i can explain in depth why we believe that these are driver bugs if you'd like). Mar 02 10:52:03 krnlyng: I believe you that it are bugs, how do I know my target might be bugged? Mar 02 10:52:14 It's the mido, same piggz did SFOS port for Mar 02 10:52:42 Herrie|Laptop, then it's most likely buggy, since piggz had to apply those patches/env settings afair. Mar 02 10:52:56 OK Mar 02 10:53:01 Will do the same at my end Mar 02 10:53:28 krnlyng: curious question, does enabling "--enable-adreno-quirks" mess with the qcom/adreno devices which are not affected? Mar 02 10:54:36 Herrie|Laptop, general rule of thumb: if the device is 64-bit + adreno, at least the 32 bit blobs are likely to be buggy. Mar 02 10:55:40 bshah, it doesn't produce any immediate additional issues if that is what you fear :) Mar 02 10:55:51 okay Mar 02 10:56:06 bshah, you can also enable it on mali devices and you'll be fine for the most part. Mar 02 10:56:25 bshah, still you should not enable it on devices where it is not required. Mar 02 10:57:20 krnlyng: right.. I asked this question because well halium, ubports and PlaMo, all try to have "one-rootfs-to-rule-all-devices" Mar 02 10:57:34 so currently it is enabled for all devices Mar 02 10:57:44 which so far is not causing any issues Mar 02 10:58:14 bshah, this is due to the nature of the bug/and bug fix: it increases memory usage. it might not be much but that's how it is. Mar 02 10:59:34 krnlyng: Well I got 64 bit device and mainly 64 bits in my rootfs Mar 02 10:59:47 But yeah I saw piggz couldn't get sensors working without some HTC 32 bits blobs Mar 02 10:59:50 And libhybris hack Mar 02 11:00:03 Think I might need to go down the same route Mar 02 11:00:19 Herrie|Laptop, it might also affect the 64 bit blobs. that hasn't been tested on our side yet. Mar 02 11:02:19 krnlyng: I guess I'll find out soon enough.... So far I got UI to display and most things seem to work apart from sensors... I.e. got audio, buttons work etc, so not a bad start.... Mar 02 11:02:27 Fixed a QT bug along the way :) https://code.qt.io/cgit/qt/qtbase.git/commit/?id=1c2499cbf141d7b07feef0b6a7ecda2b69fcc219 Mar 02 15:31:15 anyone remember how to fix `'unknown type exfat' at token '` Mar 02 15:31:28 @tchncs_bot, this? Mar 02 15:32:15 this reminds me Mar 02 15:32:34 i like how you started typing on Telegram, but then switched to IRC xd Mar 02 15:32:41 we need to act on : https://github.com/Halium/android/pull/10 Mar 02 15:32:53 i got this while building a op3 image Mar 02 15:33:36 is this fixable yet, or do i need to wait? Mar 02 15:33:46 marius somehow has a working op3 build -_- Mar 02 15:33:57 bshah: I also sent you some stuff to merge :P Mar 02 15:34:14 @vanyasem, I think he got fed up at configfs Mar 02 15:34:30 @vanyasem for time being, revert 83840c7f863cd30bd0df3c6db3701e39eee2a097 in system/sepolicy Mar 02 15:34:44 or wait for PR #10 and all other sub PRs to get merged Mar 02 15:35:31 bshah: FYI https://github.com/Halium/android_system_core/pull/4, https://github.com/Halium/android_build/pull/10/ and https://github.com/Halium/android/pull/14 all related to each other ;) Mar 02 15:36:22 Herrie|Laptop: for PR #4, would you mind if I close your PR and push my local commits? I've multiple changes I need to push and this is one of them Mar 02 15:36:34 I want to avoid merge conflicts Mar 02 15:36:45 bshah: Sure I took it from you anyway Mar 02 15:36:55 Just wanted to make sure it didn't get forgotten Mar 02 15:36:59 And mainly for my build to work Mar 02 15:37:46 @bshah, reverted, now i get `unknown type themeservice_app_data_file` Mar 02 15:37:46 https://github.com/Halium/android_build/pull/10 .... it's confusing? Mar 02 15:37:51 Others were to fix my missing binaries for ip, iptables and ip6tables. iproute2 was needed for sure. I wasn't sure about the others, but they don't harm to be there Mar 02 15:37:57 @Walid, this Mar 02 15:38:17 @vanyasem: find what added that type and revert it xD in system/sepolicy Mar 02 15:38:49 I compared the 5.1 and 7.1 checked what was missing. I figured that some stuff was removed in 7.1 and indeed doesn't need to be there, but other things still need to be there Mar 02 15:39:33 Herrie|Laptop: in pull #10, log is confusing to me Mar 02 15:39:54 like ip, iptables, ip6tables. Not sure about bson, connectivity, lz4 and mkimage, but thought it doesn't hurt to have them anyway Mar 02 15:40:00 bshah: You mean there are 2 commits? Mar 02 15:40:12 That must have been my local stuff updating from upstream Mar 02 15:41:50 I can do a clean PR with just https://github.com/Halium/android_build/pull/10/commits/57847b2fd079f143e7de787ebb2d35984e4d27f4 Mar 02 15:41:56 If that solves confusion? Mar 02 15:42:22 yeah, it avoids history mess as well Mar 02 15:42:25 :) Mar 02 15:43:32 OK let me try to clean it up Mar 02 15:48:57 bshah: https://github.com/Halium/android_build/pull/11 Mar 02 15:49:27 merged Mar 02 15:55:15 bshah: Cleanup as per JBB comments: https://github.com/Halium/halium-devices/pull/54 Mar 02 16:03:04 i was not able to find that commit, it seems like it's nowhere in the tree Mar 02 16:03:10 i ran a search using `gitk` Mar 02 16:03:35 hm Mar 02 16:15:00 I wonder where I am wrong Mar 02 16:19:18 @vanyasem You got a device running PlaMo successfully, right? Mar 02 16:19:38 yep Mar 02 16:19:47 a bunch of them actually Mar 02 16:19:51 Could you give me output of the `mount` command? Mar 02 16:20:55 in 5 minutes, ok? Mar 02 16:21:34 Yep :) Mar 02 16:22:46 I need to flash some device real quick, as I have been working with utouch recently lol Mar 02 16:32:03 @vanyasem, @bhushanshah fixed my issues by reverting commits in vendor/cm/sepolicy/qcom/ Mar 02 16:32:22 oops forgot about you @ilyaishere Mar 02 16:32:51 :P Mar 02 16:33:02 wait, booting my device Mar 02 16:34:00 oh i have the wrong boot image Mar 02 16:34:11 @bhushanshah halium boot in plasma when? Mar 02 16:34:32 @vanyasem, Don't be Simon. :P Mar 02 16:35:29 @UniversalSuperBox, Does ofono work on ubtouch 16.04 ? Mar 02 16:36:06 Actually, it did run on the 5X for a short time Mar 02 16:36:10 It was a few hacks in. Mar 02 16:36:48 And what about 15? Mar 02 16:36:57 I wouldn't touch that any more Mar 02 16:37:09 Incredibly shortsighted. Mar 02 16:37:16 @vanyasem, Is it better? Mar 02 16:37:41 @ilyaishere, https://phabricator.mynameisivan.ru/P7 Mar 02 16:37:45 We're working on the backlog now, then we'll get OTA-4 out, then I think we'll have an opportunity to work on Halium integration Mar 02 16:38:46 @vanyasem, Wow, thanks :) Mar 02 16:39:12 Hosting your own Phab instance? xD Mar 02 16:39:47 @ilyaishere, also mediagoblin, airsonic, mastodon, and nextclous xd Mar 02 16:39:47 @ilyaishere, [Edit] also mediagoblin, airsonic, mastodon, and nextcloud xd Mar 02 16:40:17 😅😬 Mar 02 16:41:35 Trying to figure out why /config isn't mounted properly... Mar 02 16:53:20 New! Fresh! Tangentally related! "Mir servers fail to run on devices that ship with CAF's Android for MSM": Mir servers fail to run on devices that ship with CAF's Android for MSM Mar 02 16:53:36 Fumbled the link Mar 02 16:53:37 https://github.com/ubports/ubuntu-touch/issues/494 Mar 02 16:56:53 @UniversalSuperBox, Bad news for me 😞 Mar 02 16:58:23 Or maybe I should say good, if its getting fixed soon enough Mar 02 17:54:26 Yeah, my axon7 port is affected too. Mar 02 17:54:26 :/ Mar 02 17:55:09 Welp might as well switch gears to porting my HTC one m8 I guess? Mar 02 17:55:12 Well, had to get it out there so hopefully someone could take a stab at it. Unfortunately we need to double down on our current devices at the moment Mar 02 17:59:44 UniversalSuperBox: do you have a minute do discuss halium-boot ? there's a section I might misunderstand Mar 02 17:59:56 (or @JBB) Mar 02 17:59:58 You bet! Mar 02 18:00:21 UniversalSuperBox: basically the section about mounting userdata Mar 02 18:00:28 and the data stuff Mar 02 18:00:59 one thing is that it modifies rootfs -- but that's not critical here Mar 02 18:01:16 Mainly, this: https://github.com/Halium/initramfs-tools-halium/blob/halium/scripts/halium#L506 Mar 02 18:01:24 Right, it can be opportunistic if the rootfs doesn't provide the right paths Mar 02 18:02:08 The `mount --move`? Mar 02 18:02:09 ${rootmnt}/userdata isn't a critical directory I think, so it might be better to put it in ${rootmnt}/android/userdata right ? Mar 02 18:02:47 Now that's an interesting problem... I'd honestly prefer to never give `/userdata` to userland, since it's the physical data partition Mar 02 18:03:16 well, it can be handy Mar 02 18:03:25 for the actual user's data Mar 02 18:03:43 Thing is, it's not actually something that Android should have. Mar 02 18:03:44 but you're right it should never become essential Mar 02 18:04:18 in our LuneOS boot, we also have a luneos-data directory in userdata, which is used for user's data Mar 02 18:04:38 Android's `/data` resides safely in physical `/data/android-data`, so you never get the mess from the running services. Mar 02 18:04:56 And also Android can't touch your stuff. Mar 02 18:05:36 @UniversalSuperBox so if I am understanding correctly, my one m8, which has support for both cm12.1 and los14.1, I should port using Halium 5.1 because of the issue above? Mar 02 18:05:41 luneos-data sounds like Ubuntu Touch's user-data, which gets put in writeable-paths Mar 02 18:05:47 @rockybulwinkle, Worth a try Mar 02 18:05:53 Yes, /data was going to be my next point :) The distribution shouldn't have a /data -> android/data link, then? Mar 02 18:06:35 I did create one, and it messed up the init script :) Mar 02 18:06:39 @rockybulwinkle, Well I'd suggest to wait little bit, the issue itself is not that critical anyway Mar 02 18:06:56 How'd it mess it up? Mar 02 18:07:18 Ohhhh Mar 02 18:07:18 one moment, I'll paste it Mar 02 18:07:21 L477 Mar 02 18:07:33 No wait, that's an Android boot Mar 02 18:07:48 @bhushanshah, Not too critical yet a blocker for those devices? Mar 02 18:07:51 more like L510+ Mar 02 18:08:10 Ah, yes Mar 02 18:08:17 https://paste2.org/tCWaVCGC Mar 02 18:08:42 @rockybulwinkle, I mean it's nothing which can't be solved Mar 02 18:08:55 the error with /rfs/data is when you do mkdir on a symbolic link, it's a weird error Mar 02 18:09:27 Right... I guess we should instead choose to link `/data -> /android/data` Mar 02 18:09:38 oooh, now I get it, it's not weird, because /android/data doesn't exist Mar 02 18:09:48 Oh jeez I'm confused Mar 02 18:10:07 the /data stuff is kind of confusing :) Mar 02 18:10:28 But I can explain, I have the device under the eyes and I understand what happened Mar 02 18:11:14 so for me, there is already a /data -> /android/data link in my rootfs. But there is no /android/data directory yet, it's up to halium init to create it Mar 02 18:11:18 which it never does Mar 02 18:11:30 ah wait yes it does Mar 02 18:11:35 oh jeez :) Mar 02 18:13:00 Yeah, that's done in L501 Mar 02 18:13:01 I'll just replay the init script by hand within recovery Mar 02 18:13:25 with a bit of luck it'll be the same error, maybe with more details Mar 02 18:13:53 I guess it'd really just be easier for `/data` to be a symlink Mar 02 18:14:23 it's what I have in my rootfs yes, and it's consistent with persist, firmware and all the android stuff Mar 02 18:15:02 oooh now I get it Mar 02 18:15:35 My symlink is precisely "data -> /android/data", *not* "data -> {$rootmnt}/android/data" Mar 02 18:15:49 so the symlink, at the time of the init, it dead Mar 02 18:15:50 Ohhhhhh Mar 02 18:16:30 so all the symlinks are dead until we switch root, that's good to remember Mar 02 18:17:12 I'll patch the script to just avoid manipulating /data Mar 02 18:17:17 Unless you were to make them relatively Mar 02 18:17:35 If the script only manipulates /android/data, it should be fine Mar 02 18:24:43 ok done, let's see... Mar 02 19:57:29 Tofe, did it work? Mar 02 19:58:08 Yes, I'm now booting the OS; there are still some fixes to do still, but the main things work Mar 02 19:58:23 Okay. So how do you want to do this config thing? Mar 02 19:58:46 sorry, which config ? Mar 02 19:58:59 For mountpoints, like the lxc mount point Mar 02 19:59:51 Your specific concern was for the module mountpoint Mar 02 20:00:08 yes, I don't have the solution yet for the kernel modules Mar 02 20:00:23 for lxc we can keep it like that for now Mar 02 20:00:49 My first idea was just to source a file from `${rootmnt]/etc/halium` but then I remembered that people do nasty things Mar 02 20:00:51 And sourcing a file runs the code in it Mar 02 20:01:17 I'm not that fond of sourcing a rootfs file from initramfs either :) Mar 02 20:02:37 Would a config file in, say, `/etc/halium` make sense? Mar 02 20:03:08 why not, it's not shocking or anything Mar 02 20:03:23 Or should we specify something that sits alongside a rootfs so it's outside the reach of userland (assuming `/userdata` isn't mounted) Mar 02 20:03:50 I would prefer the former Mar 02 20:03:59 Works for me Mar 02 20:04:19 Wonder what kinds of files we can easily parse with Busybox Mar 02 20:05:05 without sourcing it, it's a good question Mar 02 20:05:16 line with A=B seem easy enough Mar 02 20:05:25 maybe there's better Mar 02 20:07:42 FYI, I'm currently using this modified init script: https://paste2.org/4WxxEfkI Mar 02 20:08:18 Just send back any PRs that you want in upstream 😁 Mar 02 20:08:33 most of the modifications should be ok for other distros too, so I'll PR them, except the kernel modules that I disabled Mar 02 20:09:19 Yup, I'm just making sure I can boot LuneOS with the version I'll PR :p Mar 02 20:17:30 Tofe: Great work! Mar 02 20:28:11 ah I forgot /vendor -> /system/vendor , silly me Mar 02 20:28:36 yup, works Mar 02 20:30:34 UniversalSuperBox: for my PR I'll avoid the kernel modules issue just by putting it in a function and overriding that function on my current LuneOS init script Mar 02 20:31:04 So that gives us plenty of time to guess what's best for the real solution Mar 02 20:54:58 ... and here you go: https://github.com/Halium/initramfs-tools-halium/pull/11 Mar 02 20:57:48 I downside of my PR, is that it's untested for other distribs... so be careful Mar 02 21:03:08 i hosted my halium images here https://halium.mynameisivan.ru/. is there a place where image links go? Mar 03 01:25:44 Hi all, I am having an error when making systemimage with omap4 and pvrsrvinit. Can anyone help explain? full text below Mar 03 01:26:00 https://pastebin.com/YkLTFiSe **** ENDING LOGGING AT Sat Mar 03 03:00:00 2018