OTA update JWR66Y ends up in an error

Search This thread

dbenyakar

Senior Member
Nov 29, 2010
168
16
Hi All

Yesterday I received the update via OTA. When it rebooted into the TWRP recovery is started with the patch install process.
Then it failed.
After that it offered to fix the root, nice of him, which I did, and rebooted. Build version was still JWR66V.
This is what I got from the recovery log file:

Code:
Unpacking new recovery...
minzip: Can't create target file "/system/etc/install-recovery.sh": Permission denied
minzip: Extracted 0 file(s)
Symlinks and permissions...
set_perm: chown of /system/etc/install-recovery.sh to 0 0 failed: Operation not permitted
set_perm: chmod of /system/etc/install-recovery.sh to 544 failed: Operation not permitted
script aborted: set_perm: some changes failed
set_perm: some changes failed
E:Error executing updater binary in zip '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
E:Error installing zip file '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Switching packages (TWRP)
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
I:Copying file /tmp/recovery.log to /data/media/0/recovery.log

Has anyone ran into this issue with the update?
Any solution to this?
 

megabiteg

Senior Member
Apr 13, 2010
1,138
236
USA
Hi All

Yesterday I received the update via OTA. When it rebooted into the TWRP recovery is started with the patch install process.
Then it failed.
After that it offered to fix the root, nice of him, which I did, and rebooted. Build version was still JWR66V.
This is what I got from the recovery log file:

Code:
Unpacking new recovery...
minzip: Can't create target file "/system/etc/install-recovery.sh": Permission denied
minzip: Extracted 0 file(s)
Symlinks and permissions...
set_perm: chown of /system/etc/install-recovery.sh to 0 0 failed: Operation not permitted
set_perm: chmod of /system/etc/install-recovery.sh to 544 failed: Operation not permitted
script aborted: set_perm: some changes failed
set_perm: some changes failed
E:Error executing updater binary in zip '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
E:Error installing zip file '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Switching packages (TWRP)
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
I:Copying file /tmp/recovery.log to /data/media/0/recovery.log

Has anyone ran into this issue with the update?
Any solution to this?

You need to have stock recovery to run ota update. Plus your Rom has to be stock unmodified there that it checks for everything that comes factory with it.

Sent from my HTC One using Tapatalk 2
 

dbenyakar

Senior Member
Nov 29, 2010
168
16
My Nexus 7 was rooted since day 1 and with a custom recovery, and always got the OTAs.
Why is this a problem now?
Are other people with rooted devices encountered the same issue?
 
  • Like
Reactions: emameme

chakme

Member
Jul 13, 2012
33
5
Same Issue !!

Hi All

Yesterday I received the update via OTA. When it rebooted into the TWRP recovery is started with the patch install process.
Then it failed.
After that it offered to fix the root, nice of him, which I did, and rebooted. Build version was still JWR66V.
This is what I got from the recovery log file:

Code:
Unpacking new recovery...
minzip: Can't create target file "/system/etc/install-recovery.sh": Permission denied
minzip: Extracted 0 file(s)
Symlinks and permissions...
set_perm: chown of /system/etc/install-recovery.sh to 0 0 failed: Operation not permitted
set_perm: chmod of /system/etc/install-recovery.sh to 544 failed: Operation not permitted
script aborted: set_perm: some changes failed
set_perm: some changes failed
E:Error executing updater binary in zip '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
E:Error installing zip file '/cache//8b2531d9d9a686c7dcf347513ce8141d59a251c6.signed-nakasi-JWR66Y-from-JWR66V.8b2531d9.zip'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Switching packages (TWRP)
I:Set page: 'advanced'
I:Set page: 'confirm_action'
I:Set page: 'action_page'
I:Copying file /tmp/recovery.log to /data/media/0/recovery.log

Has anyone ran into this issue with the update?
Any solution to this?

