I have a rooted Galaxy Nexus with stock Android 4.3 and TWRP 2.6.0.0 (latest available for this device).
Today I received the OTA update to Android 4.3 build JWR66Y from JWR66V and accepted it. It immediately failed due to some ZIP signature problem.
I suspected that this is a TWRP problem, booted into TWRP, located the OTA update file, whose name I could still see in the log display, in /cache, and proceeded to flash it manually with TWRP after disabling the ZIP sig checking.
This worked better. Several patches appeared to run through just fine.
But then it still failed with some other error that I could not recognize quickly enough, but TWRP showed a red "Failed" signal. I could not find the log either, so I still don't know what exactly TWRP thought to have failed.
TWRP then told me that the root/superuser access rights are not OK and offered to fix them, which I gladly accepted.
I rebooted and checked the system, and everything still seems to work, including the root functionality. But the system still shows JWR66V, not JWR66Y. This is what the boot loader shows:
PRODUCT NAME - tuna
VARIANT - maguro 16GB
HW VERSION - 9
BOOTLOADER VERSION - PRIMEMD04
BASEBAND VERSION - I9250XXLJ1
Android also still behaves absolutely normally, as far as I can tell.
Normally previous OTA updates ran through just fine. They only removed root, so I always used the Nexus Root Toolkit to re-root. That was convenient enough and left me with the assurance that each update had worked perfectly. Unfortunately this time it was different.
Does anybody have an idea what has failed? Did the update indeed patch some files and then stalled after doing only half its work? Is the system now in a mixed state, some files already JWR66Y, but the rest still JWR66V? Or does the recovery roll back an incomplete update? Should I unroot the phone to let the update proceed?
You should use JWR66Y factory images+fastboot to "update".
Sent from my Galaxy Nexus using Tapatalk 4
hgmichna said:
I have a rooted Galaxy Nexus with stock Android 4.3 and TWRP 2.6.0.0 (latest available for this device).
Today I received the OTA update to Android 4.3 build JWR66Y from JWR66V and accepted it. It immediately failed due to some ZIP signature problem.
I suspected that this is a TWRP problem, booted into TWRP, located the OTA update file, whose name I could still see in the log display, in /cache, and proceeded to flash it manually with TWRP after disabling the ZIP sig checking.
This worked better. Several patches appeared to run through just fine.
But then it still failed with some other error that I could not recognize quickly enough, but TWRP showed a red "Failed" signal. I could not find the log either, so I still don't know what exactly TWRP thought to have failed.
TWRP then told me that the root/superuser access rights are not OK and offered to fix them, which I gladly accepted.
I rebooted and checked the system, and everything still seems to work, including the root functionality. But the system still shows JWR66V, not JWR66Y. This is what the boot loader shows:
PRODUCT NAME - tuna
VARIANT - maguro 16GB
HW VERSION - 9
BOOTLOADER VERSION - PRIMEMD04
BASEBAND VERSION - I9250XXLJ1
Android also still behaves absolutely normally, as far as I can tell.
Normally previous OTA updates ran through just fine. They only removed root, so I always used the Nexus Root Toolkit to re-root. That was convenient enough and left me with the assurance that each update had worked perfectly. Unfortunately this time it was different.
Does anybody have an idea what has failed? Did the update indeed patch some files and then stalled after doing only half its work? Is the system now in a mixed state, some files already JWR66Y, but the rest still JWR66V? Or does the recovery roll back an incomplete update? Should I unroot the phone to let the update proceed?
Click to expand...
Click to collapse
remove root, flash OTA zip file, re-apply root
thegios said:
remove root, flash OTA zip file, re-apply root
Click to expand...
Click to collapse
Yes, the hope is that after unrooting the OTA update will automatically be offered for installation. But what if not?
I don't even know whether I can flash the update manually after unrooting, i.e. with the standard recovery. Can I? Not used to unrooted phones.
hgmichna said:
Yes, the hope is that after unrooting the OTA update will automatically be offered for installation. But what if not?
I don't even know whether I can flash the update manually after unrooting, i.e. with the standard recovery. Can I? Not used to unrooted phones.
Click to expand...
Click to collapse
if u remove root and have standard recovery, wait for the OTA notification and it should install, otherwise unlock bootloader, isntall twrp, flash ota and then flash root
thegios said:
if u remove root and have standard recovery, wait for the OTA notification and it should install, otherwise unlock bootloader, isntall twrp, flash ota and then flash root
Click to expand...
Click to collapse
I just removed busybox, flashed standard recovery, then removed root. Checking system updates yielded only the statement that my system is up to date. Since the update file is already in /cache, shouldn't it have offered the update straight away? Or do I still have to wait, which would be rather stupid?
Here is TWRP's log. Stupidly, it cuts off the lines, so longer lines are cropped.
…
Warning: No file_contexts
Verifying current system. . .
Removing unneeded files. . .
Patching system files. . .
Unpacking new recovery. . .
Symlinks and permissions. . .
set_perm: some changes failed
E:Error executing updater binary in zip '/cache/
Error flashing zip '/cache//1b0ac7dfb2907e5981
Updating partition details. . .
I have also tried unrooting and putting the stock recovery back in place, then booting into a temporary TWRP to flash the OTA update file. Finally I used the Nexus Root Toolkit with its ADB sideload update function, which flashed the OTA update file with the stock recovery. Nothing worked. The error is always the same: set_perm: some changes failed
Next I will try to analyze the update file and see what it wants to do. Perhaps I can find out what would be likely to fail.
Generally this makes using a rooted phone awkward. Until now it was easy, but this situation turns a regular event that used to last a few minutes into an hour-long ordeal. It would be even worse if it required a total wipe. The backup situation has got worse too, both Titanium Backup and Helium are currently buggy and unreliable, not to mention very time-consuming.
Am I the only one who has this problem?
hgmichna said:
I just removed busybox, flashed standard recovery, then removed root. Checking system updates yielded only the statement that my system is up to date. Since the update file is already in /cache, shouldn't it have offered the update straight away? Or do I still have to wait, which would be rather stupid?
Here is TWRP's log. Stupidly, it cuts off the lines, so longer lines are cropped.
…
Warning: No file_contexts
Verifying current system. . .
Removing unneeded files. . .
Patching system files. . .
Unpacking new recovery. . .
Symlinks and permissions. . .
set_perm: some changes failed
E:Error executing updater binary in zip '/cache/
Error flashing zip '/cache//1b0ac7dfb2907e5981
Updating partition details. . .
Am I the only one who has this problem?
Click to expand...
Click to collapse
I have the same problem, have you found the solution
marcars said:
I have the same problem, have you found the solution
Click to expand...
Click to collapse
Some program had written a file install-recovery.sh into /system/etc and marked it immutable, apparently with the command:
chattr +i /system/etc/install-recovery.sh
The OTA update wanted to write this file by unzipping and failed.
So what I did:
adb shell
su
mount -o remount,rw /system
cd /system/etc
chattr -i install-recovery.sh
rm install-recovery.sh
After that I could install the OTA update with TWRP without any further hitch.
rdallion Secret
hgmichna said:
Some program had written a file install-recovery.sh into /system/etc and marked it immutable, apparently with the command:
chattr +i /system/etc/install-recovery.sh
The OTA update wanted to write this file by unzipping and failed.
So what I did:
adb shell
su
mount -o remount,rw /system
cd /system/etc
chattr -i install-recovery.sh
rm install-recovery.sh
After that I could install the OTA update with TWRP without any further hitch.
Be warned: After this update neither the Root Explorer function of ES File Explorer nor the abovementioned mount command worked any more:
>adb shell
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Operation not permitted
255|[email protected]:/ #
But that is yet another matter. I will start a new thread for it.
Click to expand...
Click to collapse
ok i have found a solution in your case you need factory image from developers.google.com/android/nexus/images#nakasijwr66y
unzip this package and edit file .bat if you using windows or .sh when linux is your operating system. Erase in from command "- w" and save the file. Now copy all files from package to C:\Program Files (x86)\Android\android-sdk\platform-tools and start the (double click) .bat file. After that just boot your device in fastboot mode (power + volume-) and the update start the installation. This is not erase your user data if you have modified a .bat file.
marcars said:
ok i have found a solution in your case you need factory image from developers.google.com/android/nexus/images#nakasijwr66y
unzip this package and edit file .bat if you using windows or .sh when linux is your operating system. Erase in from command "- w" and save the file. Now copy all files from package to C:\Program Files (x86)\Android\android-sdk\platform-tools and start the (double click) .bat file. After that just boot your device in fastboot mode (power + volume-) and the update start the installation. This is not erase your user data if you have modified a .bat file.
Click to expand...
Click to collapse
Weird.
hgmichna said:
Some program had written a file install-recovery.sh into /system/etc and marked it immutable, apparently with the command:
chattr +i /system/etc/install-recovery.sh
The OTA update wanted to write this file by unzipping and failed.
So what I did:
adb shell
su
mount -o remount,rw /system
cd /system/etc
chattr -i install-recovery.sh
rm install-recovery.sh
After that I could install the OTA update with TWRP without any further hitch.
Be warned: After this update neither the Root Explorer function of ES File Explorer nor the abovementioned mount command worked any more:
>adb shell
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Operation not permitted
255|[email protected]:/ #
But that is yet another matter. I will start a new thread for it.
Click to expand...
Click to collapse
install-recovery.sh is an initialization script and is used by Superuser and SuperSU to execute the su daemon process which is what we're using in JB 4.3 to establish root (su) privilege.
SuperSU sets the immutable bit (chattr) on this file and this why the update fails.
Starting with line 1309 of the OTA updater-script where the failure/error begins and subsequently aborts at line 1320; everything past that, well....
Code:
Line 1308:
delete("/system/recovery-from-boot.p",
"/system/etc/install-recovery.sh");
show_progress(0.100000, 10);
ui_print("Unpacking new recovery...");
package_extract_dir("recovery", "/system");
ui_print("Symlinks and permissions...");
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm(0, 3003, 02750, "/system/bin/netcfg");
set_perm(0, 0, 0755, "/system/bin/ping");
set_perm(0, 2000, 0750, "/system/bin/run-as");
set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");
Line 1320:
set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");
set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");
set_perm(0, 2000, 0755, "/system/vendor");
set_perm_recursive(0, 2000, 0755, 0755, "/system/vendor/bin");
set_perm(0, 2000, 0755, "/system/vendor/etc");
set_perm(0, 2000, 0755, "/system/vendor/firmware");
set_perm(0, 2000, 0755, "/system/vendor/lib");
set_perm_recursive(0, 2000, 0755, 0644, "/system/vendor/lib/drm");
set_perm(0, 0, 0644, "/system/vendor/lib/drm/libdrmwvmplugin.so");
set_perm(0, 2000, 0755, "/system/vendor/lib/egl");
set_perm(0, 2000, 0755, "/system/vendor/lib/hw");
set_perm_recursive(0, 2000, 0755, 0644, "/system/vendor/lib/mediadrm");
set_perm(0, 0, 0644, "/system/vendor/lib/mediadrm/libwvdrmengine.so");
set_perm(0, 2000, 0755, "/system/vendor/media");
set_perm(0, 2000, 0755, "/system/vendor/pittpatt");
set_perm(0, 2000, 0755, "/system/vendor/pittpatt/models");
set_perm(0, 2000, 0755, "/system/vendor/pittpatt/models/detection");
set_perm(0, 2000, 0755, "/system/vendor/pittpatt/models/detection/multi_pose_face_landmark_detectors.7");
set_perm(0, 2000, 0755, "/system/vendor/pittpatt/models/detection/yaw_roll_face_detectors.6");
set_perm_recursive(0, 2000, 0755, 0644, "/system/vendor/pittpatt/models/recognition");
set_perm(0, 0, 0644, "/system/vendor/pittpatt/models/recognition/face.face.y0-y0-22-b-N.bin");
set_perm_recursive(0, 2000, 0755, 0644, "/system/vendor/res");
set_perm(0, 0, 0644, "/system/vendor/res/images/dock/dock.png");
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
ui_print("Fixing fs_size in crypto footer...");
assert(samsung.fs_size_fix());
ui_print("Patching remaining system files...");
apply_patch("/system/build.prop", "-",
c8330f59436ae2482b603522287e4e969741ec12, 2634,
90670a6ad72244b367249db5065c563aeaefc8f3, package_extract_file("patch/system/build.prop.p"));
set_perm(0, 0, 0644, "/system/build.prop");
unmount("/system");
And the tail of the recovery log
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//8069c140a030f5fe6a6296743aab8c5a93971b79.signed-takju-JWR66Y-from-JWR66V.8069c140.zip'
E:Error installing zip file '/cache//8069c140a030f5fe6a6296743aab8c5a93971b79.signed-takju-JWR66Y-from-JWR66V.8069c140.zip'
Done processing script file
With the immutable bit set on the file no one can change (owner/perms) until the immutable bit is unset by a root (su) user.
So, if you use SuperSU you should do as hgmichna posted and chattr -i the install-recovery.sh file before proceeding with the OTA update.
I don't believe Koush's Superuser sets the immutable bit so you should be OK if that's what you use.
At any rate you'll probably need to flash Superuser again before booting to system.
HTH,
-JR-
jazzruby said:
install-recovery.sh is an initialization script and is used by Superuser and SuperSU to execute the su daemon process which is what we're using in JB 4.3 to establish root (su) privilege.
SuperSU sets the immutable bit (chattr) on this file and this why the update fails.
Click to expand...
Click to collapse
Thanks for the information!
As we now see, this decision to use the immutable property of an ext partition may not have been a very good idea. Many root users will stumble into this trap and waste time, so we are facing a considerable total cost.
I guess that the immutable bit was not meant to be used in normal programs. Does Android use it at all? I would not be surprised if it did not.
Perhaps we need a code of conduct for programmers whose products have root rights. Having root rights does not mean that the entire operating system should now be modified liberally. I propose that a better strategy is to keep modifications requiring root rights to an absolute minimum, treat the operating system gently, and provide some easy means to undo modifications. Inserting an immutable file into the center of the operating system feels more like hiding a land mine in a children's playground.
Before Android 4.3, OTA updates always ran fine on my rooted phone and merely required re-rooting, which was easy and quickly enough to do. But the last two OTA updates both failed.
So now we know that we have to be particularly careful not to get in the way of OTA updates. On my phone the previous update to Android 4.3 failed, because somebody or something had modified the file debuggerd. I guess this can only have been a program with root rights. I don't know which it was. But I now fear that root programs might become a regular source of OTA update problems.
Of course I realise that it is easy to say such things in retrospect. The Germans have a saying, "You are always wiser when you come from the town hall." Also I think we are all grateful that SuperSU exists in the first place and is even free. So don't take the above as an accusation. But if a similar thing happened with the next OTA update and then again the next thereafter, then the root programmers would have to accede that they have had ample prior knowledge and that their products may not be quite perfect yet.
Perhaps these programs need a function called, "Prepare for OTA update". The obvious wish is that rooted phones have a way of accepting OTA updates without wiping data or, worse, a factory reset, because these take too much time and some settings may get lost. In any case I hope that this fresh experience will be a cause for some thorough thinking.
I took the ota today - bone stock JWR66V to JWR66Y, not a single issue.
a maguro sent this.
hgmichna said:
Thanks for the information!
Click to expand...
Click to collapse
Inserting an immutable file into the center of the operating system feels more like hiding a land mine in a children's playground.
Click to expand...
Click to collapse
It's not exactly the "center" of the operating system and I promise you nothing is going to blow up and no children will be hurt.:fingers-crossed:
On my phone the previous update to Android 4.3 failed, because somebody or something had modified the file debuggerd. I guess this can only have been a program with root rights. I don't know which it was.
Click to expand...
Click to collapse
More than likely it was a USB (un)mounting program, e.g. in my case it is Chainfire's StickMount however it does make a backup (debuggerd.backup).
Perhaps these programs need a function called, "Prepare for OTA update".
Click to expand...
Click to collapse
There is indeed a function for this in SuperSU (Survival mode) but it is to protect the su binar(y/ies) and this is where chattr sets the immutable bit and prevents the recursive chmod, chown, etc.. on /system from stripping the su binary of it's owner/group (root) and setuid/setgid.
The install-recovery.sh is a sort of special case because it behaves as an init.d which can execute init START at boot for daemon process which is what's needed for Superuser (su) in Android 4.3 but it also used by alot of modders to take advantage of it's 'init' behavior even when there's no support in kernel.
Normally install-recovery.sh runs a hash check on the recovery partition at boot and if/when fails this check it calls/executes /system/recovery-from-boot which subsequently flashes/installs the stock recovery.
TWRP saves it's recovery by renaming the file recovery-from-boot.bak before booting back to system and preventing the install of stock recovery however it has been seen in the past that some people will modify/delete install-recovery.sh and this is why Chainfire has chosen to chattr +i the file, he does however provision for 'modders' to continue to use by calling a second init (install-recovery-2.sh) at the end of the script.
If you open/view install-recovery.sh you'll see:
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
-JR-
jazzruby said:
It's not exactly the "center" of the operating system and I promise you nothing is going to blow up and no children will be hurt.:fingers-crossed:
Click to expand...
Click to collapse
Except that it reliably kills all OTA updates. I think that is bad enough. I find the idea of using the ext immutable bit quite remarkable. Can you guess the total cost of all the people now running around in circles trying to find out why their OTA update failed? Not everybody is conversant with chattr.
jazzruby said:
More than likely it was a USB (un)mounting program, e.g. in my case it is Chainfire's StickMount however it does make a backup (debuggerd.backup).
Click to expand...
Click to collapse
Yes, that was the most likely cause of the 4.2.2 to 4.3 OTA update failure on my phone. If StickMount really has to modify system files, which I doubt, it should at least warn users about breaking OTA updates and provide a clean uninstall function. On my phone StickMount still works after I have replaced debuggerd with the original. Surprise, surprise, modifying the file seems to be quite unnecessary.
Perhaps one should simply walk a big arc around everything coming from Chainfire. The guy seems to be beset by the idea of killing OTA updates one way or another.
jazzruby said:
There is indeed a function for this in SuperSU (Survival mode) but it is to protect the su binar(y/ies) and this is where chattr sets the immutable bit and prevents the recursive chmod, chown, etc.. on /system from stripping the su binary of it's owner/group (root) and setuid/setgid.
The install-recovery.sh is a sort of special case because it behaves as an init.d which can execute init START at boot for daemon process which is what's needed for Superuser (su) in Android 4.3 but it also used by alot of modders to take advantage of it's 'init' behavior even when there's no support in kernel.
Normally install-recovery.sh runs a hash check on the recovery partition at boot and if/when fails this check it calls/executes /system/recovery-from-boot which subsequently flashes/installs the stock recovery.
TWRP saves it's recovery by renaming the file recovery-from-boot.bak before booting back to system and preventing the install of stock recovery however it has been seen in the past that some people will modify/delete install-recovery.sh and this is why Chainfire has chosen to chattr +i the file, he does however provision for 'modders' to continue to use by calling a second init (install-recovery-2.sh) at the end of the script.
Click to expand...
Click to collapse
How generous! He seems to assume that people only know his Superuser tool and will gladly cater to its particular idiosyncrasies.
I'm a programmer, though not an Android programmer. In my book such ruthless programming is subsumed under "arrogant coding".
pls help
Hello,
This is the first time ever I'm posting something. I own a Nexus 4 and I live in Pakistan. Actually I bought this phone from a local shop which offered used handsets and this nexus 4 was bought in UK and somehow had reached here in Pakistan. Now when I reset the phone first to input my details and it restarted I got to know that it had cyanogen mod installed also doing a factory reset deleted its chrome and play apps as well. It was rooted running android 4.3 build JWR66V. I don't know but I wanted a normal nexus 4 running everything stock. I wanted to get the OTAs so I followed this thread to unroot it:
http://forum.xda-developers.com/showthread.php?t=2010312
and installed the stock android 4.3 build JWR66V factory image with stock recovery and everything else.
Just left the bootloader unlocked.
But now the OTA build JWR66Y is available but every time I check it says my phone is up to date. Please help how will I be able to receive OTAs. Thanks in advance
adeelhayat90 said:
Hello,
This is the first time ever I'm posting something. I own a Nexus 4 and I live in Pakistan. Actually I bought this phone from a local shop which offered used handsets and this nexus 4 was bought in UK and somehow had reached here in Pakistan. Now when I reset the phone first to input my details and it restarted I got to know that it had cyanogen mod installed also doing a factory reset deleted its chrome and play apps as well. It was rooted running android 4.3 build JWR66V. I don't know but I wanted a normal nexus 4 running everything stock. I wanted to get the OTAs so I followed this thread to unroot it:
http://forum.xda-developers.com/showthread.php?t=2010312
and installed the stock android 4.3 build JWR66V factory image with stock recovery and everything else.
Just left the bootloader unlocked.
But now the OTA build JWR66Y is available but every time I check it says my phone is up to date. Please help how will I be able to receive OTAs. Thanks in advance
Click to expand...
Click to collapse
The OTA updates are staged rollouts and probably has not made it to you yet.
The JWR66Y factory images have been posted on Google servers HERE
Nexus 4 "occam" - https://developers.google.com/android/nexus/images#occam
Alternatively, you could download and install the OTA update manually from HERE
HTH,
-JR-
---------- Post added at 05:17 AM ---------- Previous post was at 04:31 AM ----------
hgmichna said:
If StickMount really has to modify system files, which I doubt, it should at least warn users about breaking OTA updates and provide a clean uninstall function. On my phone StickMount still works after I have replaced debuggerd with the original. Surprise, surprise, modifying the file seems to be quite unnecessary
Click to expand...
Click to collapse
To the contrary, it does modify debuggerd in order to use its daemon behavior (START | STOP) and access rights for the proper mount options to provide global access to the USB drive.
Here's the full root log captured by SuperSU:
Code:
stop debuggerd
mount -o rw,remount /system /system
cat /system/bin/debuggerd > /system/bin/debuggerd.backup
echo "#!/system/bin/sh" > /system/bin/debuggerd
echo "mkdir /data/media/0/usbStorage" >> /system/bin/debuggerd
echo "chown root.sdcard_rw /data/media/0/usbStorage" >> /system/bin/debuggerd
echo "chmod 775 /data/media/0/usbStorage" >> /system/bin/debuggerd
echo "mkdir /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "chown root.sdcard_rw /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "chmod 775 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t vfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t vfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t vfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext4 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext4 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext4 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext3 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext3 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext3 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext2 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext2 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ext2 -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "insmod ntfs.ko" >> /system/bin/debuggerd
echo "insmod fuse.ko" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/ntfs-3g -o umask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/ntfs-3g -o umask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/ntfs-3g -o umask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "ntfs-3g -o umask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "ntfs-3g -o umask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "ntfs-3g -o umask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ntfs -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ntfs -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t ntfs -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t exfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t exfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox mount -t exfat -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /da Ôta/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "/data/data/eu.chainfire.stickmount/mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0,iocharset=utf8 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "mount.exfat-fuse -o rw,nosuid,nodev,umask=0,dmask=0,fmask=0 /dev/block/sda1 /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "echo 1 > /data/data/eu.chainfire.stickmount/ready" >> /system/bin/debuggerd
chown root.shell /system/bin/debuggerd
chmod 755 /system/bin/debuggerd
mount -o ro,remount /system /system
start debuggerd
exit
As you can see debuggerd is backed up to debuggerd.backup and the first 'echo' command clears debuggerd and writes the one-liner shebang.
The following 'echo' commands are appended, the script is given owner/perms, the 'system' is mounted RO and 'start debuggerd' executes the script.
Then file is then returned to it's initial state from the .backup
Code:
stop debuggerd
mount -o rw,remount /system /system
cat /system/bin/debuggerd.backup > /system/bin/debuggerd
chown root.shell /system/bin/debuggerd
chmod 755 /system/bin/debuggerd
mount -o ro,remount /system /system
start debuggerd
exit
The above is the 'mounting' process; it goes through a similar process for unmounting.
Unmount and cleanup:
Code:
stop debuggerd
mount -o rw,remount /system /system
echo "#!/system/bin/sh" > /system/bin/debuggerd
echo "toolbox umount /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox rmdir /data/media/0/usbStorage/sda1" >> /system/bin/debuggerd
echo "toolbox rmdir /data/media/0/usbStorage" >> /system/bin/debuggerd
echo "echo 1 > /data/data/eu.chainfire.stickmount/ready" >> /system/bin/debuggerd
chown root.shell /system/bin/debuggerd
chmod 755 /system/bin/debuggerd
mount -o ro,remount /system /system
start debuggerd
exit
Return to initial state:
Code:
stop debuggerd
mount -o rw,remount /system /system
cat /system/bin/debuggerd.backup > /system/bin/debuggerd
chown root.shell /system/bin/debuggerd
chmod 755 /system/bin/debuggerd
mount -o ro,remount /system /system
start debuggerd
exit
-JR-
jazzruby said:
To the contrary, it does modify debuggerd in order to use its daemon behavior (START | STOP) and access rights for the proper mount options to provide global access to the USB drive.
…
As you can see debuggerd is backed up to debuggerd.backup and the first 'echo' command clears debuggerd and writes the one-liner shebang.
The following 'echo' commands are appended, the script is given owner/perms, the 'system' is mounted RO and 'start debuggerd' executes the script.
Then file is then returned to it's initial state from the .backup
Click to expand...
Click to collapse
Thanks for the info! I had not looked into these details. This indeed looks much better than what I had thought.
It did not work for me though. The wrong debuggerd had blocked my 4.2.2 to 4.3 OTA update. And I have seen more than one other complaint about debuggerd blocking OTA updates, so the suspicion lingers that the restoration procedure is unreliable. We will probably not be able to get to the bottom here and now, so we will have to let the matter rest until somebody comes forward with a fresh case and analysis.
adeelhayat90 said:
This is the first time ever I'm posting something. I own a Nexus 4 and I live in Pakistan. Actually I bought this phone from a local shop which offered used handsets and this nexus 4 was bought in UK and somehow had reached here in Pakistan. Now when I reset the phone first to input my details and it restarted I got to know that it had cyanogen mod installed also doing a factory reset deleted its chrome and play apps as well. It was rooted running android 4.3 build JWR66V. I don't know but I wanted a normal nexus 4 running everything stock. I wanted to get the OTAs so I followed this thread to unroot it:
http://forum.xda-developers.com/showthread.php?t=2010312
and installed the stock android 4.3 build JWR66V factory image with stock recovery and everything else.
Just left the bootloader unlocked.
But now the OTA build JWR66Y is available but every time I check it says my phone is up to date. Please help how will I be able to receive OTAs. Thanks in advance
Click to expand...
Click to collapse
Android phones download OTA updates in the background and offer the update only after the OTA file has been downloaded completely.
Do you have a fast Internet connection? I have no idea what strategy the phone uses to download OTA files. It could be that the phone first waits for a Wi-Fi connection and attempts to use mobile phone Internet only after it did not find any Wi-Fi connection for a while. Even then it could be that it prefers HSDPA connections over EDGE or GPRS. It could be that multiple download attempts over slow connections lead to file corruption, if that system is poorly designed. But this is all speculation. I don't know how reliable the download mechanism is, and I don't know what download strategy Android follows.
I also have a case here where a phone runs stock 4.2.1 unrooted (came from Samsung repair that way a week ago) and is still waiting for three OTA updates that should be pending. If anybody here knows more about the OTA update strategy and its reliability or lack thereof, please don't let us die unknowing.
Yes I have a fast Internet connection wifi 2mbps. Fast enough for me atleast. And also that update has only 1.8mb. I remember updating my brother's samsung s4 313mb on the same wifi network.
Sent from my Nexus 4 using Tapatalk 4
Hello everybody .. Hiw i can unpack lollipop system.dat file??
@Skin1980
@S3V3N
Akhayev said:
@Skin1980
Click to expand...
Click to collapse
system.dat? Explain better pls
Skin1980 said:
system.dat? Explain better pls
Click to expand...
Click to collapse
I am sorry .. I downloaded cm12 that based on lollipop and when i opened the rom theres a file named system.new.dat and all the apps inside this file and i wants to port some apps from this file but i cant open it cos its .dat file
Akhayev said:
I am sorry .. I downloaded cm12 that based on lollipop and when i opened the rom theres a file named system.new.dat and all the apps inside this file and i wants to port some apps from this file but i cant open it cos its .dat file
Click to expand...
Click to collapse
try to mount it
Skin1980 said:
try to mount it
Click to expand...
Click to collapse
7zip cannot extract a system.new.dat file and DAEMON tools cannot mount it. I'm hoping ROM devs release their ROMs with the standard format but if they don't, I'm sure someone from the community will easily find a way to extract them.
CM12 system.new.dat apps
Hi,
I had downloaded CM12 just now. There are no apks but only 1-img and 1-dat files in which "system.new.dat" file contains the stuff. Please provide a way to extract apks from system.new.dat file.
Unpack
Anyone figure how to do this?
I would like to know this as well.
I don't know for stock, I'm searching how to do it, but for cm12, you can compile from source directly, there is a thread in development section.
I'm stuck too.
Habaddon said:
I don't know for stock, I'm searching how to do it, but for cm12, you can compile from source directly, there is a thread in development section.
Click to expand...
Click to collapse
This is a chicken and egg problem for me. I want to build a ROM but first want to extract the device firmware for my ROM. (I don't have access to the Nexus 4 phone to install a ROM on and then extract the firmware.)
I've been Googling for a solution without luck.
Followed a clue. I uncommented a debug print statement in simg2img. No luck.
Code:
$ file system.new.dat
system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
$ simg2img.py system.new.dat system.new.raw
424620032
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Not a compressed ext4 file!!
Any ideas?
Yeah, I tried that too, it doesn't work. I ask a dev, in fact, it is simple. All you need to do is mount the img.
mkdir system
sudo mount system.img system
Click to expand...
Click to collapse
Still stuck
Habaddon said:
Yeah, I tried that too, it doesn't work. I ask a dev, in fact, it is simple. All you need to do is mount the img.
Click to expand...
Click to collapse
I'm still confused.
I suspect that the system.new.dat is not a simple image file and is most probably signed in some way. I don't know why the file command says that it is an ext4 filesystem while simg2img.py, with the debug statement which prints the first bytes uncommented, prints only nulls.
BTW, I asked my relative who owns the device to try flashing this ROM and it didn't work because of a known problem whereby rooting was lost. He will try a new ROM.
Plan B will be to pull the firmware via adb but I'm certainly curious about the new Lollipop way of packaging the ROM.
Code:
$ ls -l cm-12-20141123-UNOFFICIAL-mako.zip
-rw-r--r-- 1 zippy zippy 238444354 Dec 6 08:20 cm-12-20141123-UNOFFICIAL-mako.zip
$ unzip cm-12-20141123-UNOFFICIAL-mako.zip
Archive: cm-12-20141123-UNOFFICIAL-mako.zip
signed by SignApk
extracting: system.patch.dat
inflating: META-INF/com/android/metadata
inflating: META-INF/com/google/android/update-binary
inflating: META-INF/com/google/android/updater-script
inflating: META-INF/org/cyanogenmod/releasekey
inflating: boot.img
inflating: file_contexts
inflating: [COLOR="Red"]system.new.dat[/COLOR]
inflating: system.transfer.list
inflating: system/bin/backuptool.functions
inflating: system/bin/backuptool.sh
inflating: system/bin/otasigcheck.sh
inflating: META-INF/com/android/otacert
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
$ ls -l system.new.dat
-rw-rw-r-- 1 zippy zippy 424620032 Feb 29 2008 system.new.dat
$ file system.new.dat
system.new.dat: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)
$ rm -rf # remove the extracted system directory from above
$ mkdir system
$ sudo mount system.new.dat system
[sudo] password for zippy:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
$ dmesg | tail -2
[89035.798766] loop: module loaded
[89035.906824] EXT4-fs (loop0): bad geometry: block count 215040 exceeds size of device (103667 blocks)
I wonder why nobody put up a way to modify this?
I kept looking for the solution from the day lollipop releases, but without any success.
:crying:
Investigating ...
I know more now.
Below is the update-script which calls functions in the update-binary. I highlighted the code in question. This is obviously not a simple filesystem in the system.new.dat. I've hacked at it with ext4.fsck and resize2fs with no luck.
Code:
assert(getprop("ro.product.device") == "mako" || getprop("ro.build.product") == "mako" || abort("This package is for device: mako; this device is " + getprop("ro.product.device") + "."););
ifelse(is_mounted("/system"), unmount("/system"));
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
package_extract_file("system/bin/backuptool.sh", "/tmp/backuptool.sh");
package_extract_file("system/bin/backuptool.functions", "/tmp/backuptool.functions");
set_metadata("/tmp/backuptool.sh", "uid", 0, "gid", 0, "mode", 0755);
set_metadata("/tmp/backuptool.functions", "uid", 0, "gid", 0, "mode", 0644);
run_program("/tmp/backuptool.sh", "backup");
unmount("/system");
if is_mounted("/data") then
package_extract_file("system/bin/otasigcheck.sh", "/tmp/otasigcheck.sh");
package_extract_file("META-INF/org/cyanogenmod/releasekey", "/tmp/releasekey");
set_metadata("/tmp/otasigcheck.sh", "uid", 0, "gid", 0, "mode", 0755);
run_program("/tmp/otasigcheck.sh") != "31744" || abort("Can't install this package on top of incompatible data. Please try another package or run a factory reset");
else
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/userdata", "/data", "");
package_extract_file("system/bin/otasigcheck.sh", "/tmp/otasigcheck.sh");
package_extract_file("META-INF/org/cyanogenmod/releasekey", "/tmp/releasekey");
set_metadata("/tmp/otasigcheck.sh", "uid", 0, "gid", 0, "mode", 0755);
run_program("/tmp/otasigcheck.sh") != "31744" || abort("Can't install this package on top of incompatible data. Please try another package or run a factory reset");
unmount("/data");
endif;
show_progress(0.750000, 0);
[COLOR="red"]block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");[/COLOR]
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
delete("/system/bin/otasigcheck.sh");
unmount("/system");
show_progress(0.020000, 10);
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
package_extract_file("system/bin/backuptool.sh", "/tmp/backuptool.sh");
package_extract_file("system/bin/backuptool.functions", "/tmp/backuptool.functions");
set_metadata("/tmp/backuptool.sh", "uid", 0, "gid", 0, "mode", 0755);
set_metadata("/tmp/backuptool.functions", "uid", 0, "gid", 0, "mode", 0644);
run_program("/tmp/backuptool.sh", "restore");
delete("/system/bin/backuptool.sh");
delete("/system/bin/backuptool.functions");
unmount("/system");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
show_progress(0.200000, 10);
Next, one can look in the source code and try to figure out what it is doing.
Or maybe the next step is to see if there is a host build (i.e. Ubuntu, Fedora, etc) of the binary-update which can be run from the command line into a file which can be mounted.
I'm sure that there is an easy way but finding it is difficult!
Ext2Explorer, Diskinternals Linux Reader can mount, read and extract those system images. But I m not sure if they are fully compatible because in both of these apps which I tried priv-app and some other folders are shown empty. I don't know if normaly there are files in these folders or not.
I've been struggling with these system.new.dat block images since lollipop came out since I need to convert roms to flash onto F2FS system partitions. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... Luckily I've an extra device at my disposal atm. These are the steps I take:
Clean flash a lollipop rom that has a system.new.dat image in twrp.
Reboot system.
When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
In twrp make a backup of only the system partition.
Boot back to system and use the method you prefer to move the file system.ext4.win from /TWRP/BACKUPS/-ur-device-serial/-ur-backup-date on to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can now do with that as you please. :silly:
Well googling i found this solution http://forum.xda-developers.com/nexus-7/general/guide-unpack-dat-t2970707 @adomol:
I've been struggling with these system.new.dat block images since lollipop came out. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... These are the steps I take:
1.Clean flash a lollipop rom that has a system.new.dat image in twrp.
2.Reboot system.
3.When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
4.In twrp make a backup of only the system partition.
5.Boot back to system and use the method you prefer to move the file system.ext4.win from:
/TWRP/BACKUPS/-ur-device-serial/-ur-backup-date
to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can do with that as you please, or just throw it into a rom kitchen.
all credits to @adomol
adomol said:
I've been struggling with these system.new.dat block images since lollipop came out since I need to convert roms to flash onto F2FS system partitions. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... Luckily I've an extra device at my disposal atm. These are the steps I take:
Clean flash a lollipop rom that has a system.new.dat image in twrp.
Reboot system.
When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
In twrp make a backup of only the system partition.
Boot back to system and use the method you prefer to move the file system.ext4.win from /TWRP/BACKUPS/-ur-device-serial/-ur-backup-date on to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can now do with that as you please. :silly:
Click to expand...
Click to collapse
-droidberg- said:
Well googling i found this solution http://forum.xda-developers.com/nexus-7/general/guide-unpack-dat-t2970707 @adomol:
I've been struggling with these system.new.dat block images since lollipop came out. I searched high and low for a way to mount that image outside of twrp with no luck. So I just used twrp instead... These are the steps I take:
1.Clean flash a lollipop rom that has a system.new.dat image in twrp.
2.Reboot system.
3.When device finishes booting use hardware power button to power down without messing with the rom itself yet so it stays fresh. (It's ok to confirm power down on touch screen.)
4.In twrp make a backup of only the system partition.
5.Boot back to system and use the method you prefer to move the file system.ext4.win from:
/TWRP/BACKUPS/-ur-device-serial/-ur-backup-date
to your pc and rename it system.tar so you can unpack it. (Of course make sure you have the proper decompression tools, which every OS usually does now.)
Now you have the complete fresh contents of /system as you would in a traditional rom zip. You can do with that as you please, or just throw it into a rom kitchen.
all credits to @adomol
Click to expand...
Click to collapse
But this won't work when trying to port because you need to swap kernel's (for going between same-device, different-carrier)