[SOLVED] Unbricked! ('build.prop' mess; 'su' fails with EPERM ) - Kindle Fire HDX 7" & 8.9" Q&A, Help & Troubleshoot

See the next post for a solution.!
BACKGROUND
OK. So, I had an HDX 8.9 with 14.3.2.6 all setup with towelroot, HDXposed, gapps, play store, etc.
I used to have SafeStrap on this also, but I kept running out of space; so, I got rid of it:- a foolish idea, no doubt.
Even without a ROM slot, I may have had a better chance at recovering using the built-in shell... Oh, well...
THE DEED [**SCARY**]
I was trying to follow this excellent guide -without thinking too much- )
Or, closer to the truth, I thought: I have root and I won't mess with the boot process; so, what could possibly go wrong?
So, I modded my build.prop:
Code:
>>> diff build.prop.orig build.prop
25,26c25,28
< ro.product.model=KFAPWI
< ro.product.brand=Amazon
---
> #ro.product.model=KFAPWI
> #ro.product.brand=Amazon
> ro.product.model=SM-G900F
> ro.product.brand=Samsung
32c34,35
< ro.product.manufacturer=Amazon
---
> #ro.product.manufacturer=Amazon
> ro.product.manufacturer=Samsung
AND, I also forgot to adjust permissions on the new build.prop.
Code:
[email protected]:/system $ ls -l /system/build.prop*
-rw-rw-rw- root root 5561 2014-12-14 14:52 build.prop
-rw-r--r-- root root 5475 2014-09-09 03:53 build.prop.orig
I rebooted and got a nasty surprise: not only does the screen go black after the grey Kindle Fire logo (which wasn't too surprising), but su fails as well with exit code 1 (EPERM :- permission denied)
Code:
>>> adb shell
[email protected]:/ $ su
1|[email protected]:/ $ ls -al /system/xbin/su
-rwsr-sr-x root root 71264 2014-11-27 16:00 su
Permissions on the binary look OK (the same as in my backup image).
In fact, su will run with the '-v' (or '-h') option, but seems to EPERM when trying to exec another command.
Code:
[email protected]:/ $ su -v
2.35:SUPERSU
STATUS
I do have a backup of the original build.prop.
I also made images of all the 20-something MMC partitions using dd.
The "brick" has adb access, and fastboot seems to work as well.
Unfortunately, the more obvious workarounds such as adb remount or fastboot boot KERNEL MODDED-RAMDISK do not help.
Interestingly, fastboot boot downloads the image before bailing out with "boot not allowed on locked hw" (or something very similar),
which _may_ (?perhaps?) allow for overflowing a buffer by messing with the fastboot protocol.. (just speculating)
While writing this up, I also tried to flash the backup of my system partition.
Code:
>>> fastboot -i 0x1949 flash system system.img
target reported max download size of 1073741824 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.020s]
sending sparse 'system' (1032534 KB)...
OKAY [ 32.464s]
writing 'system'...
FAILED (remote: flashing not allowed for locked hw)
finished. total time: 32.536s
Not only did this not work, it also got me fairly nervous as it claimed to have erased the system partition.
Luckily, that did not happen. After rebooting, the situation is the same: everything's still there, but su fails.
QUESTIONS
Do wrong permissions on build.prop alone result in such weird behavior? Or, is it more likely that the changes in content caused the lockdown?
Does 'factory reset' (from the recovery screen) fix anything in the system partition? Or, is that the same thing as Factory Reset in Settings, which clears userdata?
All the unbricking guides (specifically for build.prop mistakes) I've seen so far are based a working su. Are there other options/exploits that could be useful?
Any chance that re-rooting might help? And, in that case, does anybody know about an adb-friendly rooting method for 14.3.2.6?
Any ideas I could try to unbrick my HDX?

Answers to my questions follow....
UNBRICKING
Learn about ghettoroot in this thread.
Code:
>>> wget 'http://forum.xda-developers.com/attachment.php?attachmentid=2924899&d=1409874318' -O ghettoroot-v0.2.2.zip
>>> unzip ghettoroot-v0.2.2.zip
>>> adb push ghettoroot/files/ghettoroot /data/local/tmp
>>> adb shell
[email protected]:/ $ cd /data/local/tmp
[email protected]:/ $ chmod 0755 ghettoroot
[email protected]:/ $ ./ghettoroot -n -m "1337 0 0 0 4 0" /system/bin/sh
# chmod 0644 /system/build.prop
# reboot
ANSWERS
Do wrong permissions on build.prop alone result in such weird behavior? Or, is it more likely that the changes in content caused the lockdown?
-- As it should be evident from the solution above, this whole nightmare was the result of the permissions being wrong; my HDX boots fine with the changed content.
Does 'factory reset' (from the recovery screen) fix anything in the system partition? Or, is that the same thing as Factory Reset in Settings, which clears userdata?
-- Thankfully, I didn't have to try this, but I do suspect that both ways to trigger Factory Reset will have the same effect.
All the unbricking guides (specifically for build.prop mistakes) I've seen so far are based a working su. Are there other options/exploits that could be useful?
-- Well, most guides also explained that one might have to root the device first; my only issue was that the examples used old exploits that do not work on 14.3.2.6.
Any chance that re-rooting might help? And, in that case, does anybody know about an adb-friendly rooting method for 14.3.2.6?
-- In fact, this is the solution. As towelroot works on 14.3.2.6, I was trying to find a command-line version: that's what ghettoroot is.
Wonderfully over-engineered for just unbricking, and the modstring is preset to work on some obscure Samsung device, but a bit of fiddling is all that was necessary to get it to work on the HDX 8.9.
Any ideas I could try to unbrick my HDX?
-- As a matter of fact, I started to look into getting around the bootloader (as I though I had lost root for good), and I have a much better clue where/how to get started.
The only problem is that I'm not exactly high on free cycles... In any case, if and when I get some time, I'll be loading the aboot image into IDA Pro...
These two -not completely unrelated- blog posts got me all excited..

draxie said:
Any ideas I could try to unbrick my HDX?
-- As a matter of fact, I started to look into getting around the bootloader (as I though I had lost root for good), and I have a much better clue where/how to get started.
The only problem is that I'm not exactly high on free cycles... In any case, if and when I get some time, I'll be loading the aboot image into IDA Pro...
These two -not completely unrelated- blog posts got me all excited..
Click to expand...
Click to collapse
Last I heard, Dan's TrustZone exploit won't do any good for our devices.