I've got the same issue... it rebooted into the TWRP recovery, but the screen just freezed and touch didin't worked. Had to remove battery and reboot. After that, JWR66V was still there! And now, it doesn't prompt the update again. I'm thinking about flashing 4.3 again, root but not to install TWRP recovery, only 4.3 stock and root !! As @dbenyakar asked "any solution to this" ?

In time, mine is a Galaxy Nexus I9250...
 
Last edited:

GedBlake

Senior Member
Jan 5, 2013
888
606
Ashton-under-Lyne, Manchester, UK
My Nexus 7 was rooted since day 1 and with a custom recovery, and always got the OTAs.
Why is this a problem now?
Are other people with rooted devices encountered the same issue?

Hi, dbenyakar...

The reason why the OTA that updates from JWR66V to JWR66Y fails if you are rooted concerns a file call /system/etc/install-recovery.sh and the different way that root now works under Jellybean 4.3.

Root uses the file install-recovery.sh to launch sudaemon that provides root, and during the process of gaining root, this file is set as 'immutable' to prevent root from being accidently lost. But this also prevents the OTA from modifying it, including the setting of permissions during the last stage of the OTA... therefore the OTA fails. See also this.

There are several different ways this problem can be resolved...

1) There is a slightly modified version of the OTA here, which 'rems out' the setting of permissions for /system/etc/install-recovery.sh, and allows the OTA to successfully complete. This modified OTA can be flashed in TWRP and was the method I used to upgrade.

2) Before allowing the OTA, unroot by going to SuperSU>>settings>>Full Unroot. Allow the OTA, and then re-root by flashing Chainfires SuperSu 1.51 in TWRP.

In any event, you'll probably need to re-root after the OTA anyway. I certainly had to.

Hope this helps.

Rgrds,
Ged.
 
Last edited:

threi_

Senior Member
Dec 18, 2011
487
198
Alliston
So based on that is this something that will occur every OTA (i.e. you will have to unroot every OTA to avoid problems)?
 

dbenyakar

Senior Member
Nov 29, 2010
168
16
Hi, dbenyakar...

The reason why the OTA that updates from JWR66V to JWR66Y fails if you are rooted concerns a file call /system/etc/install-recovery.sh and the different way that root now works under Jellybean 4.3.

Root uses the file install-recovery.sh to launch sudaemon that provides root, and during the process of gaining root, this file is set as 'immutable' to prevent root from being accidently lost. But this also prevents the OTA from modifying it, including the setting of permissions during the last stage of the OTA... therefore the OTA fails. See also this.

There are several different ways this problem can be resolved...

1) There is a slightly modified version of the OTA here, which 'rems out' the setting of permissions for /system/etc/install-recovery.sh, and allows the OTA to successfully complete. This modified OTA can be flashed in TWRP and was the method I used to upgrade.

2) Before allowing the OTA, unroot by going to SuperSU>>settings>>Full Unroot. Allow the OTA, and then re-root by flashing Chainfires SuperSu 1.51 in TWRP.

In any event, you'll probably need to re-root after the OTA anyway. I certainly had to.

Hope this helps.

Rgrds,
Ged.
OK great. Thanks for that. Will try it tonight.
I tried to use the OTA Root Keeper to temporarily unroot my device, only to realize it does not support 4.3.
So I guess I will have to unroot, update and re-root using your method. No shortcuts here. Once the OTA Root Keeper application will be compatible with 4.3 then it will be easier.
 

GedBlake

Senior Member
Jan 5, 2013
888
606
Ashton-under-Lyne, Manchester, UK
So based on that is this something that will occur every OTA (i.e. you will have to unroot every OTA to avoid problems)?

Hi, threi_...

It's speculation, obviously, as one cannot know the contents of future OTAs beyond the current one which updates to build JWR66V... but it seems likely you will have to unroot, and then re-root again after the OTA.

But there may be workarounds... as I've indicated in my previous post, somebody has already posted a modified version of the current OTA that skips setting permissions for install-recovery.sh, and allows the OTA to complete successfully.

