Related
First of I had no idea where to post this as it's not "device specific"
I'd been undertaking framewokr-res changes fine up until yesterday when I started to recieve an Invalid Argument error in ADB shell.
The command that I am using with ADB is;
su
stop
cp /sdcard/framework-res.apk /system/framework/framework-res.apk
chmod644 /system/framework/framework-res.apk
sync
start
Click to expand...
Click to collapse
But after "cp /sdcard/framework-res.apk /system/framework/framework-res.apk" I'm now recieving, "cannot remove /system/framework/framework-res.apk Invalid Argument"
Where's that come from, I've never had it before, any ideas please?
I'm no noob btw, I've searched google and the forums here to no avail.
Regards.
SWFlyerUK said:
First of I had no idea where to post this as it's not "device specific"
I'd been undertaking framewokr-res changes fine up until yesterday when I started to recieve an Invalid Argument error in ADB shell.
The command that I am using with ADB is;
But after "cp /sdcard/framework-res.apk /system/framework/framework-res.apk" I'm now recieving, "cannot remove /system/framework/framework-res.apk Invalid Argument"
Where's that come from, I've never had it before, any ideas please?
I'm no noob btw, I've searched google and the forums here to no avail.
Regards.
Click to expand...
Click to collapse
My first guess is that the system partition is mounted read-only, but that seems like an odd message.
Is this on a different device than you normally use, or one that has worked before in the past?
Yep just that device, just tried on my Nexus S and it's still working on, but not on my Archos 70. Is there anyway I can mount as r/w with ADB to ensure its read and write?
Thanks for the response, appreciated.
SWFlyerUK said:
Yep just that device, just tried on my Nexus S and it's still working on, but not on my Archos 70. Is there anyway I can mount as r/w with ADB to ensure its read and write?
Thanks for the response, appreciated.
Click to expand...
Click to collapse
I don't know anything about the device, but if it is rooted, busybox mount has a remount option:
Code:
busybox mount -o remount,rw /system
Sorry where do I enter that, just the CMD in the Android SDK? I've not used Busy Box commands before.
on the command line just like your other commands above.
I'm doing something wrong as this is what I'm getting;
No, as part of the commands you are running on the device via adb shell:
Code:
su
stop
[COLOR="Red"]busybox mount -o remount,rw /system[/COLOR]
cp /sdcard/framework-res.apk /system/framework/framework-res.apk
chmod644 /system/framework/framework-res.apk
sync
start
Yet another error;
mount: can't find /system in /proc/mounts
May aswell give up at this rate
Apparently that device uses some other mounting format that standard android.
Ok cheers, champ, I'm sure I'll find a solution, like I said, it worked before, but after a full reformat last night thats no the error that I'm getting.
I periodically get my sdcard to a state where it is read only. Not sure what causes this but a fix is to remount the sdcard. Currently I've been going into CWM and remounting it that way, but would like to do it via the terminal or adb. I found what I thought was the correct command online but I'm getting a usage error when I try it out.
Error:
Usage: mount [-r] [-w] [-o options] [-t type] device directory
Is this command correct for a Droid 2 (A955):
mount -o rw,remount -t /sdcard
Thanks!
I'll need to test this when I get home, but I believe you're missing the device before the directory. (ie. /dev/whatever)
Interesting. Copying and pasting your syntax worked fine for me. Sounds like you need a different copy of busybox. I'm running v1.16.2.
Huh? So it worked for you? Odd.
I just flashed the latest zombiestomped ROM (1.71) a few days ago and that has resolved the issue I was having that necessitated remounting my sdcard all the time. I never did figure out what was causing it to get locked into read-only mode.
Well I appreciate you verifying my syntax. At least now if I ever need to do that in the future I'll know what to do.
No problem. I can almost guarantee it was the version of busybox you had installed, as that's what provides the common linux tools like mount. They aren't the real binaries, but they're meant to be super-small applications that work just like the real thing, intended for small embedded systems.
I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app
look for the error message in /cache/recovery/recovery.log
If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....
This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app
OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.
I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks
The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck
Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks
Not sure if this will help anyone else, but I searched forever trying to figure out how to write into the system folder using Terminal Emulator on the Note 3 to no avail. I found a slew of posts that said to type "mount -o rw,remount /system" to achieve this. When I used this command it didn't return any errors so I assumed it worked, however no files ended up being copied and pasted to the location I wanted. I found numerous other examples that were supposed to enable writing to the system as well, but none of them worked. I finally figured out how to get it to work on my Note 3 by typing "mount" in terminal emulator and noticing that at the very beginning of the string that was returned was "rootfs". So if you are wanting write to your system using Terminal Emulator on the VZW Note 3 here is what ended up working for me:
Code:
mount -o remount,rw rootfs
to return to read only enter:
Code:
mount -o remount,ro rootfs
I wanted to figure this out because a bug in TWRP v2.6.3.0 maimed my efs partition and bricklooped my phone. Even flashing the Stock Developer tar by Beans wouldn't bring it out of the brickloop. I was able to get out of the brickloop by following this thread, but even though my phone booted up and the IMEI # was correct, my /efs folder was missing in action. This caused odd things to happen like my lock screen not functioning and the power button instantly turning the phone off instead of bringing up the power menu. I discovered this was because the phone was placed into something called "factory mode" and that to fix it you needed to edit some files in the efs folder, which were completely missing on my device. Member js0uth graciously sent me his efs folder from his Developer Note 3 and when I copied it to my phone it began to function normally again (big shout out to js0uth!). However, this folder was completely deleted once again after a reboot. So now you can see why I was looking for a way to copy these files using Terminal Emulator. I ended up making a Tasker profile with the Secure Settings plugin that automatically copies the files from my ext SD card to my system folder on boot of the device. In order to mount, copy/paste the files while retaining the correct permissions from the folder that js0uth sent me, and unmount the system I had the set up my Secure Settings command as follows:
Code:
mount -o remount,rw rootfs;cp -Rpf /storage/extSdCard/efs/* /efs/;mount -o remount,ro rootfs
So now I have a livable workaround for my problem until I can discover a way for the phone to rebuild my own /efs folder.
Edit: See radionerd's post for a permanent fix to this issue and be sure to hit thanks under his name if it helps you.
I did the same to my DE. Corrupted EFS about a month ago after a few flashes using TWRP 2.6.3.0. Boot loops for 28 hours of hell until I followed your tracks to the trick that deleted my corrupted EFS folder, and created a new empty folder. I guess this would wipe out IMEI, Mac, and more in models that store phone specific data in EFS. We lucked out I've read that our phones have that info in a few other folder not EFS
Since wiping EFS I have run stock ROM, CM11, and now bean V6. I didn't see the factory mode popup until recently. I noticed that the screen will flash when leaving or entering cell service.
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Thanks for documenting your steps to recovery.
radionerd
radionerd said:
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Click to expand...
Click to collapse
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
radionerd said:
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Click to expand...
Click to collapse
Setting the Factorymode folder to ON is actually what disables that mode. Seems backwards I know, but when it's set to OFF (or if the folder is completely missing as in my case) that warning message will display. If that folder is intact on your phone then you should be able to use a string to disable or enable Factorymode.
It got worse before it got better
bodieism said:
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
No worries, I went from an annoyance of no lock screen to bricked for over 6 weeks. This happened after trying to do an EFS backup.
I've learned a lot since back then, My DE is back 100%, EFS is repaired. I think we ran the same script which actually points to the wrong mount in our phones. It brought us out of bootloops, but efs was pointed to block12. Qualcom snapdragon Note-3's use mmblk0p11 to load /efs.
If you still have to load the tasker script, I think I figured out an easy fix to rebuild your original efs folder.
I would backup mounts first, delete /efs folder. Then run the original script, but this time change from 12 to 11.
Code:
adb shell
su
mke2fs /dev/block/mmcblk0p11
mkdir /efs
mount -t ext4 /dev/block/mmcblk0p11 /efs
Bet that would do the trick
Here is my thread
Click to expand...
Click to collapse
^ That did do the trick! :good:
Phone is back to 100% working order :highfive:
Hello everyone
following Problem: tried to Flash ARISE. but flashing ARISE fails cause r/o system
... opened terminal in TWRP and Mount | grep /System
Output: /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered
so i see, ist rw...but i cant Flash... still get read-only file error..
i also tried mount -o remount,rw /System
Mount | grep /System, again, and Output also same as before...
Output: /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered
still get Read-only file System Error...
someone have a solution or an advise? when i go to Mount in TWRP i can check System (without active Checkbox for ro mounting), and still got the Errors...
aivilon said:
Hello everyone
following Problem: tried to Flash ARISE. but flashing ARISE fails cause r/o system
... opened terminal in TWRP and Mount | grep /System
Output: /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered
so i see, ist rw...but i cant Flash... still get read-only file error..
i also tried mount -o remount,rw /System
Mount | grep /System, again, and Output also same as before...
Output: /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,seclabel,relatime,data=ordered
still get Read-only file System Error...
someone have a solution or an advise? when i go to Mount in TWRP i can check System (without active Checkbox for ro mounting), and still got the Errors...
Click to expand...
Click to collapse
Unlock the system partition by typing "reboot disemmcwp" in the system or TWRP terminal or ADB shell
kossie12 said:
Unlock the system partition by typing "reboot disemmcwp" in the system or TWRP terminal or ADB shell
Click to expand...
Click to collapse
tried this... phone reboots, i hold power up to go directly back to twrp... still no rw...
here is what log of ARISE says:
cp: can't create directory '/system/etc/sws': Read-only file system
cp: can't create directory '/system/etc/srs': Read-only file system
cp: can't create '/system/etc/permissions/com.huawei.audioalgo.xml': Read-only file system
cp: can't create '/system/etc/firmware/isp_dts.img': Read-only file system
cp: can't create '/system/etc/firmware/hifi_6403_tfa.img': Read-only file system
cp: can't create '/system/etc/firmware/hifi_6403.img': Read-only file system
cp: can't create '/system/etc/firmware/hifi_6402_2spk.img': Read-only file system
cp: can't create '/system/etc/firmware/hifi_6402.img': Read-only file system
cp: can't create directory '/system/etc/firmware/can_nxp': Read-only file system
cp: can't create directory '/system/etc/dts': Read-only file system
cp: can't create directory '/system/etc/codec': Read-only file system
cp: can't create directory '/system/etc/audio': Read-only file system
cp: can't create '/system/framework/com.huawei.audioalgo.jar': Read-only file System
#EDIT1:
Still the same error after
umount /System
Mount -o rw /system
Could you try in terminal app?
Su
reboot disemmcwp
kossie12 said:
Could you try in terminal app?
Su
reboot disemmcwp
Click to expand...
Click to collapse
Su not found
Sudo not found
aivilon said:
Su not found
Sudo not found
Click to expand...
Click to collapse
Seems like you are not rooted. Arise needs a rooted device
kossie12 said:
Seems like you are not rooted. Arise needs a rooted device
Click to expand...
Click to collapse
Lol not possible cause I have SuperSU on it installed runs perfectly asked me for permission for applications if they need root
kossie12 said:
Seems like you are not rooted. Arise needs a rooted device
Click to expand...
Click to collapse
I also installed Los without any problems
aivilon said:
I also installed Los without any problems
Click to expand...
Click to collapse
It was possible to make a new file in /etc and in /system with root explorer... The reload was possible without an error
kossie12 said:
Seems like you are not rooted. Arise needs a rooted device
Click to expand...
Click to collapse
Think i found the problem...
/System gets dismounted every time i try to flash ARISE
After i mount it rw over terminal, its there, flash ARISE, try to remount, cant find in /proc/mount
Wtf
aivilon said:
Think i found the problem...
/System gets dismounted every time i try to flash ARISE
After i mount it rw over terminal, its there, flash ARISE, try to remount, cant find in /proc/mount
Wtf
Click to expand...
Click to collapse
Not sure why that is happening..
Maybe someone else can help you.
I didn't run into any problems installing, but im on stock B10 (G variant).
kossie12 said:
Not sure why that is happening..
Maybe someone else can help you.
I didn't run into any problems installing, but im on stock B10 (G variant).
Click to expand...
Click to collapse
I think file system was corrupted... Restored the system from the 03.03.17, mounted over mount menu in twrp, installed...
Seems that it has worked for now cause i have esra, viper4arise etc... Strange
aivilon said:
I think file system was corrupted... Restored the system from the 03.03.17, mounted over mount menu in twrp, installed...
Seems that it has worked for now cause i have esra, viper4arise etc... Strange
Click to expand...
Click to collapse
Good to hear it works for you now.
Now its time to enjoy some music :laugh:
kossie12 said:
Good to hear it works for you now.
Now its time to enjoy some music :laugh:
Click to expand...
Click to collapse
Thanks ?
Jep a little bit better, but still not perfect :silly: