Hi,
I'm having a weird problem I couldn't find any solution to through google-foo. The concate-power_supply_info.csv if filling up crazy fast (couple MB per minute) on my xt1563 running LineageOs 14.1
I've found a dirty fix for now by removing write and exec permission in parent folder power_supply_logger located in the data partition (removing write permission for the csv itself didn't work, it was reverting back). Anyone experienced similar issue? I've updated Lineage, but the problem persists. Could any problem arise because whatever does this behavior can no longer log in the csv file?
Thanks,
Max
I have exactly the same issue on my MOto G4 Plus running LineageOS 14.1 (20171009-NIGHTLY-athene) with Magisk v14.
The cause of this problem is an internal Motorola debugging tool (batt_health) which collects stats about the battery in that file but it is not supposed to run on production devices. I fixed the problem by removing the binary on moto 8916/8939 family around a month ago. I'll notify athene's maintainers too. In the mean time you can remove system/bin/batt_health.
Related
Yesterday I flashed maniac103's latest CM7 build. Before that I used a couple of Euroskank builds, after several months using Quarx/Eppy 7.1-11-11-11.
Today I have run into the Tombstone problem with no free space on the phone. I moved a couple of apps to SD, but the tombstone immediately fills out any empty space that I can create.
I've searched and the general advice is "delete the tombstone file". Great... except I can't find it? When I browse /data there is nothing there. Is this a permissions issue? Any advice on how to solve the problem and prevent it recurring?
I would be extremely grateful for some help, in simple english and with big pictures and chewable pages ideally...
Ok, I have managed to fix it myself. For any other challenged users, here it is
My problem was that the standard file manager could not see anything in /data
I tried using terminal, but equally that would not allow me to do an ls in /data (view a list of the files in /data).
This came down to a permissions issue.
Earlier on I had deleted Adobe Flash player, which seems to be regarded as the root cause of the tombstone problem. However, I still had no free space (at all - 0.00MB available). After removing Flash player, I uninstalled another app (google+ simply because I don't use it and it's big - 22MB). After uninstalling I had 14MB showing free, which allowed me to install Yaffs explorer. This allowed me to browse with superuser enabled - now I could see the contents of /data, and find the /data/tombstones folder, and find the 905MB file that was causing all of the problem. Deleting that file (tombstone_09 in my case) solved the issue.
Hopefully this will be of help to someone equally as clueless as I.
I just had this exact same issue. Inside the tombstone folder I had tombstone_00, tombstone_01, tombstone_02 and tombstone_03. The first 3 were about 60 Kb each, but the fourth one had 885 Mb. Deleted it and it's back to normal.
This is the first time having this issue, I was using CM 7.1 for almost a year and switched to CM 7.2 last month.
Thank you so much, had this issue, without your post I wouldn't know what to do
Sent from my MB525 using xda premium
Well, the problem has reoccurred, although I now have the tool to fix it.
So my next question...
What causes the problem? How do we stop it happening again?
maniac had been looking into it and told us, that he maybe screwed up on something when he compiled the build that was supposed to fix this issue.
The builds from yesterday on should limit the filesize of tombstones to 1MB correctly.
If it doesn't work, don't blame maniac for this, because it's Adobe's fault. maniac is simply not able to look into code from 3rd party apps.
I also had big tombstones especially when watching flash-videos in the browser. So far they're gone. But you could try to trigger a tombstone that way...
Greetz, Unr3aL67
Sent from my Defy via Tapatalk
I'm not blaming maniac103 - I am extremely appreciative of the work he has done along with that of Quarx, Epsylon and others.
Last night I updated to 16th may build from Maniac, so will keep an eye on things.
I've installed the latest version of Lineage OS on my 2013 nexus 7 (Flo), following all in the instruction including the wipes.
Lineage booted ok, but the set up wizard keep stopping when you click next after setting the language.
I have used he trick to enter the setting , then set up my wifi and google account, but this still does not work.
If seen some comments on the net abut needing 7.1.2 gapps , but there only appears to be version for 7.1 the minor version is not indicated.
The files i have used are
OS
lineage-14.1-20170919-nightly-flo-signed.zip
Gapps
open_gapps-arm-7.1-nano-20170923.zip
Any ideas where to go next ?
Many Thanks
tried a few more things.
If you delete the setupwizard.apk , then you get straight to the home screen, but you cant configure multiple users (probably other functions as well but only seen users)
If you try to use the stock (non nano) gapps there is no space in /system
fast running out of ideas
I also tried the the permissions on the phone and contacts but that did not work
I have a solution but will only work in my situation.
what did work was a completely fresh install of an older version of lineage
and installing micro gapps
The files i used were
lineage-14.1-20170801-nightly-flo-signed.zip
open_gapps-arm-7.1-micro-20170924.zip
the device is currently patching its self back to the latest version.
Not sure where the correct place to report is , and i cant prove its a regression issue
XDAdeveloperHTC said:
I've installed the latest version of Lineage OS on my 2013 nexus 7 (Flo), following all in the instruction including the wipes.
Lineage booted ok, but the set up wizard keep stopping when you click next after setting the language.
I have used he trick to enter the setting , then set up my wifi and google account, but this still does not work.
If seen some comments on the net abut needing 7.1.2 gapps , but there only appears to be version for 7.1 the minor version is not indicated.
The files i have used are
OS
lineage-14.1-20170919-nightly-flo-signed.zip
Gapps
open_gapps-arm-7.1-nano-20170923.zip
Any ideas where to go next ?
Many Thanks
Click to expand...
Click to collapse
I had the same problem, but I detected that this error is a problem with the day and time in my Nexus
I set the day and time manually ( I disabled the automatic date & time on android) and then I return to the wizard setup and I was able to continue with the installation without problem.
The files that I used:
lineage-14.1-20170919-nightly-flo-signed
open_gapps-arm-7.1-micro-20170922
The issues has apparently (not tested) been fixed as a regression issue with Lineage OS. there were also other people with the same issue.
Hello World,
I recently upgraded my Samsung Galaxy Note Pro 12.2 (P900) from CM (Android 5.x) to LineageOS (Android 7.1.2).
The upgrade itself seemed to run fine, but now I get strange write errors with Apps that write into /storage/emulated/0/Android.
I verified that all files and dirs under /data/media/0 have the correct permissions and that they belong to media_rw:media_rw. Yet under /storage/emulated/0/Android there are some files and directories that have plain wrong ownership (root) and even some of those apps whose Android dirs seem to have the correct ownership produce write access errors (despite the owner having write permissions).
I am at my wits end here, since I do not know where the fuse mounted /storage/emulated/0/Android dir gets its permission settings and ownership from - and on top of that the offending dirs don't even show any settings that should prevent them from writing in there.
Similar issue here
Hey, did u ever figure this issue out? I'm having a similar issue on my Galaxy Tab 3 7.0. I'm running lineage 14.1, flashed a few things (gapps, SuperSU update, & bootanimation). I tried clearing and reflashing those with known working versions and even doing a clean install of the whole ROM. No luck tho. Please let me know if you have a solution. Thank you.
XT 1644 (4GB/64GB). Flashed to AOSP 8.1 (5.8), all is basically running well except the torch/flashlight.
From what I've surmised, after the ROM flash, there's a mismatch between the /vendor/build.prop and /system/build prop causing the silly "Android System there's an internal problem with your device. contact your manufacturer for details"
The fingerprint mismatch is odd, as the vendor file has almost the same one as the system, but if I do a "getprop ro.build.fingerprint", I get something else entirely. Trying to figure out where all the fingerprint data is stored
Nothing wrong with the phone, but I've fixed all the other pesky items, and would love to fix this one.
Has anyone tackled this issue?
Hi there
I share your frustration, see here:https://forum.xda-developers.com/android/help/build-prop-android-8-1-issues-editing-t3949531
I have what I think is the same issue. i can basically do anything I want with a device I have, but as soon as I touch the /system/build.prop I get bootloop!!
I'm pretty experienced so its not permissions, bad build.prop, have tested DM-Verity etc
My guess so far is that something is looking up the system and vendor build.props and not liking something for some reason.
Your last post was a year ago, did you manage to resolve this?
I usually change /system/build.prop and have never had an issue up through Android 10. I know this is elementary and no intention to offend anyone - but are you sure the file is being saved with unix-style line endings.
Searched the big G but couldn't find any reference to it.
Anyone knows what is creating fsdump.X.dat files in root of the internal memory?
X is for sequential number. At the moment there are two, 1 then 2.
Different sizes, 3-5MB
Seems to be written on reboot/shutdown but not every time.
Running 15.1 lineage with magisk but it has been happening on stock too.
For reference, it was the f-secure av scanner logs.