My 12GB SD card has filled up in a day

phil369 · July 25, 2019 at 5:57 PM

Hi, I have a strange problem ... my LibreELEC 7.0.2 running on a Raspberry Pi has filled up the 12GB SD card and the system stopped working. So far so good.

I then connected to the box from a windows machine using the IP and I noticed a 2.5 GB backup file on the storage card.

I moved the backup to another network location, freeing up the much needed space and all seemed good.

Now, a day later my SD card is full again but there is no backup file. So I am a bit at a loss what could have taken up the space in a matter of a few hours.

Looking at the LibreELEC SD card from my windows PC I cannot find any sizable data chunks that clog the system.

I assume I really need to read the card from a Linux machine to be able to see what's on it.

So I tried to SSH into the box using PuTTY but this failed (couldn't agree a host key algorithm). SSH is enabled through the LibreELEC config interface.

Now, here are my questions ...

(a) what else can I do to read the contents of my SD card to identify what is clogging it. I do have Raspbian running on a VM but again I am unable to connect to the SD using SSH. Error No matching host key type found.

(b) way back in time I have installed Retrogames and I suspect this might have eaten up a lot of storage space; I have already un-installed the add-on but I am not sure if there is more to remove that may reside outside of LibreELEC.

(c) is there an easy way to read from within LibreELEC what add-on's take up most space?

Anyway, your help would be greatly appreciated.

Thanks

librero · July 25, 2019 at 9:26 PM

You could enable SMB access to peek at some of the sd contents as a windows share, but not all will be available by default. Or could try to mount an image of the LibreELEC sd from the raspbian vm. But you should first try to solve the ssh access issue that probably is the fastest way to find the space hog and any future issue.

Once you get ssh access you can use the du command to list the size of each subdirectory.

Code

# du

or sorted by size:

Code

# du | sort -n | tail -50

Did you look if some debug options are enabled? By default kodi writes to /storage/.kodi/temp/kodi.log and that file could grow very large.

Myself have changed /storage/.kodi/temp to a symlink to /tmp because already killed a couple of sd cards with every addon and their uncle writting every few to the logfile in flash. The drawback is that in case of an (unlikely) crash the log will be gone, but always can revert the change later if needed.

phil369 · July 25, 2019 at 10:24 PM

Thank you for your response. Greatly appreciated.

Debugging is turned off and the event log contains just few MB. Does not seem to be the issue.

I agree, SSH would help; I have tried everything. Perhaps the problem is with my network router; difficult to say.

Anyway, I have ordered a larger SD card. Once I have the old one cloned I'll mount it to the Raspbian VM to check what the problem is.

And thanks for sending the command - hope to get it working

phil369 · July 25, 2019 at 10:55 PM

Having looked into my SSH issue ... I have found a note that SSH will only work on LibreELEC when turned on during the installation.

Note: SSH has to be enabled at the very first start of LE (installation wizard). Otherwise the SSH service isn't available.

I assume I have missed that boat then. In fact I can turn it on in the LibreELEC configuration tab - it gives me the option - but it seems this is not working.

Any idea how to enable SSH retrospectively in LibreELEC 7.0.2?

phil369 · July 30, 2019 at 10:16 AM

Hi, I managed to get SSH working; no idea what has changed but bingo; I can PuTTY into my LibreELEC.

Now, running the above du command I have identified the folder ./.cache/cores to have 23,811,216. This seems ludicrously high.

Any idea where I need to go to clear this cache?

Thank you!

phil369 · July 30, 2019 at 10:39 AM

Addendum ... my entire card seems to have stored 27,026,616 which is almost double the size of the actual storage card.

Could it perhaps be that the du command reads each byte by a factor of 2 when compared to a WINDOWS machine?

Anyway, here are the two directories in comparison ...

2573920 ./.kodi

23811512 ./.cache

I am ok with the size of Kodi but the cache directory seems to have ballooned out of proportion. is there an easy way to purge it?

**mglae** · July 30, 2019 at 4:18 PM

You can safely delete the core files:

Code

find /storage/.cache/cores/ -type f -delete

But most likely the failtng process continues crashing and generating core files. Keep an eye on the folder and post the output of ls -l /storage/.cache/cores when new files arrive.

LibreELECs du command is using a block size of 512 bytes by default.

phil369 · July 30, 2019 at 4:33 PM

Ok, did some Linux research and found out that "du -h" returns storage size in readable format.

Low and behold my cache\cores folder has a whopping 11.4 GB of data.

So far so good but how do I get it purged?

Any ideas?

phil369 · July 30, 2019 at 4:34 PM

Sorry, just seen your reply ... thank you! I will give it a shot

phil369 · July 30, 2019 at 5:56 PM

Worked like a charm.

I will keep an eye on the cache\cores directory. It now has 138 MB.

Thank you so much for helping out.

Greatly appreciated!

**mglae** · July 30, 2019 at 6:00 PM

Quote from phil369

I will keep an eye on the cache\cores directory. It now has 138 MB.

It should have 0 MB, time to check the content...

phil369 · July 30, 2019 at 7:21 PM

Thank you. Any suggestions how to identify what's writing to cache\cores?

**HiassofT** · July 30, 2019 at 8:19 PM

Check the contents of the /storage/cache/.cores/ directory - the core file names should include the program name.

eg post the output of

Code

ls -l /storage/cache/.cores/ | head -10

When you notice that a new core file had been created it'd also be useful to post your journal - that should contain some additional info what crashed, and maybe why. run the following command and post the output:

Code

journalctl -a | pastebinit

BTW: probably the number one reason for unexplainable crashes on RPis is a bad power supply. The official RPi power supply is known to be good, use that if in doubt.

so long,

Hias

phil369 · July 30, 2019 at 8:43 PM

Sorry, missed what you had said in your earlier post ... ls -l /storage/.cache/cores

I've run the command and it turns out it was spotify ... I deleted the add-on and all looks good.

Happy Days

phil369 · July 30, 2019 at 8:58 PM

Hi Hias, I have run your command ...

ls -l /storage/cache/.cores/ | head -10

... and the return is ... No such file or directory

I think deleting the spotify add-on has resolved my problem.

Thank you all for your great help.

**HiassofT** · July 30, 2019 at 9:10 PM

Sorry, I had a stupid typo in that command - it should have been /storage/.cache/cores, not /storage/cache/.cores - this is what I get for not using copy&paste but typing stuff manually

It looks like you already found the culprit, so I think you should be fine and we won't need more info.

so long,

Hias

phil369 · July 30, 2019 at 10:12 PM

I ran the command ... total 0

All good!

Once more ... thank you!