Related
I rooted my hero last night and tried out a few different ROMs but eventually decided to revert to stock and make some manual changes. I used nandroid to restore to just after the root (1.56.651.2). I was able to remove some apps using adb, but the adb remount command fails (permission denied), and I'm unable to push a new bootscreen on to the phone. I also tried a Root File Manager and pre-kitchen as alternatives for the bootscreen, and neither one works. The Root Manager won't paste the files from SD into /system/media/ and pre-kitchen just reboots the phone.
Any suggestions?
Any chance this has something to do with downloading only up to SDK Platform 1.5? I'm at a total loss. I RUU'd my phone, did a clean root at startup using adb shell, and I still have the same problem. The adb remount command won't work, and I can't push anything into the system directory. For what it's worth, when I still had Root Manager installed I was able to toggle RO R/W in any directory with no problem, and I could move files around within the ROM... but I couldn't move anything into it from the SD. I'm new at this, so I have no idea what the problem might be. Anyone else had this problem or have any suggestions?
If anyone else runs into this problem, this solution worked for me:
adb shell
# su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system (Or any subdirectory you want to push to inside system)
# exit
adb push <local file> <device location>
Restore modified permissions when done.
Though I'm still not sure why this is necessary in place of adb remount.
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
dametzg said:
I'm pretty sure the adb remount command will not work on the stock rom. You should be able to do it with just this command instead:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Click to expand...
Click to collapse
Thanks... didn't realize stock wouldn't accept adb remount. If I use the above line from within shell, that doesn't help me push anything on to the phone though... so I needed to enable global permission and then do the push. Oddly enough I tried the same approach last night using Root Manager, and the transfer from SD still failed, even after I applied 777 to the dir I was trying to modify. The current solution may be kind of tedious, but at least it works.
you really shouldn't do 777 on your filesystem, ANY app can then write to your system, overwrite things, or install malicious code. Just remount manually and you should be able to push anything you want, just remember that w/ the stock rom you also don't get a full busybox either.
I'm not positive, but I would think after you remount, you should be able to "adb push" to /system. I suppose it might be specific to that shell, but I would think not.
You just may have to do it once each time you boot your phone.
Edit - err nevermind... you're having permission errors.... um... change adbd on the phone to run as root? not sure how off the top of my head...
Im working with Andrizoid atm at seeing if we can get some progress on his Ubuntu project. Heres the issue.
Code:
busybox mount -o --bind ./dev/pts /data/local/ubuntu/dev/pts
mount: cannot read /etc/fstab: No such file or directory
In doing a little research I came across this
If there is no entry for /dev/fd0 in my fstab when I issue the command above, mount gets very confused because it doesn't know where to mount the floppy.
Click to expand...
Click to collapse
This come from http://www.tuxfiles.org/linuxhelp/fstab.html which gives a quick breakdown of what the etc/fstab file is. When i went exploring I couldnt find an etc/fstab
Code:
[B]
mount: cannot read /etc/fstab: No such file or directory
[/B]
The thing about Android though...there IS NO /ETC/FSTAB file because its become obsolete.
The init program directly mounts all filesystems and devices using either hard-coded file names or device names generated by probing the sysfs filesystem (thereby eliminating the need for a /etc/fstab file in Android). After device/system files are mounted, init reads /etc/init.rc and invokes the programs listed there (one of the first of which is the console shell).
Click to expand...
Click to collapse
EDIT: Conclusion
After bouncing some ideas around, I've come to the conclusion that it HAS to be a Busybox issue.
An Android specific variation of Busybox should take into account the fact that there isnt an etc/fstab file. The fact that these commands work on other phones leads me to think that its an Eris specific issue. If anyone remembers there were issues when using the Busybox available on the market on the Eris.
Looks like we need a Busybox update
es0tericcha0s said:
Or is there something else I can do?
Click to expand...
Click to collapse
Modify the mount command.
If the version of BusyBox is the Android version, report this issue (as a bug?). If it's the standard Linux BusyBox, the devs may not be interested. Or, if BusyBox is just calling the standard mount command, then it's not a BusyBox issue for them to worry about.
hallstevenson said:
Modify the mount command.
If the version of BusyBox is the Android version, report this issue (as a bug?). If it's the standard Linux BusyBox, the devs may not be interested. Or, if BusyBox is just calling the standard mount command, then it's not a BusyBox issue for them to worry about.
Click to expand...
Click to collapse
I'm using the Android Busybox, and those commands are being executed in an adb shell so I doubt that its calling the standard mount command-it should be calling the (hopefully) Android specific mount command. The things thats confusing me is that those same commands worked just fine for other phones. I dont see why I would get an error and others would have no issue with it?
EDIT:
And if you ave any recommendations for what I should modify the mount command to, let me know.
You mention a reference to /dev/fd0 but I'm 99.9% that's referring to the *nix mount command. The Android/BusyBox version should know better than to look for a floppy drive.
Where is BusyBox maintained ?
I did find a page about an Android ROM from Nov 2008 that mentions
- changed the "mount" symlink to be busybox's mount instead of toolbox's mount
- added an /etc/fstab file that busybox's mount can use, that lists the standard system partitions.
Click to expand...
Click to collapse
Is "mount" in fact an internal adb command ?
hallstevenson said:
You mention a reference to /dev/fd0 but I'm 99.9% that's referring to the *nix mount command. The Android/BusyBox version should know better than to look for a floppy drive.
Where is BusyBox maintained ?
I did find a page about an Android ROM from Nov 2008 that mentions Is "mount" in fact an internal adb command ?
Click to expand...
Click to collapse
The floppy drive reference was just from some background info I pulled on the etc/fstab file. I wasnt actually trying to mount a floppy disk
I have no idea where I would put in a bug report or anything. I know Stericson was the publisher of the BusyBox app thats avaiable on the market, but the one for the Eris is different anyways so idk if he could help.
Im not sure what you mean by your last statement, but mount is not a command that you can use in a shell on its own. You have to use busybox mount ...
If you can show me where you found that rom from I may be able to finish this. I was just talking to a buddy of mine about making my own /etc/fstab and slipping it in just so that the mount command would work. If theres already one put together then thats way less work for me
What I meant by referring to that info you found was that person couldn't have been talking about the Android version. I didn't think you were trying to mount a floppy.
You sure that there's no "adb mount" ? Look here, http://forum.xda-developers.com/showthread.php?t=517874. They refer to "adb shell mount".
Personally, I would just create an /etc/fstab file (I believe it can be empty) and see what happens.
hallstevenson said:
What I meant by referring to that info you found was that person couldn't have been talking about the Android version. I didn't think you were trying to mount a floppy.
You sure that there's no "adb mount" ? Look here, http://forum.xda-developers.com/showthread.php?t=517874. They refer to "adb shell mount".
Personally, I would just create an /etc/fstab file (I believe it can be empty) and see what happens.
Click to expand...
Click to collapse
well ive got an /ect/fstab file that i took from here http://www.android-devs.com/?p=152
Code:
# /etc/fstab: static file system information
#
# file system mount point type options dump pass
/dev/block/mmcblk0p2 / ext2 defaults 1 1
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /media/sdcard vfat defaults 0 0
But thats from a guide about debian on the N1 and the way they are doing it is much different from the method I'm using.
adb shell mount give the error that mount isnt found. it has to be called through busybox-at least in the instance that im using it in
Code:
busybox mount -o --bind /dev/pts /data/local/ubuntu/dev/pts
Hey guys. I've done commands in adb many times. I'm still new to it, but I never remember having this issue.
I've ran CM6 for months, and nightly's as well. I'm running a custom compiled CM6 right now though.
adb remount I get
remount failed, operation not permitted.. and in default.prop ro.secure is set to 1. I changed to 0 but still can't do remount. Any other suggestions?
Thanks!
For a workaround, try remounting through shell - mount -o rw,remount /system, or the full command (mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system).
is that a temporary fix, or for good. or just a work around?
Just a workaround. It's a command in OS itself that does the same job as "adb remount" - which is, remounts.
I just can't think of anything that would cause adb remount to fail, so I have no suggestions for you to try. But in case you want to be able to do something without getting stuck, and wait for the solution without being in a hurry - I've posted the workaround.
I don't have a solution to solve it once and for all, but every time you want to remount, use
PHP:
adb root
before your commands
excellent.
adb root
adbd is being restarted
adb remount succeeded .
Thanks dude! that will work for now til cooker fixes that. lol
Jack_R1 said:
For a workaround, try remounting through shell - mount -o rw,remount /system, or the full command (mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system).
Click to expand...
Click to collapse
Tried this and it appeared to succeed but I didn't get the results I wanted.
After doing this I tried push c:\com.amazon.mp3.apk \system\app\ and it repeated it back to me, but when I look in that directory, it's not there. What am I doing wrong?
Wrong direction of slashes:
push c:\com.amazon.mp3.apk /system/app/
And you shouldn't be doing it from the ADB shell. The remount is done in the shell, the push is done outside of it.
Jack_R1 said:
Wrong direction of slashes:
push c:\com.amazon.mp3.apk /system/app/
Click to expand...
Click to collapse
Ahhhh, I was wondering about that! Thank you!!
And you shouldn't be doing it from the ADB shell. The remount is done in the shell, the push is done outside of it.
Click to expand...
Click to collapse
So once I perform the remount I exit out of the shell?
operation not permitted.
"adb push" gets you "not permitted"?
try "adb root" first, as suggested above.
Jack_R1 said:
"adb push" gets you "not permitted"?
try "adb root" first, as suggested above.
Click to expand...
Click to collapse
adb root gets me something along the lines of "not supported on a stock build."
EDIT
ok...
adb shell
su
mount -o rw,remount /system
then i get this:
Usage: mount [-r] [-w] [-o options] [-t type] device directory
So it appears it's not actually registering the command?
Then I try
push c:\com.amazon.mp3.apk /system/app/
and I get: failed to copy 'c:\com.amazon.mp3.apk' to '/system/app/com.amazon.mp3.apk' : Read-only file system.
You need to use the full command, since you're running sh, not bash.
Look for the full command in my post.
Yes, currently it doesn't do a thing.
Jack_R1 said:
You need to use the full command, since you're running sh, not bash.
Look for the full command in my post.
Yes, currently it doesn't do a thing.
Click to expand...
Click to collapse
So I tried the full command and exited out to "dos" command prompt and tried again. This time I got "failed to copy.... ....permission denied."
Ok, try without exiting. I'm not sure it'll do anything useful, though.
There is some problem with either your ADB setup or the ROM you're using. Or you're just not rooted.
Jack_R1 said:
Ok, try without exiting. I'm not sure it'll do anything useful, though.
There is some problem with either your ADB setup or the ROM you're using. Or you're just not rooted.
Click to expand...
Click to collapse
Found another thread on another board. I just flashed amon ra's recovery and booted up from there, and it appeared to let me copy!
But then it wouldn't let me cd to system/app. It let me cd to system, but not to app. Weird... I booted back up and there's no evidence of the "copied" apk, anywhere.
What...
the...
****.
Thanks to all for your patience with my super-noobish ass, I'm hoping you're not as frustrated with me as I am with this.
When you're in the recovery, your system isn't mounted. You need to mount it first.
Use almost the same command as for remount, but leave out the "remount" option. Just "-o rw".
Your copy went to void.
Jack_R1 said:
When you're in the recovery, your system isn't mounted. You need to mount it first.
Use almost the same command as for remount, but leave out the "remount" option. Just "-o rw".
Your copy went to void.
Click to expand...
Click to collapse
lol, awesome, thanks. I'll fiddle with it some more in the morning.
Why isn't there a link somewhere to a simple instruction manual? It would be so much easier if I could read up on this myself without bugging all of you guys.
Of course there is. My sig has it in bold, and you can find everything there. It's just that people tend to rush asking questions instead of reading
Jack_R1 said:
Of course there is. My sig has it in bold, and you can find everything there. It's just that people tend to rush asking questions instead of reading
Click to expand...
Click to collapse
I've seen a couple of the basic noob guides to adb and I've seen the google definition of adb functions but it doesn't include instructions on how to do the stuff you're walking me through.
Will take a look at those links shortly. Btw, I'm on a MT3G though I don't think that makes a difference at this level.
The actual creation of an arm linux chroot image is probably out here on teh internetz somewhere, but I can assist with my mounting shell script (which works).
My image is of a debian arm chroot, and the image filesystem is ext2 (a good idea for fewer writes. ie innately non-journaling), has been used extensively on fw DE .17 and I'm currently trying it out on WW .29 (thank you, miloj).
I would upload my debian img somewhere, but I've actually broken it somewhat (it works for my needs, but it's nonetheless a bit too hacked up to be reliable).
I've modified it somewhat for generalization, some of it is probably wrong and/or redundant, and it IS hackish and ugly, but it works for me (tm).
* the chroot image only need a root account (and probably bash installed, but it usually is)
* You need busybox installed.
* You need to upload your chroot image named linux.img to the internal sdcard in a folder named linux
A shell script to set things up is attached.
What you need to do:
push the install script and run it:
Code:
adb push installlinuxstuff.sh /data/local/
adb shell sh /data/local/installlinuxstuff.sh
Now you can (from adb shell or terminal emulator on device):
Code:
su -
/data/local/mnt/linux.sh
/data/local/mnt/notlinux.sh
Feel free to remove the install script at
/data/local/installlinuxstuff.sh
when you've got it up and running.
Alternative way to run the scripts from adb shell:
Code:
adb shell su -c /data/local/mnt/linux.sh
adb shell su -c /data/local/mnt/notlinux.sh
I usually symlink start and stop (in my case deb and undeb) shell scripts placed in /data/local/mnt in /system/bin (ie shell scripts with 'su -c /data/local/mnt/whatever.sh' in them) for easy start an stop from terminal emulator, and if you've gotten this far you may welcome the small advice. (in other words - don't do this unless you _really_ know what you're doing)
Debian ARMHF or ARMEL?
If you would uploaded it (good place is google drive , sharing as public, as there are no ads or bull**** and the download is extremely fast) I would love to try your image - after modifying your script so it can work on a UHS-1 class MicroSD I want to try running this off of (should give it a little more speed).
zamaditix said:
Debian ARMHF or ARMEL?
If you would uploaded it (good place is google drive , sharing as public, as there are no ads or bull**** and the download is extremely fast) I would love to try your image - after modifying your script so it can work on a UHS-1 class MicroSD I want to try running this off of (should give it a little more speed).
Click to expand...
Click to collapse
Armel (I use the same chroot installation on my phone in a smaller image file (with less stuff installed)). I've got loads of personal stuff all over it and besides - it's somewhat broken. I really don't want to try to fix it.
So I'm working on retracing my steps, creating a clean armhf ext2 image (debian wheezy base installation for now) and redo the mount script, but I can't make any promises on a release date.
Anyhu - there are loads of images (armel, at least) on teh internetz (BT5 and too many ubuntu, for instance).
Just check so our kernel can mount the filesystem.
Edit: if not you can just create a new image file with a filsystem that's mountable and copy the chroot files to it.
So the ideal image for this tablet is armhf? If I wanted to create a Gentoo image, I would go with armv7? I'm just not sure exactly which ARM architecture this tablet is.
EndlessDissent said:
So the ideal image for this tablet is armhf? If I wanted to create a Gentoo image, I would go with armv7? I'm just not sure exactly which ARM architecture this tablet is.
Click to expand...
Click to collapse
The CPU is the Tegra 3 if you want to google it and it is an ARMv7 w/ NEON extensions chip. ARMv7 specification requires hardware fp so naturally it is ARMhf.
Nice to hear, keep us updated on your progress. I'm currently running an armel copy of Ubuntu 12.04 but it has problems with some packages and others are armhf only.
When I run linux.sh, I get an error that /sdcard can't be mounted because it doesn't exist.
Code:
mount: mounting /sdcard on /data/local/mnt/linux/sdcard failed: No such file or directory
I also tried changing the script to mount /mnt/sdcard, but that didn't work either.
EndlessDissent said:
When I run linux.sh, I get an error that /sdcard can't be mounted because it doesn't exist.
Code:
mount: mounting /sdcard on /data/local/mnt/linux/sdcard failed: No such file or directory
I also tried changing the script to mount /mnt/sdcard, but that didn't work either.
Click to expand...
Click to collapse
Yes, it is somewhat hackish, like I wrote. My image has got an sdcard folder (/sdcard) inside of it where I mount /sdcard from android. (Ie chroot and mkdir /sdcard)
followed this:
http://androlinux.com/android-ubuntu-development/how-to-install-ubuntu-on-rooted-transformer-prime/
make sure you have busybox installed der. Or at least the cp command in /system/bin
works well on my TF300T, Yea its not native but im currently configuring it for kernel building ;-D
FlyingPoo said:
followed this:
http://androlinux.com/android-ubuntu-development/how-to-install-ubuntu-on-rooted-transformer-prime/
make sure you have busybox installed der. Or at least the cp command in /system/bin
works well on my TF300T, Yea its not native but im currently configuring it for kernel building ;-D
Click to expand...
Click to collapse
Why does the mount script remount a non-existing block device with an ancient (according to android) filesystem?
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Edit: I read all the scripts, and they all mount that crap. It's not made for transformers, and on the android device it's made for it leaves /system mounted rw after you've run it, and WHEN run (installed) it modifies too much in /system/bin
Code:
# At first it copies loads of crap to /system/bin, and then:
cd /system/bin/
chmod 4777 *
It's not even "hackish" - it's just... wrong...
Will loop1 work every mount?
Code:
mknod /dev/loop1 b 7 0
losetup /dev/block/loop1
I'm almost only asking, since this thread was supposed to be about scripts?
gasingvar said:
Yes, it is somewhat hackish, like I wrote. My image has got an sdcard folder (/sdcard) inside of it where I mount /sdcard from android. (Ie chroot and mkdir /sdcard)
Click to expand...
Click to collapse
Thanks. I created /sdcard, and it works almost perfectly now. However, mounting devpts at /dev/pts doesn't seem to work. I replaced that line with
Code:
mount --bind /dev $mnt/dev
and it seems to work fine. Is there anything wrong with my method?
/dev/void said:
Why does the mount script remount a non-existing block device with an ancient (according to android) filesystem?
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
Edit: I read all the scripts, and they all mount that crap. It's not made for transformers, and on the android device it's made for it leaves /system mounted rw after you've run it, and WHEN run (installed) it modifies too much in /system/bin
Code:
# At first it copies loads of crap to /system/bin, and then:
cd /system/bin/
chmod 4777 *
It's not even "hackish" - it's just... wrong...
Will loop1 work every mount?
Code:
mknod /dev/loop1 b 7 0
losetup /dev/block/loop1
I'm almost only asking, since this thread was supposed to be about scripts?
Click to expand...
Click to collapse
I'm assuming you're talking about the link in the post you quoted, even though you seem to be referencing the OP's use of the word "hackish". The script in the OP doesn't do any of that stuff. It just creates a few directories in /data/local/mnt/ and writes the mount/unmount scripts, which themselves only un/mount appropriate directories for the tablet. As for your question, I'm not nearly experienced enough to answer it. Sorry.
EndlessDissent said:
Thanks. I created /sdcard, and it works almost perfectly now. However, mounting devpts at /dev/pts doesn't seem to work. I replaced that line with
Code:
mount --bind /dev $mnt/dev
and it seems to work fine. Is there anything wrong with my method?
Click to expand...
Click to collapse
AFAIK your mount seems to be more complete, ie more android hardware goodies accessable from the chroot environment. However - that means more things possibly going wrong (like writing to a device who's critical to the android environment).
Personally I'd try to find what "hardware goodies" and whatnot I'd need to get the chroot environment working optimally, and not mount ALL of /dev.
EndlessDissent said:
I'm assuming you're talking about the link in the post you quoted, even though you seem to be referencing the OP's use of the word "hackish". The script in the OP doesn't do any of that stuff. It just creates a few directories in /data/local/mnt/ and writes the mount/unmount scripts, which themselves only un/mount appropriate directories for the tablet. As for your question, I'm not nearly experienced enough to answer it. Sorry.
Click to expand...
Click to collapse
Yes, and the OP is very honest about his script(s) being "hackish", which I interpret to mean 'not optimal, possibly redundant but working', all of which it is (and I applaud the early release, since for instance I could get things rolling), but the ubuntu image installation and mounting scripts from the other poster ( whom I was addressing ) are plain faulty.
I am looking for a armhf build of ubuntu or debian that I can chroot (newer the better), if anyone knows of such a build that would be fantastic but if not does anyone know of an easy to follow guide to compile such a thing?
I found two pretty good guides. I mostly followed THIS ONE, but I found that it doesn't mount enough before "first boot", so what I did was follow the guide until the point where you move the image to the tablet. Then I ran the OP's installlinux.sh script, and then the mount script. However, the mount/unmount scripts need to be edited before using them. Comment out the sdcard line and probably the devpts line (mounting devpts didn't work; Bash complained that devpts didn't exist; I had to replace it with the line I mentioned a few posts above, but as /dev/void says, it could be problematic, so be careful). Mount the image, make the /sdcard directory, exit, unmount, and edit the scripts again to mount/unmount /sdcard.
Next time you enter the chroot, feel free to run the
Code:
sh /debootstrap/debootstrap --second-stage
command to build the image, and follow the linked guide until the next time it tells you to exit the session (NOTE: The second echo "whatever" > sources.list command is wrong; it should be echo "whatever" >> sources.list; Also, remember to replace "squeeze" with the appropriate Debian version, in my case, "testing"). Instead of exiting right after the apt-get update, I'd recommend playing around with the chroot and configuring whatever apps you install. You can just use the OP's scripts now and ignore the script in the linked guide.
When the guide I linked above gets to this line:
Code:
sudo debootstrap --verbose --arch armel --foreign squeeze /mnt/squeeze/ http://ftp.debian.org/debian
just replace armel with armhf, and if you want a testing image, replace squeeze with testing.
Sorry I'm not attaching my image. I made it gigantic (5GB), so I don't really have anywhere to store it, and you probably wouldn't want to download a file that big. Plus, it already has Openbox and a bunch of other things you probably don't want installed. I'm assuming you'd want GNOME or KDE instead.
I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app
look for the error message in /cache/recovery/recovery.log
If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....
This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app
OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.
I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks
The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck
Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks