Root [Development] Unofficial TWRP - K2_CL

palmtree5 · May 18, 2014

ModdingMyMind said:
Fair warning, WiFi will be broken because the modules will be pushed successfully but the kernel will not due to the current issue I mentioned previously. To fix it you will need to push back your originally modules or simply restore your /system alone.

The new modules need the new kernel in order for it all to work properly. Hence why I am tackling this flashable zip ;-)

Yeah, I took a backup before I started

ModdingMyMind · May 18, 2014

palmtree5 said:

how long should it take for the removal of everything before the Android header?

EDIT: Output of the check_bootimg_header.sh script:

PHP:

/tmp/tools/scripts # ./check_bootimg_header.sh ../boot.img 
chown: root: No such file or directory
chown: /data/tmp: No such file or directory
chmod: /data/tmp: No such file or directory
ash: : unknown operand

ash: : unknown operand
Android 'magic' header not found at start of boot.img
ash: : unknown operand
Checking if it exists elsewhere ...
ash: : unknown operand
Android header found at offset 256
ash: : unknown operand
Removing extra stuff before it so boot.img can be read properly ...
16776960+0 records in
16776960+0 records out
16776960 bytes (16.0MB) copied, 272.457806 seconds, 60.1KB/s
ash: : unknown operand

./check_bootimg_header.sh: line 87: /tmp/binaries/unmkbootimg: not found
rm: can't remove '/tmp/prebuilt/working_folder/kernel': No such file or directory
chown: root: No such file or directory
/tmp/tools/scripts #

The script isn't designed to be used on the device like that lol. Needs to be used through the recovery via flash zip.

Also, the header check is only slow if it has to remove the 256 bit signature found in the boot.img. If the android header is where it is suppose to be then the flash zip will proceed pretty quickly since it won't be required to removed the unneceassary bits because they aren't there.

palmtree5 · May 18, 2014

ModdingMyMind said:
The script isn't designed to be used on the device like that lol. Needs to be used through the recovery via flash zip.

Also, the header check is only slow if it has to remove the 256 bit signature found in the boot.img. If the android header is where it is suppose to be then the flash zip will proceed pretty quickly since it won't be required to removed the unneceassary bits because they aren't there.

Well, I was able to flash the zip without issues

ModdingMyMind · May 18, 2014

palmtree5 said:
Yeah, I took a backup before I started

If you wish to test the zip without using the recovery then here is a little trick you can do.

Extract the update-binary from the zip. Place it in the same directory where you have the zip currently stored.

Open up terminal on your device and change directories to where the zip is located.

Now type and enter:

Code:

update-binary 2 stdout test.zip

THE ONLY CATCH TO THIS is that you need to go through my scripts and change all the directories from /tmp to somewhere else on your device - like /data/local/tmp or something. Otherwise it will fail since you do not have a /tmp directory on your boot.img.

ModdingMyMind · May 18, 2014

palmtree5 said:
Well, I was able to flash the zip without issues

Make sure to review the recovery log. It will flash successfully but it doesn't mean the kernel was pushed like it was suppose to. If your WiFi is broken then that is clear evidence the kernel was not pushed as it were suppose to. The recovery log will distinguish such problems.

palmtree5 · May 18, 2014

ModdingMyMind said:
Make sure to review the recovery log. It will flash successfully but it doesn't mean the kernel was pushed like it was suppose to. If your WiFi is broken then that is clear evidence the kernel was not pushed as it were suppose to. The recovery log will distinguish such problems.

