piggz | mccreary: do you have a working bootctl binary? | 10:19 |
---|---|---|
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 10:19 |
T42 | <adampigg> mal: overriding those services and adding selinux_stubs hasnt stopped them crashing | 11:19 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 11:19 |
mal | @adampigg ok, so it's something else, I think signal 9 usually was selinux related, not sure though | 11:23 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 11:23 |
T42 | <adampigg> btw, ive requested ircsomebot get cancelled | 11:58 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 11:58 |
mal | why did it appear here? | 12:01 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:01 |
T42 | <adampigg> mal, i suppose i have the code to debug failing services...imsdatadaemon exits with 255, doesnt crash | 12:27 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:27 |
mal | @adampigg do you have the selinux related files in root | 12:30 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:30 |
T42 | <adampigg> mal, doesnt look like it. | 12:32 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:32 |
T42 | <adampigg> mal, also, im afraid to reboot phone...im away from home all weel, and my laptop doesnt like te fxtec (or vice versa) in fastboot mode. so, to flash boot ive been using wifes older laptop. same fastboot version, doesnt make sense! | 12:37 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:37 |
mal | @adampigg it seems those are not in root folder in android 9 anymore | 12:37 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:37 |
T42 | <adampigg> mal, where should they be | 12:38 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:38 |
mal | I think those are /system or /vendor | 12:40 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:40 |
T42 | <adampigg> named...... nothing jumps out | 12:42 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:42 |
mal | no idea, just ignore it, some other reason then | 12:42 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:42 |
T42 | <adampigg> k | 12:43 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:43 |
mal | try strace | 12:44 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:44 |
r0kk3rz | wow botspam | 12:47 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:47 |
T42 | <adampigg> mal, this is the last thing imsdatadaemon does....sorry about the formal | 12:57 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:57 |
T42 | <adampigg> (Photo, 2160x1080) https://irc.thaodan.de/.imgstore/sOQYuQoP80.png | 12:58 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 12:58 |
mal | nothing obvious in that strace | 13:19 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 13:19 |
T42 | <adampigg> Ill do better latet | 13:40 |
IrcsomeBot | No chat_id set! Add me to a Telegram group and say hi so I can find your group's chat_id! | 13:40 |
mal | @adampigg just curious, how is the battery life on fxtec? | 17:57 |
T42 | <adampigg> Mal, seems ok, but not used radio yet | 17:58 |
electro5751 | hi all | 19:33 |
deathmist | hey, I'm getting "/config/usb_gadget/g1/configs/b.1: opendir failed: No such file or directory" from usb_moded in journalctl when enabling MTP, I'm on 4.4 kernel and 15.1 base. found this https://git.io/fjXzj in the logs but it doesn't seem to be applicable anymore (I don't have the changed file) | 20:09 |
mal | deathmist: so your device used configfs based usb based on that error | 20:10 |
mal | the patch you linked is for the older android usb driver | 20:11 |
deathmist | right, that makes sense. is there a patch for configfs or could I be missing something else? I only have a c.1 dir in that configs path and "rndis.usb0" there, kernel sources at https://git.io/fjXgt | 20:18 |
mal | no need for such patches in configfs, either it's using wrong path or configfs is not initialized properly | 20:38 |
mal | c.1 is created by init script, b.1 should come from droid-hal-init via some .rc file it reads, check those | 20:38 |
mal | not the first device that would have issues with creation of b.1, check dmesg and journal log for any issues with chmod or chown | 20:40 |
mccreary | piggz: I don't have a working bootctl binary. I'm working on fixing the HIDL-related problems, but thought you might be interested in something simpler | 20:43 |
deathmist | mal: alright, I'll grab those after a fresh boot | 20:43 |
mccreary | piggz: I guess I have a working bootctl binary in our unfinished LineageOS build, without the SELinux policy to enable it | 21:00 |
mccreary | Since you don't care about SELinux, it might just work for you. You can get a copy here: https://drive.google.com/open?id=1iryyXTcN4UJo8Xj4T7AyqYOHBCDXTOPV | 21:10 |
mccreary | 'bootctl mark-boot-successful 0' seemed to work in my test | 21:11 |
piggz_ | mccrearythx, will test | 21:12 |
mccreary | TBC, that binary depends on android.hardware.boot@1.0-service | 21:14 |
piggz_ | mccreary: i checked that service was running earlier.... | 21:15 |
piggz_ | but | 21:15 |
piggz_ | sh-3.2# ./bootctl mark-boot-successful | 21:15 |
piggz_ | Error marking as having booted successfully: Operation not permitted | 21:15 |
piggz_ | sh-3.2# ./bootctl get-current-slot | 21:15 |
piggz_ | 0 | 21:15 |
mccreary | FxTecPro1:/vendor # md5sum /vendor/bin/hw/android.hardware.boot@1.0-service | 21:18 |
mccreary | 27218f361d333f0d12520fb4bba1000f /vendor/bin/hw/android.hardware.boot@1.0-service | 21:18 |
mccreary | piggz_: Do you have the same android.hardware.boot@1.0-service blog? | 21:18 |
piggz_ | mccreary: yup | 21:19 |
piggz_ | sh-3.2# md5sum /vendor/bin/hw/android.hardware.boot@1.0-service | 21:19 |
piggz_ | 27218f361d333f0d12520fb4bba1000f /vendor/bin/hw/android.hardware.boot@1.0-service | 21:19 |
piggz_ | sh-3.2# | 21:19 |
piggz_ | root 3900 0.0 0.0 14664 3172 ? S 12:13 0:00 /vendor/bin/hw/android.hardware.boot@1.0-service | 21:20 |
mccreary | And you are root? | 21:20 |
piggz_ | yes | 21:20 |
mccreary | And your bootloader is unlocked? | 21:21 |
piggz_ | 07-14 22:21:38.204 3900 3900 E gpt-utils: gpt_get_header: Failed to open ../../../../.. : Is a directory | 21:22 |
piggz_ | 07-14 22:21:38.204 3900 3900 E gpt-utils: gpt_disk_get_disk_info: Failed to get primary header | 21:22 |
piggz_ | 07-14 22:21:38.204 3900 3900 E bootcontrolhal: update_slot_attribute: Failed to get disk info for xbl_a | 21:22 |
piggz_ | 07-14 22:21:38.204 3900 3900 E bootcontrolhal: mark_boot_successful: Failed to mark boot successful | 21:22 |
mccreary | Well, that is useful info | 21:22 |
mccreary | FYI, those first two error messages are both from vendor/qcom/opensource/recovery-ext/oem-recovery/gpt-utils.cpp, in gpt_get_header() and gpt_disk_get_disk_info() | 21:28 |
mccreary | And I think the problem is what is being passed in as the partition name 'dev' | 21:29 |
piggz_ | mccreary: i wonder | 21:33 |
piggz_ | does it resolve the name from /dev/block..... | 21:33 |
piggz_ | becuase, in sailfish, we use a difference scheme | 21:33 |
piggz_ | must be in get_dev_path_from_partition_name | 21:34 |
mccreary | That might be it | 21:34 |
mccreary | But I haven't found the code that produced the 'bootcontrolhal' error messages yet | 21:34 |
piggz_ | mccreary: for info: | 21:36 |
piggz_ | [root@Sailfish block]# file /dev/block/platform/soc/by-name/boot_a | 21:36 |
piggz_ | /dev/block/platform/soc/by-name/boot_a: symbolic link to ../../../../sde12 | 21:36 |
mccreary | What about xbl_a | 21:36 |
piggz_ | [root@Sailfish block]# file /dev/block/platform/soc/by-name/xbl_a | 21:37 |
piggz_ | /dev/block/platform/soc/by-name/xbl_a: symbolic link to ../../../../sdb1 | 21:37 |
mccreary | OK | 21:40 |
mccreary | FYI, the calling function seems to be in hardware/qcom/bootctrl/boot_control.cpp, update_slot_attribute() | 21:41 |
piggz_ | mccreary: what do you have in /dev/ for these, i could try a symlink | 21:43 |
mccreary | /dev/block/platform/soc/by-name doesn't exist | 21:46 |
mccreary | Here is what I have in /dev/block/by-name: https://pastebin.com/GgzGmb6L | 21:47 |
mccreary | You might try making your symbolic links absolute rather than relative | 21:48 |
mccreary | So, 'hardware/qcom/bootctrl/boot_control.cpp: const char ptn_list[][MAX_GPT_NAME_SIZE] = { AB_PTN_LIST };' | 21:49 |
mccreary | And AB_PTN_LIST is defined in vendor/qcom/opensource/recovery-ext/oem-recovery/gpt-utils.h:#define AB_PTN_LIST PTN_SWAP_LIST, "boot", "system", "vendor", "modem", "bluetooth" | 21:49 |
mccreary | Looking at that file suggests it is using the files in '/dev/block/bootdevice/by-name/' | 21:50 |
mccreary | And this is what I have in that dir: https://pastebin.com/BbFMpQrN | 21:51 |
mccreary | Yep. This is the code that builds the pathname of the device node: https://pastebin.com/hxMYhALV | 21:55 |
mccreary | BOOT_DEV_DIR and AB_SLOT_A_SUFFIX are both defined in gpt-utils.h | 21:56 |
piggz_ | mccreary: adding links for xbl_a and boot_a like yours hasnt helped | 21:57 |
piggz_ | maybe i should add all | 21:57 |
mccreary | Continuing with the code trace, it calls stat() on the A and B variants to check if they exist. Those calls succeed. | 21:58 |
mccreary | Then it calls gpt_disk_get_disk_info() | 21:58 |
piggz_ | the error is still the same | 22:03 |
piggz_ | https://pastebin.com/2fbDaTPK | 22:04 |
piggz_ | this is my /dev/block/bootdevice | 22:04 |
mccreary | I think I found the problem. #define PATH_TRUNCATE_LOC (sizeof("/dev/block/sda") - 1) | 22:05 |
mccreary | 1103 buf[PATH_TRUNCATE_LOC] = '\0'; | 22:06 |
mccreary | From vendor/qcom/opensource/recovery-ext/oem-recovery/gpt-utils.cpp | 22:06 |
mccreary | The idiotic code assumes all device paths are exactly 14 characters long | 22:07 |
mccreary | So no relative symbolic links allowed | 22:07 |
mccreary | And '/dev/block/sd?' must exist | 22:08 |
piggz_ | mccreary: | 22:10 |
piggz_ | sh-3.2# ls -lh /dev/block/sd? | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sda -> ../sda | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sdb -> ../sdb | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sdc -> ../sdc | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sdd -> ../sdd | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sde -> ../sde | 22:10 |
piggz_ | lrwxrwxrwx 1 root root 6 Jul 14 12:13 /dev/block/sdf -> ../sdf | 22:10 |
mccreary | Yeah, that won't work | 22:10 |
mccreary | This is what I have: https://pastebin.com/YWMZfNUX | 22:10 |
piggz_ | hmm, can i quickly fix the code to work? | 22:11 |
mccreary | TBC, '/dev/block/sd?' must be the actual device nodes, IIUC | 22:11 |
mccreary | gpt_utils is one of the 'vendor-specific' bits of code | 22:12 |
mccreary | Google published a version for their handsets, but I haven't verified if it is compatible with the one used for the Pro1 | 22:12 |
mccreary | Motorola diddled their implementaton a bit | 22:12 |
mccreary | Can you replace the symlinks in /dev/block with actual device nodes? | 22:13 |
mccreary | ...using 'mknod' | 22:14 |
mccreary | e.g. 'mknod -m 600 sda b 8 0' | 22:16 |
mccreary | (apologies if I am being pedantic) | 22:18 |
piggz_ | mccreary: i did the mknot without the -m 600, and it didnt chnge anything | 22:19 |
piggz_ | https://pastebin.com/LAChAEJ3 | 22:19 |
mccreary | Hrm. What does logcat say? | 22:22 |
piggz_ | exactly the same | 22:22 |
piggz_ | 07-14 23:22:31.678 3900 3900 E gpt-utils: gpt_get_header: Failed to open ../../../../.. : Is a directory | 22:22 |
piggz_ | 07-14 23:22:31.678 3900 3900 E gpt-utils: gpt_disk_get_disk_info: Failed to get primary header | 22:23 |
piggz_ | 07-14 23:22:31.678 3900 3900 E bootcontrolhal: update_slot_attribute: Failed to get disk info for xbl_a | 22:23 |
piggz_ | 07-14 23:22:31.678 3900 3900 E bootcontrolhal: mark_boot_successful: Failed to mark boot successful | 22:23 |
piggz_ | mccreary: gonna have to call it a night, thx for your help tho | 22:25 |
piggz_ | if u find anything, post it :) | 22:25 |
mccreary | Notice '../../../../..' is 14 characters long. The code drops a null at position 15, truncating the path | 22:26 |
mccreary | That produces the error reported by logcat | 22:27 |
mccreary | The problem is in get_dev_path_from_partition_name() in vendor/qcom/opensource/recovery-ext/oem-recovery/gpt-utils.cpp | 22:28 |
mccreary | at line 1103 | 22:28 |
mccreary | The idiot who wrote that code was trying to work around the fact that readlink() doesn't null-terminate the path | 22:30 |
mccreary | And assumed all paths were the same size as '/dev/block/sda' | 22:30 |
mccreary | You can fix this using the return value of readlink(), as follows: | 22:31 |
mccreary | https://pastebin.com/WT58acZ1 (or similar changes) | 22:33 |
mccreary | However, that will mean digging for an open-source version of gpt-utils.cpp | 22:33 |
mccreary | If you want to make the binary blobs work, you'll need to make sure the paths returned by readlink() are all 14 characters long | 22:34 |
mccreary | And that means restructuring your /dev tree | 22:35 |
mccreary | ...aaaand this is why we all hate CAF | 22:35 |
T42 | <adampigg> Well, i can add further debugging around there, and if nescessary, change the size of buf i guess | 22:35 |
mccreary | The buffer size isn't the problem, it's the code on line 1103 that always truncates the path to 14 characters | 22:36 |
T42 | <adampigg> True, i wonderd if they made buf 14ish chars long | 22:37 |
T42 | <adampigg> Cant see the code atm | 22:37 |
mccreary | No worries, there's time to work on it tomorrow | 22:38 |
T42 | <adampigg> Yep, though im on a fairly intensive course all week! | 22:38 |
mccreary | ...or as they say in New Mexico, 'Manana' | 22:38 |
T42 | <adampigg> I mean, what course starts on a sunday, and goes on until 10pm! | 22:39 |
mccreary | In NM, 'manana' doesn't literally mean the next day ;-) | 22:39 |
T42 | <adampigg> :) | 22:40 |
mccreary | FYI, I think my pseudocode fix had an off-by-one error: https://pastebin.com/PRrH9pMu | 22:46 |
mccreary | And also, the code I was tracing ends up in android.hardware.boot@1.0-service, not in bootctl | 22:56 |
mccreary | If you want to fix the code, it might be easier to bypass HIDL | 22:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!