And to elaborate on my previous comments, here's why...

Root modifies /system/etc/install-recovery.sh in order to launch the su root daemon, and it contains the following lines...

Code:
#!/system/bin/sh

# If you're implementing this in a custom kernel/firmware,
# I suggest you use a different script name, and add a service
# to launch it from init.rc

# Launches SuperSU in daemon mode only on Android 4.3+.
# Nothing will happen on 4.2.x or older.
# If you want to force loading the daemon, use "--daemon" instead

/system/xbin/daemonsu --auto-daemon &

# Some apps like to run stuff from this script as well, but the
# installer will have done "chattr +i" on this file to prevent
# accidental modification and deletion. In your code, just search 
# this file for "install-recovery-2.sh", and if present, write
# there instead.

/system/etc/install-recovery-2.sh

And during flashing Chainfires SuperSU root updater, the following operation is performed...

Code:
chattr +i /system/etc/install-recovery.sh

This 'locks' the file, using the +i flag ('immutable'), and prevents even system updates from modifying it.

You should be able to reverse this with...

Code:
su
mount -o rw,remount /system
chattr -i /system/etc/install-recovery.sh
mount -o ro,remount /system

...in Android Terminal Emulator, but you will need Busybox installed.

So it's probably just easier to unroot... allow the OTA as normal (or flash the OTA .zip in recovery)... and then re-root again. And I can't see this changing with future OTA's... but as I stated at the beginning of this post, this is just speculation on my part.

Rgrds,
Ged.
 
Last edited:
  • Like
Reactions: threi_

dobrun.franjo

Senior Member
Jul 7, 2012
195
50
SAVA
Hi. I am on 4.3 stock rooted with m kernel a61 and with advanced power menu mod and awesome beats. Cant update .read everything about this new update and also opened a thread but still cant find a way to update.flashing failed.tried full unroot and faild again.trid modified grouper.zip and that also failed.


Any ideas???


Sent from my Nexus 7 using xda premium
 

GedBlake

Senior Member
Jan 5, 2013
888
606
Ashton-under-Lyne, Manchester, UK
Hi. I am on 4.3 stock rooted with m kernel a61 and with advanced power menu mod and awesome beats. Cant update .read everything about this new update and also opened a thread but still cant find a way to update.flashing failed.tried full unroot and faild again.trid modified grouper.zip and that also failed.


Any ideas???


Sent from my Nexus 7 using xda premium

Hi, dobrun.franjo...

Any modifications to system (including kernel) need to be removed before any OTA can proceed... and I suspect 'advanced power menu mod and awesome beats' have modified system.

This is because OTAs run a checksum on all files in system BEFORE 'patching' (meaning updating) them, to ensure they haven't been removed or changed in anyway. After all, an official OTA can't be expected to update files it has no knowledge of, that have been added by the user. If even one fails this checksum test, the OTA will abort, with no changes made.

So... remove advanced power menu, remove awesome beats and fastboot flash the factory stock kernel for Jellybean 4.3. Even then, there are no guarantees the OTA will work, without knowing (and being able to reverse) EXACTLY what files where changed as a consequence of your modifications... but it's worth a shot.

Good luck.

Rgrds,
Ged.
 
  • Like
Reactions: dobrun.franjo

NeoMagus

Senior Member
Mar 3, 2010
1,406
471
East Coast
So based on that is this something that will occur every OTA (i.e. you will have to unroot every OTA to avoid problems)?

As long as the new root process goes through the installrecovery.sh, correct

Once the OTA Root Keeper application will be compatible with 4.3 then it will be easier.

Supercurio has already said as long as it stays this way, OTA rootkeeper won't be possible anymore.

It means preserving root with OTA Root Keeper won't be possible anymore as new rooting techniques rely on more than just a setuid su binary in /system.
I'll look into solution of course to preserve the functionality if possible, but until then please follow Chainfire's job on SuperSU betas.
 

