Related
Thanks to anomalous3 over on the vibrant forum he was nice enough to port over his rom to our side based off of the new source code released by samsung
"If you feel like being a guinea pig, or know anyone who does, the deodexed build is here:
http://getyourboneon.com/CaptivateDeodexed.zip
Since I don't have a captivate I can't really test it, but it should work fine. It's based off that UCJH2 build. I didn't include any lag fixes since they've proliferated out of control, but I did include ext manipulation libraries and e2fsck to make life easier for people who want to use one of the lag fixes."
Please note I have NOT tested this rom yet, I don't have my captivate. Please somebody could test this and let us know if there's any problem so we can let him help us fix it.
Again, not responsible for whatever happens to your phone.
Here is the original thread I posted for reference.
http://forum.xda-developers.com/showthread.php?t=746466
EDIT: I'm going to assume you would install this like any other rom via update
EDIT2: anomalous3 has updated the link with corrections. Let us know how it works
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Zilch25 said:
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Click to expand...
Click to collapse
let us know how it goes
Do I just rename this to update.zip and go recovery and reinstall packages?
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Will do, flashing back to a stock JH2 while I download! I've been waiting for something like this
Clienterror said:
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It probably was my fault anyway =P
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
damn it, wish this was around 2 hours ago when i was bored! its too late now to ruin my phone haha.. tomo sometime maybe i'll try..
Question...Do I have to install the stock Captivate ROM first as it states in the linked post? I have the stock ROM that is rooted with the AT&T bloatware removed. The only other mod is the lagfix version 2.3...Can I just flash this over that?
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
nammyczc said:
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
Click to expand...
Click to collapse
That's what's taking me so long... seems like JH2 is having some issues with update.zips... namely it's getting to the "Opening installer" then "Install Aborted". The(not new) update.zip for root still works, so I'm tossing on clockwork to see if I can get this thing crammed on here with that.
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Zilch25 said:
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Click to expand...
Click to collapse
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
BuglessPete said:
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
Click to expand...
Click to collapse
I'll pm him about this
nammyczc said:
I'll pm him about this
Click to expand...
Click to collapse
Also ask him why superuser.apk is in the xbin folder.
vietphunguyen said:
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
Click to expand...
Click to collapse
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
golemaw said:
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
Click to expand...
Click to collapse
This is correct. Deodexed ROMs can be themed...
BuglessPete said:
Also ask him why superuser.apk is in the xbin folder.
Click to expand...
Click to collapse
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
anomalous3 said:
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
Click to expand...
Click to collapse
updated original post with info
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
AndrewTL said:
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
Click to expand...
Click to collapse
You need to go through all the lines of code for that and I believe some of them are binary files as well. Possible but will take much time. For now we must wait until someone finds a better solution.
Sent from my Kindle Fire using Tapatalk
signature issues.
6.2.1 experiment?
transfuntioner said:
signature issues.
Click to expand...
Click to collapse
Maybe I don't follow the process.. but I'm guessing no signatures..
not a signed bootloader.. no signatures required...
Get beyond compare and look at the differences between the OTA updates and the zip that Eldarerathis put together.
The ".bin" files are just ".zip" files renamed.
Look at
META-INF/com/google/android/updater-script in the bin files they release.
It is just a script.
And to do the things that it is doing, it has to be getting root permissions while it is running.
I don't know how to recover if it doesn't work, but I half wonder if you were to take the zip that fellow created, change the extension to ".bin" and just dump it into the update folder if the fire would install it for you?
He took out the image files from the script. He's just updating the system tree directly. He doesn't update the bootloader, recovery or backup trees.
For that matter if those contained something nasty, they could probably be pulled from an earlier update.
== cut ===
package_extract_file("recovery.img", "/dev/block/platform/mmci-omap-hs.1/by-name/recovery");
show_progress(0.100000, 10);
package_extract_file("u-boot.bin", "/dev/block/platform/mmci-omap-hs.1/by-name/bootloader");
format("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup");
mount("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup", "/backup");
package_extract_file("backup_userdata.zip", "/backup/backup_userdata.zip");
== cut ===
Please nobody try this idea that doesn't know enough to recover if it doesn't work, because I've not a clue how.
But could someone explain why wouldn't it work?
Worst case the rev might need to be manually edited to bump it one for the script.
Seems like it might be an easy way to get around headaches with OTA updates.
Andrew,
Are you having issues with getting into recovery so that you can test this? The Devolopers have a copy of TWRP 2 working perfectly on the device so you can get a clean backup of the OS before you test.
You sound like you may know what to do to fix the issue and I just want to help you get a good recovery in case it doesn't pan out or for testing.
~enjoy.
Actually I'm just afraid of messing up what I have working now.
I've got TWRP 2 running with the 6.2.1 image.
I'm setting these up as gifts. I spent a good 12 hours yesterday fighting the darn things. Guess I'm getting gun shy. Had a lot of issues with adb. Kudos to the new utility and setting the second ports up. I'm learning.
The OTA install wipes the system directory. It's in the script.
I was tempted to just comment that line out and see if it would leave the rest alone.
If I brick the thing its going to be painful for me to sort out.
I also didn't want to risk losing root. I also haven't tried loading an older OTA version.
At the time, I couldn't ask the fellow that developed the rooted 6.2.1 zip the question in his thread as I didn't have enough posts.
I'm going to be out of pocket for quite some time. I'm not going to have time to spend like this again for at least a few days.
But I was checking the zip he made versus the .bin/.zip files that the OTA releases using beyond compare. I wanted to see what files had actually changed.
That's when I found that script. It is manipulating permissions directly. It has to be running at a root level. I don't see anything like a signature on it, so why couldn't their own update system be used to tweak their own updates to allow for root?
Hello,
I don't know if you noticed but JCSullins made a new cwm6 based recovery.
If you want to give it a try I've made a cwm flashable update archive,
**Removed - wait for JCSullins official release**
menthe said:
Hello,
I don't know if you noticed but JCSullins made a new cwm6 based recovery.
If you want to give it a try I've made a cwm flashable update archive,
https://www.dropbox.com/s/hzxb7fswws5l0ss/update-cwm6_tenderloin-20121204.zip
Click to expand...
Click to collapse
For those not in the know, it is recommended to update your recovery and essential if you plan to update to cm10. This fixes s file system corruption bug that shows up when expanding the partition in preparation for cm10.
Sent from my HP TouchPad using Tapatalk 2
menthe said:
Hello,
I don't know if you noticed but JCSullins made a new cwm6 based recovery.
If you want to give it a try I've made a cwm flashable update archive,
https://www.dropbox.com/s/hzxb7fswws5l0ss/update-cwm6_tenderloin-20121204.zip
Click to expand...
Click to collapse
Thanks for your installable zip! I had been trying to get things updated and couldn't get the uImage written to the /boot dir on my TP.
Went through adb (reinstalling drivers, connecting,etc.) then tried renaming and copying to /boot through ES File explorer with SU permissions, but it still wouldn't let me write to the /boot folder. I'm not quite sure why - I thought SU permissions allowed me to write to the /boot folder, but I guess not... I'll have to further investigate. I'm still noobish on quite a lot here.
Needless to say, your zip file helped and was finally able to get CWM6 updated on my TP. Thanks button pressed! :good:
"Went through adb (reinstalling drivers, connecting,etc.) then tried renaming and copying to /boot through ES File explorer with SU permissions, but it still wouldn't let me write to the /boot folder. I'm not quite sure why - I thought SU permissions allowed me to write to the /boot folder, but I guess not... I'll have to further investigate. I'm still noobish on quite a lot here."
Click to expand...
Click to collapse
Open terminal
type
su
umount -o remount,rw /boot
then use es file explorer.
chadster1976 said:
Thanks for your installable zip! I had been trying to get things updated and couldn't get the uImage written to the /boot dir on my TP.
Went through adb (reinstalling drivers, connecting,etc.) then tried renaming and copying to /boot through ES File explorer with SU permissions, but it still wouldn't let me write to the /boot folder. I'm not quite sure why - I thought SU permissions allowed me to write to the /boot folder, but I guess not... I'll have to further investigate. I'm still noobish on quite a lot here.
Needless to say, your zip file helped and was finally able to get CWM6 updated on my TP. Thanks button pressed! :good:
Click to expand...
Click to collapse
Rom Toolbox lite will allow you to .
*sigh*
"... At this point I'm just putting out a uImage to allow those who are
comfortable swapping out the uImage to test." (less than 24 hrs ago on rootzwiki)
I was hoping to get some feedback from the "more advanced" users testing this before creating an
installable zip and unleashing it on everyone. So far, virtually no feedback.
I flashed it and now I'm soft bricked. Can't boot into sk8's CWR6, CM10 or anything.
Lesson learned, ask developers before posting there work
Sent from my Galaxy Nexus using xda app-developers app
It likely not the CWM6 that did it but the boot partition full. If you have an extra webos kernel, some moboot themes, TWRP, and then this new larger uImage for CWM you will likely run out of space.
Probably should put that warning here it's pretty important people realize it and/or add a script to remove TWRP, to prevent issues with this zip.
@jcsullins +1 Feedback. Installed your CWM uImage manually. Mounted as mass storage in CWM, copied files, Installed latest CM10 12/05(over older CM10 installed with Acme3), Installed Gapps, Installed Camera Preview 3 patch, Installed WEBCM10, cleared both caches in CWM and noticed no issues during all the processes.
I ACMEU wiped and ACME3'd the whole deal back on w/new recovery. It needed the clean up anyways and I had a NAND from yesterday.
Nice, thanks JC.
Roland Makes oopsy
jcsullins said:
*sigh*
"... At this point I'm just putting out a uImage to allow those who are
comfortable swapping out the uImage to test." (less than 24 hrs ago on rootzwiki)
I was hoping to get some feedback from the "more advanced" users testing this before creating an
installable zip and unleashing it on everyone. So far, virtually no feedback.
Click to expand...
Click to collapse
Thank you for taking the time to create this great new CWM6. I have been really enjoying the new looks and graphics. I have tested flashing different zips and Roms. I have made and restored Nandroid backups and even restored older CWM5 backups with CWM6. I do this to try and help but sometimes I really step in $#@# trying to help, like with the 4.2gapps.
Sorry about being so anxious to get this out to the public. I have had a lot of complaints about Bricked TouchPads and would like to get the word out about the problem and how to fix/prevent it.
I feel very responsible for the people affected due to me making an install video without knowledge of the corruption issue beforehand.
I wanted to make a video explaining that there was an issue but to fix it they can, Backup, uninstall, reinstall and restore. To prevent future issues I want to included this in my install instructions. They would of course need your New CWM6 to do this and I have been eagerly awaiting this fix.
Sorry about all my stupid mistakes, I get a bit over excited about Tech stuff at times. Please accept my sincerest apologies.
jcsullins said:
*sigh*
"... At this point I'm just putting out a uImage to allow those who are
comfortable swapping out the uImage to test." (less than 24 hrs ago on rootzwiki)
I was hoping to get some feedback from the "more advanced" users testing this before creating an
installable zip and unleashing it on everyone. So far, virtually no feedback.
Click to expand...
Click to collapse
I'm sorry, but I didn't see your post in Rootzwiki or I would have posted there.
This cwm has worked flawlessly. I haven't had a chance to try all the new features, but the ones I did try worked fine.
Thanks so much for this. The old 5.0.2.6 was starting to show its age. I hope this cwm does away with the sporadic partitioning problems I'd been seeing.
jcsullins said:
*sigh*
"... At this point I'm just putting out a uImage to allow those who are
comfortable swapping out the uImage to test." (less than 24 hrs ago on rootzwiki)
I was hoping to get some feedback from the "more advanced" users testing this before creating an
installable zip and unleashing it on everyone. So far, virtually no feedback.
Click to expand...
Click to collapse
In my limited testing to this point, I've not uncovered any issues. I flashed a couple of different roms, gapps and misc zipfiles and all were fine. I also made a nandroid and a subsequent restore which also worked fine.
I like the idea that that the default backup method was tar as opposed to dup, as I am more comfortable with that. Also, was pleasantly surprised to find that USB storage mount was working, I thought that this was "broken" in CWM 6.x. I transferred files back & forth on my PC with no problem.
The only oddity I came across was when trying to view the files in my nandroid backup folder in ES File Explorer, or the stock CM File Manager, the 2 android_secure.vfat.tar files were not visible. Yet they were visible in Root Explorer and of course, when I transferred it over to my PC for safekeeping, they were there.
That's about it for now. Great job as always, JC. Thanks.
Mike T
New Backup Options
I am just trying some of the new backup options. It seems that we have a choice in the backup we make now, the Default is Tar and the 2nd option is Dup. There is also a "free unused backup data" option, since the backups appears to be in several files. I wanted to backup my backups but I am in over my head here and don't know much about the new backup options. Has anyone else had a chance to take a look? I like the spinning ball animation in the Androids stomach while I make and restore my backups:good: I can use my old CWM5 backups but now I don't know what to do about the new ones. Could anyone more experienced help me out please:fingers-crossed:
webdroidmt said:
In my limited testing to this point, I've not uncovered any issues. I flashed a couple of different roms, gapps and misc zipfiles and all were fine. I also made a nandroid and a subsequent restore which also worked fine.
I like the idea that that the default backup method was tar as opposed to dup, as I am more comfortable with that. Also, was pleasantly surprised to find that USB storage mount was working, I thought that this was "broken" in CWM 6.x. I transferred files back & forth on my PC with no problem.
The only oddity I came across was when trying to view the files in my nandroid backup folder in ES File Explorer, or the stock CM File Manager, the 2 android_secure.vfat.tar files were not visible. Yet they were visible in Root Explorer and of course, when I transferred it over to my PC for safekeeping, they were there.
That's about it for now. Great job as always, JC. Thanks.
Mike T
Click to expand...
Click to collapse
I was having the same issues trying to view the files from ES File Explorer, and from the PC. I feel like such a noob
RolandDeschain79 said:
I am just trying some of the new backup options. It seems that we have a choice in the backup we make now, the Default is Tar and the 2nd option is Dup. There is also a "free unused backup data" option, since the backups appears to be in several files. I wanted to backup my backups but I am in over my head here and don't know much about the new backup options. Has anyone else had a chance to take a look? I like the spinning ball animation in the Androids stomach while I make and restore my backups:good: I can use my old CWM5 backups but now I don't know what to do about the new ones. Could anyone more experienced help me out please:fingers-crossed:
I was having the same issues trying to view the files from ES File Explorer, and from the PC. I feel like such a noob
Click to expand...
Click to collapse
Hi Roland, hope all is well with you. I am not having a problem viewing my nandroid files on my PC, just from the apps I mentioned within Android.
Anyway, just a quick blurb on the 2 backup methods of .tar & .dup. Tar is what we are used to with the older CWM version, .dup is something new to CWM and fairly similar to the way a windows PC does backups. I'm no expert but in a nutshell, .tar backs up everthing each time you do a nandroid, .dup does incremental backups each time and stores the data in "blob" files which become very large. With the .dup method, because it's only doing incremental, backup time is faster than .tar but with the large "blob" folders of data, it's a PITA to move to your PC for safekeeping.
With all the flashing I do, I'm constantly moving nandroids back & forth, so I prefer .tar at this time. But as usual, YMMV. Take care.
Mike T
.dup & .tar enlightenment
webdroidmt said:
Hi Roland, hope all is well with you. I am not having a problem viewing my nandroid files on my PC, just from the apps I mentioned within Android.
Anyway, just a quick blurb on the 2 backup methods of .tar & .dup. Tar is what we are used to with the older CWM version, .dup is something new to CWM and fairly similar to the way a windows PC does backups. I'm no expert but in a nutshell, .tar backs up everthing each time you do a nandroid, .dup does incremental backups each time and stores the data in "blob" files which become very large. With the .dup method, because it's only doing incremental, backup time is faster than .tar but with the large "blob" folders of data, it's a PITA to move to your PC for safekeeping.
With all the flashing I do, I'm constantly moving nandroids back & forth, so I prefer .tar at this time. But as usual, YMMV. Take care.
Mike T
Click to expand...
Click to collapse
Thank you very much for the detailed response. I’m feeling good now that I am starting to understand the new recovery. I also really liked having those individual .tar backups:good:, I made one for each version of CM. I wonder how .dup backups will affect the free space on my device. I also backup a lot but I did find that i was able to restore the older CWM5 backups without a problem. I will probably just keep the older CWM5 .tars for CM7, CM9 and do my CM10 backing up with the newer .dup. Time to transfer some backups:victory:
Can we maybe get rid of the link in op? Jc has stated this was only for testing, you shouldn't host a devs work without permission, and maybe for the fact of it will soft brick a TP? Just saying....
Sent from my HTC VLE_U using xda app-developers app
Sorry for possibly misunderstanding but is it recommended to use this yet due to possible corruption issues with older versions of CWM or only intended for testing atm? I've been meaning to ACME uninstall the TP and reinstall CM10 clean again and if this newer version of recovery is recommended for flashing I'll throw it on there while I'm at it
Thx JCSullins! :fingers-crossed:
jcsullins said:
*sigh*
"... At this point I'm just putting out a uImage to allow those who are
comfortable swapping out the uImage to test." (less than 24 hrs ago on rootzwiki)
I was hoping to get some feedback from the "more advanced" users testing this before creating an
installable zip and unleashing it on everyone. So far, virtually no feedback.
Click to expand...
Click to collapse
Hello,
Sorry for that :/
I haven't seen your rootzwiki post and so far I was just willing to help users to install it
easily (seems that was my mistake :x) because after I gave it a try it solved the issues
I was having with the previous CWM one. There is just one thing that disturb me, in
Backup and Restore menu, 'choose backup format' should be rename in something like
"choose default backup format".
That's just my 2cents and besides this all functions work well, thanks for your hard work.
I'll remove the link from the OP post and wait for your public release
Sincerely, menthe.
Has anyone tried the adb sideload yet?
When attempting to sideload I get: * failed to write data 'protocol fault (no status)' *
Any other adb commands I issue are met with "error:closed"
I am stuck here because I don't have a power button to do a hard reset... please someone tell me this function is working and I am just doing something wrong. My TP has a full charge and I don't feel like waiting 8hrs for it to die so it can be reset.
Edit: just took the whole thing apart and pulled the battery
Tried updating from 4.2.1 to 4.2.2.
But assert check failed returning above file in results. Somehow it's been modified. No idea when and how.
Anyone running 4.2.1, could you please provide me this file.
Thanks in anticipation.
Sent from my Nexus 7 using Tapatalk HD
gurudev32 said:
Tried updating from 4.2.1 to 4.2.2.
But assert check failed returning above file in results. Somehow it's been modified. No idea when and how.
Anyone running 4.2.1, could you please provide me this file.
Thanks in anticipation.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
I have the exact same issue!
Here is the list of only apps with root access in my tab.
Carbon - App backup and restore, Solid explore, Stick mount, SuperSU, System tuner pro and Terminal Emulator.
Thought to seek out the culprit!
Sent from my Nexus 7 using Tapatalk HD
https://dl.dropbox.com/u/17326185/debuggerd
MD5: B59443115C4181F49A57C1290EE3225B
https://dl.dropbox.com/u/17326185/build.prop
MD5: D9D1855E0C90049DC410A4406B802259
Pulled this from the 4.2.1 factory image. I seem to have got past the debuggerd error message now (though I need to revert my build.prop entirely, apparently).
Included build.prop (not yet tested) from 4.2.1 image too.
Working for me and now running 4.2.2.
At your own risk, yadda yadda, not responsible for explosions or anything less terrible, blah blah.
FWIW, I had been using Stickmount and superSU.
PhoenixTank said:
Pulled this from the 4.2.1 factory image. I seem to have got past the debuggerd error message now (though I need to revert my build.prop entirely, apparently).
Included build.prop (not yet tested) from 4.2.1 image too.
Working for me and now running 4.2.2.
At your own risk, yadda yadda, not responsible for explosions or anything less terrible, blah blah.
FWIW, I had been using Stickmount and superSU.
Click to expand...
Click to collapse
Thanks Now 'm on 4.2.2
In the future, If you want to pull arbitrary file(s) from Google N7 factory images, a useful skill set is to figure out how to use "sim2img" utility and loopback mounts (Windows need not apply).
Those system.img files shipped by Google are "sparse ext4 images" - they can not be directly mounted as a loopback, but that's where the "sim2img" utility comes in
The sequence goes like this:
- use sim2img to convert Google image file to regular ext4 image file
- loopback mount reg. image file
- grab whatever files you want (and check user/GRP ownership & modes)
It really is just that easy.
The "sim2img" utility is part of the android ext4_utils toolset. See this XDA thread from the Galaxy S forums for more details. (Yes the N7 system.img files from Google are also in this format.)
cheers
PhoenixTank said:
https://dl.dropbox.com/u/17326185/debuggerd
MD5: B59443115C4181F49A57C1290EE3225B
https://dl.dropbox.com/u/17326185/build.prop
MD5: D9D1855E0C90049DC410A4406B802259
Pulled this from the 4.2.1 factory image. I seem to have got past the debuggerd error message now (though I need to revert my build.prop entirely, apparently).
Included build.prop (not yet tested) from 4.2.1 image too.
Working for me and now running 4.2.2.
At your own risk, yadda yadda, not responsible for explosions or anything less terrible, blah blah.
FWIW, I had been using Stickmount and superSU.
Click to expand...
Click to collapse
How to make it? and i will lose all data? thanks
TheRejzo said:
How to make it? and i will lose all data? thanks
Click to expand...
Click to collapse
Big thanks.
Replacing the debuggerd file allowed twrp to load the 4.2.2 update.
Also interesting, other than titanium, the only other root app on this device is Stickmount.
Did not work for me ...
I have a N7 3G and the same message when trying to update. Replaced mine with the one from the download, no change, same error.
diba320 said:
Did not work for me ...
I have a N7 3G and the same message when trying to update. Replaced mine with the one from the download, no change, same error.
Click to expand...
Click to collapse
First of all, thanks a lot to PhoenixTank who provides me the solution. :good:
In fact to make it work, I had to change the permissions allowed on that file named "debuggerd", I checked what permissions were allowed on the original file and do the same on the copied one. I did it with ES explorer in root mod.
TheRejzo said:
How to make it? and i will lose all data? thanks
Click to expand...
Click to collapse
You'd need to backup and rename the existing debuggerd then move/copy the 4.2.1 debuggerd file to /system/bin/
Then match the permissions of the old debuggerd (I think it was 644, but I wouldn't swear by it).
The OTA zip should actually go through after that, or at least tell you about a new file you need to fix. You shouldn't lose any data, but you should probably clear cache and dalvik cache.
I did most of this via adb shell, but there are root file managers that can help. If you aren't confident about doing this and how it works, my posting was not really for you. Strongly suggest reading up until you feel confident before you start changing things around in the system partition.
diba320 said:
Did not work for me ...
I have a N7 3G and the same message when trying to update. Replaced mine with the one from the download, no change, same error.
Click to expand...
Click to collapse
Unfortunately the 3G version is different to the Wifi Nexus 7, and as you've found, the files will not work.
Since I posted, Google pulled the 4.2.1 factory images from the download site - I'm not really in a good position to help you here.
The 4.2.2 factory image might be of more use if you can't source the 3G specific files. i.e. flash the new factory image.
Had this same problem. Will try solution tomorrow morning. Probably will download the links rather than trying to extract them myself (though I may leave that for a later exercise).
Would like to note that I also use StickMount as well as SixAxis Controller, Wifi Key Recovery, AppSync and LMT Launch err.
Seems like stick mount is the common one though.
Sent from my Nexus 7 using xda app-developers app
PhoenixTank said:
https://dl.dropbox.com/u/17326185/debuggerd
MD5: B59443115C4181F49A57C1290EE3225B
https://dl.dropbox.com/u/17326185/build.prop
MD5: D9D1855E0C90049DC410A4406B802259
Pulled this from the 4.2.1 factory image.
Click to expand...
Click to collapse
bftb0 said:
In the future, If you want to pull arbitrary file(s) from Google N7 factory images, a useful skill set is to figure out how to use "sim2img" utility and loopback mounts (Windows need not apply).
Those system.img files shipped by Google are "sparse ext4 images" - they can not be directly mounted as a loopback, but that's where the "sim2img" utility comes in
The sequence goes like this:
- use sim2img to convert Google image file to regular ext4 image file
- loopback mount reg. image file
- grab whatever files you want (and check user/GRP ownership & modes)
It really is just that easy.
The "sim2img" utility is part of the android ext4_utils toolset. See this XDA thread from the Galaxy S forums for more details. (Yes the N7 system.img files from Google are also in this format.)
cheers
Click to expand...
Click to collapse
Thanks guys
Those 2 files worked.
I got past "Verifying current system" and am now on 4.2.2.
I wanted to try to get the files myself as an exercise but Google pulled the 4.2.1 images from their website.
What is weird... is that I noticed a /system/bin/debuggerd.bak file that I didn't make myself, don't know what did (though StickMount seems to be the current suspect).
The weird thing is that debuggerd and debuggerd.bak were exactly the same.
FunkyELF said:
I wanted to try to get the files myself as an exercise but Google pulled the 4.2.1 images from their website.
Click to expand...
Click to collapse
oldblue910 (OP of the OTA thread) has got you covered. Select the link on the rhs of the page as appropriate for your device (nakasi/nakasig)
cheers
I want to do this, but I can't find the system/bin folder, what root explorer apps do you guys use?
EDIT: Used Total Commander, copied the permissions from old file to new and voilah! It worked.
No need to download build prop.
Now I am on 4.2.2
EDIT 2: Now WiFi only says SAVED and not CONNECTED.
Just want to say THANK YOU!! I've been researching this error since Friday and finally found the solution here! And yes, I too have Stickmount!
Rody2k6 said:
I want to do this, but I can't find the system/bin folder, what root explorer apps do you guys use?
EDIT: Used Total Commander, copied the permissions from old file to new and voilah! It worked.
No need to download build prop.
Now I am on 4.2.2
EDIT 2: Now WiFi only says SAVED and not CONNECTED.
Click to expand...
Click to collapse
Can only recommend that you clear cache and dalvik cache. I have not experienced Wifi issues since the update.
To anyone I've helped, you are very welcome and I appreciate those thanks clicks too.
bftb0 said:
In the future, If you want to pull arbitrary file(s) from Google N7 factory images, a useful skill set is to figure out how to use "sim2img" utility and loopback mounts (Windows need not apply).
Those system.img files shipped by Google are "sparse ext4 images" - they can not be directly mounted as a loopback, but that's where the "sim2img" utility comes in
The sequence goes like this:
- use sim2img to convert Google image file to regular ext4 image file
- loopback mount reg. image file
- grab whatever files you want (and check user/GRP ownership & modes)
It really is just that easy.
The "sim2img" utility is part of the android ext4_utils toolset. See this XDA thread from the Galaxy S forums for more details. (Yes the N7 system.img files from Google are also in this format.)
cheers
Click to expand...
Click to collapse
can i do the reverse ? i.e. ext4 partition back to flashable img ?
that way it would be easier to root as I just need to dump a copy of su into it then flash.
And for Windows, just get oracle virtualbox(or your favorite VM, even virtual PC should work) and boot a copy of debian
chimpanzeexda said:
can i do the reverse ? i.e. ext4 partition back to flashable img ?
that way it would be easier to root as I just need to dump a copy of su into it then flash.
And for Windows, just get oracle virtualbox(or your favorite VM, even virtual PC should work) and boot a copy of debian
Click to expand...
Click to collapse
Yes. I did exactly the same thing, but for 4.2.1. Guess I need to repeat it now for 4.2.2. Note in this case "flashable" means the fastboot way (as with the Factory ROM flashes), not via custom recovery.
Uhh let's see - the script tool used for re-packing is ./mkuserimg.sh - see the links I provided above
I need some help... I'm rather noobie. Had issue with upgrading to 4.2.2 so copied the debuggerd and build.prop files over to the system/bin directory. Still failed to upgrade. Tried it again today and now the N7 will not boot up. I can see it's on but it just stops at a blank screen. I have stock 4.2.1 w/root. Stock bootloader. I'm thinking its refusing to boot because I forgot to change the file permissions on the debuggerd file but not sure how to try and fix it. Please advise...
UPDATE: Managed to flash the system partition for 4.2.2 so hoping I'm good to go. Asked this question in another post but is it necessary to update any of the other partitions?
This thread is meant to help share programs and older files that have gone missing or have dead links and to collect everything in one place. I came here a long time ago to ask a few questions, but now I would like to return the favor by organizing everything so owners of the VK810 don't have to run around looking for everything.
One of the most common files I see asked for is TWRP 2.7.0.1. I still have my old copy and have uploaded it to Android File Hosts. The link is located below at the very bottom. In that link, I also include a stock rom in case anyone wants to start over along with the tools to do so. Other TWRP versions are also included. I also include some other programs as well, but they are mostly meant to act as a backup in case other links go down. Just to clarify, they are not my own. I just want to make sure everyone gets what they need. If there is anything I forgot to give credit for, I will add it as I remember or let me know so I can properly give the credit.
I don't want to take credit for anything here. I just want to help people have an easy time with setting up their device, but I will give out credit where needed.
For people starting out, roirraW "edor" ehT has made an extensive tutorial for the VK810. His roms work with LTE if you need it.
https://forum.xda-developers.com/lg-g-pad-83/general/vk810-4g-reliable-to-root-install-t3283027
Since his Android File Host page is still working and he is still very active, I won't archive any of his work. Get everything you need from his pages.
For anyone that wants to return to stock, ttn1185 has a very simple guide on return to root along with the stock rom, but the link to the guide doesn't seem to work.
https://forum.xda-developers.com/lg-g-pad-83/general/vk810-verizon-lg-g-pad-8-3-to-stock-t2800857
To save time, I have included the guide I used and the link to the guide for returning to stock below. Credit goes to hyelton for creating it.
https://forum.xda-developers.com/showthread.php?t=2432476
Magendanz has been making new TWRP builds for the VK810. I included one of his older builds in my archive since it helped me out a lot.
https://forum.xda-developers.com/lg-g-pad-83/general/vk810-twrp-3-1-1-0-unofficial-t3691551
One way I managed to install it was to flash my recovery to version 2.8.7.0, run the recovery, flash the image using TWRP, and then restart. There are easier methods, but I used this one since it doesn't rely on using ADB or setting it up if you don't have it already.
Drgravy originally had the important TWRP 2.7.0.1, but his link to it is dead. The instructions for it are still relevant.
https://forum.xda-developers.com/showthread.php?t=2726707
For those that don't want to use ADB, you can copy the contents of the files to a folder you have easy access to, download/run a terminal emulator of your choice on the device, change directory to where the lok and flash files are, and use the cp command in place of push to copy the contents to the specified folders. Other than that, the other commands in the instructions are the same and can be followed verbatim. I believe it is easier or required to have root first to do this, so run Stump to root the device before doing this. It is also included in the link.
For people that do not need LTE, invisiblek has created a rom of Lineage 14.1 to work with the device. It is what I am currently using right now. While invisiblek gets credit for creating the rom, I give credit to thunderbolt128 for introducing it to me. He has simple instructions on how to install it and has a link to download the rom included in the post.
https://forum.xda-developers.com/lg-g-pad-83/general/vk810-invisibleks-lineage-14-1-rom-t3806903
I flashed pico gapps (ARM) when I was flashing the rom in recovery, but use whichever gapps (or none) that you are comfortable with.
Finally, here is my page with all of the files I mentioned before.
https://www.androidfilehost.com/?w=files&flid=278786
Again, I do not take credit for anything in here other than organizing it. I do hope it helps you a lot like it did for me.