Wednesday, 2019-12-11

T42<Matthew %lastname%> Is Sailfish more difficult to pott to an Android RootFS? If so, why?07:18
r0kk3rznot really, we do that commonly07:45
T42<Matthew %lastname%> What changes would be needed?07:49
T42<Matthew %lastname%> (besides not being able to have a custom /init )07:49
r0kk3rzyou need a custom init and kernel08:27
r0kk3rzotherwise no dice08:27
Mister_Magisterr0kk3rz: custom kernel is not really needed, same is custom init we could just edit init on /system since it's system as root now08:30
Mister_Magisterto not have custom kernel one would have to patch glibc a lot08:30
Mister_Magisterbut it's doable08:31
r0kk3rzsystemd wouldnt work without a custom kernel08:44
Mister_Magisterif you patch glibc it would08:45
*** Mister_Magister is now known as Guest83910:57
*** Mister_Magister_ is now known as Mister_Magister11:47
T42<adampigg> Liking the new after call dialog on 3.2.115:37
Mister_Magisterrinigus: you fixed bootctl in your sony device. can you tell me how you did it?16:03
maldoesn't the default bootctl work?16:15
malif you mean the command to set successful boot16:15
Mister_Magisterno default bootctl doesn't work16:20
Mister_Magisterit didn't work either in 5z or pro116:20
T42<adampigg> Mister_Magister: is our patch not good enough for you?16:24
Mister_Magistermal: question for you, why capabilities don't work in 16.016:25
Mister_Magister@adampigg what patch16:25
Mister_Magisteryou told me to ask rinigus about patch16:25
T42<adampigg> i said we have one, and rinigus improved it a little16:25
Mister_Magisteridk what patch you are talking about16:28
malMister_Magister: not sure what the issue is, can you show what you are trying to do16:28
mal@adampigg what are you even patching16:28
T42<adampigg> mister_magister: 632befce0d88528a9fe986504eafc11518bacf3016:29
Mister_Magistermal: bootctl16:29
T42<adampigg> mal: specifically, vendor/qcom/opensource/recovery-ext/oem-recovery/gpt-utils.cpp16:29
Mister_Magistermal: i need CAP_NET_BIND_SERVICE in capabalities for a pm-service to work16:30
Mister_Magisteror removing validation for it16:30
malwhat does pm-service do16:31
Mister_Magisteri have no idea but it's needed for device to boot16:32
Mister_Magisteri can ask though16:32
malon sonys we don't need anything, except making boot as successful
T42<adampigg> mal: android uses absolute filenames, sfos relative, the bootctl binary expects only the androidnaming scheme
T42<adampigg> mal: rinigus added a patch to sony aosp repo for same thing16:33
Mister_Magister@adampigg i don't have that file16:35
Mister_Magisterin addition, i have prebuild bootctl16:35
T42<adampigg> mal: mister_magister:
T42<adampigg> ^^rinigus PR16:37
mal@adampigg but why don't we have issues on xa2 or x10?16:38
T42<adampigg> mal: not having eiterh device, ive no idea! ;)16:39
Mister_Magistermal: did i mention mount --bind is also not working lmao16:39
T42<adampigg> mal: do those use sdX for rootfs, or mmc?16:40
Mister_Magister@adampigg doubt they use any recent flagship cpu16:40
Mister_Magisterlike 835 or 84516:41
Mister_Magister@adampigg meanwhile i'm hacki… erm fixing problems ^^
Mister_Magistermal: capabalities don't work so i have to do this ^16:43
malthe real question is why are capabilities not working16:50
Mister_Magister@adampigg i don't have gpt-utils16:50
Mister_Magistermal: ye that was my question ^^'16:50
Mister_Magistermal: i did this
malMister_Magister: what error do you see in logs16:52
Mister_Magistermal: spam of [  222.473161] (CPU:7-pid:4224:pm-service) IPC_RTR: msm_ipc_router_bind: pm-service Do not have permissions16:53
Mister_Magisterlike spam aka after boot i don't see anything else in dmesg/journal16:53
rinigusevening! is a correct pr and there is the same pr pushed into sony's aosp9 tree17:33
rinigusmal: as for why you don't you have the same issue in x10 and xa2 - not sure.17:34
malrinigus: I find it very odd why some sonys would have such issue but others don't17:38
rinigusmal: chipsets are different, storage is organized differently. so, looks like symlinks are made differently as well. for xz2, symlinks were such that the assumptions used in gpt-utils were incorrect. fix was initially done by piggz for his device, adjusted later for sonys17:40
rinigusin this respect looks like the divide is by chips, not manufacturer of device.17:41
Mister_Magisterrinigus: that doesn't help me much as i don't build bootctl sadly17:42
Mister_Magisterbut thanks17:42
Mister_Magistermal: any idea how to change lipstick height17:42
rinigusMister_Magister: yes, it comes from android side of things. but you should probably build it and get it used somehow.17:43
Mister_Magisterrinigus: wdym17:43
rinigushow do you plan to mark boot as 'successful'?17:44
rinigusMister_Magister: ^17:44
Mister_Magisteri have no idea17:44
malrinigus: so did you look at checking if symlinks could be fixed if those are causing some issues18:11
malrinigus: I gave the link to how boot is marked successful18:12
rinigusmal: I believe I am using the same way as xa2 and x10 to mark the boot successful. in the end of the day, its calling that function in gpt-utils. as that function was just trimming link names, we made it better.18:15
malso was the issue udev rules really?18:15
malwhich you ended up fixing in another way?18:15
rinigusit was some time ago and I don't remember the details. but, from the comment on it sounds like we have different path for created links18:16
rinigusmal: no, udev makes all correctly. just it makes them differently from what's made in android18:16
malbut if the issue is link then to me that seems like udev rule issue not issue in that18:16
malrinigus: well then those are not correct if android doesn't like it18:17
malthe whole point of the complicated rules is to make android side happy18:17
malit wouldn't be the first time we have to change the rules18:18
Mister_Magistermal: i can experiment with udev rules18:18
rinigusmal: depends on your pov. as that android function was particularly silly, sony's aosp accepted the change.18:19
rinigusand it now works for aosp and linux18:19
malmy view is that if our udev rules break something then it's our fault not android side18:19
T42<adampigg> mal: my view is that the android code should make such simple assumptions....they even assume a fixed length block device name18:24
rinigusmal: ok, let's get down to this. that function was assuming that device is in /dev/block/sda form. so, when link was to /dev/sda, you were screwed. see
T42<adampigg> s/shouldnt18:24
Mister_Magisteralso mal and rinigus here is my log
rinigusnew code checks for buffer overflows and in a more correct way (not perfect though, that would require way more data) finds device from partition name.18:25
T42<adampigg> mister_magister, error isnt bootctl binary, its the boot service ... check android log18:26
Mister_Magisterbootcontrolhal: get_partition_attribute: Failed to get disk info18:27
Mister_Magisteroh and gpt-utils: gpt_get_header: Failed to open ../../../../.. : Is a directory18:27
malrinigus: so incorrect udev rules18:29
Mister_Magistermal: i can help debugging if you want…18:29
rinigusMister_Magister: check where do those links really point. its18:29
Mister_Magisterwhat links though?18:29
rinigusits the same issue as piggz and I had18:29
mal@adampigg of course android code can make stupid assumptions, we just have to live with it, we don't really want to patch all bases with some random patches18:29
Mister_Magisterrinigus: i have no idea what links are those18:30
malprobably would be a good idea to boot to android if possible and check the ls -lR /dev/18:30
malor just /dev/block/18:31
malbut based on what rinigus said the fix should be quite simple18:31
rinigusmal: I do understand your point. not all are as responsive as sony18:32
T42<adampigg> or us with the fxtec source :)18:32
Mister_Magisterc…closed source here…18:33
T42<adampigg> well, you can be the first to try mal's way then18:33
Mister_Magisterwell i offered my help but well18:33
T42<adampigg> as mal said, you will need the /dev/ path from android, and write udev rules to re-create fully on sfos18:34
Mister_Magisteroki asked people for /dev already18:34
Mister_Magisterit will take a while though18:34
T42<adampigg> no symlinks aloud18:35
Mister_Magisteryou mean allowed?18:35
rinigusMister_Magister: pull /dev/block ls -lR18:35
T42<adampigg> ayw18:35
T42<adampigg> aye18:35
Mister_Magisteryou want sfos one too?18:36
rinigusin sfos we use relative links and point to /dev/sda18:37
rinigusas in ../../../../sda for example.18:37
Mister_Magistercan we not use relative links?18:37
Mister_Magister sfos here18:37
rinigushence you get that stupid error message from gpt-utils18:37
rinigusmal: looking forward to udev magic to fix those symlinks18:38
Mister_Magisterrinigus: passive agressive :P18:39
Mister_Magisteri will have to yet make custom install to allow sfos install in twrp18:41
Mister_Magisterrinigus: we killed him ;-;18:51
T42<Akatsu %lastname%> can i use one HADK to develop for two separated devices?18:51
rinigusMister_Magister : surely not :)18:52
vknechtmal, following up on yesterday, seems I have all correct patches esp. wrt. selinux... could it be I need to adapt ld.config.txt (which loire has), like it's done for ld.config.28.txt (which loire hasn't) ?18:58
vknechtseems like a goog alternative to adding lots of ld preloads...18:59
malcould be19:22
vknechthmm, there must be something else, seeing « SELinx: failed to acquire [...] context. Aborting » in logcat
vknechtlooks like it's binder complaining19:32
malvknecht: so are you trying to have selinux enabled or disabled?19:46
vknechtenabled, if possible19:50
vknechtdoes this question imply that if I don't use selinux=0 cmdline, I shouldn't disable selinux in /etc/selinux/config ?19:54
maland the proper patch to system/core so android doesn't try to init selinux and systemd does19:57
maldo you have all of those19:58
T42<adampigg> vknecht: i fell foul of this, when updating to 3.2.0, i had selinux enabled but permissive, 3.2.0 systemd turns it on, and dhi breaks19:59
vknechtI have those in sparse, tho disabled in config ; so SELINUX= in config should match what's set on boot ?20:01
vknechtwill have to try that then...20:02
maldisabled in config?20:03
maljust check the sony ganges kernel configs to see how it should be20:04
vknechtI meant in  sparse/etc/selinux/config20:04
malyou should use the ones in that commit I linked20:04
mali.e. permissive mode20:05
maland what did you mean by " so SELINUX= in config should match what's set on boot"20:05
vknechtwas wondering if it's a problem when selinux mode set on boot (by bootloader) is different than what's set in sparse/etc/selinux/config at SELINUX= line20:07
malit shouldn't matter afaik, hopefully20:07
rinigusmal & vknecht: while I was able to have selinux in permissive in 3.1. on xz2, 3.2 with new systemd didn't allow me to boot properly. to look into it is in my todo list at some moment...20:44
rinigus... would like to get selinux supported properly and move in parallel with official devices20:45
vknechtrinigus, what were the symptoms following 3.2 change ? was it something like {hw,vnd}servicemanager getting killed, or something else ?21:02
rinigusvknecht: it was stuck on logo, I think. can't find log right now, will probably have to try again some other night21:04
rinigus(getting late over here)21:05
vknechtok well, that's what I have (stuck on logo, with led lighting for ~30s then off), tried both disabled and permissive in config file but it's the same21:06
vknechttho I suspect there's some loire difference to handle21:06
vknechtbut right, it's late, we'll see :-)21:07
vknechtI mostly followed tama's procedure, but I have a doubt about syspart section: ganges' procedure mention doing a "rpm/ --mb" while tama's don't21:10
rinigusvknecht: interesting... I used ganges as a base and I do wonder whether I missed it when I was doing it21:13
vknechtmaybe it's nothing, or handled differently, can't say I have it all wrapped around my head21:13
vknechtuh, is the community meeting tomorrow ? too bad there was no reminder :-)21:20
malthere are sets of patches, one for system partition and other for hybris, in the sony build21:29
vknechtah, and the syspart part is just the equivalent of sony's repo_update, right ?21:32
T42<edp_17> @Elros, Can you help me if you are around, please?22:17
deathmistthere is definitely something horribly wrong with RIL on SFOS side for me, logcat -b radio only gives about 200 lines and never gets any output after toggling cellular, compared to android with almost 4400 lines from same output and connected cellular data right after boot22:22
deathmistSMS and calls work flawlessly, just cellular data is dead and not working in Sailfish OS for me...22:23
deathmistdevice is OnePlus 5 / cheeseburger based on hybris-16.0 (RIL v15)22:24
T42<edp_17> I am still struggling with my S7 port. Have added the suggested parameters into my kernel defconfig, recompiled the kernel, rebuilt the sfos image, flashed on the device and got the same symptom: the phone stuck on Samsung logo and I manually need to assign a mac address then an IP address to be able to telnet into it.22:24
T42<edp_17> I am puzzled what's wrong. 😢22:25
T42<edp_17> I have connected to the phone with telnet, then did a 'tail -f /init.log &' then 'echo "continue" >/init-ctl/stdin' but still stuck at the samsung logo.22:27
T42<edp_17> When I tried 'systemctl --user restart lipstick' I got: 'Failed to get D-Bus connection: No such file or directory'22:28
deathmist@edp_17 prob just means systemd isn't running correctly, did you run that from initramfs (telnet 23) or SFOS rootfs (telnet 2323)?22:30
T42<edp_17> I did 'telnet 2323'22:31
T42<edp_17> Should I try to 'telnet 23'?22:32
T42<edp_17> The 'telnet 23' gives me: 'telnet: Unable to connect to remote host: Connection refused'22:33
deathmistno lol that is for very early init, you don't use it unless SFOS rootfs fails to load (/data not mounted or something)22:33
deathmistdbus issues / journalctl not working point to incorrect defconfig iirc, there could be other things wrong too that influence this tho. what base are you using? output of "mount" command is probably useful22:35
T42<edp_17> I use CM14.1 base. The output of mount:
T42<edp_17> Soryyyyy, wrong mount output! That's my pc's22:39
T42<edp_17> I accidentally exited the telnet before I did the mount.22:40
T42<edp_17> This is the output of mount of the device:
T42<edp_17> Sorry!22:40
deathmistright, well you only seem to have /data mounted which isn't much help to get droid services running etc. other mounts like /system should've be picked up from your device fstab => fstab is probably not in out/ of your HADK source tree22:45
deathmistthat's all I'm gonna say as I'll have to go now and get some sleep22:45
T42<edp_17> Thank you and good night!22:46
T42<elros34> @edp_17 have you checked droid-hal-$DEVICE.log like I told you?22:52
T42<elros34> you also had android.mount in you log. Where did it come from?22:56
T42<edp_17> Hi @Elros! Yes, and I found something bigger issue.23:02
T42<edp_17> Or maybe it is not, I just think big.23:02
T42<elros34> so why don't you pastebin it and upload your droid-config changes because that mount unit looks wrong and timouts23:03
T42<edp_17> Give me a few minutes I commit and push all changes to github.23:03
T42<edp_17> Oh well, yes I can put that to the pastebin. In a minute.23:04
T42<edp_17> The issue I have found was: the .repo/manifest.xml was pointing to the manifests/default.xml rather to the local_manifests/herolte.xml23:06
T42<edp_17> At least in my hammerhead build the .repo/manifest.xml is pointing into the local_manifests/hammerhead.xml23:07
T42<elros34> I also have manifest.xml -> manifests/default.xml23:10
T42<edp_17> Okay, so this might wasn't a problem then.23:11
T42<elros34> problem is probably with your mount points23:12
T42<edp_17> In the meantime I uploaded the defconfig:
T42<edp_17> and the mer-kernel-check result:
T42<edp_17> How and where should I check that mounting point? Is it supposed to be somewhere in sparse?23:15
T42<elros34> I told you check droid-hal-$DEVICE.log23:16
T42<elros34> not sure if that is important but you should set CONFIG_UEVENT_HELPER_PATH="", CONFIG_AUTOFS4_FS=y and CGROUP related when possible23:17
T42<edp_17> The droid-hal-herolte.log:
T42<edp_17> Yes, I did check that, but I wasn't sure what I see was good or not so good.23:19
T42<elros34> check content of /lib/systemd/system/system.mount. It should mount /dev/sdaX. Looks like you are missing detritus package23:23
T42<edp_17> Okay, I set those what you suggested in the kernel defconfig and re-try. Thanks.23:24
T42<elros34> kernel changes are not that importatn right now. You still didn't answer about android.mount . It's not created by droid-hal so I guess you created it?23:26
T42<edp_17> I didn't do that.23:29
T42<edp_17> 5.3 in the hadk. Oops. I didn't need to worry about that in hammerhed so I skipped that for the S7 too. I go back and check.23:30
T42<elros34> check what package provides these moun units: rpm -qf /lib/systemd/system/android.mount and android_external.mount and what they contains.23:34
T42<edp_17> I have found out that I did update the fixup-mountpoints with the relevant stuff:
T42<edp_17> android.mount and android_external.mount are by me:
T42<edp_17> I wanted to mount the android root into /android and the external sd card into /externalsd.23:37
T42<edp_17> Wasn't a good idea?23:37
T42<elros34> no, android.mount is wrong (it use /dev/block/sdaX instead /dev/sdaX) and pointless, this partition is already mounted in /data. External sdcard should be mounted by udisks23:38
T42<elros34> Remove them drom device, reboot and get fresh journalctl. This is also needed:
T42<elros34> from*23:41
T42<edp_17> Okay, the android.mount I copied over from hammerhead and modified, then I created the other.23:41
T42<elros34> is also wrong. You added to many custom changes instead just trying to get gui working first23:43
T42<edp_17> Aye aye, sir. android.mount and the other plus the corresponding .sh from /usr/bin are removed.23:44
T42<edp_17> I am a bit lost, where that is located?23:46
T42<edp_17> Found it.23:47
T42<edp_17> I didn't add anything extra into that. Hmm.23:48
T42<edp_17> The thing is, based on my recent hammerhed work, I thought I squeeze everything into the firs S7 build what I could. Seemingly that was a very bad idea.23:53
T42<edp_17> I wanted to save time and do less iteration.23:53
T42<elros34> if you want to do less iteration then make changes on device23:54
T42<edp_17> I see.23:55

Generated by 2.17.1 by Marius Gedminas - find it at!