khaytsus

Senior Member
Apr 8, 2008
7,258
1,175
Central Kentucky
Hi. I am on 4.3 stock rooted with m kernel a61 and with advanced power menu mod and awesome beats. Cant update .read everything about this new update and also opened a thread but still cant find a way to update.flashing failed.tried full unroot and faild again.trid modified grouper.zip and that also failed.


Any ideas???

As the previous poster said, you screwed with system, OTA's won't work. Easiest way to update at this point IMO is to grab the YJWR66 factory image from Google and fastboot flash system, then re-root.
 

emameme

Senior Member
Jun 8, 2013
52
3
www.aspirinaco.tk
Today I have update with OTA and same error appear.
Now I have unroot the nexus with supersu's app but how I can update it? It doesn't give any update now :(
Thx guys.

Inviato dal mio Nexus 7 usando Tapatalk 4
 

dbenyakar

Senior Member
Nov 29, 2010
168
16
Hi, dbenyakar...

The reason why the OTA that updates from JWR66V to JWR66Y fails if you are rooted concerns a file call /system/etc/install-recovery.sh and the different way that root now works under Jellybean 4.3.

Root uses the file install-recovery.sh to launch sudaemon that provides root, and during the process of gaining root, this file is set as 'immutable' to prevent root from being accidently lost. But this also prevents the OTA from modifying it, including the setting of permissions during the last stage of the OTA... therefore the OTA fails. See also this.

There are several different ways this problem can be resolved...

1) There is a slightly modified version of the OTA here, which 'rems out' the setting of permissions for /system/etc/install-recovery.sh, and allows the OTA to successfully complete. This modified OTA can be flashed in TWRP and was the method I used to upgrade.

2) Before allowing the OTA, unroot by going to SuperSU>>settings>>Full Unroot. Allow the OTA, and then re-root by flashing Chainfires SuperSu 1.51 in TWRP.

In any event, you'll probably need to re-root after the OTA anyway. I certainly had to.

Hope this helps.

Rgrds,
Ged.

OK I did it your way. Thank you very much for that.
I had some problems with my SuperSU and could not access the SuperSU>>settings but eventually I managed to unroot the device and continue with the installation and re-root. :laugh:
 

tu3218

Senior Member
Apr 14, 2009
3,413
368
Hi, dbenyakar...

The reason why the OTA that updates from JWR66V to JWR66Y fails if you are rooted concerns a file call /system/etc/install-recovery.sh and the different way that root now works under Jellybean 4.3.

Root uses the file install-recovery.sh to launch sudaemon that provides root, and during the process of gaining root, this file is set as 'immutable' to prevent root from being accidently lost. But this also prevents the OTA from modifying it, including the setting of permissions during the last stage of the OTA... therefore the OTA fails. See also this.

There are several different ways this problem can be resolved...

1) There is a slightly modified version of the OTA here, which 'rems out' the setting of permissions for /system/etc/install-recovery.sh, and allows the OTA to successfully complete. This modified OTA can be flashed in TWRP and was the method I used to upgrade.

2) Before allowing the OTA, unroot by going to SuperSU>>settings>>Full Unroot. Allow the OTA, and then re-root by flashing Chainfires SuperSu 1.51 in TWRP.

In any event, you'll probably need to re-root after the OTA anyway. I certainly had to.

Hope this helps.

Rgrds,
Ged.

I tried step one and it failed in twrp. I downloaded grouper for my WiFi version. Any ideas why it failed? Is it because I'm trying to flash over clean ROM 4?

Sent from my Nexus 7 using xda app-developers app
 

tu3218

Senior Member
Apr 14, 2009
3,413
368
2000+ posts and you don't realize you can't flash a stock OTA over $randomrom ? Just wow.

Well its a small zip. Not a full ROM. So I figured it was just patching the updated files. Clean ROM is a pretty stock ROM so I was thinking it may have worked. Normally updates are full roms.

