[SuperSU] nkk71:
[MENTION=631273]Chainfire[/MENTION] regarding that hiccup (courtesy of [MENTION=1162986]Captain_Throwback[/MENTION] ) , I mentioned earlier, it seems it's back / still there.

At first we thought it's due to the size of the kernel, but turns out that's not the issue.

Trying to find the cause is proving difficult, so I'll just summarize my findings as best I can:

When installing SuperSU 2.67 from within a custom rom (twrp flashable zip), it fails to properly create the new boot.img (it's truncated for some reason):

extract of the updater-script:

set_progress(0.700000);
ui_print("Extracting boot image...");
ui_print(" ");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
set_progress(0.800000);
#ROOT
ui_print("Installing SuperSU..."); ui_print(" ");
package_extract_dir("supersu", "/tmp/supersu");
run_program("/sbin/busybox", "unzip", "/tmp/supersu/BETA-SuperSU-v2.67.zip", "META-INF/com/google/android/*", "-d", "/tmp/supersu");
run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "0", "/tmp/supersu/BETA-SuperSU-v2.67.zip");
ui_print(" ");

extract of the recovery.log error

(towards the end of the SuperSU script, when it runs

/su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img)

sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

Loading from [/dev/block/mmcblk0p42] ...

magic: [ANDROID!]
kernel: [6662360] (6664192) @ 0x00008000
ramdisk: [1193431] (1193984) @ 0x02000000
second: [0] (0) @ 0x00f00000
tags: @ 0x01e00000
page size: 2048
unused: [0x0040f800] [0x00000000]
dtb(?): [4257792] (4257792)
name: []
command line: [console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3b7 ehci-hcd.park=3]
extra command line: []
id: [0xc760d7abbc1949e9deaa692a43b1f4b1deee5c43000000000000000000000000]

Loading from [/sutmp/ramdisk.packed] ...

Saving to [/sutmp/boot.img] ...

magic: [ANDROID!]
kernel: [6662360] (6664192) @ 0x00008000
ramdisk: [1200876] (1202176) @ 0x02000000
second: [0] (0) @ 0x00f00000
tags: @ 0x01e00000
page size: 2048
unused: [0x0040f800] [0x00000000]
dtb(?): [4257792] (4257792)
name: []
command line: [console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3b7 ehci-hcd.park=3]
extra command line: []
id: [0xaba2324aa866e82c9a07e21a90b4ea37d01877aa000000000000000000000000]

[B][SIZE="3"][COLOR="Red"]Could not write data[/COLOR][/SIZE][/B]
2954+0 records in
2954+0 records out
[B][COLOR="Red"]12099584 [/COLOR][/B]bytes (11.5MB) copied, 0.095180 seconds, 121.2MB/s

script result was [M8 GPE 5.07.1700.9 CDMA Edition Installed]

M8 GPE 5.07.1700.9 CDMA Edition Installed
I:Legacy property environment disabled.
rm: can't remove 'META-INF/com/google/android': No such file or directory
ZIP successfully installed
I:Running cmd "rm "/dev/block/mmcblk0p42""
I:Running cmd "mv "/dev/block/mmcblk0p42"-orig "/dev/block/mmcblk0p42""
Restoring mounts...

It says succeeded, but the log shows "Could not write data",

and the resulting boot.img is actually too small (it should be 12126208 bytes, not 12099584) and therefore corrupt (which will throw an error, since multirom can inject it's own changes into the kernel)

I've tried debugging, but results are quite confusing :eek:

1- added a sleep command just after

check_zero_def "- Creating boot image" "LD_LIBRARY_PATH=$SYSTEMLIB /su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img"

checked the recovery log, and it showed "Could not write data" (and incorrect size of boot.img in /sutmp)

opened an adb shell and manually ran

/su/bin/sukernel --bootimg-replace-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed /sutmp/boot.img

(p42 is the same as the script is using)

--> succeeded with correct boot.img size, let the script continue and all went well

2- put the script to sleep, and manually ran all the commands from adb shell

/su/bin/sukernel --bootimg-extract-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed
/su/bin/sukernel --ungzip /sutmp/ramdisk.packed /sutmp/ramdisk
/su/bin/sukernel --cpio-extract /sutmp/ramdisk sepolicy /sutmp/sepolicy
/su/bin/supolicy --file /sutmp/sepolicy /sutmp/sepolicy_patched
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 644 sepolicy /sutmp/sepolicy_patched
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 700 sbin/launch_daemonsu.sh /tmp/supersu/common/launch_daemonsu.sh
/su/bin/sukernel --patch /sutmp/ramdisk /sutmp/ramdisk /dev/block/mmcblk0p42
/su/bin/sukernel --gzip /sutmp/ramdisk /sutmp/ramdisk.packed
/su/bin/sukernel --bootimg-replace-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed /sutmp/boot.img

once using "/sutmp/tst_boot.img" and once directly with "/dev/block/mmcblk0p42", as the script would do

-> both generated the correct patched boot.img

3- changed the SuperSU update-binary to include at line 1184 (after the patch check, but before patching the kernel):

cp $STOCKBOOTIMAGE /sutmp/wrk_boot.img
STOCKBOOTIMAGE=/sutmp/wrk_boot.img

--> succeeded, no issues

I tried playing around with sukernel a bit, and found the following very curious:

C:\ADB\ADB_M8>[B][COLOR="Blue"]adb push C:\ADB\ADB_M8\MM3\tst_boot.img /tmp[/COLOR][/B]
3705 KB/s ([COLOR="Green"]12118016 [/COLOR]bytes in 3.193s)

C:\ADB\ADB_M8>[B][COLOR="Blue"]adb shell[/COLOR][/B]

~ # [6n [B][COLOR="Blue"]/su/bin/sukernel --backup /tmp/tst_boot.img[/COLOR][/B]
/su/bin/sukernel --backup /tmp/tst_boot.img
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/tmp/tst_boot.img]([COLOR="Green"]12118016[/COLOR]) --> [/data/stock_boot_[COLOR="Green"]22acb886172c5eb575bfd7c9ee070fc2f2cc8bf7[/COLOR].img.gz](8629168)

~ # [6n [B][COLOR="Blue"]dd if=/tmp/tst_boot.img of=/dev/block/mmcblk0p42[/COLOR][/B]
dd if=/tmp/tst_boot.img of=/dev/block/mmcblk0p42
23668+0 records in
23668+0 records out
12118016 bytes (11.6MB) copied, 0.398213 seconds, 29.0MB/s

~ # [6n [B][COLOR="Blue"]/su/bin/sukernel --backup /dev/block/mmcblk0p42[/COLOR][/B]
/su/bin/sukernel --backup /dev/block/mmcblk0p42
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/dev/block/mmcblk0p42]([COLOR="Red"]12058624[/COLOR]) --> [/data/stock_boot_[COLOR="Red"]18effe115987f74d93b0657b3da93c2e4e95a7f6[/COLOR].img.gz](8616560)

~ # [6n [B][COLOR="Blue"]sha1sum /dev/block/mmcblk0p42[/COLOR][/B]
sha1sum /dev/block/mmcblk0p42
[COLOR="Green"]22acb886172c5eb575bfd7c9ee070fc2f2cc8bf7[/COLOR] /dev/block/mmcblk0p42

Hope this helps you narrow it down

PS: at first I thought it was a memory issue, but that is sort of ruled out by the --backup command, and number 2 and 3 above