Related
Has anyone been able to root thier Erie yet? If so how did you do it? Or can anyone point me in the right direction to get started. Thanks for the help.
I think it'll be at least a few weeks. Someone needs to get the recovery image and mod it as they did with the Hero. I think.
so is anyone working on this? if you give me instuctions i will dump my phone and post it, if that will help? i would really just like to be able to tether over wifi when needed without having to pay out the ear for it.
Is it that different from the Sprint's Hero? Try the current method...
herzzreh said:
Is it that different from the Sprint's Hero? Try the current method...
Click to expand...
Click to collapse
I'm concerned that the image from the Hero will cause problems since it's different carrier etc
The method used to root isn't carrier dependent. You probably won't want to load MoDaCo's current ROM as it is Sprint specific, but assuming the kernel build is the same you may be able to gain root with the asroot2 script.
To clarify, 'rooting' is not the same as loading a custom ROM. One begets the other, but loading a custom ROM isn't a requirement, just a door that gets opened when you gain root access to your phone.
Assuming everything else is the same on the phone, the Amon_Ra recovery bootloader should work as well.
If asroot2 works then we can flash a new recovery image, you can dump your ROM, and I can do a MCR version.
P
would i still use the recovery image that is posted for the hero? or would i stop at that step when rooting?
binny1007 said:
would i still use the recovery image that is posted for the hero? or would i stop at that step when rooting?
Click to expand...
Click to collapse
If you use the recovery image for the hero and it doesn't work, it's not usually a big deal.
Just pull out the battery to restart your phone normally. Since the recovery image is separate from the rom, replacing the first does not affect the latter.
binny1007 said:
would i still use the recovery image that is posted for the hero? or would i stop at that step when rooting?
Click to expand...
Click to collapse
Follow the rooting instructions to the letter, all the way through. Just don't flash a new rom if successful.
You can use the recovery image posted for the Hero.
ok i am following the instructions and this is what i am getting? what is going wrong?
C:\AndroidSDK\tools>adb shell
$ chmod 0755 /data/local/asroot2
chmod 0755 /data/local/asroot2
$ /data/local/asroot2 /system/bin/sh
/data/local/asroot2 /system/bin/sh
[1] Killed /data/local/asro
$ mount -o remount,rw -t yaffs2 /dev/block/mtd
mount -o remount,rw -t yaffs2 /dev/block/mtdbl
mount: Operation not permitted
$ cd /system/bin
cd /system/bin
$ cat sh > su
cat sh > su
cannot create su: read-only file system
$ chmod 4755 su
chmod 4755 su
Unable to chmod su: No such file or directory
The eris and droid can't use that exploit unfortunately, you'll have to wait until there's another way in
binny1007 said:
ok i am following the instructions and this is what i am getting? what is going wrong?
C:\AndroidSDK\tools>adb shell
$ chmod 0755 /data/local/asroot2
chmod 0755 /data/local/asroot2
$ /data/local/asroot2 /system/bin/sh
/data/local/asroot2 /system/bin/sh
[1] Killed /data/local/asro
$ mount -o remount,rw -t yaffs2 /dev/block/mtd
mount -o remount,rw -t yaffs2 /dev/block/mtdbl
mount: Operation not permitted
$ cd /system/bin
cd /system/bin
$ cat sh > su
cat sh > su
cannot create su: read-only file system
$ chmod 4755 su
chmod 4755 su
Unable to chmod su: No such file or directory
Click to expand...
Click to collapse
You guys and Bell South...sounds like Sprint had the only vulnerable CDMA version.
You guys will have to wait for a new "asroot" type file...a new exploit to get you guys access.
well that sucks, so there is no other way around this right now? Or if anyone needs a ginnie pig i am more than happy to help.
thecodemonk said:
You guys and Bell South...sounds like Sprint had the only vulnerable CDMA version.
You guys will have to wait for a new "asroot" type file...a new exploit to get you guys access.
Click to expand...
Click to collapse
That's what I thought. Hopefully since the hardware is so similar it wont take long.
Unfortunately hardware is barely a glimmer in this equation - the expliots used to gain root are software, usually kernel bugs.
Something will turn up soon.hopefully.
binny1007 said:
well that sucks, so there is no other way around this right now? Or if anyone needs a ginnie pig i am more than happy to help.
Click to expand...
Click to collapse
Just remember, while it's unlikely, any of these actions could theoretically brick your phone...be aware of the risks!
Have you attempted the flashrec method?
Drop the Recovery Image from here onto your sd card
http://forum.xda-developers.com/showthread.php?t=581521
Download the apk from here and install it on your phone:
http://zenthought.org/content/project/flashrec (download it from your phone's webbrowser and open the file...if that doesn't work, download astro file explorer from the market and try again).
Once you open flashrec, click on the "backup" link and then type in the path to your recovery image (most likely: /sdcard/recovery-RA-heroc-v1.2.3.img)
Then flash and try to reboot into recovery mode (power off, then either home+power, volume down+power, or camera+power...depends on who you ask, one of those should get you into the recovery image where you'll see an option for nandroid, that's how you'll know it was a success).
If you reboot and it doesn't work or it freezes, pop out the battery and boot normally...shouldn't hurt anything (though if you want to be more safe, I'd wait until we got the RUU for whatever carrier you're on (Verizon/Telus/etc)). Currently the Sprint RUU is the "get out of jail" card that's saved a bunch of people.
Just remember, while it's unlikely, any of these actions could theoretically brick your phone...be aware of the risks!
thecodemonk said:
You guys and Bell South...sounds like Sprint had the only vulnerable CDMA version.
Click to expand...
Click to collapse
Cellular South
thecodemonk said:
Have you attempted the flashrec method?
Click to expand...
Click to collapse
It doesn't use the same exploit as asroot2?
markachee said:
Cellular South
It doesn't use the same exploit as asroot2?
Click to expand...
Click to collapse
Sorry, Cell South, Bell south...(can you tell I'm not from around there? )
I have no idea if it does...but I figured it can't hurt to try eh? Because if it works, wouldn't that be awesome?
How to root Nook HD+ (and Nook HD too, I guess).
(Thanks for some useful ideas to sparkym3: http://forum.xda-developers.com/member.php?u=4411543 )
(tested only on 2.0.0 version (as comes out of the box), also works on 2.0.2
Get one of the attached files: root_win.zip if you are on windows, or root_unix.tgz if you are on Linux or Mac.
unpack the file to some dir and run "makeroot" on Windows or "sh makeroot.sh" on Mac/Linux
After a couple of reboots you should be able to do
adb shell and issue a "su" command in the shell and get the root prompt (#).
Thanks to someone0 for his prior investigations here.
Known bugs:
Superuser.apk does not really install because package manager could not be contacted.
Oh, and I think you'll find this interesting too:
Hai.
Kind of a two-fer, eh?
I noticed that people see their Nook HDs restoring to factory settings after 8 unsuccessful reboots next time you boot after rooting, so possibly there's some extra check somewhere.
Very sneaky on the B&N side, I'd say.
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
Do the new HD & HD+ still allow you boot from the external sd card ?
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
if you put your books into /system/media, it will back them up to the cloud
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
leapinlar said:
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
Click to expand...
Click to collapse
stuff is best to be not mentioned. /sarcasm.....
recovery is signed, so it's not super easy to replace it with anything that would run.
The unsigned bootloader trick at the moment requires a boot from sdcard.
shouldn't step 8 & 9 be outside the code block?
verygreen:
I just want to thank you for your all your work on the Nook series. I've been using your "size-agnostic method ..." tools and process to run from the SD card on my Nook Color since you created the method, and now I'm excited to use your work on my new Nook HD+ (just received yesterday) !
just got mine and got an update notification. turned off wifi so it didnt complete.any word if it breaks root ir bootloader?
CWM is now possible too.
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Code:
@echo off
cls
@echo .
@echo wait for it
@echo .
adb devices
@echo .
@echo if you do not see you device listed above hit ctrl+c and exit the script
@echo then check adb on your PC and device then try again.
@echo .
@echo reroute /data/local/tmp
adb wait-for-devices shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
@echo .
@echo Now rebooting
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and making directory /data/su
adb wait-for-devices shell mkdir /data/su
@echo uploading su
adb push su /data/su/
@echo uploading busybox
adb push busybox /data/su/
@echo uploading boot_complete_hoot
adb push boot_complete_hook.txt /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh /data/su/*
@echo .
@echo Now rebooting again
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and getting shell
adb wait-for-devices shell
someone0 said:
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Click to expand...
Click to collapse
so, when you run this, after the final adb shell, what are the permissions on /system/xbin/su?
run su and you should get the root prompt.
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice. either boot_complete_hook.sh didn't get executed or it did but never get launched with root permission.
someone0 said:
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice.
Click to expand...
Click to collapse
well, there should be more stuff in the shell file, you miss the final chown line: chmod 06755 /system/xbin/su
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
someone0 said:
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
Click to expand...
Click to collapse
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
verygreen said:
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
Click to expand...
Click to collapse
This is interesting, it look as if it won't launch the /data/boot_complete_hook.sh
Code:
cat /data/boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
[B][email protected]:/data $ /data/boot_complete_hook.sh
/data/boot_complete_hook.sh
/system/bin/sh: /data/boot_complete_hook.sh: No such file or directory
1|[email protected]:/data $
[/B]
Yub it does
Code:
cat clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
[B]/data/boot_complete_hook.sh[/B]
# Zero the boot count
cat /system/etc/zerobootcnt > /bootdata/BootCnt
Hi,
Sorry if it's not the good forum, I have looked for the good one but I'm not very easy with English.
I want to sort out files by date in directories to delete automatically oldest backup files with a script. I have Cyanogenmod 11 on a Samsung Galaxy S2. I have installed Busybox (Stephen Stericson) on my phone from the Playstore to use the command ls -t because in standard we have only ls and ls -l. But when I tape ls -t, I have an error message "Unknown option". I've tried with Cyanogenmod 12 but I have the same problem.
I would want to know if ls -t doesn't function in BusyBox or if I have another problem.
Thank you.
No response :crying: .
Can somebody tell me if he haves a BusyBox which enables to use the command and which is this BusyBox : ls -t?
Thank you .
Are you sure you are using busybox?
try running: busybox ls -t
Ok, I have to type "busybox" first. I will try it, thank you.
Ok, it works when I add "busybox" in the command . I'm just a little surprised, I had understood the busybox commands replaced the shell commands.
You can also add: busybox sh
to your script and after that you could easily use ls -t without busybox.
Ok, thank you but it's not annoying to add "busybox". I don't create a lot of scripts .
Now I try to solve the problem to move files to the sdcard. It worked fine in 4.1.2 but with Cyanogenmod 11, I have a cross device link. I tried also "cp -p" to keep initial attributes but I have "Operation not permitted".
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
mgbelisle said:
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
Click to expand...
Click to collapse
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Sent from my SCH-I535 using Tapatalk
Droidriven said:
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Click to expand...
Click to collapse
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
mgbelisle said:
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
Click to expand...
Click to collapse
You're using a temp recovery aren't you? Are you using that because your bootloader is locked? Are you rooted?
Sent from my SCH-I535 using Tapatalk
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I doubt you'll make the changes and keep them without root.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
I doubt you'll make the changes and keep them without root.
Click to expand...
Click to collapse
Hmm but that doesn't quite make sense to me. I made the changes as root and they've definitely persisted (even when I reboot into twrp) and the changes are there if you do the same thing in Android 6. There are many references to doing changes this way like in http://forum.xda-developers.com/nexus-5x/general/guide-how-to-unlock-tethering-nexus-5x-t3231301 but it's just with Android 7 now, the stock 7 firmware is mounting something on /system/build.prop that is different than what TWRP mounts at /system/build.prop. I'll try the same thing with CyanogenMod Recovery, maybe that will have different results.
mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Click to expand...
Click to collapse
Yeah I understand that, but even though it wouldn't cause a problem it doesn't seem that would be necessary. Interestingly, when I'm booted into twrp with /system mounted, the build.prop file has the contents and timestamp I expect.
# ls -la /system/build.prop
-rw-r--r-- 1 root root 4919 Dec 17 16:52 /system/build.prop
But when booted into system (stock Android 7 like I mentioned) the timestamp shows a very different file is being mounted.
$ ls -la /system/build.prop
-rw-r--r-- 1 root root 4876 2009-01-01 03:00 /system/build.prop
More info, flashing twrp as opposed to just booting it had the same effect. I tried that because of what you said Droidriven, BTW thanks for your help so far.
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
tronik said:
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
Click to expand...
Click to collapse
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
mgbelisle said:
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
Click to expand...
Click to collapse
Appreciate the prompt response. Yeah, I'm using twrp 3.0.2-2 also, and I've tried numerous versions of SuperSU all failing with the same sepolicy update error... I just don't get it. Never had these problems before Nougat.
Just tried with the specific one in the article you linked:
"Patching sepolicy
--- Failure, aborting"
So weird. Anyway, glad to know yours was fixed!
edit:
I finally decided to try this other root method (phh) and it is working: http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
I don't know why my trusty SuperSU no longer works.
Oh well.
My native language is not English.
I am sorry, but I do not understand native English.
This operation is very dangerous.
Enables writing to "/".
All at your own risk.
Devices preinstalled with android 10 or later are
Even if you root the device, it will still be r/o and you will not be able to edit it at all.
By running this script, you can r/w the system itself.
We will use makeSystemRW and makesysrw_repair created by lebigmac.
You will need a linux system to run makesysrw_repair.
[SCRIPT][Android 10+] Universal Mount System read write R/W
I would like to thank lebigmac for creating this script.
1. After unlocking the boot loader and becoming root, disable all vbmeta.
Code:
fastboot -–disable-verity -–disable-verification flash vbmeta vbmeta.img
fastboot -–disable-verity -–disable-verification flash vbmeta_system vbmeta_system.img
2. Copy makeSystemRW to /data/local/tmp of edge s.
3. Run makeSystemRW.
Code:
adb shell
su
chmod +x /data/local/tmp/makesysrw_1.31/makesysrw.sh
setenforce 0
./data/local/tmp/makesysrw_1.31/makesysrw.sh size=20
An error will occur here and it will fail.
You need to use makesysrw_repair.
4. Run makesysrw_repair.
Copy makesysrw_repair, open a terminal at the location where you copied it, and run the code.
Code:
sudo bash makesysrw_repair.sh
We have confirmed that this command is executable on Ubuntu.
5. Finish.
You are now done.
You can mount it with r/w using the root explorer.
Make sure that you can create new files and folders.
Would like to do this but why hasn't anyone else posted on this thread regarding success or fails?
nexus7lte said:
Would like to do this but why hasn't anyone else posted on this thread regarding success or fails?
Click to expand...
Click to collapse
I guess no one tried it, or they did and never commented
Thank you for your interest in my SystemRW/SuperRW feat. MakeRW project.
Yes I got the project thread closed while I was enjoying the summer holidays. Everyone needs a well deserved break every once in a while. I'll have it reopened as soon as I'm ready to publish the new version of my script. Hopefully soon
It's looking like a fall release rather than a summer release though... Time flies...
The old version 1.32 works in A10, A11 and some folks even got it to work in A12 simply by disabling the sdkCheck() function
The new version should have A13 support straight out of the box if everything goes according to plan. Wish me luck! Thanks!
Cheers
i would like to try this just to get rid of the annoying Android 12 update message.
Evan after disabling google play services notifications and freezing the OTAs, I still cant stop
com.motorola.ccc.ota and I assume thats because its on a read only portion, right? ADB commands didnt work.
My error in adb or terminal is_
u
:/ # pm disable com.motorola.ccc.ota
Exception occurred while executing 'disable':
java.lang.SecurityException: Cannot disable a protected package: com.motorola.ccc.ota
Hi @nexus7lte
Did you get my SystemRW/SuperRW feat. MakeRW script to work on your Android 12 device?
Is it the Motorola Moto G100 ? How do you like it?
Yeah disabling those protected system packages can be tricky sometimes. I'm sure it's possible somehow.
On Xiaomi devices we also got this Xiaomi security app and I can't disable it even as root with full rw access but I'm sure a true expert could do it
lebigmac said:
Hi @nexus7lte
Did you get my SystemRW/SuperRW feat. MakeRW script to work on your Android 12 device?
Is it the Motorola Moto G100 ? How do you like it?
Yeah disabling those protected system packages can be tricky sometimes. I'm sure it's possible somehow.
On Xiaomi devices we also got this Xiaomi security app and I can't disable it even as root with full rw access but I'm sure a true expert could do it
Click to expand...
Click to collapse
Well... I tried your script on my new Realme GT Neo 3T android 12. It booted but seems like nothing changed. Mounting system still says "mount: '/system' not in /proc/mounts"
Vipxpert said:
Mounting system still says "mount: '/system' not in /proc/mounts"
Click to expand...
Click to collapse
Hi. That's a nice device you've got!
Are you sure you're calling the command as root?
Usually you get this error message if you try to remount something as shell user...
Or you're trying to remount the wrong path. Try mount -o remount,rw /
Without seeing any screenshots or at least your log it's very difficult to tell what's wrong on your device from here. Did you check if my script successfully removed the infamous shared_blocks read-only feature from your phone?
Bash:
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $a | grep -e "feat" -e "vol"; done
lebigmac said:
Hi. That's a nice device you've got!
Are you sure you're calling the command as root?
Usually you get this error message if you try to remount something as shell user...
Or you're trying to remount the wrong path. Try mount -o remount,rw /
Without seeing any screenshots or at least your log it's very difficult to tell what's wrong on your device from here. Did you check if my script successfully removed the infamous shared_blocks read-only feature from your phone?
Bash:
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $a | grep -e "feat" -e "vol"; done
Click to expand...
Click to collapse
Here I have flashed it through EX kernel manager since there's no TWRP for Neo 3T or even a forum yet. Do u need a full log somewhere though?
lebigmac said:
Hi. That's a nice device you've got!
Are you sure you're calling the command as root?
Usually you get this error message if you try to remount something as shell user...
Or you're trying to remount the wrong path. Try mount -o remount,rw /
Without seeing any screenshots or at least your log it's very difficult to tell what's wrong on your device from here. Did you check if my script successfully removed the infamous shared_blocks read-only feature from your phone?
Bash:
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $a | grep -e "feat" -e "vol"; done
Click to expand...
Click to collapse
Ah here I found
Also I tried copy-paste your code. It gives a bunch of nonsenses hmm...
Same this result for me even with your command
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $ etc
Or if i flashed rw fixed_super.bin
Device not able to boot anymore
Hi @Vipxpert thanks for your log and for the screenshots!
I don't understand why the script didn't detect your shared_blocks read-only feature...
Are you saying the script didn't do anything and you flashed the resulting super_fixed.bin to your super partition and phone still boots in read-only mode?
Oh yeah right I forgot that OnePlus devices usually have dozens of useless pseudo (cow) partitions in its partition table...
To find out if your device has got the infamous shared_blocks read-only feature please try this updated code. Good luck!
Bash:
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $a | grep -e "feat" -e "vol" -e "mounted on"; done
Or like this:
Bash:
adb shell
su
for a in `seq 0 5`; do tune2fs -l /dev/block/dm-$a | grep -e "feat" -e "vol" -e "mounted on"; done
@Mr Hassan bootloops are always very sad . Do you have any idea why it happened?
Try to boot into TWRP and pull any log files to find out reason for error and then reflash original stock super.img and phone should boot again Good luck!
lebigmac said:
Hi @Vipxpert thanks for your log and for the screenshots!
I don't understand why the script didn't detect your shared_blocks read-only feature...
Are you saying the script didn't do anything and you flashed the resulting super_fixed.bin to your super partition and phone still boots in read-only mode?
Oh yeah right I forgot that OnePlus devices usually have dozens of useless pseudo (cow) partitions in its partition table...
To find out if your device has got the infamous shared_blocks read-only feature please try this updated code. Good luck!
Bash:
adb shell
su
for a in /dev/block/dm-*; do tune2fs -l $a | grep -e "feat" -e "vol" -e "mounted on"; done
Or like this:
Bash:
adb shell
su
for a in `seq 0 5`; do tune2fs -l /dev/block/dm-$a | grep -e "feat" -e "vol" -e "mounted on"; done
@Mr Hassan bootloops are always very sad . Do you have any idea why it happened?
Try to boot into TWRP and pull any log files to find out reason for error and then reflash original stock super.img and phone should boot again Good luck!
Click to expand...
Click to collapse
I even try stock super but device wont boot until flash back stock
And hes oneplus have somekinda cow partitions etc
I see when i try flash its asked to delete all cow parts
Don't know what's this
Yeh I did flash it with "fastboot flash super super-fixed.bin" and that took no effect ://
Anyways here're the results of your 2 commands. They seem not to end up well
@lebigmac mention mention
Well it looks like your /product partition does indeed have the infamous shared_blocks read-only feature.
I know that's a stupid feature but this is actually good news. This means new upcoming version of my script should be able to do the job
lebigmac said:
Well it looks like your /product partition does indeed have the infamous shared_blocks read-only feature.
I know that's a stupid feature but this is actually good news. This means new upcoming version of my script should be able to do the job
Click to expand...
Click to collapse
Yess!! U're the hero thanks so much now I can debloat, fake Google daydream service, add AR supports, edit mixer_path.xml for volume and tons of stuffs. Oh I miss those time a lot ^^^
lebigmac said:
Well it looks like your /product partition does indeed have the infamous shared_blocks read-only feature.
I know that's a stupid feature but this is actually good news. This means new upcoming version of my script should be able to do the job
Click to expand...
Click to collapse
any any estimate of days or release date