EncryptedCurse said:
Last I heard, Dan's TrustZone exploit won't do any good for our devices.
Click to expand...
Click to collapse
Fair enough. No point wasting time on that track then...
Just out of curiostiy, I ran strings on my aboot image (tha's the level of complexity I had time for)
and got a few -for me- new and interesting tidbits such as evidence of embedded public keys (expected)
Code:
Production Kernel Key1
Lab1261
Amazon1
Lab126 Root CA 10
Engineering Key1
Lab1261
Amazon1 0
Lab126 Tablet Root CA 10
Unlock Key1
Lab1261
Lab126 Bootchain CA0
and possible indications of a "native" unlock command:
Code:
Unlock code is correct
Unlock code is NOT correct
unlock_code
Of course, any unlock code is likely to be signed by the privare part of that "Unlock Key",
but there's hope that signature checking may be broken..
Wishful thinking, I know, but given that little kernel itself was vulnerable to an RSA padding attack (CVE-2014-0973),
I'd at least check if something similar might work for a "supported" unlock method (if such a thing now exists).
BTW, any clue if said padding attack may apply to our slate? All three public keys listed above have exponent 3 (see attachment); so, that part -at least- is fine. (-;
I'm not too inclined to test this as I'm unsure how I'd recover from a low-level boot error without a sane recovery partition...

Related

Manual rooting - cannot mount /system as read/write

I have researched xda and the web for my problem, but it seems to be different from other posters.
I bought a Nextbook Premium 7 with Android 2.3.1 and wanted to root it. Another user already mentioned hack apps like Gingerbreak, superoneclick and z4root did not work, therefore I thought I would try the manual rooting method from the guide below:
http://www.nexusoneforum.net/forum/nexus-one-development-hacking/10940-simple-sdk-setup-guide.html
I pushed Gingerbreak and ran it using ADB, and it was successful granting temporary root. However, in the next step when I tried to remount /system as read/write (in order to install Superuser), it did not work - this step was:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
After executing this, I DID NOT get any error message like other posters (eg. NO "remount failed: operation not permitted").
However, when I tried to execute the next part:
chmod 777 /system/bin (or chmod 777 /system/app)
I got an error message: "Read-only file system".
This tablet has a Rockchip rk2918 processor and Android 2.3.1, otherwise I know nothing about it. The company (nextbookusa.com) does not have any firmware support on this model yet.
Can anyone help? Thanks.
More research on the web makes me suspect this tablet uses cramfs file system, because I've seen "cramfs" coming up in other similar 7 inch rk2918 tablets.
I understand it is common for chinese tablets with similar hardware to have similar basic Android OS, which is modified by the brand owner in their own specific models.
Apparently cramfs is read-only. I can only find one post where the poster successfully rooted the device by unpackaging the firmware, added Superuser, repackaged it and re-install it (as a firmware update) like a "custom(ised) ROM".
I guess until Nextbook issues firmware update on their website to unpackage and add root, there is no way to do it now.
Also RK2918
I've just bought a GoogleTv box with RK2918. I know that there's cramfs on it. I have a firmware from the producer. Any tips or trix on howto root it?
I received a RK2918 WOPAD 9.7 with a built in 3G and I have same issue can't mount system as RW. No messages but get access denied. Busybox is installed in /system/bin and GingerBreak ran fine and gave proper message when completed.
Just can't copy Superuser.apk because I have no write access. This is alot different than the GTAB. I can see the # prompt # and I can see files and dirs I make are root - but not access to Superuser.apk to allow other programs to write.
Any help would be appreciated. Also when I use busybox whoami I get the following:
# busybox whoami
whoami: unknown uid 0
Prior to me doing it the manual root method - I used Z4root and UniversalAndroot - no success.
As far as me thinking I have some root access I did the following:
# cd /data/local/
# ls
tmp
# ls -l
drwxrwx--x shell shell 2011-09-12 17:31 tmp
# su
# ls -l
drwxrwx--x shell shell 2011-09-12 17:31 tmp
# mkdir test
# ls -l
drwxrwx--x shell shell 2011-09-12 17:31 tmp
drwxrwxrwx root root 2011-09-12 18:23 test
apparently I have root access but can't execute the remount command or that block in not writable while system is up - but not sure.
Anyhelp would be appreciated!
sorry for bad english, the issue seems to be in boot ini and recovery mode, i had the same issue on a tab rk 2918, you can only unpack then repack after modifying anything you want, but not mount on rw.
has anyone tried zergRush root method for this tablet yet?????
I tried using SuperOneClick's zergRush on my WoPad i7. Same results.
dicksoft said:
I've just bought a GoogleTv box with RK2918. I know that there's cramfs on it. I have a firmware from the producer. Any tips or trix on howto root it?
Click to expand...
Click to collapse
Hello, I also have an rk2918 tvbox. I succesfully rooted it and prepared a custom rom..
you can check if you have my same box and download the rom my site.. you can find it searching "clamelmod" with google..
Converting cramfs to ext3
You will need to convert the cramfs to ext3, check the instructions described at:
google for "google sites rk2918tools", 1st link.
Let me know if it worked.
hey do you know how to put ics on this rk2918 box?

Rooting F-01D : Fujitsu Arrows TAB

Just in case someone is
This page details how to root the Fujitsu Arrows TAB F-01D.
http://arrowstab-f01d.blogspot.com/2012/03/easy-rooting-toolkit-for-arrows-tab-f.html
it works.
Now if only somebody can post the firmware updates..
English instructions
Well, with some help from Google Translate and some creative interpretations, I managed to do this and thought I'd provide some English instructions for others (with some added comments)
DISCLAIMER: AS USUAL, YOU SHOULD KNOW THAT FOLLOWING THESE ACTIONS (AND ESPECIALLY FOLLOWING THEM INCORRECTLY) CAN BRICK YOUR DEVICE (I.E. YOUR DEVICE WILL STOP WORKING, POSSIBLY PERMANENTLY). I AM NOT RESPONSIBLE FOR ANY DAMAGES THAT MAY ARISE FROM YOU FOLLOWING THESE INSTRUCTIONS, YOU DO SO AT YOUR OWN RISK.
Downloads
1. Windows -- the Arrows TAB USB driver Download.
2. Easy rooting toolkit (ERT) for Arrows Tab F-01D (ver 1.0) Download
3. goroh_kun's lsm_disabler.ko Download
Info
4. A su binary, such as the one found in DooMLoRD_v3_ROOT-zergRush-busybox-su.zip
5. Android SDK platform tools. adb(.exe) (and in Windows, specifically: AdbWinApi.dll, AdbWinUsbApi.dll)
Preparation
1. Unzip ert4F01D.zip, and in the subdirectory 'files' place:
* adb.exe (Windows only, from step 4 above)
* AdbWinApi.dll (Windows only, from step 4 above)
* AdbWinUsbApi.dll (Windows only, from step 4 above)
* lsm_disabler.ko (from step 3 above)
* su (from step 5 above)
2. Before connecting the USB, in Settings -> Applications -> Development:
* Check (tick) USB debugging ("Debug mode when USB is connected")
* Check (tick) Stay awake ("Screen will never sleep while charging")
3. Set up the USB drivers and Android Development stuff if you haven't already. I don't use Windows so can't help with this.
The Dirty Work
At this stage, you can run the batch file. Since I don't use Windows, I did the steps by hand, so you'll have to correlate your actions appropriately (I can't read Japanese either, so your guess is as good as mine ).
1. On your PC:
adb shell "mv /data/local/calib.dat /data/local/calib.dat_"
adb shell "ln -s /data/local.prop /data/local/calib.dat"
2. On the tablet, go into Google Maps, touch the GPS icon ("locate me" icon) on the top right hand corner, and then touch the BACK key to exit.
3. On your PC:
adb shell "echo ro.kernel.qemu=1 > /data/local.prop"
adb shell "rm /data/local/calib.dat"
adb shell "mv /data/local/calib.dat_ /data/local/calib.dat"
adb reboot
5. Once the device has fully rebooted, on your PC:
adb shell "mkdir /data/local/lib"
adb push files\lsm_disabler.ko /data/local/lib/
adb shell "insmod /data/local/lib/lsm_disabler.ko"
adb shell "mkdir /data/local/bin"
adb shell "echo '#!/system/bin/sh' > /data/local/bin/autoexec.sh"
adb shell "echo '/system/xbin/soff' >> /data/local/bin/autoexec.sh"
adb shell "chmod 755 /data/local/bin/autoexec.sh"
adb shell "mount -o rw,remount /system /system"
adb shell "ln -s /data/local/bin/autoexec.sh /system/etc/install-recovery.sh"
adb push files\su /system/xbin/
adb shell "chown root.root /system/xbin/su"
adb shell "chmod 06755 /system/xbin/su"
adb shell "echo insmod /data/local/lib/lsm_disabler.ko > /system/xbin/soff"
adb shell "chmod 755 /system/xbin/soff"
adb shell "mount -o ro,remount /system /system"
adb shell "echo > /data/local.prop"
6. I think at this point I was just meant to exit the lock screen.
7. adb reboot
8. Congratulations. You're now rooted. Go to the Play Store and download "Superuser" (by ChainsDD) and "BusyBox" (by Stericson). If you decide to buy BusyBox Pro, do not check the "symlinks" option in version 8.0, otherwise it's game over (no wifi, no adb shell, no root, no remount). It's a pain, but not impossible to repair this situation, see http://forum.xda-developers.com/showthread.php?p=26964465. I've emailed the author and I hope future versions won't trash the system so easily.
After all this, I'd suggest download Titanium Backup for Root users, backing everything up, and uninstall the all the bloatware that came with the device. Read up elsewhere about Titanium Backup.
Let me know if this helped you! Not sure how many other English speakers are using this device
Thank you for this wonderful post! A few questions:
1.) I use the F-01D but I don't live in Japan. One of the gripes I've been having about this tablet is that there doesn't seem to be anyway for me to get firmware updates unless I go there. Once rooted am I able to use Market Enabler to fake a carrier and update my tablet?
2.) This is slightly off on a tangent but since I can't find much English material about this tablet anway I might as well ask here. Another one of my gripes about the tablet is it doesn't seem to handle video very well. even 720p video doesn't play smoothly on it. On most of the software I download, it seems hardware acceleration is not enabled? Is this a hardware issue, or is it blocked by the software. And if the latter would rooting the tablet help resolve this issue; or is there any other solution? From what I've read the OMAP processor in this thing should easily be able to handle 1080p video right?
Many thanks! :good:
Kinslayer81 said:
Well, with some help from Google Translate and some creative interpretations, I managed to do this and thought I'd provide some English instructions for others (with some added comments)
DISCLAIMER: AS USUAL, YOU SHOULD KNOW THAT FOLLOWING THESE ACTIONS (AND ESPECIALLY FOLLOWING THEM INCORRECTLY) CAN BRICK YOUR DEVICE (I.E. YOUR DEVICE WILL STOP WORKING, POSSIBLY PERMANENTLY). I AM NOT RESPONSIBLE FOR ANY DAMAGES THAT MAY ARISE FROM YOU FOLLOWING THESE INSTRUCTIONS, YOU DO SO AT YOUR OWN RISK.
Downloads
1. Windows -- the Arrows TAB USB driver Download.
2. Easy rooting toolkit (ERT) for Arrows Tab F-01D (ver 1.0) Download
3. goroh_kun's lsm_disabler.ko Download
Info
4. A su binary, such as the one found in DooMLoRD_v3_ROOT-zergRush-busybox-su.zip
5. Android SDK platform tools. adb(.exe) (and in Windows, specifically: AdbWinApi.dll, AdbWinUsbApi.dll)
Preparation
1. Unzip ert4F01D.zip, and in the subdirectory 'files' place:
* adb.exe (Windows only, from step 4 above)
* AdbWinApi.dll (Windows only, from step 4 above)
* AdbWinUsbApi.dll (Windows only, from step 4 above)
* lsm_disabler.ko (from step 3 above)
* su (from step 5 above)
2. Before connecting the USB, in Settings -> Applications -> Development:
* Check (tick) USB debugging ("Debug mode when USB is connected")
* Check (tick) Stay awake ("Screen will never sleep while charging")
3. Set up the USB drivers and Android Development stuff if you haven't already. I don't use Windows so can't help with this.
The Dirty Work
At this stage, you can run the batch file. Since I don't use Windows, I did the steps by hand, so you'll have to correlate your actions appropriately (I can't read Japanese either, so your guess is as good as mine ).
1. On your PC:
adb shell "mv /data/local/calib.dat /data/local/calib.dat_"
adb shell "ln -s /data/local.prop /data/local/calib.dat"
2. On the tablet, go into Google Maps, touch the GPS icon ("locate me" icon) on the top right hand corner, and then touch the BACK key to exit.
3. On your PC:
adb shell "echo ro.kernel.qemu=1 > /data/local.prop"
adb shell "rm /data/local/calib.dat"
adb shell "mv /data/local/calib.dat_ /data/local/calib.dat"
adb reboot
5. Once the device has fully rebooted, on your PC:
adb shell "mkdir /data/local/lib"
adb push files\lsm_disabler.ko /data/local/lib/
adb shell "insmod /data/local/lib/lsm_disabler.ko"
adb shell "mkdir /data/local/bin"
adb shell "echo '#!/system/bin/sh' > /data/local/bin/autoexec.sh"
adb shell "echo '/system/xbin/soff' >> /data/local/bin/autoexec.sh"
adb shell "chmod 755 /data/local/bin/autoexec.sh"
adb shell "mount -o rw,remount /system /system"
adb shell "ln -s /data/local/bin/autoexec.sh /system/etc/install-recovery.sh"
adb push files\su /system/xbin/
adb shell "chown root.root /system/xbin/su"
adb shell "chmod 06755 /system/xbin/su"
adb shell "echo insmod /data/local/lib/lsm_disabler.ko > /system/xbin/soff"
adb shell "chmod 755 /system/xbin/soff"
adb shell "mount -o ro,remount /system /system"
adb shell "echo > /data/local.prop"
6. I think at this point I was just meant to exit the lock screen.
7. adb reboot
8. Congratulations. You're now rooted. Go to the Play Store and download "Superuser" (by ChainsDD) and "BusyBox" (by Stericson). If you decide to buy BusyBox Pro, do not check the "symlinks" option in version 8.0, otherwise it's game over (no wifi, no adb shell, no root, no remount). It's a pain, but not impossible to repair this situation, see http://forum.xda-developers.com/showthread.php?p=26964465. I've emailed the author and I hope future versions won't trash the system so easily.
After all this, I'd suggest download Titanium Backup for Root users, backing everything up, and uninstall the all the bloatware that came with the device. Read up elsewhere about Titanium Backup.
Let me know if this helped you! Not sure how many other English speakers are using this device
Click to expand...
Click to collapse
Just wanted to say thank you again. The rooting worked perfectly, though it took me a while to manually type in all the commands. For people who want to try this, you do need to install busybox before any other programs such as rootchecker will properly verify that your device is actually rooted.
And just for anyone wondering - rooting and using MarketEnabler has NOT been able to resolve the issue of not being able to update the software overseas...
Hey, sorry for the late reply, busy times :>
Glad the post helped you! I know I was super amped to finally get rood and get rid of all the bloatware I couldn't even understand. Things have definitely been a lot smoother since then (but far from perfect, also dying for an ICS upgrade). As for your questions:
simzhewei said:
1.) I use the F-01D but I don't live in Japan. One of the gripes I've been having about this tablet is that there doesn't seem to be anyway for me to get firmware updates unless I go there. Once rooted am I able to use Market Enabler to fake a carrier and update my tablet?
Click to expand...
Click to collapse
From playing around, the requirements seem to imply that you *have to* upgrade via cellular data from a Docomo SIM card, and it can't be done via roaming, so yeah, it seems like you have to physically go to Japan to upgrade Your market enabler idea was a good one, but since you tried that (I'm assuming using the Docomo info), I guess the upgrade app is using a different source to check where you're at. Ultimately we need to somehow get hold of an update.zip (or other file) that can be run through the Recovery system (which does exist!).
2.) This is slightly off on a tangent but since I can't find much English material about this tablet anway I might as well ask here. Another one of my gripes about the tablet is it doesn't seem to handle video very well. even 720p video doesn't play smoothly on it. On most of the software I download, it seems hardware acceleration is not enabled? Is this a hardware issue, or is it blocked by the software. And if the latter would rooting the tablet help resolve this issue; or is there any other solution? From what I've read the OMAP processor in this thing should easily be able to handle 1080p video right?
Click to expand...
Click to collapse
Haven't tried 1080p, but after some tinkering I did get 720p playing. I use MX Player, and although they said it would download needed hardware decoders automatically, it didn't, and things improved a lot after I downloaded the MX Player ARMv7 codec. Video plays great, but to get sound, I had to run the sound through the software decoder (just tap the music note icon, and choose "Track #1 (S/W decoder)".
On the other hand, I found the hardware decoding often gets stuck (relaunching MX player just gives you a waiting indicator forever)... and the only way to fix it is a reboot. Since this happens quite often, it's incredibly annoying, and I'm hoping an upgrade will fix it. Let me know if this doesn't happen to you. Also have some very intermittent wifi issues, some things work fine (speedtest, etc) but apps like streaming radio, some work fine (spotify) and others don't work at all (di radio). Some things work fine for a while after a reboot.
---------- Post added at 10:02 AM ---------- Previous post was at 10:00 AM ----------
Incidentally, here's what happens if I try update via recovery (with no update files). Maybe it will help someone. Googling most of the stuff came up with nothing. The ** in the middle somewhere is stuff I couldn't read, guess I should go back and do it again but this is from quite a while ago.
Code:
C_L1_043
2.6.35.7
V19R36D
=======================
SD Downloader
=======================
Device SW Downloading...
Don't remove
the SD Card & the Battery.
checking battery
eMMC SD mount complete.
microSD mount complete.
Firm name :
Firm name :
Target:
Check eMMC(SD).
Firm name :
Update GANG file not found
File open error!
**ddl Touch Firm Write start
Firm name :
/external_sd/I2C_HSSP_Bridge_Parallel.cyacd file not found
firm name :
/sdcard/I2C_HSSP_Bridge_Parallel.cyacd file not found
#sddl touch firm not found ret: 1
SKIP sddl launch firm write end ret: 1
SD : SdFgldfirmwrite -------
firm name :
BAC_H_19.enc =
firm name :
BAC_H_1.9.enc =
error
SKIP sddl fgic firm write end ret: 1
end
****************************
****************************
****
All firmware not found!
****
Interesting situation...
First off...Kinslayer81, thanks for posting this. I found the original in Japanese, and was not eager to try to translate it. Thanks for putting in the work.
For everyone (especially if you got this to work) - when I went through the step, I keep getting a "permissions denied" message. Whether it's the ERT4F01D batch file, or typing the commands in... I get "permissions denied".
Did you guys encounter this?
Glad it helped you On which step are you getting the error? Any strange output on any of the preceding steps?
Every step is important, to be done in the exact same order, e.g. loading google maps and pressing the 'my location' icon, etc.
Dakedo_Baby said:
First off...Kinslayer81, thanks for posting this. I found the original in Japanese, and was not eager to try to translate it. Thanks for putting in the work.
For everyone (especially if you got this to work) - when I went through the step, I keep getting a "permissions denied" message. Whether it's the ERT4F01D batch file, or typing the commands in... I get "permissions denied".
Did you guys encounter this?
Click to expand...
Click to collapse
Permission denied
Oh I know... I'm not new to the game. I've stalked these boards for a while now... This is my first tablet though.
I've tried running both the ERT4F01D batch... and the manual input.
I get it from the batch file, as soon as I tell it to "RUN"... "Permissions Denied"
From manual input - LINE 2: adb shell "ln -s /data/local.prop /data/local/calib.dat" = "Permissions Denied"
Like there's some additional admin privilege I don't have. Hmmmmm....
And here's an additional kicker... the tablet auto-reboots each and every time. I've tried it a number of times (started over from the top), same result each time.
Kinslayer81 said:
Glad it helped you On which step are you getting the error? Any strange output on any of the preceding steps?
Every step is important, to be done in the exact same order, e.g. loading google maps and pressing the 'my location' icon, etc.
Click to expand...
Click to collapse
I must admit, I don't have any great ideas.
So you can move the file in the first step no problem, and just the attempt to symlink gives you the error?
What is the output of "adb shell ls -la /data/local/".
When does the auto reboot occur?
Dakedo_Baby said:
Oh I know... I'm not new to the game. I've stalked these boards for a while now... This is my first tablet though.
I've tried running both the ERT4F01D batch... and the manual input.
I get it from the batch file, as soon as I tell it to "RUN"... "Permissions Denied"
From manual input - LINE 2: adb shell "ln -s /data/local.prop /data/local/calib.dat" = "Permissions Denied"
Like there's some additional admin privilege I don't have. Hmmmmm....
And here's an additional kicker... the tablet auto-reboots each and every time. I've tried it a number of times (started over from the top), same result each time.
Click to expand...
Click to collapse
I'm stumped too...
Well... this is getting a little interesting...
LS command - no problem (included image)
Decided to have another shot at it... and I was able to get a little further. Still encountered a problem
Now, the INSMOD command failed... "Operation not permitted"
Kinslayer81 said:
I must admit, I don't have any great ideas.
So you can move the file in the first step no problem, and just the attempt to symlink gives you the error?
What is the output of "adb shell ls -la /data/local/".
When does the auto reboot occur?
Click to expand...
Click to collapse
file system set to READ-only...
My file systems are set to Read-only... that explains quite a bit....
Dakedo_Baby said:
Well... this is getting a little interesting...
LS command - no problem (included image)
Decided to have another shot at it... and I was able to get a little further. Still encountered a problem
Now, the INSMOD command failed... "Operation not permitted"
Click to expand...
Click to collapse
Dakedo_Baby said:
My file systems are set to Read-only... that explains quite a bit....
Click to expand...
Click to collapse
Do you mind me asking, how did you set your file system to read-write? I have the same error as you were seeing but it's not allowing me to remount as read-write...
Can you confirm what command you used please?
thanks
Sorry again for late reply
Dakedo_Baby, I've looked at your stuff a few times and it's not obvious to me where things are going wrong. I again need some more info to try get a better idea of what's going on:
1) Before the first reboot, let me know the output of: adb shell "cat /data/local.prop"
2) After the reboot, let me know the output of: adb shell id
As for the file systems, well, /data should be already mounted rw, and /system should be mounted ro until you remount it. You can see how each is mounted with just "adb mount".
histrix said:
Do you mind me asking, how did you set your file system to read-write? I have the same error as you were seeing but it's not allowing me to remount as read-write...
Can you confirm what command you used please?
thanks
Click to expand...
Click to collapse
The command to remount the /system partition as read-write is: adb shell "mount -o rw,remount /system /system"
Of course, you should only be executing that step as part of the given sequence and in the correct order. You won't be able to execute the command until after your first reboot in the instructions, after which adb should still be running as root.
Any good Custom ICS roms you guys recommend after rooting the Arrows Tab?
ICS..Hurray!!!
Just found this out in Fujitsu site:
http://spf.fmworld.net/fujitsu/c/update/nttdocomo/f-01d/update1/top/index.html
There is a 4.0.3 download available. Click the 3rd Button (Green) downloads the zip package.
The 2nd link has howto from PC.
Still not sure if this will work, but trying out.
Also may lose root..and whatever else..So keeping my fingers crossed.
Google translation link
http://translate.google.com/transla...update/nttdocomo/f-01d/update1/top/index.html
Will post how it goes.
I made a new thread for this, since it's a different topic and you'll lose root too
http://forum.xda-developers.com/showthread.php?p=32200671
insmod lsm-disabler.so to remount /system rw
Back to the original topic... what I maybe didn't notice before is that the stock kernel blocks even root users from remounting /system as rw. So in case you ever need rw access to /system again, obviously you'll first have to be root, and afterwards you'll need to "insmod lsm-disabler.so" (as per the original instructions) before you can "busybox mount -o remount,rw /system" (or run any root app that remounts the system partition).
locked F-01d
Kinslayer81 said:
Well, with some help from Google Translate and some creative interpretations, I managed to do this and thought I'd provide some English instructions for others (with some added comments)
DISCLAIMER: AS USUAL, YOU SHOULD KNOW THAT FOLLOWING THESE ACTIONS (AND ESPECIALLY FOLLOWING THEM INCORRECTLY) CAN BRICK YOUR DEVICE (I.E. YOUR DEVICE WILL STOP WORKING, POSSIBLY PERMANENTLY). I AM NOT RESPONSIBLE FOR ANY DAMAGES THAT MAY ARISE FROM YOU FOLLOWING THESE INSTRUCTIONS, YOU DO SO AT YOUR OWN RISK.
Downloads
1. Windows -- the Arrows TAB USB driver Download.
2. Easy rooting toolkit (ERT) for Arrows Tab F-01D (ver 1.0) Download
3. goroh_kun's lsm_disabler.ko Download
Info
4. A su binary, such as the one found in DooMLoRD_v3_ROOT-zergRush-busybox-su.zip
5. Android SDK platform tools. adb(.exe) (and in Windows, specifically: AdbWinApi.dll, AdbWinUsbApi.dll)
Preparation
1. Unzip ert4F01D.zip, and in the subdirectory 'files' place:
* adb.exe (Windows only, from step 4 above)
* AdbWinApi.dll (Windows only, from step 4 above)
* AdbWinUsbApi.dll (Windows only, from step 4 above)
* lsm_disabler.ko (from step 3 above)
* su (from step 5 above)
2. Before connecting the USB, in Settings -> Applications -> Development:
* Check (tick) USB debugging ("Debug mode when USB is connected")
* Check (tick) Stay awake ("Screen will never sleep while charging")
3. Set up the USB drivers and Android Development stuff if you haven't already. I don't use Windows so can't help with this.
The Dirty Work
At this stage, you can run the batch file. Since I don't use Windows, I did the steps by hand, so you'll have to correlate your actions appropriately (I can't read Japanese either, so your guess is as good as mine ).
1. On your PC:
adb shell "mv /data/local/calib.dat /data/local/calib.dat_"
adb shell "ln -s /data/local.prop /data/local/calib.dat"
2. On the tablet, go into Google Maps, touch the GPS icon ("locate me" icon) on the top right hand corner, and then touch the BACK key to exit.
3. On your PC:
adb shell "echo ro.kernel.qemu=1 > /data/local.prop"
adb shell "rm /data/local/calib.dat"
adb shell "mv /data/local/calib.dat_ /data/local/calib.dat"
adb reboot
5. Once the device has fully rebooted, on your PC:
adb shell "mkdir /data/local/lib"
adb push files\lsm_disabler.ko /data/local/lib/
adb shell "insmod /data/local/lib/lsm_disabler.ko"
adb shell "mkdir /data/local/bin"
adb shell "echo '#!/system/bin/sh' > /data/local/bin/autoexec.sh"
adb shell "echo '/system/xbin/soff' >> /data/local/bin/autoexec.sh"
adb shell "chmod 755 /data/local/bin/autoexec.sh"
adb shell "mount -o rw,remount /system /system"
adb shell "ln -s /data/local/bin/autoexec.sh /system/etc/install-recovery.sh"
adb push files\su /system/xbin/
adb shell "chown root.root /system/xbin/su"
adb shell "chmod 06755 /system/xbin/su"
adb shell "echo insmod /data/local/lib/lsm_disabler.ko > /system/xbin/soff"
adb shell "chmod 755 /system/xbin/soff"
adb shell "mount -o ro,remount /system /system"
adb shell "echo > /data/local.prop"
6. I think at this point I was just meant to exit the lock screen.
7. adb reboot
8. Congratulations. You're now rooted. Go to the Play Store and download "Superuser" (by ChainsDD) and "BusyBox" (by Stericson). If you decide to buy BusyBox Pro, do not check the "symlinks" option in version 8.0, otherwise it's game over (no wifi, no adb shell, no root, no remount). It's a pain, but not impossible to repair this situation, see http://forum.xda-developers.com/showthread.php?p=26964465. I've emailed the author and I hope future versions won't trash the system so easily.
After all this, I'd suggest download Titanium Backup for Root users, backing everything up, and uninstall the all the bloatware that came with the device. Read up elsewhere about Titanium Backup.
Let me know if this helped you! Not sure how many other English speakers are using this device
Click to expand...
Click to collapse
thanks for the rooting tutorial but mine is also locked to ntt DOCOMO,,,ANY WAY TO UNLOCK IT
how to unlock the network
please help me how to unlock this tablet i got this tablet from my japan friend but it is network locked please help me to unlock this

How to root Fujitsu Stylistic M532

Hello,
I have a new Fujitsu Stylistic M532 Android Tablet. It would be great if someone could help me to root this tablet.
Which Information are neccessary from the tablet?
Maybe there is a standart process to test?
Please let me know what i can do to try to root the tablet?
Best regards
Sent from my M532 using xda app-developers app
Hello again,
Here are some more information about the tablet
Android 4.0.3
Kernel 2.6.39.4
Nvidia Tegra 3 T30S
MicroSDHC Slot
Mini USB Port
Updating via an external memory card (micro SD card)
Download and copy the system update package onto an external memory card (micro SD card).
Slide the memory card (micro SD card) into your Tablet PC.
Switch your Tablet PC off by one long press of the ON/OFF switch and confirm the question on the shut down with OK.
Switch your Tablet PC on again.
When you see the Android logo on the screen, press the ON/OFF switch and the volume button (increase volume) and keep them pressed for 2 seconds and then release them.
⇒ After a few seconds you reach the Recovery menu.
Info: If the Fujitsu logo appears on the screen, then you have not reached the recovery menu. Repeat the above step until you reach the recovery menu.
Select "apply update from external storage".
Info: Navigate as follows through the menu:
Volume button (increase volume) to select an option above the current option
Volume button (decrease volume) to select an option below the current option
ON/OFF switch to confirm the selection
Follow the instructions on the screen to perform the system update.
⇒ After the system update has completed, you will be in the recovery menu again.
Select "Reboot system now" to finish the system update.
Sent from my M532 using xda app-developers app
I am also considering buying this tablet. Therefor a root manual would be highly appreciated.
Thanks.
OK. I think no one has done the root on this tabet.
Maybe somone could give me a hint what i can try to root this tablet?
I`m ready to try some some procedures
maybe a standart procedure is available for android 4?
Or is the rooting of each device different?
What happens if i try a wrong procedure? I think a recovery of the os should always be possible or not?
Maybe someone could answer some questions
Sent from my M532 using xda app-developers app
I have the same tablet. Have you already tried to root it?
Is there any guide available in the meantime?
Hi,
I also have the M532, it is really great.
Any advise how to root it would be appreciated.
Thanks for any hint.
Sent from my STYLISTIC M532
I have no fujitsu tablet, but the same model Pegatron Chagall. (exactly the same)
this set you can upgrade my Fujitsu tablet?
Rom which includes applications?
I don't think so.
Look at the detailed update procedure from Fujitsu and you will see that the update process is checking the model and version information and refuses to install if they do not match.
You're right, the update package does not work on my tablet (Síragon 4N) ... it's a shame.
However, if there is a method to be root, so if you serve ...
Even this recent tablet market, hopefully get into the right hands and can unlock.
Hey, has anyone managed to root the M532?
Is there anyone I could send my M532 to to have it rooted?
ironxp said:
I have no fujitsu tablet, but the same model Pegatron Chagall. (exactly the same)
Click to expand...
Click to collapse
+1
Could someone download the boot.img and recovery.img from this tablet? We need those files in order to modify the following values in the default.prop file
filero.secure=0
ro.debuggable=1
persist.service.adb.enable=1
Repack the images and flash it using fastboot to get a privileged shell.
After doing that you will be able to root this table using "unlockroot" software
mandraxxx said:
Could someone download the boot.img and recovery.img from this tablet? We need those files in order to modify the following values in the default.prop file
Click to expand...
Click to collapse
All you can find is a .pkg file which you need for an upgrade.
How to download boot and recovery
I would be glad to, but how do I find them and get them copied to get to you?
mandraxxx said:
Could someone download the boot.img and recovery.img from this tablet? We need those files in order to modify the following values in the default.prop file
filero.secure=0
ro.debuggable=1
persist.service.adb.enable=1
Repack the images and flash it using fastboot to get a privileged shell.
After doing that you will be able to root this table using "unlockroot" software
Click to expand...
Click to collapse
Here is the pkg file which you can download on this page
-Script by Bin4ry-
I have a Tablet Chagall / Pegatron / Siragon 4N (the same model as the Fujitsu)
I tell them that I tried several rooting script:
Cube Root for ICS 4.0.3 , Cube Root for ICS 4.0.3 v2 , DROID 3 easy root script v7, Root_with_Restore_by_Bin4ry_v8, Google Nexus 7 ToolKit, NRT_v1.5.3., superclick, El UnlockRoot..
and three do not remember ...
And no I worked ...
today ... was half annoyed, and I happened to search again Bin4ry script and found this:
"Root_with_Restore_by_Bin4ry_v10" and try with this script by several methods ... but nothing ...
(http://forum.xda-developers.com/showthread.php?t=1886460)
Then I found this old script bin4ry original,
But it did not work ...
script "Root para ICS 4.1.A.0.562"
What I did was change a few lines ... why were here on xda forum
Here the modified
*******************************************************************
@echo This is an adapted idea from the methods of
@echo Dan Rosenberg (vulnfactory.org)
@echo -Script by Bin4ry-
echo off
cd data
echo Please plug the device in ADB-Mode
adb wait-for-device
echo Rename /data/local/tmp to be able to create symlink
adb shell mv /data/local/tmp /data/local/tmp.old
echo Trying to create /data symlink
adb shell ln -s /data /data/local/tmp
adb reboot
echo Waiting for device to reboot
adb wait-for-device
adb shell rm /data/local.prop > nul
echo Trying to write value in tablet to prop-file
adb shell "echo \"filero.secure=0\" > /data/local.prop"
adb shell "echo \"ro.debuggable=1\" > /data/local.prop"
adb shell "echo \"persist.service.adb.enable=1\" > /data/local.prop"
echo Rebooting
adb reboot
echo Waiting for device to reboot again
adb wait-for-device
echo Try to remount /system
adb remount
echo Pushing su and Superuser.apk
adb push su /system/bin/su
adb shell chmod 06755 /system/bin/su
adb push Superuser.apk /system/app/Superuser.apk
adb shell chmod 644 /system/app/Superuser.apk
echo Cleanup of the Stuff created while running
adb shell rm /data/local.prop
adb shell rm /data/local/tmp
adb shell mv /data/local/tmp.old /data/local/tmp
adb reboot
cd ..
pause
echo Reboot and done Have fun!
*******************************************************************
Note that the only thing not to run this script to copy the application was Superuser.apk and of course change the privileges ...
Install the "superuser" from the market ... and remove the line copy the superuser, and run the whole script.
It was no root ...
I returned to run the scritp of bin4ry, V10 ... and did you root the tablet seems.
(standard option)
Check and reset the tablet, and was even root ..., delete all tablet for recovery to start once again ... and continued to root ...
But, try to certify and document the process for publishing ... and V10 bin4ry script, we apply "unroot"
Now I could not repeat the process, and I could not do root again ...
... but I notice that in the folder / system, I find the SU ...
If someone wants to try, because only must be sure that you can restart the tablet completely ... so that applications may have the lost ...
I managed to root, unroot after applying ...
I root Bin4ry the script, and then with the same script I unroot (Here)
And now I root with script WkPark (Here)
Try making the tablet fujitsu root with these script, they must work ...
My tablet is a Pegatron \ Chagall \ Síragon 4N, which is exactly equal to the Fujitsu ...
ironxp said:
I managed to root, unroot after applying ...
I root Bin4ry the script, and then with the same script I unroot (Here)
And now I root with script WkPark (Here)
Try making the tablet fujitsu root with these script, they must work ...
My tablet is a Pegatron \ Chagall \ Síragon 4N, which is exactly equal to the Fujitsu ...
Click to expand...
Click to collapse
What a pitty!
Did not work on my M532
I only get following message when i try to run the script rooting.bat
Pushing busybox...
error: device not found
error: device not found
error: device not found
rooting.sh: adb: Invalid argument
[*] Remove old fake files...
error: device not found
error: device not found
rooting.sh: adb: Invalid argument
[*] Restore fake backup...
adb: unable to connect for backup
adb: unable to connect for backup
rooting.sh: adb: Invalid argument
[*] Please look at your device and select RESTORE button!
[*] Waiting ...
error: device not found
error: device not found
rooting.sh: adb: Invalid argument
[*] Running ...error: device not found
error: device not found
rooting.sh: adb: Invalid argument
[*] check /data/local.prop
***** FAIL *****
Please retry again
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
Best regards
quaker75 said:
What a pitty!
Did not work on my M532
I only get following message when i try to run the script rooting.bat
Pushing busybox...
error: device not found
Best regards
Click to expand...
Click to collapse
These errors are not connected in "ADB mode" to your pc
Brother, first try to install the driver of google android sdk, and not those of Fujitsu tablet (if you have one installed, it is best to uninstall and reboot the PC)
Then do a factory reset of the tablet, marking the option to delete all.
*- Active in Developer options, USB debugging, stay active and allow test location. Also active in security, unknown sources.
*- Connect the tablet (verifies that Windows recognizes it as "Android ADB Interface")
*- Run the script WkPark friend, follow the instructions and after two reboots, you will have root access to the tablet.
Performs a shutdown and start at the end and if you can run a new factory restore. Install "Root Check" of the market
*- If you do not succeed, try the same steps but running the script Bin4ry friend, and using the "Special" ... you follow the steps indicated.
Always remember to run a shutdown and startup at the end of each script ...
If you have problems with applications that are lost, do not pay much attention as you can re-run a factory reset or restore the tablet for recovery, for it ready.
I can certify that the script works Bin4ry and also the WkPark
(I have a tablet exactly like yours ... Pegatron / Chagall / Síragon 4N)

BusyBox Issues

I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
What I had to do, is flash busybox from TWRP, installing from playstore did not work at all. It has something to do with HTC security.
I just tried that and couldn't seem to find where it's stored.
Sent from my HTC One using XDA Premium 4 mobile app
Added a couple edits, explained at the end of some paragraphs in case someone comes across this, don't like leaving things incorrect if I know it. I strongly recommend enabling xtrace in the shell to check what's actually being executed, you see your functions and aliases expanded too. With all (busybox ash)|mksh|bash|zsh you can do 'set -x' at any time, append it when calling the shell: 'sh -x' or 'sh -o xtrace' with 'sh' being a symlink to any of the mentioned shells; sh runs the shell in posix mode.
Diesel321 said:
I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
Click to expand...
Click to collapse
This sounds like SELinux shenanigans. I don't have the HTC One, but I've experienced similar oddities with a SELinux enforced system. (latest TWRP includes SELinux which might be why a twrp doesn't make a difference) With the addition of the SELinux filesystem, a new "file context" permission is attributable to each file/process. The context defines a user, basic function, that it's in the right place, and a sensitivity parameter. There's some good basic info on the SELinux wiki page with commands.
If your system is using enforced SELinux, a program like busybox installed without setting context is going to be denied to exist/run by default, but this depends on how SELinux is configured. I'm guessing it's context is not being set, so it's getting purged on reboot. Another possible SELinux related issue : a custom kernel that doesn't support SELinux is installed on a rom with SELinux --> bad mix, so if that's the case don't be surprised if more issues like this crop up or a data wipe in your sleep randomly occurs out of nowhere --This happened to me twice actually after disregarding this warning-- You can check your SELinux status with
Code:
getenforce
-in adb or terminal emu. This should also be displayed in phone info menu in settings. Make sure it's "permissive" or "enforced". Permissive logs warnings of what SELinux would do if enforced. You can change SELinux to permissive with:
Code:
setenforce 0
This only works if both your kernel and rom are Selinux compatible. Btw you'll probably find all your SELinux command tools in /system/bin symlinked from toolbox. There's also runcon (run with a context), chcon(change context), restorecon (restore original context), and updates have started integrating a flag (usually -Z) to **filter in** SELinux permissions, e.g. toolbox ls -Z. Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
**(filters not a good way to put it at 2nd glance, sounds confusing. I mean 'test' or read ACLs<extended perms)
So I would check busybox' context after installing it:
Code:
ls -Z "$(which busybox)"
If it's undefined or unconfined, we will change it to this:
Code:
u:object_r:busybox_exec:s0
.. We can fix it ourselves over adb or in a su'd mksh/bash shell, (use supersu since cwm superuser does not pass arguments correctly or at all in most situations):
Code:
su --shell mksh exec -c mksh -x --
First try to restore original context from file_contexts and see if it works:
Code:
restorecon "$(which busybox)"
Then set busybox' context:
Code:
sync && mount -w -o remount -t ext4 /system /system
chcon u:object_r:busybox_exec:s0 "$(which busybox)"
sync && mount -r -o remount -t ext4 /system /system
*** added "-t ext4" to mount command- it should then work with toolbox or busybox no errors
The other thing I might guess besides all this SELinux file context stuff is that the installation of the busybox binary didn't write to disk. If you run fsync off in your kernel, a fast reboot soon after busybox installation could very possibly lead to data loss of recent files. Similarly, but without a huge risk of collateral damage, recent changes to files could be lost if you have writeback journaling enabled for /system and you rebooted within (dirty expire + dirty writeback) / 100 seconds. A normal reboot that spends 5-10 seconds dumping and getting everything written to disk should be fine though. IF the new busybox' "mount" applet/function is incompatible or broken or outdated, a mount failure could occur leading to data loss. Backup toolbox mount in /system/bin should be enough to save this though, so I'm sticking with my diagnosis of a "SELinux gotcha".
Hope this helps, nothing worse than losing busybox or su functionality. As a side note, in case this problem takes a few days to figure out, check out Terminal IDE if you haven't before. It is definitely a nice busybox replacement to say the least if you need backup/better primary tools, at least temporarily. It's probably the most valuable app/terminal/busybox/Java/c/c++/ide/apkbuilder I've ever seen. ZERO ads, no net connection. You can get the latest apk off Google code, and there's a thread on xda by the creator Spartacus Rex. The tools and configurations are much more heavy duty than anything I've seen for Android. It has great well written tutorials to walk anybody through java, c, some shell stuff and utilizing ssh,telnet,iirc,git to make using android more like a linux machine. I've really gotten into this so I thought I would mention it.
7175 said:
... Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
Click to expand...
Click to collapse
This must be the only sensible post on XDA, that has both Busybox and SELinux in the same post! Thanks.
Any ideas where to get a fully context featured Busybox? Tried to look in those tips you gave, but they're all outdated, i.e Busybox versions lower than 1.22.1.

Rooting Android OS on a Samsung Chromebook Plus?

I've had the Samsung Chromebook Plus for about 2 weeks now, and I love it! Chrome OS is pretty good at handling itself for notetaking with the stylus, and the gorgeous screen is great for high res stuff (although Chrome OS is in desperate need of DPI scaling). It even runs Android apps out of the box! So far, I only have 2 major gripes about Chrome OS:
-It cannot do multitasking on anything (Android or Chrome app) when in tablet mode (buttons disappear, window drags are disabled) even on the beta branch
-Android cannot be rooted on the Chrome OS (so I think).
That second one is the one I'd like help with. Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Nilithium said:
Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Click to expand...
Click to collapse
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
On a general basis, running scripts from random strangers on the Internet is a bad thing. But I'll take it!
I've encountered an ID10T error though: I set the debugging password during setup, and I THOUGHT that was the sudo password to run your script. Problem is, that's not true, and I've no idea what it is.
Tried Google Account password, no dice.
Tried Chromebook PIN, no dice.
Tried Debug Pass set in Setup, no dice.
Tried password, no dice.
Tried null password (no input), no dice.
What is the sudo password? Did I miss something?
Nilithium said:
What is the sudo password? Did I miss something?
Click to expand...
Click to collapse
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Nolirum said:
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Click to expand...
Click to collapse
DELETE
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Anyone tried it on Pixelbook?
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
holy cow, script works flawlessly! (Samsung Chromebook Plus)
Anyone know why my Tivo app and Sirius XM don't work on my new Samsung Chromebook Plus V2? They install and than don't open and crash any other workable apks that anyone knows about? Sirius I can do online Tivo won't play all my recorded shows online just some and I really bought this Chromebook to use the Tivo app to watch shows when not at home or sitting outside. I know this thread is about rooting but I thought someone here may be able to help me. I also posted in the Tivo Community Forum also and am waiting for a response. Thanks!
MsWadera said:
Anyone tried it on Pixelbook?
Click to expand...
Click to collapse
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
phonefreedom said:
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
Click to expand...
Click to collapse
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
phonefreedom said:
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
Click to expand...
Click to collapse
When you say it was unusable, did Android (apps) appear to fail to load up completely, just the icon spinning? Or something else?
Did you happen to notice if any errors were shown on the script's output at all?
For example, there was this issue reported on github when the Pixelbook was first released, in which the Android rootfs container created by the script turned out to be a bit smaller than required, and so errors occurred when copying files to the new rooted /system. The user was able to successfully continue after manually editing the script so it created a container that was slightly bigger.
The script has been updated since then to reflect the increased space requirements, so that particular problem should no longer occur. Other potential sources of error might include if there could have been a problem downloading the required files (SuperSU, BusyBox), a problem patching SE Linux (in which case there is a separate script to do this part) , or maybe something else, possibly due to Chrome OS changes/updates.
In the case of the script rendering Android unusable, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Entering the above will restore the original read-only squashfs unrooted rootfs, which, after a reboot, should then load up as normal.
I think I'll edit my earlier post in this thread to add the command to restore from backup. Apologies for failing to mention it here initially. I might add an explicit message in the script itself regarding this, as well.
Flashing zips
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
do-tim said:
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
Click to expand...
Click to collapse
Depends what you want to flash, probably.
You might be able to rewrite the relevant edify commands in the update-binary that you want to flash into an equivalent shell script for the Chrome OS shell.
However, by default the Android rootfs container is in a read-only squashfs format, so normally cannot be modified directly. One way to modify it is to make a writable copy of the container in /usr/local, then replace the original file pathname with a symbolic link to the R/W copy. This works fine for the most part (but does takes up extra disk space, and needs to be re-done after an OS update).
For instance, here is part of the rooting script mentioned upthread, which makes a writable copy of the Android container, copies the files from the original container therein, renames the original to .bk, replaces the original file pathname with a symlink to the copy and, at the end, changes a couple of relevant envs in CrOS's /etc/init/arc-setup-env file.
Code:
#!/bin/sh
# Detect CPU architecture
case "$ARCH" in
x86 | i?86) ANDROID_ARCH="x86";;
x86_64 | amd64) ANDROID_ARCH="x86";;
armel) ANDROID_ARCH="armel";;
arm64 | aarch64) ANDROID_ARCH="armv7";;
arm*) ANDROID_ARCH="armv7";;
*) error 2 "Invalid architecture '$ARCH'.";;
esac
# Make some working dirs
mkdir -p /usr/local/Android_Images
mkdir -p /usr/local/Android_Images/Mounted
mkdir -p /usr/local/Android_Images/Original
# Create container image file. Intel devices need a slightly larger file.
if [ $ANDROID_ARCH=armv7 ]; then
cd /usr/local/Android_Images
fallocate -l 1.7G /usr/local/Android_Images/system.raw.expanded.img
else
if [ $ANDROID_ARCH=x86 ]; then
cd /usr/local/Android_Images
fallocate -l 2.2G /usr/local/Android_Images/system.raw.expanded.img
# Format the .img file.
mkfs ext4 -F /usr/local/Android_Images/system.raw.expanded.img 2>/dev/null
# Set SELinux to permissive.
setenforce 0
# Check that the stock Android container exists and is not already a symlink.
# If this is the case, mount it in order to copy files.
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
if [ -e /opt/google/containers/android/system.raw.img ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
# If the stock container's missing, check if there is a backup.
if [ -e /opt/google/containers/android/system.raw.img.bk ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img.bk /usr/local/Android_Images/Original 2>/dev/null
else
# If there's no backup in the expected location, check in ~/Downloads, too.
# NOTE: We can also use a container from a different device/other OS versions by putting it in ~/Downloads.
# To use a different container, we just need to rename any existing containers in /opt/google/containers/android/
# e.g. rename /opt/google/containers/android/system.raw.img.bk to /opt/google/containers/android/system.raw.img.bk.bk
# Containers from different devices/OS versions are unlikely to boot, however.
if [ -e /home/chronos/user/Downloads/system.raw.img ]; then
echo "Mounting /home/chronos/user/Downloads/system.raw.img and copying files"
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /home/chronos/user/Downloads/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
echo
echo "Error!"
echo "System.raw.img not found"
echo
exit 1
fi
fi
fi
fi
ANDROID_ROOTFS=/usr/local/Android_Images/Original
# Mount the new .img.
mount -o loop,rw,sync /usr/local/Android_Images/system.raw.expanded.img /usr/local/Android_Images/Mounted
# Copy the files.
cp -a -r $ANDROID_ROOTFS/. /usr/local/Android_Images/Mounted
# Rename the original container to .bk.
if [ -e /opt/google/containers/android/system.raw.img ]; then
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
echo "Moving original Android rootfs image to /opt/google/containers/android/system.raw.img.bk"
mv /opt/google/containers/android/system.raw.img /opt/google/containers/android/system.raw.img.bk
# Make the symlink from the original pathname to our writeable rootfs image.
echo "Replacing original Android rootfs image path with symlink to /usr/local/Android_Images/system.raw.expanded.img"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
else
if [ -e /usr/local/Android_Images/system.raw.expanded.img ]; then
echo "Creating symlink to /usr/local/Android_Images/system.raw.expanded.img at original Android rootfs image file path"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
fi
# Change the envs for writeable mount and debuggable in CrOS's /etc/init.
sed -i 's/export WRITABLE_MOUNT=0/export WRITABLE_MOUNT=1/g' /etc/init/arc-setup-env 2>/dev/null
sed -i 's/export ANDROID_DEBUGGABLE=0/export ANDROID_DEBUGGABLE=1/g' /etc/init/arc-setup-env 2>/dev/null
The rooting script is basically just the above, with the addition of a couple of other bits, including the relevant commands from the update-binary script in the SuperSU zip, slightly rearranged from Edify to regular shell script for the CrOS shell. That part of the script can be seen here.
So you could maybe do a similar script, with the files you want to flash. Also, once you have a R/W Android rootfs, it may be possible to update files from directly within Android, although, as mentioned in the last few posts in this thread, on some recent CrOS builds, some people have been running into an issue with the rootfs still getting mounted RO within Android, even with a writable container. This does not occur on all devices though, and should be just a temporary issue.
It would probably also be possible to set up a sort of overlay configuration, somewhat similar to Magisk in effect, but due to the somewhat convoluted mount configuration of the container based system, and the almost constant changes/updates (to the container, its config, and so on) that have been occurring with each update to Chrome OS, this would likely require quite a bit of work to implement and maintain.
Corrective measures to run the script...
Spoke too quickly - all installed but no root detected in SuperSU...
Yes, thanks, it seems to work.
I wonder why the script cannot handle downloading SuperSU & busybox on its own, some corrections are needed.
justqt said:
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Click to expand...
Click to collapse
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Davestar2000 said:
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Click to expand...
Click to collapse
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Click to expand...
Click to collapse
If it says no android system detected, I downloaded it in 2 parts from here: ( github(dot)com/nolirium/aroc ), followed the instructions, and then it worked for me.
Nolirum said:
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Click to expand...
Click to collapse
thanks for all the help. I have chromebook plus v1,I am on chrome osversion 74. I tried to follow the instruction
but my android apps did not start after restarting. I tried doing it manually but i got stuck at remounting file system as read only. Please help if possible. Thanks again.
Hi,
I'm having problems with this. I have an HP Chromebook with an Intel cpu, Chrome OS Version 75.0.3770.144 (Official Build) (64-bit). When I run the scripts this is the output:
Setting 'ANDROID_DEBUGGABLE: true' and 'WRITABLE_MOUNT: true' in /usr/share/arc-setup/config.json
The file at /opt/google/containers/android/system.raw.img is already a symlink!
Removing symlink
Using /opt/google/containers/android/system.raw.img.bk
Creating new Android system image at /usr/local/Android_Images/system.raw.expanded.img
1814633472 bytes (1.8 GB, 1.7 GiB) copied, 13 s, 140 MB/s
1800000+0 records in
1800000+0 records out
1843200000 bytes (1.8 GB, 1.7 GiB) copied, 25.2601 s, 73.0 MB/s
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Creating symlink to /usr/local/Android_Images/system.raw.expanded.img
SuperSU files not found in ~/Downloads! Attempting to download BusyBox and SuperSU now...
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5810 100 5810 0 0 5624 0 0:00:01 0:00:01 --:--:-- 9078
Unexpected file size. Trying again...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
50 6756k 50 3407k 0 0 305k 0 0:00:22 0:00:11 0:00:11 311k
Unzipping SuperSU zip, and copying required directories to ~/Downloads.
/usr/local/bin/busybox: 1: /usr/local/bin/busybox: Syntax error: word unexpected (expecting ")")
cp: cannot stat 'common': No such file or directory
cp: cannot stat 'armv7': No such file or directory
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6756k 100 6756k 0 0 328k 0 0:00:20 0:00:20 --:--:-- 351k
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
Copying sh from system/bin/sh to system/xbin/sugote-mksh and setting permissions and contexts
Adding extra files system/etc/.installed_su_daemon and system/etc/install-recovery.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
Symlinking system/bin/install-recovery.sh to system/etc/install-recovery.sh
Adding system/bin/daemonsu-service.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
Creating file init.super.rc in Android rootfs
Adding daemonsu service to init.super.rc
Adding 'import /init.super.rc' to existing init.rc
Substituting '|mount rootfs rootfs / remount bind rw' for '|mount rootfs rootfs / remount bind ro' in existing init.rc
A backup of init.rc will be stored as init.rc.old
sed: can't read /../init.rc: No such file or directory
Removing temporary files
Done!
Please check the output of this script for any errors.
Please reboot now, then run script 02SEPatch.sh.
[email protected] / $
Any help would be very much appreciated. I've done a good bit of searching and so far have been unable to figure what the problem is. Thanks alot, guys.
JR

Categories

Resources