Yeah, attaching my recovery log (minus serial number). It seems like it may not have flashed properly (assuming I'm reading it properly)

ModdingMyMind · May 18, 2014

palmtree5 said:
Yeah, attaching my recovery log (minus serial number). It seems like it may not have flashed properly (assuming I'm reading it properly)

Yea, same results I am getting.

Code:

 about to run program [/tmp/tools/scripts/check_bootimg_header.sh] with 1 args
run_program: execv failed: Exec format error
run_program: child exited with status 1

That is where the problem is. Has to do with the unmkbootimg binary being called. If I can get that to work properly then the entire zip will work like it should.

palmtree5 · May 18, 2014

ModdingMyMind said:
Yea, same results I am getting.

Code:

about to run program [/tmp/tools/scripts/check_bootimg_header.sh] with 1 args run_program: execv failed: Exec format error run_program: child exited with status 1

That is where the problem is. Has to do with the unmkbootimg binary being called. If I can get that to work properly then the entire zip will work like it should.

Ok, I made an edit to the updater_script. On the line that reads something to the effect of "run_program("/tmp/tools/scripts/check_bootimg_header.sh")" change that to "run_program("/sbin/sh", "/tmp/tools/scripts/check_bootimg_header.sh")". That allows the script to run

ModdingMyMind · May 18, 2014

palmtree5 said:
Ok, I made an edit to the updater_script. On the line that reads something to the effect of "run_program("/tmp/tools/scripts/check_bootimg_header.sh")" change that to "run_program("/sbin/sh", "/tmp/tools/scripts/check_bootimg_header.sh")". That allows the script to run

And did the recovery log show promising results?

I may have to rewrite the entire script. May be required to wipe out the update-binary and write my own version of the update-binary in order to get it working.

palmtree5 · May 18, 2014

ModdingMyMind said:
And did the recovery log show promising results?

I may have to rewrite the entire script. May be required to wipe out the update-binary and write my own version of the update-binary in order to get it working.

Yeah, I forgot to grab that so I'll get back to you in a few minutes

ModdingMyMind · May 18, 2014

palmtree5 said:
Yeah, I forgot to grab that so I'll get back to you in a few minutes

No worries, I already checked on my end. Gave a segmentation fault that time. I'm gonna write up a update-binary and rule out the updater-script all together. Should fix my problem.

palmtree5 · May 18, 2014

ModdingMyMind said:
No worries, I already checked on my end. Gave a segmentation fault that time. I'm gonna write up a update-binary and rule out the updater-script all together. Should fix my problem.

Yeah, same here on the segfault

ModdingMyMind · May 18, 2014

palmtree5 said:
Yeah, same here on the segfault

Working with a different script lol.

PHP:

 #!/sbin/sh
# arg 1 is recovery api version, generally 3.
# arg 2 is the pipe fd, to the recovery binary.
# communicate with it using the recovery api.
# arg 3 is the zip file

#Set these per device, /proc/emmc is unreliable now
BOOTBLK="/dev/block/mmcblk0p20"


echo -n -e 'ui_print Installing Kernel...\n' > /proc/self/fd/$2
echo -n -e 'ui_print\n' > /proc/self/fd/$2

cd /tmp
unzip -o "$3"

tools=/tmp/tools;
binaries=/tmp/binaries;
working=/tmp/prebuilt/working_folder;
prebuilt=/tmp/prebuilt/kernel;
modules=/tmp/modules/lib/modules;

#Give permission to use tools
chmod 755 $binaries/mkbootimg
chmod 755 $binaries/unmkbootimg
chmod 755 $tools/busybox
chmod 755 $tools/dump_image

#Pull boot.img
dd if=$BOOTBLK of=$working/boot.img
#$tools/dump_image boot $working/boot.img

#Check if kernel is signed
echo -n -e 'ui_print Checking old kernel for signature...\n' > /proc/self/fd/$2

#Boot.img uses a magic header of ANDROID!
#
# Check for strange boot.img header
#

check_header=`$tools/busybox od -A n -h -j 0 -N 8 $working/boot.img | sed 's/ //g'`

if [ "$check_header" != "4e415244494f2144" ]
then
   echo -n -e 'ui_print\n' > /proc/self/fd/$2
   echo -n -e 'ui_print Android magic header not found at start of boot.img\n' > /proc/self/fd/$2
   echo -n -e 'ui_print Checking if it exists elsewhere ...\n' > /proc/self/fd/$2

  # Look for Header
  hex_offset=`$tools/busybox od -x -A x $working/boot.img | grep -m 1 "4e41 [ ]*5244 [ ]*494f [ ]*2144" | sed -e 's/ .*//'`

  if [ "$hex_offset" != "" ]
  then

    #
    # Remove leading bytes before the Android header 
    #

    dec_offset=`printf "%d" 0x$hex_offset`
    echo -n -e 'ui_print Android header found at offset $dec_offset\n' > /proc/self/fd/$2
     echo -n -e 'ui_print Removing extra stuff before it so boot.img can be read properly ...\n' > /proc/self/fd/$2

    dd if=$working/boot.img of=$working/modboot.img bs=1 skip=$dec_offset
    rm -f $working/boot.img
    mv $working/modboot.img /tmp/newboot.img
    echo -n -e 'ui_print\n' > /proc/self/fd/$2

#Kernel info is given by unmkbootimg

dump_boot() {
mv $binaries/unmkbootimg /tmp/unmkbootimg
mv $binaries/mkbootimg /tmp/mkbootimg
KERNEL_INFO_RAW=$(./unmkbootimg -i newboot.img)
KERNEL_INFO=$(echo $KERNEL_INFO_RAW | grep mkbootimg)
KERNEL_BASE=$(echo $KERNEL_INFO  | cut -d " " -f 3)
KERNEL_PAGESIZE=$(echo $KERNEL_INFO | cut -d " " -f 5)
KERNEL_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 7)
RAMDISK_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 9)
TAGS_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 13)
KERNEL_CMDLINE=$(echo $KERNEL_INFO | cut -d "'" -f 2)
RAMDISK_NAME=$(echo $KERNEL_INFO | cut -d " " -f 20)
}

