Related
I've been rooting a lot of nooks lately... around 60 of them so far. Some of the nooks I've purchased turned out to be the in-store demo devices. These models just run a loop, advertising the features. My procedure has been:
-using NookManager, reset to the factory image, this wipes out the advertising loop app
-register all the devices to the same email address, for uniformity
-upgrade the devices to 1.2.1 via usb
-use NookManager to root the device
-install my software
However, I've recently come across half a dozen nooks where the factory image IS the advertising loop. These devices are still rootable, however, they are preconfigured in their factory image with their "TEST NOOKUSER" owner and "[email protected]" account email address. In addition, the "Erase and Deregister Device" option is grayed out.
Summary of unusualness:
-adb via USB not recognized (ADB works via wifi inside NookManager)
-owner/account not editable
-screen time out greyed out at 2 minutes
-adb install -r pickyourfavorite.apk yields "/system/bin/sh: pm: not found" so this renders installing impossible
For the curious, these units are generally 1.0.0 or 1.1.0 software versions.
What are the ideas on the way forward here? I'm sure a lot of these demo devices will be hitting flea markets.
Anders
Anders
I wonder if it would be possible to flash 1.2.1 using CWM? Perhaps that would get you out of the demo loop. I have never tried anything like this, so it is just speculation.
I'd try the unbricking procedure in this thread.
Essentially, you want to save the rom partition from the problem device. Then restore an image from a properly working device. Then restore the rom partition. The thread doesn't go into fixing the rom partition data backup that is in the factory partition in rombackup.zip. Depending on what you're doing with the NST you might want to restore that as well when you're done. Come to think of it, you might want to look at that zip file before you do anything. Unzip it and see if devconf/OperatingMode has Normal in it. If not, change it and zip it back up then do your factory restore.
David0226 said:
I wonder if it would be possible to flash 1.2.1 using CWM? Perhaps that would get you out of the demo loop. I have never tried anything like this, so it is just speculation.
Click to expand...
Click to collapse
Yup, it's absolutely possible to upgrade them to 1.2.1 using the "copy over via USB" method.
Does not get rid of the demo loop though.
Anders
Isn't demo mode just here?
Code:
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
update system set value=0 where name='demo_mode';
.q
If Renate's idea doesn't work, you could try booting into NookManager and connecting using ADB. Once in an adb shell, you can mount the device's internal /system partition using this procedure:
mkdir /int_sys
mount -o rw /dev/block/mmcblk0p5 /int_sys
At this point, try going into /int_sys/app and renaming DemoMode.apk so that when the Nook boots and tries to enter the DemoMode, it can't because the app is gone. This should at least get you access so that you can make other necessary changes.
factory resetting via stock recovery worked for me
i had this problem with one of the nooks i found on ebay. i had to change OperatingMode in rom partition to Normal, and do a factory reset to get out of demo mode. I didn't bother fixing the romrestore.zip
I have a FTV that is rooted and still at 51.1.0.1 I want to upgrade to 51.1.1.0_user_511070220, but don't want to risk going to the latest 51.1.2.0 unrootable version. Can I use adb to copy the upgrade to /cache and upgrade locally with the box disconnected from the internet or does it need to call home when I am doing the local upgrade? I can also block the update sites in the router firewall:
amzdigitaldownloads.edgesuite.net
softwareupdates.amazon.com
once this is done, I can re-run towelroot and disable OTA.
Any advise on the best way to proceed is appreciated.
Thanks in advance for everyone's help!
Yes, do the manual upgrade to the latest rootable firmware. Follow the directions on http://www.aftvnews.com/how-to-manually-upgrade-or-downgrade-the-amazon-fire-tv/ That is the best way to upgrade without jumping through each upgrade.
It will need internet connection, I removed mine before upgrade and it would not let me proceed and get stuck on the network selection pickup. Maybe after you have pushed the upgrade.zip to your cache and send it a recovery reboot command, you can disconnect the internet. I did not, so not sure if that works.
Before you do anything, make sure you have blocked those 2 sites. Re-verify it before you proceed.
Once you upgrade, immediately disable the FTV upgrade package. I would suggest to keep the blocks on those 2 sites even after you disable the FTV auto upgrade.
dbdoshi said:
Yes, do the manual upgrade to the latest rootable firmware. Follow the directions on http://www.aftvnews.com/how-to-manually-upgrade-or-downgrade-the-amazon-fire-tv/ That is the best way to upgrade without jumping through each upgrade.
It will need internet connection, I removed mine before upgrade and it would not let me proceed and get stuck on the network selection pickup. Maybe after you have pushed the upgrade.zip to your cache and send it a recovery reboot command, you can disconnect the internet. I did not, so not sure if that works.
Before you do anything, make sure you have blocked those 2 sites. Re-verify it before you proceed.
Once you upgrade, immediately disable the FTV upgrade package. I would suggest to keep the blocks on those 2 sites even after you disable the FTV auto upgrade.
Click to expand...
Click to collapse
If you have dcp blocked before doing the update, it should remain blocked after the update.
rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
Thanks, that is good to know and comforting.
rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
You are probably right, I am a novice to this. But, I swear to God, I seem to remember not dcp blocking it on a friend's FTV when I upgraded his to the latest rootable firmware and checking the system on FTV did not generate the error or "Checking now..." message (His was blocked before the OTA upgrade). So, to clarify, the block remains for OTA and manual upgrade both?
dbdoshi said:
You are probably right, I am a novice to this. But, I swear to God, I seem to remember not dcp blocking it on a friend's FTV when I upgraded his to the latest rootable firmware and checking the system on FTV did not generate the error or "Checking now..." message (His was blocked before the OTA upgrade). So, to clarify, the block remains for OTA and manual upgrade both?
Click to expand...
Click to collapse
The block *should* remain. I can't imagine why it wouldn't. But I haven't really done any extensive testing on it. Doing the OTA and doing the manual upgrade are the same. The manual upgrade is manually doing exactly what the OTA does. The OTA downloads the .bin file, and tells recovery to flash it and reboots to recovery. The problem comes if you get an OTA update to the unrootable firmware. The dcp will remain blocked, but you won't be able to gain root anymore.
rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
I updated the box to 51.1.1.0_user_511070220 last night. No problems at all. I used this process to update the box:
http://forum.xda-developers.com/showthread.php?t=2796067
I used ftp to binary transfer the update file to /cache/update.zip and I set r/w permissions on this file.
the /cache/recovery folder did not exist (needed in tutorial above) so I created it and did a chmod 777 /cache/recovery
Once the update completed, I re-rooted the box - towelroot, Let it rain button.
I forgot to check if the dcp package was still disabled. I ssh'ed to the box and disabled it just to make sure.
I also had to run busybox to re-install it.
I was using the install-recovery-2.sh trick to mount my usb stick, so I lost this and had to recreate /system/etc/install-recovery-2.sh (set execute permission on it and add the line:
mount -t ext4 /dev/block/sda1 /data/sdext2
install-recovery-2.sh is a non-existent file that is called in the last line of install-recovery.sh. This is executed during the boot process and can be used to execute commands when booting. To take advantage of this, create the install-recovery-2.sh file and add the lines you want executed. you have to set execute permission on the file.
su
mount -o rw,remount /system
create and add commands to /system/etc/install-recovery-2.sh
( I added: mount -t ext4 /dev/block/sda1 /data/sdext2 (where /data/sdext2 is where I want my flash drive to show up)
chmod 755 /system/etc/install-recovery-2.sh
mount -o ro,remount /system
exit
Can this be used to exploit much more interesting commands?
Such as making a backdoor for rooting the unrootable OTA update and even unlocking the bootloader/Custom ROM?
Edit:What about overclocking by permanently modifying the related files to set GPU to minimum 400Mhz and maximum 500Mhz and overclocking the CPUs to a maximum of 1.9Ghz or 2.0Ghz?
If it can be used to overclock,please elaborate on how you can do it?
I posted the directory of the related files in a topic a while back.
retroben said:
Can this be used to exploit much more interesting commands?
Such as making a backdoor for rooting the unrootable OTA update and even unlocking the bootloader/Custom ROM?
Click to expand...
Click to collapse
So that is a good idea, but unfortunately the first thing that happens when you install the OTA is it wipes /system. But once you have root, anything you could put in that script, you could manually run as root, so it can't let you do anything extra.
As for custom roms, the good news is that the OS on the Fire TV is pretty much stock CAF android. The kernel can boot AOSP/CM as is. And using a similar but different script earlier in the boot process, I'm able to get Safestrap working. I currently have Clockwork mod working, but Safestrap uses TWRP and as of yet I have been unable to get TWRP to display anything on the TV. I'm going to try to work on it some more this weekend.
rbox said:
So that is a good idea, but unfortunately the first thing that happens when you install the OTA is it wipes /system. But once you have root, anything you could put in that script, you could manually run as root, so it can't let you do anything extra.
As for custom roms, the good news is that the OS on the Fire TV is pretty much stock CAF android. The kernel can boot AOSP/CM as is. And using a similar but different script earlier in the boot process, I'm able to get Safestrap working. I currently have Clockwork mod working, but Safestrap uses TWRP and as of yet I have been unable to get TWRP to display anything on the TV. I'm going to try to work on it some more this weekend.
Click to expand...
Click to collapse
Rbox,
Sounds very interesting. Keep the good work.
rayosx said:
Rbox,
Sounds very interesting. Keep the good work.
Click to expand...
Click to collapse
So I was finally able to get TWRP booting and displaying (in the correct colors). As you can see, it doesn't fill the screen. The problem is TWRP needs theme files to match the resolution, and it currently has no support for 1080p, although adding support for 1080p isn't the problem. It's figuring out if I should add in dynamic switching support to let it switch between 1080p and 720p. Which is why I need people to fill out the poll I created here.
The other problem with 720p is my TV is 1080p, so I can't really test it. Does anyone know if there is TWRP support for any of the other android based TV devices like OYUA or whatever?
What?
The 720p mode works on 1080p TVs since I used that mode briefly until switching to 1080p for better quality.
retroben said:
What?
The 720p mode works on 1080p TVs since I used that mode briefly until switching to 1080p for better quality.
Click to expand...
Click to collapse
Unfortunately in recovery, if the graphics are 720p then it won't fill the screen at 1080p. Although now that I think about it, I wonder if I could set it up to just scale up from 720 to 1080. That would probably be easiest.
I just managed to get TWRP running on the new Shield console, and installed SuperSU successfully. Two caveats: the display is upside down, and the USB host ports don't work. I had to plugin a mouse via an OTG cable in order to interact with it. ETA: That's only an issue when booted to TWRP. Everything's working fine in the stock ROM after rooting.
Procedure:
- enable developer tools / USB debugging
- adb push supersu.zip /sdcard
- adb reboot bootloader
- fastboot oem unlock
- fastboot boot twrp-2.8.6.0-shieldtv-unofficial.img
- unplug USB cable, connect mouse via USB, install SuperSU
TWRP boot image is attached. Off to explore...
EDIT: by request, some more detailed instructions:
On the Shield device, head to Settings -> About, and click "Build number" 7 times. This will enable Android's Developer options.
Go to Settings -> Developer options, and enable USB debugging.
Install the ADB/fastboot drivers and utilities if you don't already have them. When "adb devices" shows your Shield, you're good to go.
Download and extract recovery.zip from this thread.
Head to the SuperSU forum and download the latest version.
Open a command prompt and navigate to the directory where you downloaded everything. (Google this for your OS if you don't know how).
With the Shield still booted, run "adb push supersu.zip /sdcard" (change supersu.zip to appropriate file name). This will upload the SuperSU update zip to your device, which you'll install from TWRP.
If that worked fine, run "adb reboot bootloader". Your device should shut down, and display the Fastboot screen after a few seconds.
FOLLOW THE NEXT THREE INSTRUCTIONS AT YOUR OWN RISK. This WILL wipe all your user data, back it up with ADB first if you want to preserve it. DISCLAIMER #2: I have no idea if there are any DRM keys or anything that get wiped when this is done (this was the case on my Xperia Z3 Compact). I will say that Grid streaming still works fine after doing this.
This step will unlock your bootloader to enable booting unsigned images.
Run "fastboot devices" and make sure your Shield is visible.
Run "fastboot oem unlock" and follow the prompts on the screen. Your bootloader is now unlocked.
Now, boot the TWRP image with: "fastboot boot twrp-2.8.6.0-shieldtv-unofficial.img" - Note: I used this instead of "fastboot flash" so I could keep the stock recovery around, to grab an image of it after rooting.
You should now see a TWRP recovery menu (upside down for now).
Connect a keyboard or mouse via OTG cable, and select "Install", navigate to your SuperSU zip, select it, and follow the prompts.
Click "reboot" and you should now be rooted.
Great job. Will try later.
It offers fastboot OEM unlock?!? Sweet
I'm starting dev work on this as well. Can you try the flipped screen flag and see if it that fixes the display? That's required to make the tablet work correctly. I preordered the pro edition, so I can't test anything for almost another two weeks. Hopefully someone will be able to get the normal usb ports working, since it'll be much easier to use those for a mouse/keyboard.
Sweet can't wait to try this out
Thanks for posting this. I've got my NVIDIA Shield Android TV coming on Wednesday, so I'll give this a try. I had a USB OTG cable, but lost it several months ago so I ordered another one of those as well. Just to clarify... the 2 USB 3.0 ports will work after rooting when you boot back to stock, right?
Also, this works on the latest 1.1 OTA update too, correct?
Sorry to ask this as it is super n00bish, but could someone explain to me step-by-step directions for rooting this or perhaps link to a guide that uses this same procedure? I know the main steps are listed in the OP, but I'm not really sure how to use adb to push supersu.zip, reboot into bootloader, fastboot, etc.
Lastly, what will be the process of upgrading via OTA updates in the future after I root it? Will I need to unroot one way or another (instructions or a link to a guide would be great), or will OTA updates work just fine?
Once again, sorry for all the n00b questions. I just want to make sure I don't do something stupid to mess the device up...
FreeEmulator said:
Thanks for posting this. I've got my NVIDIA Shield Android TV coming on Wednesday, so I'll give this a try. I had a USB OTG cable, but lost it several months ago so I ordered another one of those as well. Just to clarify... the 2 USB 3.0 ports will work after rooting when you boot back to stock, right? Also, this works on the latest 1.1 OTA update too, correct?
Also, sorry to ask this as it is super n00bish, but could someone explain to me step-by-step directions for rooting this or perhaps link to a guide that uses this same procedure? I know the main steps are listed in the OP, but I'm not really sure how to use adb to push supersu.zip, reboot into bootloader, fastboot, etc.
Click to expand...
Click to collapse
Yup, everything works normally after rooting. These issues only exist in TWRP because I did an extremely quick and dirty build (extracted a Shield Tablet TWRP and replaced the kernel). I'll work on fixing them soon, unless someone beats me to it. Thanks for the tip on the screen flipping, Steel01.
I've updated the OP with some more detailed instructions.
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
teletype said:
Yup, everything works normally after rooting. These issues only exist in TWRP because I did an extremely quick and dirty build (extracted a Shield Tablet TWRP and replaced the kernel). I'll work on fixing them soon, unless someone beats me to it. Thanks for the tip on the screen flipping, Steel01.
I've updated the OP with some more detailed instructions.
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
Click to expand...
Click to collapse
Awesome, thank you so much for the info and instructions. :good: I should be good to go now once everything arrives on Wednesday.
Twrp for forge?
Is there any skilled folks out the with a forge tv? I'm in need of some kind of recovery for this. I'm a bit of a noob so compiling it on my own is kinda greek to me
Quick warning for Pro owners: OEM Unlock takes about 92 minutes. Just be warned and ready for it...
Yeah so go to links with viruses in them and then waste time removing them. You know there are website without a million links to viruses all over them that can be used. It's always nice not to have to play guess which download link isn't a virus. -_-
i read somewhere that full hd/4k playback in netflix and other vod services needs a locked bootloader. is that right?
A.N.Droid said:
i read somewhere that full hd/4k playback in netflix and other vod services needs a locked bootloader. is that right?
Click to expand...
Click to collapse
Hypothetically if you can oem unlock bootloader can you just oem lock bootloader to fix the issue?
teletype said:
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
Click to expand...
Click to collapse
Actually rooting will likely break OTA updates. Since lollipop, Google has moved to block level OTA updates. That means it doesn't just patch individual files, it patches at the block level. So if there is a change to /system the OTA won't update.
The same seems to apply to the Shield TV. Here's the updater-script from the current OTA:
Code:
(!less_than_int(1432624016, getprop("ro.build.date.utc"))) || abort("Can't install this package (Tue May 26 00:06:56 PDT 2015) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "foster" || abort("This package is for \"foster\" devices; this is a \"" + getprop("ro.product.device") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/platform/sdhci-tegra.3/by-name/APP", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/platform/sdhci-tegra.3/by-name/LNX");
show_progress(0.200000, 10);
nv_copy_blob_file("blob", "/staging");
nv_copy_blob_file("bmp.blob", "/bmps");
But borked OTA shouldn't be much of an issue, since Nvidia is releasing the fastboot factory images: https://developer.nvidia.com/shield-open-source The text is there now for them, but they aren't up yet. So you can always revert to stock, then OTA update.
Wait... What? You got one of of the tablet twrps to boot on the console? I'm shocked that worked. Didn't think it what that easy to get 32-bit mode. Anyways, that's why it's upside down, because that flag is set for the tablet. As soon as a console section opens up here and on androidfilehost, I'll post my builds. I have cm, twrp, and multirom compiling, but I can't test them until next week, when Amazon ships the pro, so they might not even boot.
@agrabren: Oh my goodness, the wipe takes that long? What's it doing? US Government certified nuking? And people complain about multi minute cache wipes on the tablet now. What am I going to be hearing in a couple weeks for this?
Actually, since you're around again... Do you still have the CM files you made for the portable? I'm still interested in what you did to make the cwm recovery work as well as it did.
One more quick question for now... once rooted, does anyone know how I would go about locking the GPU clock speed / frequency at its highest setting (which if I've read correctly is 1 GHz)? I'd like to be able to flip the lock on only while testing out some pretty hardware intensive emulator games (the Dolphin GameCube/Wii emulator, which I was told by a developer of the emulator to try to lock the maximum GPU clock speed to ensure best performance). Thanks again for all the help, you guys are great.
Tested out the pro console on my side (Got it early due to reasons).
It refuses to mount any partitions, so it is impossible to root.
sonicadvance1 said:
Tested out the pro console on my side (Got it early due to reasons).
It refuses to mount any partitions, so it is impossible to root.
Click to expand...
Click to collapse
It's probably because the partition layout/names are different for the internal 500GB drive. If you poke around you can probably find the info, or just dump your boot.img, decompile it and look for the fstab file. It will look similar to the below (that is for the ADT-1).
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/system /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/cache /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check
/dev/block/platform/sdhci-tegra.3/by-name/userdata /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/crypto
/dev/block/platform/sdhci-tegra.3/by-name/misc /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/boot /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/recovery /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/DTB /dtb emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/staging /staging emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/sysdata /sysdata emmc defaults defaults
Someone skilled do this also for Forge anyways hopefully XDA adds Android TV forums.
Keep up the good work even though I don't own the Shield.
patt2k said:
Someone skilled do this also for Forge anyways hopefully XDA adds Android TV forums.
Keep up the good work even though I don't own the Shield.
Click to expand...
Click to collapse
The forge has a locked bootloader. Sure, you can root it (supposedly), then replace the recovery, but you'll never be able to use fastboot until it's unlocked.
BTW, the Nvidia Shield TV factory images are up now :victory:
How to I Install Xposed on Rooted Amazon Fire TV 2? (Guide Please)
Do I download XposedInstaller_3.0_alpha4.apk? and xposed-v78-sdk21-arm64.zip?
Please Help
Could I Use Flashfire?
You can't install xposed since there is no custom recovery
Tried with Flashfire where no custom recovery is needed ? what version of xposed should i try?
No Luck with Flashfire and xposed v78-sdk22-arm 64. Going to have to wait for a fix
yeah I've had no luck, just have to wait I guess
ians325 said:
No Luck with Flashfire and xposed v78-sdk22-arm 64. Going to have to wait for a fix
Click to expand...
Click to collapse
Did you encounter boot loop or soft-brick when you attempted this?
z_thompsonpa said:
Did you encounter boot loop or soft-brick when you attempted this?
Click to expand...
Click to collapse
No
ians325 said:
No
Click to expand...
Click to collapse
Thanks! You prompted me to give this a shot after confirming that it wouldn't do any serious damage. I found some things out in the process that explain why this isn't working as of yet.
The Xposed zip you mentioned requires the following Linux GNU tools (or equivalent):
cut
find
head
sed
I suspect this is why it is failing, because I was able to backup my system partition and restore my backed-up system partition through FlashFire. (more on this later)
Sooo.. I thought why not go all the way and try to install BusyBox first? ..since this would fix the missing commands
Much to my surprise the Busybox install actually worked and I had the whole suite of linux commands at my disposal!!!
Things went south pretty quick, though, when I realized that SELinux was blocking my ability to run the following command:
I couldn't run this command:
Code:
mount -o remount rw /system
So, this would prevent a further attempt at installing Xposed through Flashfire, because it would have to mount the system partition as rw in order to modify the files and add the Xposed framework.
I ended up restoring my system partition after this fiasco using Flashfire. It re-enabled my ability to remount /system as rw and SELinux has seemed to calm down in the logs.
In conclusion:
Xposed requires Busybox
[*]SELinux enforces more policies when Busybox is installed
[*]Setting SELinux to Permissive has no effect
EDIT: **Details in my next post**
z_thompsonpa said:
Thanks! You prompted me to give this a shot after confirming that it wouldn't do any serious damage. I found some things out in the process that explain why this isn't working as of yet.
The Xposed zip you mentioned requires the following Linux GNU tools (or equivalent):
cut
find
head
sed
I suspect this is why it is failing, because I was able to backup my system partition and restore my backed-up system partition through FlashFire. (more on this later)
Sooo.. I thought why not go all the way and try to install BusyBox first? ..since this would fix the missing commands
Much to my surprise the Busybox install actually worked and I had the whole suite of linux commands at my disposal!!!
Things went south pretty quick, though, when I realized that SELinux was blocking my ability to run the following command:
Code:
mount -o remount rw /system
So, this would prevent a further attempt at installing Xposed through Flashfire, because it would have to mount the system partition as rw in order to modify the files and add the Xposed framework.
I ended up restoring my system partition after this fiasco using Flashfire. It re-enabled my ability to remount /system as rw and SELinux has seemed to calm down in the logs.
In conclusion:
Xposed requires Busybox
SELinux enforces more policies when Busybox is installed
Setting SELinux to Permissive has no effect
Click to expand...
Click to collapse
Nice work, have you seen this tidbit on BusyBox Github for SELinux?
https://github.com/ukanth/afwall/wiki/BusyBox#difference-between-selinux-and-non-selinux-busybox
There's also some decent results on Google that may offer some clues... https://www.google.com/search?q=SELinux+mount+system+as+rw+android&ie=utf-8&oe=utf-8
fldash said:
Nice work, have you seen this tidbit on BusyBox Github for SELinux?
https://github.com/ukanth/afwall/wiki/BusyBox#difference-between-selinux-and-non-selinux-busybox
There's also some decent results on Google that may offer some clues... https://www.google.com/search?q=SELinux+mount+system+as+rw+android&ie=utf-8&oe=utf-8
Click to expand...
Click to collapse
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.
keep up the good work
z_thompsonpa said:
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.
Click to expand...
Click to collapse
How are you restoring your system partition? Using that diff patcher (for root) with a USB A-A cable?
fldash said:
How are you restoring your system partition? Using that diff patcher (for root) with a USB A-A cable?
Click to expand...
Click to collapse
I haven't had to break out the USB A-A cable yet... thankfully (except for root of course).
I used Flashfire to backup my /system partition as RAW backup before I started all of this experimentation. I have just been restoring back to this known good state using Flashfire after each time I corrupt the system partition.
I intended on trying this method, and if it didn't work to fall back to the method mentioned in the root thread. I checked the logs last night and Flashfire seems to be succeeding at this task, at least.
Right now, I am picking through the Xposed installer script source and using the Flashfire logs to debug why it is failing. It appears to be a permissions issue, but a lot of the stdout/stderr is suppressed so its hard to tell exactly where. When I get home today, I am going to try to modify the installer script to produce more output so I can debug the issue further. If I cant figure it out, I'll post my findings either way.
I've fixed a few bugs in the flash script already, but it always errors on overwriting:
Code:
/system/lib/libart.so
It's throwing some error about read-only filesystem. (I'll post exact error later)
I've thrown in some checks to see if the /system mount is unmounting or something odd like that, but that's not it.
I've got a few guesses as to why, but I am not going to mention them until I have more solid evidence.
Any advice would help as well... I just wanted to post the update I promised.
z_thompsonpa said:
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.
Click to expand...
Click to collapse
z_thompsonpa said:
I've fixed a few bugs in the flash script already, but it always errors on overwriting:
Code:
/system/lib/libart.so
It's throwing some error about read-only filesystem. (I'll post exact error later)
I've thrown in some checks to see if the /system mount is unmounting or something odd like that, but that's not it.
I've got a few guesses as to why, but I am not going to mention them until I have more solid evidence.
Any advice would help as well... I just wanted to post the update I promised.
Click to expand...
Click to collapse
I think we should go another method. Use the tools in the root thread to just create an image with Xposed/root and just do a DIFF.
fldash said:
I think we should go another method. Use the tools in the root thread to just create an image with Xposed/root and just do a DIFF.
Click to expand...
Click to collapse
I think so... I am pretty sure its a dead end. I also tested using adb to write the files and it failed on /system/lib/libart.so, as well. It's, I believe, because the object is loaded in memory?? don't quote me on that... but loading through preloader, I think, would avoid this limitation as ART is not running.
So can anyone in here tell me if its possible to have xposed on fire tv 2 5.0.5 thats rooted and now has twrp recovery on ? I have tried to flash the xposed zip in recovery but when i reboot its stuck at amazon logo. Went back into recovery and flashed rbox's pre rooted 5.0.5 and booted normally. Id like to have (im sure many others would also) xposed and playstore, ive searched the forums but because rbox method is new there is no information on this subject now.
sconnyuk said:
So can anyone in here tell me if its possible to have xposed on fire tv 2 5.0.5 thats rooted and now has twrp recovery on ? I have tried to flash the xposed zip in recovery but when i reboot its stuck at amazon logo. Went back into recovery and flashed rbox's pre rooted 5.0.5 and booted normally. Id like to have (im sure many others would also) xposed and playstore, ive searched the forums but because rbox method is new there is no information on this subject now.
Click to expand...
Click to collapse
Use this method, I've slightly modified the text from another post & added it into a text file for you, this works a 100% but as usual I take no responsibility if you do any thing wrong & brick the Fire Tv2.
Enjoy & press that thanks button If this helped you
Thanks for this. I will try it shortly and report back if it works for me. I have stumbled upon another thread that the guys seem to be working on playstore issues, http://forum.xda-developers.com/fire-tv/help/q-guide-to-getting-google-play-rbox-t3310974
Made a guide here if anyone wants to install
http://forum.xda-developers.com/fire-tv/general/installing-xposed-fire-tv-2-guide-t3314142
I have managed to root my LG G3, using kingroot. Have what appears to be a Ghost push virus which either appears to be resident in Battery Control, which will not allow itself to be disabled, or something labelled Fakedupdt.q. The former was identified by Clean Manager and the latter by " Stubborn Trojan Killer", which unfortunately crashes when trying to remove the threat.
Please can you advise on how to get rid if these issues?
Regards,
Robert Young
[email protected] said:
I have managed to root my LG G3, using kingroot. Have what appears to be a Ghost push virus which either appears to be resident in Battery Control, which will not allow itself to be disabled, or something labelled Fakedupdt.q. The former was identified by Clean Manager and the latter by " Stubborn Trojan Killer", which unfortunately crashes when trying to remove the threat.
Please can you advise on how to get rid if these issues?
Regards,
Robert Young
Click to expand...
Click to collapse
Well one choice you have is to KDZ it back to stock. Doing so will wipe everything and put it back to factory.
If your rooted try using something like root app delete or something
Ghost Push Virus follow up
thewalkingdude said:
Well one choice you have is to KDZ it back to stock. Doing so will wipe everything and put it back to factory.
Click to expand...
Click to collapse
Excuse my ignorance, but kdz it back to stock? What does that entails?
[email protected] said:
Excuse my ignorance, but kdz it back to stock? What does that entails?
Click to expand...
Click to collapse
I do apologize I should have explained it. Your best bet is to search XDA. It would be easier for you to do that than me trying to explain it as I am not always the best at explaining.
Resolution
Root App Delete didn't solve the solution, but it did suggest the one that worked.
Downloaded Impactor_0.9.14 and connected phone in debugging mode
Opened shell to device and set to "SU"
Mounted system partition in RW mode
"mount -o remount rw /system"
Then used rm to remove "BatteryControl.apk", which was located in \system\priv-app\
Rebooted phone, job done