Related
I had downloaded a version of this file from a post embedded deep inside one of the threads over here (sorry can't find it right now), but upon examination of its contents, I discovered some issues:
1. The checksums on the files in contained in the the original zip file showed that B&N had at least two versions of 1.3.0 update you can download from them, and the zip I got contained an older version so I put in the latest files in there.
2. There were unnecessary files included inside the original zip file, I deleted those, and only included what was needed.
3. There were errors in the script syntax, which I corrected, so that the proper commands are run during the update, and the proper sed substitutions are made during the editing of the unpacked init.rc inside the ramdisk.
What this zip will do is replace any older version of a B&N ROM on the alternate eMMC partitions of a dual booting configurations to the latest versions. This will prevent B&N from pushing the 1.3.0 update to you OTA, and messing up your dual boot setup. Just put the zip on your sdcard, boot into CWM recovery, and apply the zip. I apologize in advance for not giving credit to the original creators of the scripts here.
Note: There have been two different protocols for a dual booting u-boot.bin, with an older one relying on the files u-boot.altimg, and u-boot.altram to specify the names of the secondary boot ramdisk and kernel, and a newer one assuming that they are named uAltRam, and uAltImg respectively. This update conforms to the new u-boot.bin protocol. If you are still using the old one, you will have to get root access to /boot and edit the two files to point to uAltRam and uAltImg.
So if you want try it out, here it is:
http://www.mediafire.com/?gcrpzzc0kdoxcjx
MD5 Sum: 51e24c1e5eff11ba5ea481a63f7404eb
Update
I have now uploaded files for B&N Update 1.4.1.
The first file (MD5 Sum: 4ff1d9764663278c3f51e2e2c9d841a6) is meant to update a pre 1.4.1 Stock B&N ROM on secondary /system through CWM:
https://rapidshare.com/files/52135913/secondary_update_NC_stock_1_4_1.zip
The second file (MD5 Sum: c1506816fbfb8c419fbbc4afe1b12887) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM without messing with recovery;
https://rapidshare.com/files/869435270/primary_update_NC_stock_1_4_1_keep_CWM.zip
The third file (MD5 Sum: ab1307c55a2c35c91d339c8037ce9a78) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM, replacing recovery and all:
https://rapidshare.com/files/2059644016/primary_update_NC_stock_1_4_1.zip
None of these files will wipe user apps and data, so if you wish to do that, boot into recovery and wipe from there. [This will work on primary /data partition only]
Please note: If the B&N Stock ROM is rooted, you will lose root upon updating.
Thanks!
This worked beautifully! I flashed it from my sdcard after booting into CWM on my primary partition on emmc.
I'm betting you got the original from jasoraso in this dual boot thread: http://forum.xda-developers.com/showpost.php?p=17122342&postcount=142
What I would love is a straight CWM-flashable 1.3 ROM, to include in my up-to-date (for now) guide for setting up the dual boot, rather than having to set up and move 1.2, then update to 1.3.
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Sent from my SAMSUNG-SGH-I897 using XDA App
rajendra82 said:
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
Click to expand...
Click to collapse
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
rajendra82 said:
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Click to expand...
Click to collapse
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Taosaur said:
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
Click to expand...
Click to collapse
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Taosaur said:
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Click to expand...
Click to collapse
No way to get around having to register the primary partition image first. Once that is done it could be moved to secondary and then updated straight to 1.3 instead of going 1.2 first.
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
yelloguy said:
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
Click to expand...
Click to collapse
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
rajendra82 said:
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Click to expand...
Click to collapse
I wouldn't know what to change and what to leave alone, myself, but I think you're making this more complicated than it needs to be. I'm talking about installing 1.3 using CWM, regardless of how the device is partitioned or what was on the primary partition previously. Like the files in this thread, but 1.3: http://forum.xda-developers.com/showthread.php?t=1050520.
I understand that you were just cleaning up jaso's update-dualboot-to-1.3 file. I used the original and it worked fine, but it would have saved me a couple steps (and would be more useful in a guide for setting up dualboot) to simply install 1.3 rather than 1.2 to the primary partition when setting up. The reason I started with 1.2 is because it is the most current stock ROM available for CWM. What I would like is to avoid a historical re-enactment of stock OS development altogether. A general-purpose, CWM-flashable 1.3 ROM would be broadly useful, but is so far lacking as far as I've seen.
1. Do you envision this to be an uprooted stock 1.3 update ROM (either as primary or the only boot option) ? I just don't see the need for this to be CWM flashable. It is very easy to get there by resetting the device to stock, and then updating the device to 1.3.0 using the B&N file, and restoring dual boot as need be. If one has any older stock ROM running on primary, the B&N update will get them to 1.3 while losing root. There is no need to apply 1.2 update first.
2. Do you envision this to be for already rooted single or primary booting 1.1/1.2 users? There is once again no need to create any file for this. One can simply apply the B&N update, and then rerun manual nooter, and restore dual booting to the secondary.
3. The only users with no clear upgrade path are those who have already moved the B&N ROM to secondary. That's why I fixed up the zip file, and shared it. I am glad the original file worked for you despite the script errors. I can see other setups where it would have failed though.
I am not trying to make this more complicated than it needs to be. The Nook Color is just capable of being set up in so many ways, there isn't simply going to be a single update method that will work in all scenarios.
Sent from my SAMSUNG-SGH-I897 using XDA App
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Taosaur said:
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Click to expand...
Click to collapse
Then the best bet is two step process:
1. Wipe device and restore to factory stock.
2. Download B&N 1.3 update file from website and place it on the root of SD card. Let the device recognize it, and apply it.
Once the 1.3 update gets applied, you are free to reroot, install CWM, set up dual booting, or whatever the next step may be.
It is the only method that will work in all circumstance as it involves starting from scratch regardless of setup. If want to preserve any of your current setup, no one step file will work for all circumstances. Some people have the stock firmware rooted, others do not. Some have the stock as the only internal boot, others have it as primary option of a dual booting configuration, while others have it as a secondary option. Some have stock recovery and run CWM off the sdcard when needed and want to update their recovery to the latest stock version, others want to keep the CWM recovery, and not update the recovery. There simply is no way file to cope with all these options.
rajendra82 said:
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
Click to expand...
Click to collapse
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
rajendra82 said:
1. Wipe device and restore to factory stock.
Click to expand...
Click to collapse
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
---------- Post added at 02:15 PM ---------- Previous post was at 01:58 PM ----------
yelloguy said:
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
Click to expand...
Click to collapse
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Taosaur said:
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Click to expand...
Click to collapse
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
Click to expand...
Click to collapse
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
Click to expand...
Click to collapse
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0p1 at the temporary location you created using the command:
mount /dev/block/mmcblk0p1 <full path to the directory you created>
4. Now use Astro to go over to the directory you created and mounted mmcblk0p1 into. You should see:
u-boot.bin which is the bootloader
u-boot.bin.stock which is the backup of the old stock bootloader
uImage and uRamdisk which are your primary kernel and ramdisk
uFImg and uFRam which are your secondary kernel and ramdisk (and whose names are mismatching the CM7 bootloader protocol)
u-boot.altimg and u-boot.altram, which are text files per the old bootloader method containing names of uFImg and uFRam
5. Rename uFImg to uAltImg, uFRam to uAltRam. And edit the contents of u-boot.altimg and u-boot.altram to match the new file names.
6. Reboot as usual into primary or secondary.
Now if an CM7 update ever replaces your u-boot.bin, you will not lose dual boot, as you have it set up as uAltImg and uAltRam per the new protocol.
Sent from my SAMSUNG-SGH-I897 using XDA App
---------- Post added at 03:24 PM ---------- Previous post was at 03:06 PM ----------
Taosaur said:
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
Click to expand...
Click to collapse
I am sorry if you think I am rationalizing, but that was not my intention. I just wanted to point out that the files you linked to do not meet your own criteria.
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible IMO, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
---------- Post added at 03:30 PM ---------- Previous post was at 03:24 PM ----------
Taosaur said:
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
Click to expand...
Click to collapse
It would work. If you apply my zip, there will be a uAltImg and uAltRam in /boot (in addition to uFImg and uFRam). If you apply another update that pushes the CM7 bootloader, it will then look for these files with trying to do an alternate boot, and would boot into a unrooted stock 1.3.
rajendra82 said:
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0 at the temporary location you created using the command:
mount /dev/block/mmcblk0 <full path to the directory you created>
Click to expand...
Click to collapse
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
yelloguy said:
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
Click to expand...
Click to collapse
I see a typo in my command (stupid Swiftkey X). It should be:
mount /dev/block/mmcblk0p1 <some directory>
Also try typing just mount in terminal to see if /dev/block/mmcblk0p1 is already mounted somewhere else.
rajendra82 said:
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter will lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
Click to expand...
Click to collapse
Riiiiight... it would install stock 1.3 to the device. That's the intended behavior. The point is to avoid the unnecessary step of updating in any process that includes flashing stock to the sole or primary partition. One example of such a process would be a fresh dual boot setup. That it does not update or otherwise rely upon an existing install is the point.
Granted, such a file would not repartition the device, but it would install up-to-date stock in one step regardless of how a device is partitioned (1/5, 2/5, 5/1 or dual boot).
Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (see this thread) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition, having almost bricked my tablet once by doing so.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
If anyone's interested, you can check out the uim-sysfs script I'm using for the copy & paste hack in the linked file in this thread.
Interesting and very useful for stock users. Well done!
~ Veronica
Stop it, BN. Stop it.
/init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist!
Click to expand...
Click to collapse
Interesting find. What is BN thinking with this manifest checking stuff. BN, just stop it. Seriously. Stop it.
Stop it, BN.
FWIW, uim-sysfs is the no-longer-used userspace side of the "shared transport" wireless daemon stuff (the other side is called "kim" in the kernel) that's used for bluetooth, FM, and gps on the 1271... it's used in CM7/CM9 (backported from 2.6.35 to 2.6.32) for nookcolor to make bluetooth work.
BN likely just modified TI's stock init.omap3.rc and left lines like the uim service as-is. Running this non-existent file as root is kinda a "security" hole, IMO, assuming the manifest verification was supposed to be some kind of security. Remove this, there will doubtlessly be other examples of the same thing.
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Nice discovery tho.
fattire said:
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Click to expand...
Click to collapse
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
care to share the files?
jichuan89 said:
Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (will post details later) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
Click to expand...
Click to collapse
would be nice if you can share some files
MikeCh said:
would be nice if you can share some files
Click to expand...
Click to collapse
If you're interested in copy & paste, I've now posted instructions at http://forum.xda-developers.com/showthread.php?t=1534757
jichuan89 said:
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
Click to expand...
Click to collapse
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
Click to expand...
Click to collapse
do you mean for the developer or end user?
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
Click to expand...
Click to collapse
but aren't you still moving framework files around "on the fly"?
Well, in any event it was a good observation that can be used for all kinds of purposes-- rooting, running background processes, etc. You could even drop a cwm recovery binary in there to instantly turn stock into cwm I bet...
fattire said:
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
Click to expand...
Click to collapse
True.
fattire said:
do you mean for the developer or end user?
Click to expand...
Click to collapse
I guess that's personal preference more than anything else. Please disregard.
fattire said:
but aren't you still moving framework files around "on the fly"?
Click to expand...
Click to collapse
Yes - but the process is automated by the script in uim-sysfs. From the user's perspective it's just copying a file to /system/bin say using ES File Explorer, rather than burning an image to an SD card and booting from it which appears to scare/confuse a lot of people. Also they wouldn't need a computer or a card reader or a spare SD card or a USB cable or any special software on their computer.
A little background first. Flashed stock recovery and my original first backup in order to take OTA for Marshmallow. OTA wouldn't take so I downloaded / installed MM update successfully. Currently at 6.0, 3.38.502.12. Then, re-unlocked bootloader (S-ON) and flashed TWRP 3.0.2.0. I then immediately created a full backup successfully before rooting.
Since that point, I've been unable to create another backup. I've also had countless problems trying to flash anything at all like custom ROMs and such. Keep having to revert to my unrooted backup post-MM update. The problem had to occur somewhere after my first successful TWRP backup post-MM update and now. Puzzling part is that I restored this same successful backup then without leaving TWRP, I immediately tried to do another backup and it fails the exact same way.
Recovery.log shows:
* MD5 Created.
Backing up System...
Error opening: '/system/app/Ds' (Not a directory)
I:Error in Generate_TarList!
Error creating backup.
createTarFork() process ended with ERROR: 255
Backup Failed. Cleaning Backup Folder.
I've tracked this down and it does indeed appear to be a directory "Ds". Inside as a sub-directory called 'oat' with Ds.apk inside of that, which is the Dolby Audio service.
I'm completly stumped. Any ideas?
Update, in the /system/app/ (list of apps) it looks like there is an oat subdirectory followed by arm64 then filename.odex:
/system/app/BasicDreams/oat/arm64/BasicDreams.odex
However, when I browse to the problem app "Ds"... oat does not appear as a directory.
This could be a simple fix then?? Coudn't I just obtain root again, somehow change that oat to a directory and hope I see the rest of the subdirectories and files there?
OR... could I find Ds.odex somewhere and re-create the file structure?
Better yet! Would someone out there be able to give me or post a link for Ds.odex? Would it be as easy as me making a sub-directory called oat/arm64 and placing this Ds.odex file in there??
Any help would be much appreciated.
sirvalence said:
Update, in the /system/app/ (list of apps) it looks like there is an oat subdirectory followed by arm64 then filename.odex:
/system/app/BasicDreams/oat/arm64/BasicDreams.odex
However, when I browse to the problem app "Ds"... oat does not appear as a directory.
This could be a simple fix then?? Coudn't I just obtain root again, somehow change that oat to a directory and hope I see the rest of the subdirectories and files there?
OR... could I find Ds.odex somewhere and re-create the file structure?
Better yet! Would someone out there be able to give me or post a link for Ds.odex? Would it be as easy as me making a sub-directory called oat/arm64 and placing this Ds.odex file in there??
Any help would be much appreciated.
Click to expand...
Click to collapse
I don't have any oat directories under /system/app/(app name)/oat/ARM64/...
Only thing that is in the app directory (for me) is the .apk, and at times, a lib subdirectory (webviewgoogle is like that, which has an arm and arm64 directory under that).
I'm running VenomRom which may handle this differently.. it's prerooted and whatnot.
I also disabled boomsound which I think also disabled the Dolby sound system app from running. Viper is better [emoji2]
Id back up your internal storage again, ruu, flash twrp 3.0.0-2, boot into recovery, let it make system writable, reboot into recovery again, and see what happens.
Or flash a pre-rooted sense rom instead of stock.
I honestly couldn't get this stupid AT&T varient working correctly until I s-off'd, updated Sid to developer, then run dev ruu. Works great now.
Sent from my HTC One M9 using XDA-Developers mobile app
grandpajiver said:
I don't have any oat directories under /system/app/(app name)/oat/ARM64/...
Only thing that is in the app directory (for me) is the .apk, and at times, a lib subdirectory (webviewgoogle is like that, which has an arm and arm64 directory under that).
I'm running VenomRom which may handle this differently.. it's prerooted and whatnot.
I also disabled boomsound which I think also disabled the Dolby sound system app from running. Viper is better [emoji2]
Id back up your internal storage again, ruu, flash twrp 3.0.0-2, boot into recovery, let it make system writable, reboot into recovery again, and see what happens.
Or flash a pre-rooted sense rom instead of stock.
I honestly couldn't get this stupid AT&T varient working correctly until I s-off'd, updated Sid to developer, then run dev ruu. Works great now.
Sent from my HTC One M9 using XDA-Developers mobile app
Click to expand...
Click to collapse
Thanks, yeah I'm having nothing but trouble since moving to MM. Each time, I can RUU back to stock ATT US and everything is fine. Not sure if it happens during my first TWRP pre-root backup, or the restore process. I looked at the recovery.log of said backup and nothing looked different regarding the /system/apps. I've since tried a few times and it just seems to throw a few /system/apps into another directory altogether, no rhyme or reason. Last try, there wasn't even a Ds directory as it disappeared. A Ds 0 byte file then appeared at /system level. This happened with 10 or so other random system apps. WEIRD! Maybe I should just S-OFF. I've never done that or changed my MID or SID for that matter. I'm still fairly new to this.
sirvalence said:
Thanks, yeah I'm having nothing but trouble since moving to MM. Each time, I can RUU back to stock ATT US and everything is fine. Not sure if it happens during my first TWRP pre-root backup, or the restore process. I looked at the recovery.log of said backup and nothing looked different regarding the /system/apps. I've since tried a few times and it just seems to throw a few /system/apps into another directory altogether, no rhyme or reason. Last try, there wasn't even a Ds directory as it disappeared. A Ds 0 byte file then appeared at /system level. This happened with 10 or so other random system apps. WEIRD! Maybe I should just S-OFF. I've never done that or changed my MID or SID for that matter. I'm still fairly new to this.
Click to expand...
Click to collapse
So worth the 25 dollars. But you need your system up and rooted for that to work.
But yeah, the dev edition SID 01 worked for me.
Made it way easier to work with and taking that ruu was magic.
Oh, also, do you have an sdcard? There is always the rom.zip method... placing the appropriate 0PJAIMG.ZIP in the root of the sdcard then rebooting into download mode works nicely.
Sent from my HTC One M9 using XDA-Developers mobile app
Hi,
I'm running the last cyanogenmod 12.1 ROM on my S2. There is no custom kernel or recovery. The only thing I did was a repartition to 1GB system. This setup ran since 2016 feb. without problems. Tuesday morning got a notification from the play store, that there are updates to some of my apps, so I set my phone to update them all and left it there. I came back after 20min and then came the problem:
The phone is bootlooping. The booting animation finishes, then it starts optimizing my apps, every time different amount of apps. After it finishes it starts booting again... rinse and repeat. I tried to leave it there for a very long time, with no success. The phone is very hot in the CPU area and the battery gets hot too when it's bootlooping.
I am able to go in recovery and download mode. My recovery is the stock cyanogen recovery unfortunately. I tried putting it in download mode and since I have Android Studio installed on my pc, I tried to establish an adb shell (with adb shell command) with the adb tool that came it. Unfortunately it does not find my device (neither with adb devices). I might do it wrong though. Fortunately Odin 3.04 seems to recognize my phone, so I might be able the flash something, but I'm afraid that my internal memory is starting to fail and that is causing all these issues, so the flash would fail. First I'd like to try to save data without flashing if possible.
I have most of my user data on my sd card, so the most important thing would be to save is my contacts, messages and call history. No, I don't sync it with google, yes I know it's stupid. It used to mess up my contact list so I dropped using it.
Any help and advice would be appreciated, thanks in advance!
N7Gabe said:
Hi,
I'm running the last cyanogenmod 12.1 ROM on my S2. There is no custom kernel or recovery. The only thing I did was a repartition to 1GB system. This setup ran since 2016 feb. without problems. Tuesday morning got a notification from the play store, that there are updates to some of my apps, so I set my phone to update them all and left it there. I came back after 20min and then came the problem:
The phone is bootlooping. The booting animation finishes, then it starts optimizing my apps, every time different amount of apps. After it finishes it starts booting again... rinse and repeat. I tried to leave it there for a very long time, with no success. The phone is very hot in the CPU area and the battery gets hot too when it's bootlooping.
I am able to go in recovery and download mode. My recovery is the stock cyanogen recovery unfortunately. I tried putting it in download mode and since I have Android Studio installed on my pc, I tried to establish an adb shell (with adb shell command) with the adb tool that came it. Unfortunately it does not find my device (neither with adb devices). I might do it wrong though. Fortunately Odin 3.04 seems to recognize my phone, so I might be able the flash something, but I'm afraid that my internal memory is starting to fail and that is causing all these issues, so the flash would fail. First I'd like to try to save data without flashing if possible.
I have most of my user data on my sd card, so the most important thing would be to save is my contacts, messages and call history. No, I don't sync it with google, yes I know it's stupid. It used to mess up my contact list so I dropped using it.
Any help and advice would be appreciated, thanks in advance!
Click to expand...
Click to collapse
Ok, did you try dirty flashing the ROM using CyanogenMod recovery?
And then wiping cache and dalvik cache?
MigoMujahid said:
Ok, did you try dirty flashing the ROM using CyanogenMod recovery?
And then wiping cache and dalvik cache?
Click to expand...
Click to collapse
First of all, thanks for the advice, I didn't think of that. I assume this means there is probably no solution without flashing. Do I need to flash gapps too?
N7Gabe said:
First of all, thanks for the advice, I didn't think of that. I assume this means there is probably no solution without flashing. Do I need to flash gapps too?
Click to expand...
Click to collapse
No, no need for that, just the ROM, and it won't delete anything.
MigoMujahid said:
No, no need for that, just the ROM, and it won't delete anything.
Click to expand...
Click to collapse
So, I went to recovery, pressed apply update, searched for the cm12.1-20160203-nightly rom (same I had installed), flashed it without error messages, then I pressed wipe cache partition, then reboot system now. Now the phone starts to boot, the boot animation is playing for a few minutes, then the phone turns off. Tried it multiple times, with and without charging. I can still get into recovery.
N7Gabe said:
So, I went to recovery, pressed apply update, searched for the cm12.1-20160203-nightly rom (same I had installed), flashed it without error messages, then I pressed wipe cache partition, then reboot system now. Now the phone starts to boot, the boot animation is playing for a few minutes, then the phone turns off. Tried it multiple times, with and without charging. I can still get into recovery.
Click to expand...
Click to collapse
Ok, we will try another thing, can your phone be recognized using adb in recovery?
If so you can pull the data(contacts, sms) using adb pull command.
The data usually is stored there:
/data/data/com.android.providers.telephony/databases/mmssms.db
And there:
/data/data/com.android.providers.contacts/databases/contacts.db
If you were able to do it then fine, if not, there is luckily another solution!!
You have the latest cm12.1 build which is Feb 3rd build, so your build support iso-rec TWRP recovery, so you can flash TWRP recovery zip provided by the.gangster using CM recovery and reboot recovery so it will replace the CM recovery with TWRP, in TWRP you can mount system and data using "mount", and using the file manager there you can access the above mentioned directories and copy the files manually in the external sdcard(or the internal sdcard), then you can clean flash and copy them again after that.
That would be the ultimate solution
MigoMujahid said:
Ok, we will try another thing, can your phone be recognized using adb in recovery?
If so you can pull the data(contacts, sms) using adb pull command.
The data usually is stored there:
/data/data/com.android.providers.telephony/databases/mmssms.db
And there:
/data/data/com.android.providers.contacts/databases/contacts.db
If you were able to do it then fine, if not, there is luckily another solution!!
You have the latest cm12.1 build which is Feb 3rd build, so your build support iso-rec TWRP recovery, so you can flash TWRP recovery zip provided by the.gangster using CM recovery and reboot recovery so it will replace the CM recovery with TWRP, in TWRP you can mount system and data using "mount", and using the file manager there you can access the above mentioned directories and copy the files manually in the external sdcard(or the internal sdcard), then you can clean flash and copy them again after that.
That would be the ultimate solution
Click to expand...
Click to collapse
In recovery I can see my device with adb, but every command runs into a device unauthorized error.
Code:
D:\Android\sdk\platform-tools>adb devices
List of devices attached
0009bd0863c43f unauthorized
Code:
D:\Android\sdk\platform-tools>adb shell
error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
etc.
So I assume I flash TWRP with odin. Is it possible to save data to a PC through USB connection with TWRP? I'm asking, because I'd still prefer a full backup if possible (I don't have the space for it on my external sd). Second question, if I'm able to save mmssms.db and contacts.db, how do I extract the data from it, or maybe reimport it (even to a different phone/ROM)? I don't entirely understand isorec, but let's say I manage to flash TWRP and save my data. Can I flash the latest LOS 14.1 and keep the isorec TWRP? Or after the LOS flash, I need to flash TWRP again? As I mentioned I already have the 1GB system partition, so that shouldn't be an issue. It would be a nice two birds with one stone, saving my data and updating my obsolete ROM to a isorec TWRP+LOS 14.1 combo.
Lastly, this is the recovery you mentioned, right?: recovery-the.gangster-IsoRec-TWRP-3.1.0-0-i9100.zip
N7Gabe said:
In recovery I can see my device with adb, but every command runs into a device unauthorized error.
etc.
So I assume I flash TWRP with odin. Is it possible to save data to a PC through USB connection with TWRP? I'm asking, because I'd still prefer a full backup if possible (I don't have the space for it on my external sd). Second question, if I'm able to save mmssms.db and contacts.db, how do I extract the data from it, or maybe reimport it (even to a different phone/ROM)? I don't entirely understand isorec, but let's say I manage to flash TWRP and save my data. Can I flash the latest LOS 14.1 and keep the isorec TWRP? Or after the LOS flash, I need to flash TWRP again? As I mentioned I already have the 1GB system partition, so that shouldn't be an issue. It would be a nice two birds with one stone, saving my data and updating my obsolete ROM to a isorec TWRP+LOS 14.1 combo.
Lastly, this is the recovery you mentioned, right?: recovery-the.gangster-IsoRec-TWRP-3.1.0-0-i9100.zip
Click to expand...
Click to collapse
First, TWRP won't be flashed with Odin, it will be flashed with CM recovery that you already have, and yes i meant the one you mentioned.
Second, the contacts.db and mmssms.db won't take that much space, and anyway it's OK to copy them to internal sdcard, not obligated to external, and no need to access them, after you flash another ROM like LOS 14.1, you can re copy them back to their directories.
Third, if you flash the latest LOS 14.1, you can keep the iso-rec TWRP it won't be removed.
MigoMujahid said:
First, TWRP won't be flashed with Odin, it will be flashed with CM recovery that you already have, and yes i meant the one you mentioned.
Second, the contacts.db and mmssms.db won't take that much space, and anyway it's OK to copy them to internal sdcard, not obligated to external, and no need to access them, after you flash another ROM like LOS 14.1, you can re copy them back to their directories.
Third, if you flash the latest LOS 14.1, you can keep the iso-rec TWRP it won't be removed.
Click to expand...
Click to collapse
Okay, so I need to find an SD card reader then, to put the recovery on it. Or is there another way to get it on the phone?
By the way, thank you for taking your time and helping me, I'm really grateful!
N7Gabe said:
Okay, so I need to find an SD card reader then, to put the recovery on it. Or is there another way to get it on the phone?
By the way, thank you for taking your time and helping me, I'm really grateful!
Click to expand...
Click to collapse
No pb bro, you're welcome.
Yes, you will need to get the recovery in the phone somehow, or you can put your memory card in another phone and use the phone to put the recovery in the sdcard, then place it in your phone again.
That would be an alternative if you don't have a sdcard reader.
MigoMujahid said:
No pb bro, you're welcome.
Yes, you will need to get the recovery in the phone somehow, or you can put your memory card in another phone and use the phone to put the recovery in the sdcard, then place it in your phone again.
That would be an alternative if you don't have a sdcard reader.
Click to expand...
Click to collapse
I managed to get it on the phone and flashed it. The phone was plugged in to my pc, and I could acces my internal SD so I managed to back that up. But here's the thing, TWRP file manager showed my /data to be empty, and not long after, the phone just shut down. My battery is only a few months old, so that should not be the issue, and the phone was also charging from the PC.
After this shutdown, I had a very hard time to get into recovery, because the phone thinks the battery is dead. I couldn't start booting normally either. Only download mode was available, but it only said, it can't get into download mode, because the battery is low. (when I plug in the charger the phone shows 100% battery) I changed my battery to my old weak one, I managed to get into recovery with it, after multiple tries. (I think it had nothing to do with the battery but was lucky) Now I check my /data through adb and it shows empty aswell:
Code:
D:\Android\sdk\platform-tools>adb pull /data/data/com.android.providers.telephony/databases/mmssms.db
adb: error: remote object '/data/data/com.android.providers.telephony/databases/mmssms.db' does not exist
D:\Android\sdk\platform-tools>adb shell
~ # [6n
~ # [6nls
and-sec init.recovery.service.rc selinux_version
boot init.recovery.smdk4210.rc sepolicy
boot.txt init.recovery.usb.rc service_contexts
cache license sideload
charger mnt supersu
data proc sys
default.prop property_contexts system
dev recovery tmp
etc res twres
file_contexts sbin ueventd.rc
fstab.smdk4210 sdcard0 ueventd.smdk4210.rc
init sdcard1 usbotg
init.rc seapp_contexts
~ # [6ncd data
/data # [6nls
/data # [6n
Do I have to mount it somehow maybe? (Oh and twrp always ask at start to mount sys in read-only or R/W. I always mounted it in R/W.) I'm afraid if I start moving in TWRP the phone will shut down as it always did. If I use adb or windows explorer to acces the phone it does not shut down.
N7Gabe said:
I managed to get it on the phone and flashed it. The phone was plugged in to my pc, and I could acces my internal SD so I managed to back that up. But here's the thing, TWRP file manager showed my /data to be empty, and not long after, the phone just shut down. My battery is only a few months old, so that should not be the issue, and the phone was also charging from the PC.
After this shutdown, I had a very hard time to get into recovery, because the phone thinks the battery is dead. I couldn't start booting normally either. Only download mode was available, but it only said, it can't get into download mode, because the battery is low. (when I plug in the charger the phone shows 100% battery) I changed my battery to my old weak one, I managed to get into recovery with it, after multiple tries. (I think it had nothing to do with the battery but was lucky) Now I check my /data through adb and it shows empty aswell:
Do I have to mount it somehow maybe? (Oh and twrp always ask at start to mount sys in read-only or R/W. I always mounted it in R/W.) I'm afraid if I start moving in TWRP the phone will shut down as it always did. If I use adb or windows explorer to acces the phone it does not shut down.
Click to expand...
Click to collapse
You should go to "mount" in TWRP, and tick "data" and "system", i said that already earlier.
MigoMujahid said:
You should go to "mount" in TWRP, and tick "data" and "system", i said that already earlier.
Click to expand...
Click to collapse
After I sent the message and before I read yours just now, I managed to mount, save and even make LOS run. So I was wrong, the battery is probably dead. I guess the lot of heat it produced while bootlooping killed the battery. I switched back to my old original wore out battery which is humpy and everything, but I managed to do everything with the phone. Now my problem is after I put back the .db files in their place, when the phone start it constantly crashes android.process.acore, the messaging app and the caller app. I think it might be a permission issue, but I have no idea how to fix it.
N7Gabe said:
After I sent the message and before I read yours just now, I managed to mount, save and even make LOS run. So I was wrong, the battery is probably dead. I guess the lot of heat it produced while bootlooping killed the battery. I switched back to my old original wore out battery which is humpy and everything, but I managed to do everything with the phone. Now my problem is after I put back the .db files in their place, when the phone start it constantly crashes android.process.acore, the messaging app and the caller app. I think it might be a permission issue, but I have no idea how to fix it.
Click to expand...
Click to collapse
Download ES file explorer from play store and grant root access for root explorer and set permissions to the 2 files as (rw- rw- ---) as described in screenshot, then reboot.
MigoMujahid said:
Download ES file explorer from play store and grant root access for root explorer and set permissions to the 2 files as (rw- rw- ---) as described in screenshot, then reboot.
Click to expand...
Click to collapse
This method worked with the contacts db, but not with the messages db. Actually I did not find any databases when I first copied it there, even made the databases folder. Thanks though, I'm almost done!
N7Gabe said:
This method worked with the contacts db, but not with the messages db. Actually I did not find any databases when I first copied it there, even made the databases folder. Thanks though, I'm almost done!
Click to expand...
Click to collapse
Ok, i seem to know the problem here, i looked at my own mmssms.db file and found it in this path:
/data/data/com.android.providers.telephony/databases/mmssms.db
(not the same path for the contacts.db file)
So you should move it there and add the same permissions that you added to the other file, that will do the job for you
MigoMujahid said:
Ok, i seem to know the problem here, i looked at my own mmssms.db file and found it in this path:
/data/data/com.android.providers.telephony/databases/mmssms.db
So you should move it there and add the same permissions that you added to the other file, that will do the job for you
Click to expand...
Click to collapse
This is the path you told me the first time, and this is where it doesn't work. That databases folder was not even there, until I made it. I don't even have any other files in the folder but the mmssms.db that I copied there.
N7Gabe said:
This is the path you told me the first time, and this is where it doesn't work. That databases folder was not even there, until I made it. I don't even have any other files in the folder but the mmssms.db that I copied there.
Click to expand...
Click to collapse
I don't know what is the problem...I've ran out of ideas here
At least you got your contacts back :silly:
MigoMujahid said:
I don't know what is the problem...I've ran out of ideas here
At least you got your contacts back :silly:
Click to expand...
Click to collapse
No problem, I got lucky, run a search in the data partition for mmssms.db and it appears that now it is located in /data/user_de/0/com.android.providers.telephony/databases. I backed it up, then overwrote it, fixed the permission, rebooted and now it seems to work, so all is well.
In the end I managed to not only save my data, but to fix my phone and even upgrade it to the latest LineageOS, thanks to you! I wish you a good life!
N7Gabe said:
No problem, I got lucky, run a search in the data partition for mmssms.db and it appears that now it is located in /data/user_de/0/com.android.providers.telephony/databases. I backed it up, then overwrote it, fixed the permission, rebooted and now it seems to work, so all is well.
In the end I managed to not only save my data, but to fix my phone and even upgrade it to the latest LineageOS, thanks to you! I wish you a good life!
Click to expand...
Click to collapse
Thanks for the tip, i have a marshmallow ROM right now, it seems that the location was changed in Nogut, I'll keep that in mind.
Have a good life too.
I guess I'm a moron and can't figure this out :v
Using stock rooted Oreo, Magisk, edXposed, everything that goes with them. TWRP 3.2.3-7.
Lately, I've been using my headphones while driving to work. I need a touch more volume over stock to deal with wind noise.
The problem is, I absolutely can't get /system/vendor/etc into a writable state.
Attempts to modify mixer_paths_tavil.xml whilst booted up fail, either resulting in an unreadable file (Total Commander) or just not working (Root Explorer).
Trying to flash a modified zip (just grabbed a dual-speaker mod and replaced the xml) in TWRP results in no file being created; it doesn't seem to throw an error, just silently fails.
Manually copying the xml to /system/vendor/etc using TWRP's file manager ~appears~ to work, but attempts to set permissions results in error code 1. The file doesn't exist upon reboot.
Remounting manually as RW in TWRP's terminal doesn't seem to help. And yes, "mount System as read-only" is unchecked.
I can make build.prop changes, so I know /system is writable. The only way I can get anything written to /system/vendor/etc is restoring a full system backup.
I've modified this file before; I manually tweaked the call volume higher and enabled "fake" high-impedance mode.
So I'm sure I'm doing something really stupid here. Help.
Septfox said:
I guess I'm a moron and can't figure this out :v
Using stock rooted Oreo, Magisk, edXposed, everything that goes with them. TWRP 3.2.3-7.
Lately, I've been using my headphones while driving to work. I need a touch more volume over stock to deal with wind noise.
The problem is, I absolutely can't get /system/vendor/etc into a writable state.
Attempts to modify mixer_paths_tavil.xml whilst booted up fail, either resulting in an unreadable file (Total Commander) or just not working (Root Explorer).
Trying to flash a modified zip (just grabbed a dual-speaker mod and replaced the xml) in TWRP results in no file being created; it doesn't seem to throw an error, just silently fails.
Manually copying the xml to /system/vendor/etc using TWRP's file manager ~appears~ to work, but attempts to set permissions results in error code 1. The file doesn't exist upon reboot.
Remounting manually as RW in TWRP's terminal doesn't seem to help. And yes, "mount System as read-only" is unchecked.
I can make build.prop changes, so I know /system is writable. The only way I can get anything written to /system/vendor/etc is restoring a full system backup.
I've modified this file before; I manually tweaked the call volume higher and enabled "fake" high-impedance mode.
So I'm sure I'm doing something really stupid here. Help.
Click to expand...
Click to collapse
Don't know, but tonight or tomorrow I'll shoot you a file to test.
ChazzMatt said:
Don't know, but tonight or tomorrow I'll shoot you a file to test.
Click to expand...
Click to collapse
Appreciated, but I think something's going pear-shaped and I just need to reflash the ROM; setting up for the drive home last night, it seems I've lost the ability to use direct output in Poweramp. I don't know how, since the system+system image backup I restored is known-good and audio is otherwise working.
Good ol' bitrot, I suppose.
Septfox said:
Appreciated, but I think something's going pear-shaped and I just need to reflash the ROM; setting up for the drive home last night, it seems I've lost the ability to use direct output in Poweramp. I don't know how, since the system+system image backup I restored is known-good and audio is otherwise working.
Good ol' bitrot, I suppose.
Click to expand...
Click to collapse
See my PM.