Action taken: Attempted to flash recovery zip using TWRP
Error(s):
I rebooted and attempted flashing again, with no change.
pmos.log: https://pastebin.com/r9eux0pS
Edit: I forgot to mention, the zip I am flashing was created when @Moocow9m closed issue #1551 using PR #1556, in case that adds any helpful information
Thanks for reporting! As a workaround: does it work after rebooting the device and running the installation again?
CC: @ata2001: I haven't looked into this yet, maybe we can work around this by calling partprobe manually like we do in the Python install code?
Rebooting has no effect, log output stays the same
@arccot: After the installation fails there, can you give us the output of mount?
You could do that with piping it into a file and then copying that via adb:
$ mount > /mount_output
If mount is not available:
$ cat /proc/mounts > /mount_output
mount > /external_sd/mount_output
https://pastebin.com/DEQvhsdC
Thanks for uploading the log!
I can't find a clue in there unfortunately, but here are more questions:
ls -la /dev/mapper give you?/proc/config.gz file via adb in case it exists)ls -la /dev/mapper:
__bionic_open_tzdata: couldn't find any tzdata when looking for CST6CDT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
drwxr-xr-x 2 root root 60 Jun 18 16:13 .
drwxr-xr-x 12 root root 4080 Jun 18 16:13 ..
crw------- 1 root root 10, 236 Jun 18 16:13 control
Thanks again. Okay, I couldn't find anything suspicious in the kernel config. Could you provide the output of ls -la /dev/block as well?
Regarding partprobe, I have found out, that the non-busybox partprobe does things differently than partprobe (see this comment). That means if the regular partprobe is broken with your particular kernel, it _might_ be worth using busybox partprobe /dev/block/mmcblk0 (@ata2001: how would we call that from the TWRP terminal? and do you have an idea?)