[SuperSU] nkk71:
I don't think it's an issue with the script.

I just went through some more debugging, and the issue seems to be with sukernel when accessing files or symlinks in the /dev/ subfolder... long story short it truncates down to the nearest 65536 block size:

tst_BLOCKSIZE Original Truncated
12148736 12124160
65536 [COLOR="Red"]185.375[/COLOR] [COLOR="Blue"]185[/COLOR]

Test: 186x65536..: [COLOR="Blue"]12189696[/COLOR]

test 2: +/- 1byte: 12189697 12189695
Result...........: [COLOR="Red"]12189696 12124160[/COLOR]

here are some sample shell outputs:

~ # [6ndd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile4 bs=[COLOR="Blue"][B]12189696 [/B][/COLOR]count=1
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile4 bs=1218
9696 count=1
1+0 records in
1+0 records out
12189696 bytes (11.6MB) copied, 0.238792 seconds, 48.7MB/s
~ # [6n/su/bin/sukernel --backup /dev/dummyfile4
/su/bin/sukernel --backup /dev/dummyfile4
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/dev/dummyfile4]([COLOR="Blue"][B]12189696[/B][/COLOR]) --> [/data/stock_boot_df95813d3fb0376d87b6fd5cae14f3de30d402a6.img.gz](9933359)

~ # [6nsha1sum /dev/dummyfile4
sha1sum /dev/dummyfile4
df95813d3fb0376d87b6fd5cae14f3de30d402a6 /dev/dummyfile4
~ # [6ndd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile5 bs=[COLOR="Blue"][B]12189695 [/B][/COLOR]count=1
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile5 bs=1218
9695 count=1
1+0 records in
1+0 records out
12189695 bytes (11.6MB) copied, 0.174374 seconds, 66.7MB/s
~ # [6n/su/bin/sukernel --backup /dev/dummyfile5
/su/bin/sukernel --backup /dev/dummyfile5
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/dev/dummyfile5]([COLOR="Red"]12124160[/COLOR]) --> [/data/stock_boot_85db6903438fd5f7de7b7297ec1664ee0ab364b6.img.gz](9927456)

~ # [6ndd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile6 bs=[COLOR="Blue"][B]12189697 [/B][/COLOR]count=1
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dev/dummyfile6 bs=1218
9697 count=1
1+0 records in
1+0 records out
12189697 bytes (11.6MB) copied, 0.175018 seconds, 66.4MB/s
~ # [6n/su/bin/sukernel --backup /dev/dummyfile6
/su/bin/sukernel --backup /dev/dummyfile6
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/dev/dummyfile6]([COLOR="Red"][B]12189696[/B][/COLOR]) --> [/data/stock_boot_df95813d3fb0376d87b6fd5cae14f3de30d402a6.img.gz](9933359)

I don't want to post extensive shell code of all the test's i've performed, but anything that sukernel accesses through /dev/ is truncated down to the nearest 65536 block size.

On the other hand a symbolic link from outside /dev/ to inside /dev/ seems to work:

~ # [6nln -s /dev/dummyfile6 /tmp/dummyfile6
ln -s /dev/dummyfile6 /tmp/dummyfile6

~ # [6n/su/bin/sukernel --backup /tmp/dummyfile6
/su/bin/sukernel --backup /tmp/dummyfile6
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/tmp/dummyfile6]([B][COLOR="Blue"]12189697[/COLOR][/B]) --> [/data/stock_boot_882a37f1a9b3979da5f8b0fba4a65b7fa86f3c3c.img.gz](9933359)

But symlinks from inside /dev/ to elsewhere also truncate:

~ # [6ndd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dummyfile7 bs=[B][COLOR="Blue"]12189697 [/COLOR][/B]count=1
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/dummyfile7 bs=12189697
count=1
1+0 records in
1+0 records out
12189697 bytes (11.6MB) copied, 0.225071 seconds, 51.6MB/s
~ # [6nln -s /dummyfile7 /dev/dummylink7
ln -s /dummyfile7 /dev/dummylink7
~ # [6n/su/bin/sukernel --backup /dev/dummylink7
/su/bin/sukernel --backup /dev/dummylink7
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

[/dev/dummylink7]([B][COLOR="Red"]12189696[/COLOR][/B]) --> [/data/stock_boot_df95813d3fb0376d87b6fd5cae14f3de30d402a6.img.gz](9933359)

Also worth noting, is other commands, such as dd , cp , ls , sha1sum directly into /dev/dummyfile(s) work properly, only sukernel is showing this issue.

I havent tested for MultiROM purposes (as of yet), but it shouldn't be difficult to just pad the boot.img (which in MultiROM would be a regular file) to be on the correct boundary.

Though, I felt you should need to know this about sukernel

and whether this is an expected result, or a possible bug

PS: all these tests were done in normal twrp recovery adb shell mode, nothing was being modified by multirom extensions.