Sent from my Nexus 7 using xda app-developers app
 

khaytsus

Senior Member
Apr 8, 2008
7,258
1,175
Central Kentucky
Well its a small zip. Not a full ROM. So I figured it was just patching the updated files. Clean ROM is a pretty stock ROM so I was thinking it may have worked. Normally updates are full roms.

Updates are never full ROMs, they're a set of patches against checksummed files. Any single checksum difference and it'll fail. IE: Modify the ROM in almost any way, you can't use OTAs.

When you're on a custom ROM, use the custom ROM updates as they come out, no real difference between modified stock and say Cyanogenmod in this respect.
 

tu3218

Senior Member
Apr 14, 2009
3,413
368
Updates are never full ROMs, they're a set of patches against checksummed files. Any single checksum difference and it'll fail. IE: Modify the ROM in almost any way, you can't use OTAs.

When you're on a custom ROM, use the custom ROM updates as they come out, no real difference between modified stock and say Cyanogenmod in this respect.

Yeah you're right. Not sure what made me think it would work. I guess I was thinking it was modified, but its still just the stock ota with a slight adjustment to be installed properly on rooted devices.

It doesn't appear clean ROM will be updated as scott has ,moved onto the newer nexus 7. So I have to find out my next best move. I'm fine with stock, just getting there.

Sent from my Nexus 7 using xda app-developers app
 