#Make the boot.img

write_boot() {
  echo -n -e 'ui_print\n' > /proc/self/fd/$2
  echo -n -e 'ui_print Make new boot.img\n' > /proc/self/fd/$2
  echo -n -e 'ui_print\n' > /proc/self/fd/$2
   ./mkbootimg --base $KERNEL_BASE --pagesize $KERNEL_PAGESIZE --kernel_offset $KERNEL_OFFSET --ramdisk_offset $RAMDISK_OFFSET --tags_offset $TAGS_OFFSET --cmdline "$KERNEL_CMDLINE" --kernel $working/kernel --ramdisk "$RAMDISK_NAME" -o modboot.img
}

#Flash the boot.img

flash_boot() {
echo -n -e 'ui_print Flash boot.img\n' > /proc/self/fd/$2
dd if=/tmp/modboot.img of=$BOOTBLK
busybox mount /system
echo -n -e 'ui_print Flashing modules...\n' > /proc/self/fd/$2
rm -rf /system/lib/modules/
cp -r $modules/ /system/lib/modules/
busybox umount /system
echo -n -e 'ui_print Boot.img flashed, you may now reboot...\n' > /proc/self/fd/$2
}

dump_boot;
write_boot;
flash_boot;
    exit 0

  else
    echo -n -e 'ui_print Warning: Android header not found in boot.img (unsupported format)\n' > /proc/self/fd/$2
return $?
    exit 1
  fi
fi

#Kernel info is given by unmkbootimg

mv $working/boot.img /tmp/newboot.img

dump_boot() {
mv $binaries/unmkbootimg /tmp/unmkbootimg
mv $binaries/mkbootimg /tmp/mkbootimg
KERNEL_INFO_RAW=$(./unmkbootimg -i boot.img)
KERNEL_INFO=$(echo $KERNEL_INFO_RAW | grep mkbootimg)
KERNEL_BASE=$(echo $KERNEL_INFO  | cut -d " " -f 3)
KERNEL_PAGESIZE=$(echo $KERNEL_INFO | cut -d " " -f 5)
KERNEL_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 7)
RAMDISK_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 9)
TAGS_OFFSET=$(echo $KERNEL_INFO | cut -d " " -f 13)
KERNEL_CMDLINE=$(echo $KERNEL_INFO | cut -d "'" -f 2)
RAMDISK_NAME=$(echo $KERNEL_INFO | cut -d " " -f 20)
}

#Make the boot.img

write_boot() {
  echo -n -e 'ui_print\n' > /proc/self/fd/$2
  echo -n -e 'ui_print Make new boot.img\n' > /proc/self/fd/$2
  echo -n -e 'ui_print\n' > /proc/self/fd/$2
   ./mkbootimg --base $KERNEL_BASE --pagesize $KERNEL_PAGESIZE --kernel_offset $KERNEL_OFFSET --ramdisk_offset $RAMDISK_OFFSET --tags_offset $TAGS_OFFSET --cmdline "$KERNEL_CMDLINE" --kernel $working/kernel --ramdisk "$RAMDISK_NAME" -o modboot.img
}

#Flash the boot.img

flash_boot() {
echo -n -e 'ui_print Flash boot.img\n' > /proc/self/fd/$2
dd if=/tmp/modboot.img of=$BOOTBLK
busybox mount /system
echo -n -e 'ui_print Flashing modules...\n' > /proc/self/fd/$2
rm -rf /system/lib/modules/
cp -r $modules/ /system/lib/modules/
busybox umount /system
echo -n -e 'ui_print Boot.img flashed, you may now reboot...\n' > /proc/self/fd/$2
}

dump_boot;
write_boot;
flash_boot;
exit 0

ModdingMyMind · May 18, 2014

So, I have decided that it isn't my scripts... It's the recovery being STUPID! lol

Got to figure out a way to work around this dilemma.

ModdingMyMind · May 19, 2014

Gonna recompile my unmkbootimg and mkbootimg binaries from source and hopefully I can resolve it from there.

palmtree5 · May 19, 2014

ModdingMyMind said:
So, I have decided that it isn't my scripts... It's the recovery being STUPID! lol

Got to figure out a way to work around this dilemma.

Are you using the unmkbootimg from your boot manipulation repo? If so, I can try to build that and see what happens on my end

EDIT: Actually, is there any easy way of trying to debug that binary on device?

ModdingMyMind · May 19, 2014

palmtree5 said:
Are you using the unmkbootimg from your boot manipulation repo? If so, I can try to build that and see what happens on my end

Yea it is. I spoke with simonsickle over on XDA and he said it's a common linux problem where when compiling from source such things as what I am currently dealing with tends to happen. Best solution is to recompile it again.

So I plan to do just that. Feel free to compile it on your end as well.

Edit: compile both unmkbootimg and mkbootimg.

palmtree5 · May 19, 2014

ModdingMyMind said:
Yea it is. I spoke with simonsickle over on XDA and he said it's a common linux problem where when compiling from source such things as what I am currently dealing with tends to happen. Best solution is to recompile it again.

So I plan to do just that. Feel free to compile it on your end as well.

Edit: compile both unmkbootimg and mkbootimg.

Just checking, do I need one of the Android toolchains? I would assume yes in which case, I probably won't be able to do this until tomorrow sometime

ModdingMyMind · May 19, 2014

palmtree5 said:
Just checking, do I need one of the Android toolchains? I would assume yes in which case, I probably won't be able to do this until tomorrow sometime

That is correct lol.

palmtree5 · May 19, 2014

ModdingMyMind said:
That is correct lol.

Which one?

ModdingMyMind · May 19, 2014

palmtree5 said:
Which one?

arm-eabi-4.6 will do just fine. Same one I used to compile TWRP. I can send more info later on tomorrow after work.

palmtree5 · May 19, 2014

I can probably just Google it

ModdingMyMind · May 19, 2014

palmtree5 said:
I can probably just Google it

I originally compiled my binaries from my phone. They both might be dynamically linked. I'm almost certain of it. I will be compiling them both again from my computer today after work to statically link them and try it out.

Here is a similiar problem that was found with vrthemes a while back that TeamWin posted about. Most likely the same problem with trying to use these current binaries as well. Would seem any binary you try to use must be statically linked or it will cause problems amongst other devices when using them in TWRP.

http://teamw.in/VRThemes

palmtree5 · May 19, 2014

Ok, I've built those binaries from my computer and am about to test

ModdingMyMind · May 19, 2014

palmtree5 said:
Ok, I've built those binaries from my computer and am about to test

If they are not statically linked then they will seg fault lol. My makefile doesn't include the needed flags to statically link them.

Root [Development] Unofficial TWRP - K2_CL

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

ModdingMyMind

Guest

Sunny Vacation Supporter!

Attachments

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

ModdingMyMind

Guest

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest

Sunny Vacation Supporter!

ModdingMyMind

Guest