Related
I've just installed the last porting of the cyanogen for my Magic 32a. I'm enjoining the idea behind the script fix_permissions. But, observing the structure of the files/folders in my /data/data/, I can see that it is not perfect.
It does chown the folders /data/data/NAME-OF-PACKAGE/ and the subfolders 'databases' and 'shared_prefs'.
Observing the typical contents of my /data/data/ I can see that some applications has further folders and some times also single files in /data/data/NAME-OF-PACKAGE/ that need a touch of chown.
For example:
/data/data/com.htc.android.mail/
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_config
drwxrwxrwx 1 10021 10021 2048 Aug 18 09:00 app_mail_eas
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_mail_temp
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_temp
-rw------- 1 10021 10021 1048576 Aug 18 09:00 bufferFileForMailAP
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 databases
drwxr-xr-x 1 1000 1000 2048 Aug 18 08:41 lib
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 shared_prefs
You can test on your system by yourself:
for APP in /data/data/* ; do echo -e "\n$APP" ; ls -l $APP ; done | more
I'm attaching an improved version that should fix the permissions on all the subfolders different than 'lib' and also on the single files.
I hope it works for you and that it can be included in the future firmwares.
UPDATE: in this thread, several users are making contributions to the original script (with a fast increasing version number ). There is also a report in the Cyanogen bug system: http://code.google.com/p/cyanogenmo...ID Type Status Priority Version Owner Summary
You should find there the last revision. Thanks to all for the contributions.
ankn said:
I've just installed the last porting of the cyanogen for my Magic 32a. I'm enjoining the idea behind the script fix_permissions. But, observing the structure of the files/folders in my /data/data/, I can see that it is not perfect.
It does chown the folders /data/data/NAME-OF-PACKAGE/ and the subfolders 'databases' and 'shared_prefs'.
Observing the typical contents of my /data/data/ I can see that some applications has further folders and some times also single files in /data/data/NAME-OF-PACKAGE/ that need a touch of chown.
For example:
/data/data/com.htc.android.mail/
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_config
drwxrwxrwx 1 10021 10021 2048 Aug 18 09:00 app_mail_eas
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_mail_temp
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 app_temp
-rw------- 1 10021 10021 1048576 Aug 18 09:00 bufferFileForMailAP
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 databases
drwxr-xr-x 1 1000 1000 2048 Aug 18 08:41 lib
drwxrwx--x 1 10021 10021 2048 Aug 18 09:00 shared_prefs
You can test on your system by yourself:
for APP in /data/data/* ; do echo -e "\n$APP" ; ls -l $APP ; done | more
I'm attaching an improved version that should fix the permissions on all the subfolders different than 'lib' and also on the single files.
I hope it works for you and that it can be included in the future firmwares.
Click to expand...
Click to collapse
Btw, I was wondering why we fix only userId and not also sharedUserId
as I'm quite sure I've seen them messed up sometimes after some of my to
ambitious experiments. Shouldn't be difficult to add support for that if there
is some evidence that it is a Good Thing(tm).
farmatito said:
Btw, I was wondering why we fix only userId and not also sharedUserId
Click to expand...
Click to collapse
I don't understand the meaning of the parameter "sharedUserId". Some packages in packages.xml use the parameter "UserId", others the "sharedUserId" one. What's the difference?
ankn said:
I don't understand the meaning of the parameter "sharedUserId". Some packages in packages.xml use the parameter "UserId", others the "sharedUserId" one. What's the difference?
Click to expand...
Click to collapse
shared user id is for the case when you have a program extended by another installable program in order to run in the same process:
http://developer.android.com/reference/android/R.attr.html#sharedUserId
Another improvement could be to fix the file modes as well. I have noticed that sometimes the user permissions on files and directories in /data/data get removed.
Then you get FCs with an sqlite error like below:
Code:
sqlite3_open_v2("/data/data/com.xta.foodmkt/databases/Hungry.db", &handle, 6, NULL) failed
The below commands fixes the access errors:
Code:
find /data/data -type d -exec busybox chmod u+rwx {} \;
find /data/data -type f -exec busybox chmod u+rw {} \;
farmatito said:
Btw, I was wondering why we fix only userId and not also sharedUserId
as I'm quite sure I've seen them messed up sometimes after some of my to
ambitious experiments. Shouldn't be difficult to add support for that if there
is some evidence that it is a Good Thing(tm).
Click to expand...
Click to collapse
I'm attaching another version with support to packages with sharedUserId; fixed the remount mechanism that doesn't work on the other firmware that I'm actually using (HoFo).
smeat said:
The below commands fixes the access errors:
Code:
find /data/data -type d -exec busybox chmod u+rwx {} \;
find /data/data -type f -exec busybox chmod u+rw {} \;
Click to expand...
Click to collapse
This code should fixes all the permission-related problems but it is too risky from the security point-of-view.
ankn said:
This code should fixes all the permission-related problems but it is too risky from the security point-of-view.
Click to expand...
Click to collapse
Why risky, if i understand it right:
directory: 700 (owner only can read, write or enter directory)
files: 600 (owner only can read or write file)
Where is the risk?
You can also use:
chmod 700 directory
chmod 600 files
farmatito said:
Why risky, if i understand it right:
directory: 700 (owner only can read, write or enter directory)
files: 600 (owner only can read or write file)
Where is the risk?
You can also use:
chmod 700 directory
chmod 600 files
Click to expand...
Click to collapse
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
smeat said:
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
Click to expand...
Click to collapse
This in my opinion is far more risky than doing
a chmod for the owner only at least in the case
that the permissions are messed up for whatever
reason as some insecure settings will not be corrected
that way, e.g.:
permissions are wrongly set to 666 or 777
than you do chmod +urwx file and the result
will continue to be an insecure setting 666 or
677 that doesn't enforce isolation between apps.
BTW, by looking at ls of /data/data it seems to
me that all folders have 755 permissions so
chmod 755 folder should be safe. For the deeper level:
Code:
/data/data/app 755
/data/data/app/files 700
/data/data/app/lib 755
/data/data/app/shared_prefs 771
but I have not the time right now to check all subfolders
to see if there are exceptions to this default settings.
smeat said:
It doesn't even go that far, it ADDS the owner to the permissions, not reset them to just the owner having permissions.
Click to expand...
Click to collapse
This is true. Sorry!
farmatito said:
This in my opinion is far more risky than doing
a chmod for the owner only at least in the case
that the permissions are messed up for whatever
reason as some insecure settings will not be corrected
that way, e.g.:
permissions are wrongly set to 666 or 777
than you do chmod +urwx file and the result
will continue to be an insecure setting 666 or
677 that doesn't enforce isolation between apps.
BTW, by looking at ls of /data/data it seems to
me that all folders have 755 permissions so
chmod 755 folder should be safe. For the deeper level:
Code:
/data/data/app 755
/data/data/app/files 700
/data/data/app/lib 755
/data/data/app/shared_prefs 771
but I have not the time right now to check all subfolders
to see if there are exceptions to this default settings.
Click to expand...
Click to collapse
fix_permissions is not about removing permissions and never has been from what I can tell. Currently it just goes through the /data/system/packages.xml and finds the listed owner of the /data/data files and then changes ownership of the files and directories.
I am talking about adding an additional chmod to make it so that file and directory owners are added as being able to read/write to the files they own. I have seen an issue were running something made it so that a ton of my application sqlite databases had file permissions of 060. When this happens you get the error I posted originally: sqlite3_open_v2("/data/data/com.xta.foodmkt/databases/Hungry.db", &handle, 6, NULL) failed. Even though the group write and read bit are set and the group is correct the error above happens. Adding the owner back as having read/write permissions fixes this error.
Again, adding permissions to only the user/owner of the files and directories does not open the files up to being written by other processes on the phone.
Again, adding permissions to only the user/owner of the files and directories does not open the files up to being written by other processes on the phone.
Click to expand...
Click to collapse
I know. I was trying to improve the concept of fix permission as you can not know
in advance how the permissions could have been messed up. So it would be better
to enforce some sane defaults rather than to add some hacks to fix a specific problem.
This obviously is only possible if there are some patterns in file and folder permissions of /data/data.
That is what i will try to find out.
farmatito said:
I know. I was trying to improve the concept of fix permission as you can not know
in advance how the permissions could have been messed up. So it would be better
to enforce some sane defaults rather than to add some hacks to fix a specific problem.
This obviously is only possible if there are some patterns in file and folder permissions of /data/data.
That is what i will try to find out.
Click to expand...
Click to collapse
Ahhh, sorry I misunderstood what you were getting at.
If you run:
Code:
find /data/data -type f -exec ls -l {} \;
Will tell you what all the files are currently set to.
A run of:
Code:
find /data/data -type d -exec ls -ld {} \;
Will list the current directory permissions.
What I can find is that any /sslcache directory is 700, /lib 755 and owned by 1000:1000, /database 771, /shared_prefs 771, But I have some apps with 700 directories for everything.
Here is a table for /data/data/app, format: directory/file, permissions, ownership
Directories:
/database 771 appuser:appgroup
/lib 755 1000:1000
/shared_prefs 771 appuser:appgroup
/sslcache 700 appuser:appgroup
/anythingelse 771 appuser:appgroup
Files:
/database/* 660 appuser:appgroup
/lib/* ??? ??????, never seen any files in these directories.
/sslcache/* 600 appuser:appgroup
/shared_prefs/* 660 appuser:appgroup
/anythingelse/* 660 appuser:appgroup
Does this align with what you are seeing? If so we can adjust the script to apply these permissions to the files and directories more selectively.
I was actually wondering about this very thing yesterday. Is there some reason why the initial script only changed the permissions of databases and shared_prefs?
I'm trying to think of a scenario in which you wouldn't just want a recursive chown, but especially in the case of wiping and then copying back data directories, having ALL the subdirectories owned by the app's uid seems preferable to having any of them owned by the wrong uid.
smeat said:
Ahhh, sorry I misunderstood what you were getting at.
If you run:
Code:
find /data/data -type f -exec ls -l {} \;
Will tell you what all the files are currently set to.
A run of:
Code:
find /data/data -type d -exec ls -ld {} \;
Will list the current directory permissions.
What I can find is that any /sslcache directory is 700, /lib 755 and owned by 1000:1000, /database 771, /shared_prefs 771, But I have some apps with 700 directories for everything.
Here is a table for /data/data/app, format: directory/file, permissions, ownership
Directories:
/database 771 appuser:appgroup
/lib 755 1000:1000
/shared_prefs 771 appuser:appgroup
/sslcache 770 appuser:appgroup
/anythingelse 771 appuser:appgroup
Files:
/database/* 660 appuser:appgroup
/lib/* ??? ??????, never seen any files in these directories.
/sslcache/* 600 appuser:appgroup
/shared_prefs/* 660 appuser:appgroup
/anythingelse/* 660 appuser:appgroup
Does this align with what you are seeing? If so we can adjust the script to apply these permissions to the files and directories more selectively.
Click to expand...
Click to collapse
So far this is what i've found:
Code:
/data/data/pkgdir uid/gid 755
/data/data/pkgdir/lib system/system 755
/data/data/pkgdir/databases uid/gid 771
/data/data/pkgdir/databases/*.db uid/gid 660
/data/data/pkgdir/shared_prefs uid/gid 771
/data/data/pkgdir/shared_prefs/*.xml uid/gid 660
/data/data/pkgdir/cache uid/gid 771
/data/data/pkgdir/cache/* uid/gid 771
The only differences are in the anythingelse part wher I have found
all possible combinations of permissions, but I suspect that these files
and dirs are setup by the apk at runtime as no reference could be found
for them in the apk package nor in the installd source code.
So i think it would be a big improvement to try to fix this standard dirs and their
contents with ownership and permissions as shown above.
This could save a lot of headaches to users and devs. Single apps with
exotic permissions could always be reinstalled or fixed manually.
In script 1.3 you should change:
cat /data/system/packages.xml | grep "^<package" | grep userId
to
cat /data/system/packages.xml | grep "^<package" | grep serId
as else no packages with sharedUserId will be found
farmatito said:
So far this is what i've found:
Code:
/data/data/pkgdir uid/gid 755
/data/data/pkgdir/lib system/system 755
/data/data/pkgdir/databases uid/gid 771
/data/data/pkgdir/databases/*.db uid/gid 660
/data/data/pkgdir/shared_prefs uid/gid 771
/data/data/pkgdir/shared_prefs/*.xml uid/gid 660
/data/data/pkgdir/cache uid/gid 771
/data/data/pkgdir/cache/* uid/gid 771
The only differences are in the anythingelse part wher I have found
all possible combinations of permissions, but I suspect that these files
and dirs are setup by the apk at runtime as no reference could be found
for them in the apk package nor in the installd source code.
So i think it would be a big improvement to try to fix this standard dirs and their
contents with ownership and permissions as shown above.
This could save a lot of headaches to users and devs. Single apps with
exotic permissions could always be reinstalled or fixed manually.
Click to expand...
Click to collapse
Yeah, I was assuming on the /anythingelse.
Alright here is my shot at this modification. Not much of a coder... so be gentle.
I created an issue for this on the code.google.com cyanogenmod site. thenefield posted some changes and I have integrated them into a new script.
smeat said:
I created an issue for this on the code.google.com cyanogenmod site. thenefield posted some changes and I have integrated them into a new script.
Click to expand...
Click to collapse
In your rewrite of the script, you forgot to apply the chown to the subfolders that are different than 'databases' and 'shared_prefs' as well as to the single files in the application-root. Look at my first post in this thread: these cases exist and we have to deal with them. In other words: you reverted my changes.
Cyanogenmod 7 for the Lenovo Ideapad A1, by Milaq and myself.
BEFORE YOU BEGIN
You should install the modified bootloader that allows you to get into fastboot mode if necessary. This is because there is only one kernel on the A1, and if the kernel causes problems (unlikely, but it's better save yourself the risk) you won't be able to boot normally or into recovery. Being able to boot into fastboot mode gives you a way out of this by allowing you to flash a kernel through usb with the fastboot command. See this post: http://forum.xda-developers.com/showpost.php?p=25186171&postcount=120
Simple installation guide
David Artiss has written a beginners' guide that walks you through the process of installing CM7 starting from the stock system. Get to it here:
http://www.artiss.co.uk/2012/04/installing-cyanogenmod-on-a-lenovo-ideapad-a1
Syncing and building it:
Clone the Cyanogenmod repository:
Code:
repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
Then add the local manifest:
Code:
git clone https://github.com/milaq/android.git local-android
cd local-android
git checkout gingerbread
cd ..
cp local-android/local_manifest.xml android/.repo
They sync the repo, get rom manager, and build:
Code:
cd android
repo sync
./vendor/cyanogen/get-rommanager
source build/envsetup.sh && brunch A1_07
What works:
Graphics HW acceleration
Touchscreen
Buttons (vol, power, menu, back, home)
Removable SD card
Audio
Accelerometer
Wifi (see caveat below)
Bluetooth
Vibration
Internal SD card
Front and back camera for still images, video recording from back camera
GPS
HW accelerated decoding (h.264 etc)
Issues
No 3G on the 3G versions.
Video recording from the front camera
Accelerometer switch not working
Market gives phone layout instead of tablet layout after update
Modified partition layout used with CWM 5.0.2.8 seems to prevent the internal SD card mounting.
GPS Time from android.location.Location.getTime() is wrong (1 day ahead?).
DSPManager sometimes crashes when headphones are inserted.
Bluetooth file transfer doesn't work, but Bluetooth HID seems to work.
IRC Channel
#ideapad-a1 on irc.freenode.net.
Recent logs at http://shron.de/irclogs/ideapad-a1.log
Some older logs at http://shron.de/ideapad-a1.log
Download page
Nightly builds, built by Milaq and hosted by goo.im:
http://goo.im/devs/milaq/a107/cm-7
Acknowledgments
Many thanks to:
Milaq - fixing loads of things: Camera, GPS, vibration, autobrightness, cpu responsiveness, scrolling performance, wifi geolocation, disabling background blur, hiding phone signal by default, density fixes, etc, etc, ...
SpiegelEiXXL - many discussions and thoughts, setting up nightly builds, hosting nightly builds.
Pati- for spotting how to prevent the reboots and internal SD card fixes.
Templis - Channel logs
Collaboration
Please feel free to discuss this porting effort here, point out errors, fork the repositories, submit patches/pull requests etc!
Latest updates:
18 Feb: Nightly downloads added. Please follow the commit log on Github for further details of updates: https://github.com/gmarkall/android_device_ideapad_a1/commits/gingerbread
12 Feb: Fixed the 5:43 reboot issue, wifi (sort of), and accelerometer. New version on download page.
17 Jan: Got it booting, added download page.
15 Jan: Made some very hacky changes that allow an otapackage to be built.
14 Jan: Tried flashing it - so far not quite booting as far as the home screen, but does get to the boot screen.
13 Jan: I had the wrong size for the system partition, which was causing make_ext4fs to fail. This is now corrected, and the build finishes.
13 Jan: I created an IRC channel for discussion of Clockworkmod, Cyanogenmod and development on the A1. It is #ideapad-a1 on irc.freenode.net.
12 Jan: I've added a few more bits and bobs to the build - in particular editing BoardConfig.mk to include settings for building libaudio.so, using the camera stub for the time being, bluetooth settings, etc. Also added some missing files: /etc/media_profiles.xml and vold.a1.fstab, overlay.omap3.so.
11 Jan: added a script that pulls the proprietary libraries off the device and creates a vendor/lenovo/a1 folder for them.
I have a 16GB Lenovo A1 and am more than happy to help out with any testing you need with CM7!
Just drop me a PM if you want any private testing done or I will test out the moment you post a Rom here to flash.
Thanks, Charlie.
awesome! did you already try to flash and run it?
BuzzyB said:
awesome! did you already try to flash and run it?
Click to expand...
Click to collapse
Not yet. At the moment the build system doesn't quite work for making a flashable zip suitable for the ideapad. I want to get the build system to make the update.zips without any manual intervention, rather than just putting one together by hand - otherwise it will be a pain every time I change something to have to manually make a new update.zip.
BuzzyB said:
awesome! did you already try to flash and run it?
Click to expand...
Click to collapse
I tried flashing it - I'm not quite getting as far as the home screen in booting yet, but it's a start:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
nice teaser
Awesome!!!
Simply wonderful!
Update
something new...
:sehorn:
Cool beans!
So with the latest version I have, after bootup there's some problems with dalvik-cache.
The files in /cache/dalvik-cache and their permissions are:
Code:
# ls -l
-rw-r--r-- 1 system system 850744 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 57112 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 232920 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 27960 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 root root 266000 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 system system 194352 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 13880 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 root root 778656 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 system system 7448 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 root root 24128 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 root root 4798600 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 root root 1391096 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 root root 8087736 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 system system 6816 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 4504 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 61616 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 89720 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 28496 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 root root 1638216 Jan 16 23:36 [email protected]@[email protected]
-rw-r--r-- 1 system system 147728 Aug 1 2008 [email protected]@[email protected]
-rw-r--r-- 1 system system 8496 Aug 1 2008 [email protected]@[email protected]
Logcat is at: http://www.doc.ic.ac.uk/~grm08/ideapad/cm7-a1-logcat-jan-17.txt
Any suggestions?
Did you try to chmod 777 /cache/dalvik-cache
Just for testing it?
OTA use data/dalvik-cache and have the same File right like you do.
# create dalvik-cache and double-check the perms
mkdir /data/dalvik-cache 0771 system system
chown system system /data/dalvik-cache
chmod 0771 /data/dalvik-cache
# create the lost+found directories, so as to enforce our permissions
mkdir /data/lost+found 0770
mkdir /cache/lost+found 0770
---------- Post added at 09:47 PM ---------- Previous post was at 09:35 PM ----------
What rights have your /cache/dalvik-cache Folder?
It schould have 771
But i think that /cache have only 770
xbdesign said:
Did you try to chmod 777 /cache/dalvik-cache
Just for testing it?
Click to expand...
Click to collapse
I did try that, but it didn't make any difference unfortunately.
So what rights you have now for that Folder (after/at boot)?
xbdesign said:
So what rights you have now for that Folder (after/at boot)?
Click to expand...
Click to collapse
Code:
# ls -l
drwxrwx--x 2 system system 3072 Jan 17 21:02 dalvik-cache
I just noticed that it's only things that run as app_XX that have a problem opening /cache/dalvik-cache/[email protected]@ ...
Things that run as system, e.g. com.android.settings, don't seem to have a problem.
I feel like I'm missing something obvious now!
Right,
all Positions that have root have a Problem
-rw-r--r-- 1 root root
On STOCK ROM there are no Files that have one root root.
They are all having
system system
or
system app_<AppNr>
or
system radio
xbdesign said:
Right,
all Positions that have root have a Problem
-rw-r--r-- 1 root root
Click to expand...
Click to collapse
What is the problem? Those are the same permissions as on my CM7 Desire which doesn't have this issue.
No Problem.
Just wondering why every one of them giving an Error.
I have no working CM7 to compare it to.
---------- Post added at 10:59 PM ---------- Previous post was at 10:52 PM ----------
Are you at stage where you can Wipe dalvik-cache, or it is hapening by building/restoring it?
I've installed Fresh ROM on my Evo Shift 4G. It worked for about a week, then the GPS stopped working (a known bug with this device and Gingerbread). I restarted the device as normal, and when it came back up all my downloaded apps and the Market were gone, and the device was in that strange indeterminate state where I'm both synced to a Gmail account and not at the same time (the Setup app appears in the Apps folder). Signing in doesn't help.
I rebooted into Clockwork Recovery (3.2.0.1), wiped data/factory reset, wiped the cache, wiped dalvik, and installed Fresh ROM again.
Once that was complete and booted, I signed in, attempted to install an app and the phone reset. There's no file manager installed nor terminal app so I can't delete things by bash. I connected over USB and tried to adb shell in, but that caused the phone to reset.
I'm stuck. Clearly something has not been properly wiped prior to installing Fresh ROM.
What do I need to do to get out of this loop?
SoopahMan said:
I've installed Fresh ROM on my Evo Shift 4G. It worked for about a week, then the GPS stopped working (a known bug with this device and Gingerbread). I restarted the device as normal, and when it came back up all my downloaded apps and the Market were gone, and the device was in that strange indeterminate state where I'm both synced to a Gmail account and not at the same time (the Setup app appears in the Apps folder). Signing in doesn't help.
I rebooted into Clockwork Recovery (3.2.0.1), wiped data/factory reset, wiped the cache, wiped dalvik, and installed Fresh ROM again.
Once that was complete and booted, I signed in, attempted to install an app and the phone reset. There's no file manager installed nor terminal app so I can't delete things by bash. I connected over USB and tried to adb shell in, but that caused the phone to reset.
I'm stuck. Clearly something has not been properly wiped prior to installing Fresh ROM.
What do I need to do to get out of this loop?
Click to expand...
Click to collapse
Sounds like you either had a bad Flash, a bad Download, or both. So redownload the Rom you choose, then Clear and Flash your device according to THESE INSTRUCTIONS .
Thanks for the response. I downloaded the ROM again and ran a check - identical to the file I downloaded previously. So, if the ROM is the culprit, then the latest version of Fresh ROM for Evo Shift does not work (4.1.1).
I followed the instructions linked, wiping the cache and dalvik-cache twice (why?), and wiping system etc prior to installing the ROM.
I'm running into the exact same issues as before - I can't install anything from the Market, and the phone resets if I connect it to a computer over USB. When it resets, it resets multiple times and when it comes back up the 4G no longer works.
If I rerun the above instructions, the 4G works again, but I'm stuck back in this loop - can't use the Market or connect it over USB or it will reset, so forth.
Could Fresh ROM 4.1.1 for Evo Shift be bad? I still suspect the real problem is something is not sufficiently wiped or setup prior to install.
In case it might help, here's an ls -al after installing Fresh Rom 4.1.1 on my phone (an HTC Evo Shift 4G after following the above install instructions).
/
drwxr-xr-x 2 root root 0 Jan 17 07:39 boot
drwxr-xr-x 4 root root 1024 Jan 17 07:41 cache
drwxrwx--x 2 root root 0 Jan 1 1970 data
drwxr-xr-x 2 root root 0 Jan 17 07:39 datadata
-rw-r--r-- 1 root root 3462 Jan 1 1970 default.prop
drwxr-xr-x 12 root root 3060 Jan 17 07:39 dev
drwxr-xr-x 2 root root 0 Jan 17 07:39 emmc
drwxr-xr-x 2 root root 0 Jan 17 07:39 etc
-rwxr-x--- 1 root root 94372 Jan 1 1970 init
-rwxr-x--- 1 root root 899 Jan 1 1970 init.rc
dr-xr-xr-x 79 root root 0 Jan 1 1970 proc
drwxr-xr-x 4 root root 0 Jan 1 1970 res
drwx------ 2 root root 0 May 15 2011 root
drwxr-x--- 2 root root 0 Jan 1 1970 sbin
drwxr-xr-x 2 root root 0 Jan 17 07:39 sd-ext
drwxrwxrwx 78 root root 32768 Jan 1 1970 sdcard
drwxr-xr-x 18 root root 0 Jan 17 07:39 sys
drwxr-xr-x 3 root root 0 Jan 1 1970 system
drwxr-xr-x 2 root root 0 Jan 17 07:45 tmp
-rw-r--r-- 1 root root 0 Jan 1 1970 ueventd.goldfish.rc
-rw-r--r-- 1 root root 4027 Jan 1 1970 ueventd.rc
-rw-r--r-- 1 root root 987 Jan 1 1970 ueventd.speedy.rc
/data
(empty)
/system
drwxr-xr-x 2 root root 0 Jan 1 1970 bin
/system/bin
(empty)
/sys
drwxr-xr-x 2 root root 0 Jan 17 07:53 android_camera
drwxr-xr-x 2 root root 0 Jan 17 07:53 android_camera_awb_cal
drwxr-xr-x 2 root root 0 Jan 17 07:53 android_touch
drwxr-xr-x 2 root root 0 Jan 17 07:53 block
drwxr-xr-x 2 root root 0 Jan 17 07:39 board_properties
drwxr-xr-x 9 root root 0 Jan 17 07:53 bus
drwxr-xr-x 2 root root 0 Jan 17 07:53 camera_led_status
drwxr-xr-x 47 root root 0 Jan 17 07:53 class
drwxr-xr-x 4 root root 0 Jan 17 07:53 dev
drwxr-xr-x 10 root root 0 Jan 17 07:39 devices
drwxr-xr-x 2 root root 0 Jan 17 07:53 firmware
drwxr-xr-x 3 root root 0 Jan 17 07:53 fs
drwxr-xr-x 6 root root 0 Jan 17 07:53 kernel
drwxr-xr-x 62 root root 0 Jan 17 07:53 module
drwxr-xr-x 2 root root 0 Jan 17 07:53 power
drwxr-xr-x 2 root root 0 Jan 17 07:53 systemlog
I can post more or other diagnostics if others have something to recommend. Really stuck here.
Is it odd that /sd-ext is at root and not located on the SD card, and a directory not a symlink?
Now that you have 10 posts you should try posting your questions in the thread for flipz's rom.So the dev can help and maybe anyone else that is running this rom. Also have you tried the a2sd remove command adb shell or from terminal emulator? See if that helps.
Sent from my PG06100 using Tapatalk
A bit more to isolate the problem:
If the phone resets (due to attempting an install from the Market or plug in from USB), 4G fails - but if I restart the phone at that point, when it reboots 4G works again. So 4G appears to be fine, it's the resets that are at the core of the issue.
I shutdown, removed the SD card, booted, and attempted to install an app and got the same reset, so it's not the SD card - it's definitely a problem somewhere on internal storage.
What else do I need to clear to clear this up?
Fresh ROM's pages say to look in /data/app and /system/app for a place where an app already exists that would cause a conflict.
Here's /data after booting the ROM and setting up a Gmail account:
lrwxrwxrwx 1 root root 14 Jan 17 07:54 app -> /system/sd/app
lrwxrwxrwx 1 root root 22 Jan 17 07:54 app-private -> /system/sd/app-private
drwx------ 5 system system 1024 Jan 6 1980 backup
drwxrwx--x 2 system system 14336 Jan 17 16:25 dalvik-cache
drwxrwx--x 161 system system 9216 Jan 17 07:57 data
drwxr-x--- 2 root log 1024 Jan 17 07:54 dontpanic
lrwxrwxrwx 1 root root 11 Jan 17 07:54 drm -> /data/local
-rw-r--r-- 1 root root 6134 Jan 6 1980 dta2sd.lg1
-rw-r--r-- 1 root root 6266 Jan 6 1980 dta2sd.lg2
-rw-r--r-- 1 root root 6266 Jan 6 1980 dta2sd.log
drwxrwxrwx 2 root root 1024 Jan 17 07:54 htcfs
drwxr-xr-x 4 root root 1024 Jan 17 07:42 jit
drwxrwx--x 4 shell shell 1024 Jan 17 07:54 local
drwxrwx--- 2 root root 12288 Jan 17 07:41 lost+found
drwxrwx--t 10 system misc 1024 Jan 17 07:55 misc
drwx------ 2 root root 1024 Jan 6 1980 property
drwx------ 3 system system 1024 Jan 17 07:55 secure
drwxrwxr-x 9 system system 1024 Jan 17 17:48 system
drwxrwx--- 3 system system 1024 Jan 17 17:14 wimax
I'd like to know if app and app-private are as expected (they appear to be the result of the ROM install, since they were completely wiped prior to installing it). The app symlink is a strange one. It points to /system/sd/app, which I can't cd to. /system/sd I can cd to, and this is all it contains:
-rw-r--r-- 1 root root 17 Aug 1 2008 placeholder
A file named placeholder. What?
I'm starting to suspect apps2sd. None of the relevant partitioning steps are in those install instructions, and they appear to be specific to the apps2sd of CyanogenMod. Google's appears to support a DOS partition, while CyanogenMod's appears to only support an ext3 partition, which I do not have.
At the same time, removing the SD card didn't change things, so color me confused.
As suggested by FdxRider you should definately post up in the Rom thread. That way you can get help resolving the issue from others running the same Rom.
It was apps2sd.
To resolve this problem, I had to:
Reboot into ClockwordModRecovery
Connect the phone to a computer over USB
In Clockwork, choose Mount Storage and choose the last option, Mount USB.
Dump anything I wanted to keep off of the SD card (most importantly, the FreshRom zip file).
Then, back in Clockwork, Advanced>Partition SD
Choose a size (they recommend 1024M)
This wipes out everything on the SD card, creates a Linux partition for apps2sd to use, marks the rest as a Windows partition.
Wait till it's done, then, still from ClockworkModRecovery:
Wipe cache, dalvik cache, system, data
Factory reset
Now Mount USB again so you can copy the FreshRom zip back onto the Windows partition (the only part that will come up on a Windows machine).
Eject on the Windows machine to ensure the copy completes, Unmount in Clockwork.
Install the ROM again
Let it boot, restart
Setup my Google Account/Gmail user
And one final thing:
As it turns out ES File Explorer is pre-installed on this ROM. That means installing it from the Market will make the phone go crazy regardless of proper setup. But I am now able to install other apps just fine from the Market (at last).
reset loop NO clockwork until factory reset
I installed Fresh 4.1.1 on my shift 4g
I went to install ROM Manager got it downloaded and it reset the phone at install.
I even tried going to the website and installing it that way. Same results.
I can't get clockwork to work, when i hold the volume down and then press power nothing happens until i release the power button then it goes directly to the Fresh install.
PLEASE HELP!!!!
---------- Post added at 05:30 AM ---------- Previous post was at 05:09 AM ----------
I got the problem solved. I used the RRU and it walked me through a recovery, part of it was yanking the battery. DUH!
In adb shell, with myself set as su, I cannot write directly to /mnt/extSdCard. Get's "permission denied"
When I do a chmod or chown to root, I get an "operation not permitted"
I have to copy (push) files to /mnt/sdcard and use the device to move/copy stuff over to /mnt/extSdCard.....pretty annoying.
I guess the reason is because the ownership looks like this:
ls -al
...
drwxrwxr-x system media_rw 2012-10-12 10:07 extSdCard
drwxr-xr-x root system 2012-10-11 09:10 obb
drwxrwxr-x root sdcard_rw 2012-10-12 10:29 sdcard
drwx------ root root 2012-10-11 09:10 secure
Any ideas how I can write to /mnt/extSdCard - even Android Commander is not doing anything
I think you have to mount it first with something that should look like,
"Adb mount /mnt/blk/[some wierd path here]/" or something
Not sure but that's my best guess since no one else was offering insight
Sent from my GT-N8013 using xda app-developers app
Same problem here, have you already found a solution or workaround?
Important:
Now since Official Oreo is out, you can simply update to Official Oreo via fastboot and your IMEI will be restored.
This method will not work if you have restored other device's persist from some Youtube video or some Internet guide.
Read post #3 if you have restored some other persist and do not have a backup of your original persist.
For those who can't read this much, here is a better guide for you:
Hello everyone, this is a guide for solving the problem for IMEI = 0 on Moto G4/Plus which is caused after flashing stock ROM.
I got this problem last week and was constantly researching for the solution to this problem for the past 5 days and finally, I was able to get my IMEI back on my Moto G4 Plus (XT1643).
Note: I will be using stock firmware and stock ROM interchangeably in this thread as a lot of people consider it the same so don't get confused since I am by no means referring to the /firmware partition.
There are two common and major problems which occur while flashing custom/stock ROMs:
1. IMEI = Unknown and Baseband = Unknown
2. IMEI = 0
1st Problem:
Reason: You flashed the firmware/stock ROM which wasn't meant for your device.
Solution: Flash the firmware which is made for your device like XT1621 or XT1643, etc.
2nd Problem:
This is a major problem and there are two reasons for this:
1. Mess up your persist partition.
2. fastboot erase all command.
If your problem is caused by the first reason, it might be possible to fix it.
However, if the problem is caused by the second reason, I'm sorry I don't know if a solution to this problem exists.
Firstly you need to check if your device still has IMEI intact or not. For that use the following command through fastboot in the bootloader mode:
Code:
fastboot getvar imei
If the command returns an IMEI, it means that the IMEI is not completely lost and it can be recovered.
However, if the command returns IMEI as 0, then there are two reasons:
1. Either you flashed the bootloader that wasn't meant for your device. This can be solved by flashing the correct bootloader which is made for your device again by the command:
Code:
fastboot flash bootloader bootloader.img
2. If you have flashed the correct bootloader that is meant for your device and facing this issue, I'm sorry I don't think there is a solution to this problem. This problem is either caused by fastboot erase all command (which erases everything like IMEI from the device's motherboard or the place where IMEI is permanently stored) or some hardware issue.
Here is a little explanation:
Device specific or device unique IDs are stored in a separate place in the device like the motherboard or some other place which I am unaware of.
When EFS partition is created, it picks up the IMEI from that unique place in the device like the motherboard (or some other place which I am unaware of) where the IMEI is stored.
On every reboot, EFS partition is checked and if it does not exists, the Android system by default creates it.
When we flash stock ROM, we use the following commands:
Code:
fastboot erase modemst1
fastboot erase modemst2
These commands wipe the EFS partition and on rebooting, EFS partition is recreated.
But, in some cases, the EFS partition is not able to regenerate IMEI or the Android system is unable to recreate it and so we are left with IMEI = 0.
Here is a detailed explanation regarding this issue:
NZedPred said:
4) Explanation
4a) What happened to persist.
To understand what happened, you need to know a few things about filesystem permissions in Linux. Files and folders have user and group ownership, and permissions. Examples of owners are the system, root, user, etc. Examples of permissions are read access, write access, execute access. The permissions are applied at three levels 1) the user, 2) the group, 3) everyone else.
@rachitrawat's investigation into the failures showed that the issue was relating to the persist partition, specifically some files dhob.bin etc that are under the rfs sub folder in this partition. Under stock, these files/folders are owned by a user called rfs, and have group ownership under a group also called rfs. Additionally, the permissions on these files/folders are limited - only the rfs user can read/write/execute these files. Other users, groups, or everyone else, cannot access the files.
There was a change in the Oreo roms. If you flash and boot into an Oreo rom, and you look at the permissions/ownership, you will see that a user and group oem_2951 owns the rfs folder, and a group oem_2952 owns the hlos_rfs folder. Now this is a different name, but on its own, a different name does not mean different ownership.
In Linux, all users and groups are assigned an ID, i.e. a number. So something happened in lineage that changed the user IDs that are applied to the rfs folder.
If you look at the ownership of persist files/folders within TWRP, you will see that a STOCK PERSIST has the owner of the rfs folder as rfs_old. Similarly in TWRP, a LINEAGE PERSIST has the owner of the rfs folder as rfs. So TWRP is seeing owners differently again to stock and Lineage. Trying to run the above commands in TWRP will not fix the issue, as it will use ID 2951 for the user rfs, but we need it to be 3012 in stock (which TWRP sees as rfs_old).
In addition to the rfs folder, there is also another folder that is impacted - hlos_rfs. Its user owner is rfs, but its group owner if rfs_shared. A stock rfs_shared is shown as rfs_shared_o in TWRP. It appears that this folder is not as important in getting the IMEI back, but I have included the commands to restore ownership, to ensure there are no future errors.
4b) What happened to IMEI.
Despite the issue above, many people who flashed Oreo roms would have had no problems (other than I guess, bugs in the roms themselves). The change of ownership of the rfs folder didn't change the actual file content, so essentially all is intact. In fact, I verified that my dhob.bin and other files had the same md5sum in stock and lineage persist.
The issue of the IMEI changing to zero has only happened when people have flashed Stock roms. All of the guides that I have seen, have included the following commands (and equivalent commands have been included in the TWRP flashable stock builds as well):
Code:
fastboot erase modemst1
fastboot erase modemst2
The partitions modemst1 and modemst2 are your EFS. Normally, if your persist is pure stock, if either is erased, the modem re-creates them. But, referring to the above about permissions, if the rfs user (which is presumably used by the modem) cannot access the files (because the owner of the files is someone else, and the permissions on the files mean that only the owner can access them), then the modem cannot recreate the EFS, and the IMEI is left as zero.
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Solution:
I have made a youtube video for this which just shows how to fix the issue and does not goes into explanation of the problem as well as the solution. Here is the link: Moto G4/G4 Plus IMEI=0 fix
Pre-requisites:
You must be on Stock Nougat 7.0
You must be rooted (install Elemental-X kernel first and then flash Magisk otherwise you will have boot issues)
You must be on your own persist
Terminal app or adb drivers in PC/Laptop
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 1: Check if there is a problem with persist
Note: The below commands are to be typed in a terminal app or adb shell.
Q) How to type in adb shell?
A) Open command prompt in the folder where you have adb and fastboot installed and type:
Code:
adb shell
So lets start now!
Code:
su
This command it to get root access for the terminal/shell. Grant the root access and you will see that the $ symbol is replaced with # symbol which means that root access has been granted.
Code:
ls -l /persist
If your presist has some problem, then you can see the following as the output.
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 2951 2952 4096 1969-12-31 19:02 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 2951 2951 4096 1969-12-31 19:02 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
You can see system instead of these red number if you flash Soak Test before flashing Stock ROM, so no worries, as the process will remain the same.
As it can be seen in the red part, the owner of rfs folder is a number (2951) which means that the system is unable to identify its real owner.
Also the owner of hlos_rfs folder is a number too (2952) which also means that the system is unable to identity its real owner.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 2: Check for the key persist files
Code:
find /persist -type f
If you run the above command, you will see something similar to this:
Code:
athene_f:/ # find /persist -type f
/persist/coresight/qdss.agent.sh
/persist/coresight/qdss.config.sh
/persist/coresight/qdss.functions.sh
/persist/sensors/sensors_settings
/persist/data/sfs/6lgxCka66cxdsueYeHhCqx+j1DI_
/persist/data/sfs/VsxbuQew8Rbt0TRZjDAX8S9tV+M_
/persist/data/sfs/KfLHQpS5zKuygZcMelQOTtWzBvw_
/persist/data/sfs/R9+zCYj56-AHybZuQCWLm2H46E4_
/persist/data/sfs/NjJIuGH0j7kE08PFwp1yw+BminY_
/persist/data/sfs/7pU6SoXdsBUbDsxRiZOHNIjPVtw_
/persist/data/sfs/yLawqeQeY8AQGJmo46PVJbfYVxY_
/persist/data/tz/tz_counter
/persist/data/tz/tz_counter.bak
/persist/data/app_g/wv_usage
/persist/camera/focus/offset_cal
/persist/camera/ledcal/rear
/persist/factory/audio/temp
/persist/factory/audio/cnt
/persist/factory/audio/acc
/persist/factory/audio/f0
/persist/factory/audio/ref_diff
/persist/factory/fti
/persist/public/hiddenmenu/data/mobile_data_rx
/persist/public/hiddenmenu/data/mobile_data_tx
/persist/public/hiddenmenu/data/wifi_data_rx
/persist/public/hiddenmenu/data/wifi_data_tx
/persist/public/hiddenmenu/data/factoryreset_time
/persist/public/hiddenmenu/data/activation_date
/persist/public/hiddenmenu/life_calls
/persist/public/hiddenmenu/life_timer
/persist/security/18.bin
/persist/mdm/oma_dm_update
/persist/.bt_nv.bin
/persist/rfs/shared/server_info.txt
/persist/rfs/msm/mpss/datablock/id_00
/persist/rfs/msm/mpss/datablock/id_01
/persist/rfs/msm/mpss/server_check.txt
[COLOR="Red"]/persist/rfs/msm/mpss/dhob.bin
/persist/rfs/msm/mpss/shob.bin[/COLOR]
[COLOR="Green"]/persist/rfs/msm/mpss/dhob.bin.bak[/COLOR]
/persist/rfs/msm/adsp/server_check.txt
/persist/bluetooth/.bt_nv.bin
/persist/time/ats_1
/persist/time/ats_2
/persist/time/ats_12
/persist/time/ats_13
/persist/time/ats_15
/persist/time/ats_16
/persist/.twrps
athene_f:/ #
Note: The key files here are dhob.bin, shob.bin, id_00 and id_01.
Your IMEI is stored in id_00 (first IMEI) and id_01 (second IMEI)
dhob.bin and shob.bin are responsible to create the EFS partition.
Note: If you do not have dhob.bin.bak, you will still be able to get your IMEI back (tested and confirmed working on Moto G4 Plus(athene)), however if you have some other device like Moto G5 Plus(potter) or Moto G5s Plus(sanders), you cannot get your IMEI back with this method however trying won't hurt.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 3: Fix the your persist
For this step, there is also a TWRP flashable zip file which will fix the persist. So for those who do not want to type the commands manually, you can simply flash the zip file (Tested and working).
Downloads:
Link: https://www.androidfilehost.com/?fid=11410963190603873125
md5: 5aac75092fc84f46dd5c6bd443df0748
These commands will restore the owners of rfs and hlos_rfs folder back to their respective original owners (rfs and rfs_shared):
Code:
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
Alternatively, you can also type:
Code:
chown -R 3012:3012 /persist/rfs
chown -R 3012:3013 /persist/hlos_rfs
You will see no output on typing the first command, however, you may or may not see any output after typing the second command (there was an output shown on my device but not on the other tested devices). I'm sorry I don't have that output stored, if someone who can see it, please repond so the thread can be updated.
3012 is infact the id for rfs folder and 3013 is the id for hlos_rfs folder so instead of typing their names, you can also type their ids.
Now, to check if the owners of rfs and hlos_rfs have been set back to their original ones, type this command:
Code:
ls -l /persist
If everything went fine, you should be able to see the following output:
The below output will be seen on a perfectly fine persist as well
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 rfs rfs_shared 4096 1969-12-31 19:02 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 rfs rfs 4096 1969-12-31 19:02 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
As you can see here that the owner of rfs folder is rfs folder and the owner of hlos_rfs folder is rfs_shared folder, the problem has been resovled.
Reboot your device and the problem should be fixed and you will be able (hopefully) to get your IMEI back by either typing *#06# in phone dialer or in Settings>About Phone>Status>IMEI Information.
On rebooting, the system will check for the EFS folder and since it didn't exist earlier, it will be recreated by the system and therefore you will get your IMEI back.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A huge thanx to NZedPred, rachitrawat, for doing in depth research in this problem and coming up with a solultion.
Also, I would like to thank Tyrantre who did a lot of research for this problem and has posted the workaround which was tried here in this thread here: Diag Mode with G4 for QPSD? which finally lead me to NZedPred's below thread as I could understand what was the problem due to which IMEI was set to 0 and why Diag mode wouldn't work.
Note: This thread was made with the help of the following guide which is confirmed to be working on Moto G5 Plus (potter) Fix Persist, resolve IMEI=0, Volte, 4G, Explanation, Requirements.
Note: This guide is made for G4/Plus and I have hardly done anything to fix this problem apart from making this thread, so all credits go to the respective owners who did research in this problem. This guide should work on other Motorola devices too as we aren't focusing on device-specific fixes that will only work on Moto G4 Plus.
Refer post #2 for fixing other issues faced after recovering IMEI.
Some Common Issues:
Here are the issues observed after recovering IMEI:
Sim card detected but no network
Baseband version changed
Volte not working
If you have any one of the above-mentioned problems, there is a specific thread made for those problems. Refer to this thread: [Guide] [XT16XX] [Solve] G4+ Baseband/Network/Volte issue, Lost 1 IMEI & fingerprint
Please discuss any issues related to the above-mentioned problems in the above-provided thread (link).
If you have any other issues apart from the issues mentioned above, discuss them here.
--------------------------------------------------------------------------
Complete Backup Zip/Script (All partitions):
Now since you have faced this issue, make sure to take a complete backup of all the partitions so that if you ever face an issue like this in future, you will always have your partitions with you to restore your device.
Here is the link to the thread to take complete backup of all partitions: [Guide] [XT16XX] Moto G4/Plus Complete Partition Backup/Restore Zip/Script
The above thread can backup/restore using TWRP flashable zip files for convenience.
There are a few youtube videos and internet guides which tells you to restore somebody else's persist file. That persist file is same in the Youtube video as well as those Internet guide (I have checked them).
Persist is unique to each and every device and using somebody else's persist on your device will never work.
IMEI is stored in /persist/rfs/msm/mpss/datablock directory where there are two files named as id_00 and id_01.
id_00 contains your 1st IMEI and id_01 contains your second IMEI.
The persist (from those guide and youtube videos) lacks id_00 and id_01 and since you restored that persist, you have those files missing as well. Those files are unique to every device anyways so if you try to restore a persist which has those files, it won't work too as your device's IMEI is different altogether.
The only possible fix that comes to my mind is by manually editing the persist file.
On comparing both the files in a hex editor, it is found that both of them are completely same except from memory address/location 00000028 to 000000C7.
This makes me think that IMEI is stored between those memory locations.
Furthermore, the first 14 digits of IMEI are stored from 00000028 to 0000002F in a different manner.
This is how it is stored,
Lets take a sample random IMEI: 3 12 34 56 78 90 12 34
This will be stored as following: 3A 21 43 65 87 09 21 03
Code:
3A [COLOR="Black"]21[/COLOR] [COLOR="DarkRed"]43[/COLOR] [COLOR="Red"]65[/COLOR] [COLOR="Magenta"]87[/COLOR] [COLOR="Sienna"]09[/COLOR] [COLOR="DarkOrange"]21[/COLOR] [COLOR="DarkOliveGreen"]03[/COLOR]
3 [COLOR="black"]12[/COLOR] [COLOR="darkred"]34[/COLOR] [COLOR="red"]56[/COLOR] [COLOR="magenta"]78[/COLOR] [COLOR="sienna"]90[/COLOR] [COLOR="darkorange"]12[/COLOR] [COLOR="darkolivegreen"]34[/COLOR]
The first set of hex numbers is what is stored in id_00 and id_01
The second set of hex numbers is what the actual IMEI is.
As you can clearly notice the difference via colors that the digits are getting flipped. The persist is storing the last digit 4 in some different way.
Why is there a letter A in the start just after 3, I found that it means that the last digit of IMEI stored in persist is 0. And that makes sense to as when you flip the last two digits i.e 03, you indeed get 30 which indicates the last digit is 0.
I don't think I need to mention this, but if you have a dual sim device, the first thirteen digits of IMEI are same and only the last two digits are different.
Now, this makes me conclude that the last digit of actual IMEI is stored in some way in the rest of the id_00 and id_01. And since most of the content in both the files are same, we just have to compare the part which is different as that part has that last digit of the two IMEIs stored.
I can't upload the contents of my IMEI for obvious reasons. If we are able to find the pattern in which the last digit is stored inside those files, then I think we can edit them and it should solve the problem for those people. Of course, editing and putting on somebody else's IMEI in those files wouldn't work either as we have already tried replacing the entire id_00 and id_01 (infact entire working persist) but the IMEI still remains 0.
Perhaps there is someplace (not talking about fastboot imei) where IMEI is stored as well, and while generation of EFS, that place and the persist are checked together and if the IMEIs in both the places match, you get your IMEI and if not, then it knows that IMEI has tampered and hence it doesn't work.
This might be too dangerous as people could edit their IMEI and put on somebody else's IMEI and can create problems, but as I mentioned above, it doesn't work as you will need to have your own IMEI in persist.
Update: Thanx to @NZedPred for correcting me. Even on deleting id_00 and id_01, and then eraseing EFS, we still get our IMEI.
I also tried changing the first digit of dhob.bin file while keeping id_00 and if_01 intact and then erased EFS, but didn't get my IMEI.
So, dhob.bin is the one which is responsible for IMEI creation and I am not able to understand anything inside dhob.bin.
I am sorry, but I was already trying beyond my capabilities earlier by using many internet sources as reference and it was just by chance that I stumbled upon id_00 and id_01. I am going to stop here for now, as this stuff goes beyond my current capabilities. If I ever get to know anything, I will update it here so that if anybody else would like to continue, they could do it.
I am sorry I tag you here, @echo92, @strongst, @NZedPred, @rachitrawat. This is what I was able to find out. I request you to read this post, and please help if you can. Thank You.
If you run the ls -l /persist command on android P ROM (which is causing this IMEI issue), this is the output you get:
Code:
athene:/ # ls -l /persist
total 88
drwxrwx--- 2 system system 4096 1970-01-10 08:37 alarm
drwxr-xr-x 2 vendor_mot_pwric vendor_mot_pwric 4096 1970-01-01 01:01 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2018-03-29 00:04 bluetooth
drwxr-xr-x 2 vendor_mot_tcmd bluetooth 4096 1970-01-01 01:01 bt
drwxr-xr-x 4 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 camera
drwxr-xr-x 2 root root 4096 2018-03-29 00:04 coresight
drwx------ 5 system system 4096 2018-03-29 00:04 data
drwxrwx--- 2 system graphics 4096 1970-01-01 01:01 display
drwxrwx--- 2 system system 4096 1970-01-01 01:01 drm
drwxr-xr-x 4 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 factory
[COLOR="red"]drwxrwx--- 3 vendor_rfs vendor_rfs_shared 4096 2018-03-29 00:04 hlos_rfs[/COLOR]
drwxrwx--- 2 root root 4096 2018-03-29 00:04 lost+found
drwxrwx--- 2 radio radio 4096 2018-03-29 00:04 mdm
drwxrwx--- 3 system system 4096 2018-03-29 00:04 misc
drwxrwx--- 2 system system 4096 1970-05-31 18:25 properties
drwxr-xr-x 8 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 public
[COLOR="Red"]drwx------ 6 vendor_rfs vendor_rfs 4096 2018-03-29 00:04 rfs[/COLOR]
drwxrws--- 2 vendor_mot_tpapi vendor_mot_tpapi 4096 2018-03-29 00:04 security
drwxrwxr-x 2 system system 4096 2018-03-29 00:04 sensors
drwxrwx--- 2 system system 4096 2018-03-29 00:04 time
drwxr-xr-x 2 vendor_mot_tcmd vendor_mot_tcmd 4096 1970-01-01 01:01 wifi
drwxrwxr-x 2 vendor_mot_drm vendor_mot_drm 4096 1970-01-01 01:01 wmdrm
Notice how, android Pie is using vendor suffix prefix.
One fix that was thought was to fix the owners in android Pie ROM itself before flashing Stock ROM, but on rebooting, the owners were changed back to vendor_rfs and vendor_rfs_shared.
Also, if you flash an Oreo ROM after flashing Pie ROM (which broke IMEI), this is the output you get:
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 root root 4096 2018-03-29 00:04 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 root root 4096 2018-03-29 00:04 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
Here are some of the points that can throw some light on the topic:
rachitrawat said:
Hey all,
After spending hours on the IMEI 0 problem, here are my findings:
1. IMEI is stored in nv 550 variable in QCN. However, this variable is write protected. This means all IMEI write programs such as QCOM Write IMEI tool will fail.
2. Interestingly, only IMEI 1 is stored in the nv. IMEI 2 is derived by performing some fixed hex arithmetic on IMEI 1.
3. IMEI also seems encrypted since the nv 550 in QCN never has a correct hex notation of IMEI. For example, Only half of the IMEI is correct.
4. Any attempt to restore the QCN backup of someone else will successfully write all nv variables except nv 550. Means you cannot rewrite your factory IMEI.
5. The above is true even if you hexedit the QCN with your own IMEI. NV 550 is write protected.
6. modemst1 and modemst2 are sort of some baseband cache which are created by radio/bootloader using fsg. fsg seems to be some sort of backup partition for modemst.
7. After downgrading and erasing modemst1-2, these modemst are not recreated successfully by the modem. The nv 550 variable goes missing.
8. My guess is that modem has some checksum mechanism wherein if any discrepancy is found, the modemst cache recreation fails. Not sure.
9. Our IMEI is most likely intact somewhere (not talking about fastboot IMEI). Just not interpreted properly.
10. People who restored their efs after IMEI 0 are essentially restoring working cached modemst1-2. However, if fastboot erase modemst is done, it'll likely result in IMEI 0 again because modem cannot recreate modemst correctly.
Click to expand...
Click to collapse
Thanks alot!!!
My friend was having the same problem, it worked for him??
Edit: Volte is still not working in the device...
@Heeth21,
I am facing this issue after moving to stock. Getting IMEI on "fastboot getvar imei", however unable to restore it. I followed all the instructions you had shared. Any help or further instruction in this regard would be helpful.
Thanks in advance.
checksamir said:
@Heeth21,
I am facing this issue after moving to stock. Getting IMEI on "fastboot getvar imei", however unable to restore it. I followed all the instructions you had shared. Any help or further instruction in this regard would be helpful.
Thanks in advance.
Click to expand...
Click to collapse
Can you post the output of this command in terminal?
Code:
su
ls -l /persist
Also of this command too:
Code:
su
find /persist -type f
If would be beneficial if you format it in code or you might just attach the output in a txt file.
Also can you tell me your baseband version. I think as far as I have observed, those who are getting this IMEI=0 issue, their basebands are ending with "u"
Heeth21 said:
Can you post the output of this command in terminal?
Code:
su
ls -l /persist
Also of this command too:
Code:
su
find /persist -type f
If would be beneficial if you format it in code or you might just attach the output in a txt file.
Also can you tell me your baseband version. I think as far as I have observed, those who are getting this IMEI=0 issue, their basebands are ending with "u"
Click to expand...
Click to collapse
@Heeth21,
THanks for the quick response. Please find the attached output files in text and screenshot for baseband..
checksamir said:
@Heeth21,
THanks for the quick response. Please find the attached output files in text and screenshot for baseband..
Click to expand...
Click to collapse
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Code:
su
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
ls -l /persist
Heeth21 said:
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Code:
su
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
ls -l /persist
Click to expand...
Click to collapse
I had to try it twice: after executing code /persists/rfs, some file or path or folder was missing and it started something which eventually closed before I could take a screenshot. Next time I tried, there was nothing as such. Second screenshot attached for reference.
Really appreciated your quick responses..
Heeth21 said:
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Click to expand...
Click to collapse
Man! Thanks a ton! It worked like a charm... I'm back to stock with full functional VoLTE.. you're a genius.. I owe you a beer..!:good:
Nao deu certo comigo, me ajuda por favor.
Hello, I'm sorry for bad English, I'm Brazilian. I'm translating through google translator.
I am with the same problem of this post, after flashing the stock rom the imei got 0, I did the procedures of this post but it did not work with me, my imei appears correctly with the command (fastboot gevtar imei)
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
the version of the base band is m8952_70030.25.03.62.02a
Is there any procedure I can try? I'll be very grateful.
---------- Post added at 01:53 AM ---------- Previous post was at 01:47 AM ----------
Hello, I'm sorry for bad English, I'm Brazilian. I'm translating through google translator.
I am with the same problem of this post, after flashing the stock rom the imei got 0, I did the procedures of this post but it did not work with me, my imei appears correctly with the command (fastboot gevtar imei)
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
the version of the base band is m8952_70030.25.03.62.02a
I'll try to send prints.
Is there any procedure I can try? I'll be very grateful.
Oliver1995 said:
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
Click to expand...
Click to collapse
The chown command won't do anything as the owners of the partitions are already rfs and rfs_shared.
Reflash stock rom again, and check if you get to see 2951 or 2952 on executing the command "ls -l /persist", and respond.
If you still don't get to see 2951 and 2952, then it seems you have tried doing some changes to your efs/persist partition by either restoring someone else's efs/persist or tried to edit yours.
what should I understand:It means that some custom roms erase imei while going back to stock,it can be recovered but volte cant
Is it right?
BogartX said:
what should I understand:It means that some custom roms erase imei while going back to stock,it can be recovered but volte cant
Is it right?
Click to expand...
Click to collapse
Partially right. Some custom ROMs do some changes with the EFS folder which is responsible for the recreation of IMEI. However, while flashing the Stock ROM, if you do not erase EFS partition, then you will retain your IMEI.
The commands which erase EFS partitions are:
Code:
fastboot erase modemst1
fastboot erase modemst2
The modemst1 and modemst2 are indeed the EFS partition itself. So just skip the above lines while flashing Stock ROM if the custom ROM is doing some changes with the EFS partition, and you will not lose your IMEI.
Volte can be recovered but there is a condition which should be satisfied. The baseband should remain as Indian. If it does, then you will be having Volte working and if it doesn't, you won't be having Volte running.
The only ROMs which are causing this issue on our device currently are Android Pie ROMs. I hope when Official Oreo is released for our device, the new blobs and modem will solve this issue. The developers have already checked if there is something in the ROMs which is causing this issue, and they found no problems at all. Same was the case with Oreo ROMs on Moto G5/Plus and Moto G5s/Plus
Heeth21 said:
The chown command won't do anything as the owners of the partitions are already rfs and rfs_shared.
Reflash stock rom again, and check if you get to see 2951 or 2952 on executing the command "ls -l /persist", and respond.
If you still don't get to see 2951 and 2952, then it seems you have tried doing some changes to your efs/persist partition by either restoring someone else's efs/persist or tried to edit yours.
Click to expand...
Click to collapse
yes actually I tried to restore the persistence of another person by a tutorial on youtube (I do not know if I can post the link here) and also did this tutorial to restore these files modem.img, fsg.img, hw.img: https://forum.xda-developers.com/moto-g4-plus/how-to/solve-moto-g4-plus-one-imei-fp-sensor-t3800410
already tried to reinstall the stock rom but does not appear the numbers 2951 or 2952
Do not have any solution for this?
This helped me alot,Thanks?
In my case both sim are working,with no volte
But jio 4g voice or dialer app with data on is not working
Yes I tried to restore the persist
the problem occurred after installing this rom 9.0 when I came back to the stock the imei was 0: https://forum.xda-developers.com/moto-g4-plus/development/rom-arrowos-9-x-t3859849
Oliver1995 said:
yes actually I tried to restore the persistence of another person by a tutorial on youtube (I do not know if I can post the link here) and also did this tutorial to restore these files modem.img, fsg.img, hw.img: https://forum.xda-developers.com/moto-g4-plus/how-to/solve-moto-g4-plus-one-imei-fp-sensor-t3800410
already tried to reinstall the stock rom but does not appear the numbers 2951 or 2952
Do not have any solution for this?
Click to expand...
Click to collapse
Restore your original persist back. I have seen that tutorial. This issue can only be solved if you are on your own persist as every device has its unique persist.
It doesn't matter if you tried restoring modem, hw, fsg files. Just make sure you are on your own persist.
If you haven't taken a backup of your original unmodified persist, then I'm sorry that is a completely different issue which I don't think there is a soluton to.
Pranavchorge said:
This helped me alot,Thanks
In my case both sim are working,with no volte
But jio 4g voice or dialer app with data on is not working
Click to expand...
Click to collapse
I was hoping if you could atatch your build.prop so that we can compare and check for Volte solution.
You need to grant permissions to Jio4GVoice, enable mobile data (wifi should be off), and dial via Jio4GVoice. Check if this works (it should), and then you will have an ongoing activity notification for Jio4GVoice app