Top Liked Posts

  • There are no posts matching your filters.
  • 10
    My Nexus 7 was rooted since day 1 and with a custom recovery, and always got the OTAs.
    Why is this a problem now?
    Are other people with rooted devices encountered the same issue?

    Hi, dbenyakar...

    The reason why the OTA that updates from JWR66V to JWR66Y fails if you are rooted concerns a file call /system/etc/install-recovery.sh and the different way that root now works under Jellybean 4.3.

    Root uses the file install-recovery.sh to launch sudaemon that provides root, and during the process of gaining root, this file is set as 'immutable' to prevent root from being accidently lost. But this also prevents the OTA from modifying it, including the setting of permissions during the last stage of the OTA... therefore the OTA fails. See also this.

    There are several different ways this problem can be resolved...

    1) There is a slightly modified version of the OTA here, which 'rems out' the setting of permissions for /system/etc/install-recovery.sh, and allows the OTA to successfully complete. This modified OTA can be flashed in TWRP and was the method I used to upgrade.

    2) Before allowing the OTA, unroot by going to SuperSU>>settings>>Full Unroot. Allow the OTA, and then re-root by flashing Chainfires SuperSu 1.51 in TWRP.

    In any event, you'll probably need to re-root after the OTA anyway. I certainly had to.

    Hope this helps.

    Rgrds,
    Ged.
    3
    As long as the new root process goes through the installrecovery.sh, correct



    Supercurio has already said as long as it stays this way, OTA rootkeeper won't be possible anymore.

    Yes however a method has been found for 4.3, so I'll look into that soon :)
    2
    HI, could you please teach me how to do this step-by-step? Doing this could help me learn using fastboot and at the same time help me solve my current problem. I would definitely appreciate your help.
    By the way, I have read this guide: http://xdaforums.com/showthread.php?t=1907796 but there it states that everything will be erased so I'm hoping to do your suggestion instead.

    Ok I will try. The above was just an example. I will be more specific.

    pre-reqs: 1. having adb and fastboot in your path
    2. having adb/fastboot drivers installed on your os (if you're on windows)
    3. having basic command line and file management skills
    4. know how to get your device into fastboot or recovery modes reliably
    5. you have the latest flashable SuperSU.zip in the root of your /sdcard
    6. you've made a nandroid backup first!!!

    Notes: I am going to use tilapia as an example because that's what I have. if you have grouper, ignore the part about flashing the radio!
    Flashing "bootloader" might give you an error if youre already on v4.23. Ignore it.
    Flashing "system" takes a few minutes longer than everything else

    Here we go:
    1. download correct firmware for your device from here: https://developers.google.com/android/nexus/images#nakasi
    2. extract all contents of nakasig-jwr66y-factory-bdbb7bd7.tar to an empty directory
    3. extract image-nakasig-jwr66y.zip to the same directory. you should now have the following in a single directory:
    Code:
    android-info.txt boot.img radio-tilapia-1231_0.18.0_0409.img bootloader-tilapia-4.23.img recovery.img flash-all.bat system.img flash-all.sh userdata.img flash-base.sh
    4. shift+right-click in this directory and "open command window here"
    5. plug your device into your computer, enable adb, and issue "adb reboot-bootloader" command (no quotes) and your device will reboot to fast boot
    6. issue all these commands one-by-one in the command window:
    Code:
    fastboot erase boot
    fastboot erase system
    fastboot flash bootloader bootloader-tilapia-4.23.img
    fastboot reboot-bootloader
    fastboot flash radio radio-tilapia-1231_0.18.0_0409.img
    fastboot reboot-bootloader
    fastboot flash boot boot.img
    fastboot flash system system.img
    7a. At this point, if you don't already have a custom recovery installed you should install one e.g. "fastboot flash recovery recovery-clockwork-6.0.3.6-tilapia.img" (no quotes)
    7b. Press Vol-Down two times. Your device should say "Recovery Mode" in red, press Power once to select and it reboot into recovery mode.
    8. install zip>choose zip from sdcard>0/>UPDATE-SuperSU-v1.55.zip>Yes
    9. ***Go Back***>wipe cache partition>Yes
    10. reboot system now>Yes- Disable recovery flash

    yer done
    1
    My Nexus 7 was rooted since day 1 and with a custom recovery, and always got the OTAs.
    Why is this a problem now?
    Are other people with rooted devices encountered the same issue?
    1
    So based on that is this something that will occur every OTA (i.e. you will have to unroot every OTA to avoid problems)?

    Hi, threi_...

    It's speculation, obviously, as one cannot know the contents of future OTAs beyond the current one which updates to build JWR66V... but it seems likely you will have to unroot, and then re-root again after the OTA.

    But there may be workarounds... as I've indicated in my previous post, somebody has already posted a modified version of the current OTA that skips setting permissions for install-recovery.sh, and allows the OTA to complete successfully.

    And to elaborate on my previous comments, here's why...

    Root modifies /system/etc/install-recovery.sh in order to launch the su root daemon, and it contains the following lines...

    Code:
    #!/system/bin/sh
    
    # If you're implementing this in a custom kernel/firmware,
    # I suggest you use a different script name, and add a service
    # to launch it from init.rc
    
    # Launches SuperSU in daemon mode only on Android 4.3+.
    # Nothing will happen on 4.2.x or older.
    # If you want to force loading the daemon, use "--daemon" instead
    
    /system/xbin/daemonsu --auto-daemon &
    
    # Some apps like to run stuff from this script as well, but the
    # installer will have done "chattr +i" on this file to prevent
    # accidental modification and deletion. In your code, just search 
    # this file for "install-recovery-2.sh", and if present, write
    # there instead.
    
    /system/etc/install-recovery-2.sh

    And during flashing Chainfires SuperSU root updater, the following operation is performed...

    Code:
    chattr +i /system/etc/install-recovery.sh

    This 'locks' the file, using the +i flag ('immutable'), and prevents even system updates from modifying it.

    You should be able to reverse this with...

    Code:
    su
    mount -o rw,remount /system
    chattr -i /system/etc/install-recovery.sh
    mount -o ro,remount /system

    ...in Android Terminal Emulator, but you will need Busybox installed.

    So it's probably just easier to unroot... allow the OTA as normal (or flash the OTA .zip in recovery)... and then re-root again. And I can't see this changing with future OTA's... but as I stated at the beginning of this post, this is just speculation on my part.

    Rgrds,
    Ged.